reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - PanVP

Stran: [1] 2 3 ... 7
1
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 19. 01. 2020, 17:06:20 »
Nic, co bych chtěl veřejně prezentovat.

Je v tom prostor pro práci víc lidí, peníze tu jsou skutečně až ten úplně poslední problém.
Nicméně zvýšení výkonu 100x by zřejmě vyžadovalo přepsat to pod OpenCL nebo na FPGA.

Ale obávám se, že jsem to dostal tam, kam to jen šlo.
První implementace celé té blbosti v Pythonu zvládala jednotky operací za vteřinu.
Teď už to není tak špatné, ale silně pochybuji, že to půjde zrychlit 10x bez OpenCL neb FPGA.

Tobě a RDa bych o tom mohl říct víc, ukázat zdrojáky a vysvětlit princip.
Pokud máš rád peníze a nebojíš se OpenCL, dej mi vědět.
Tohle je něco, co se dělá jen (skutečně jen) pro peníze, nic víc za tím není.
Je to jen pro peníze, ale bez vlastní finanční investice (nehrozí ztráta vlastních peněz) si člověk může vydělat tolik, aby za rok už nemusel nikdy pracovat nebo si koupil někde uprostřed města dům a tam si otevřel kavárnu, jen aby byl mezi lidmi.

2
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 18. 01. 2020, 21:18:35 »

Promyslím si to a když tak se ozvu.
Mám s lidmi dost špatné zkušenosti, naprosto obecně, rozhodně se tě nechci dotknout.

Díky ;-)

3
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 18. 01. 2020, 19:22:16 »
AD FPGA: Samozřejmě jsem viděl běžné tutoriály, určitě dokážu rozsvítit ledku, ale naprogramovat v tom obyčejný cyklus for nebo provést nějakou složitější matematickou operaci...mi hlava nebere...

4
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 18. 01. 2020, 18:59:36 »

Samozřejmě máš pravdu, ale pokud bych první z těch testů přepsal na AVX, čistě teoreticky, i když AVX jednotky nejsou zdvojené a není u nich výkonový zisk na HT, měl bych nějaký výkon navíc dostat, protože zbylé části programu nevyužívají AVX.

Výkon toho prohledávání byl horší, inspirovali jste mě k pár krokům, no a po několika drobných úpravách se z toho stalo opravdu něco, co nemá smysl dál řešit. Je to marginální záležitost.

Nástroje typu "CallGrind a KCacheGrind" neznám, podívám se na ně.  Děkuju :-)


Výkon na tom Phi vypadá docela dobře, koukal jsem, že deska stojí 12k a procesory jsou fakticky zadarmo (3k za 64 jader na e-bay). Velmi dobrý tip! Děkuju!

PS: Náhodou nějaký návod "pro blbé", jak proniknout do FPGA?
Přiznám se, že nemám ponětí, jak rychle to může běžet ve srovnání s běžným CPU nebo GPU.
Chápu, že hardware za 50 000 tisíc je schopný běžný procesor naprosto deklasovat.

Ale co třeba takový nějaký board?
https://www.aliexpress.com/item/4000176584679.html



Jak to může být rychlé?
Podobně jako kdybych ten výpočet pustil na highendové VGA kartě?
Pomalejší? Rychlejší?

Pokud bych totiž reorganizoval strukturu a sestavená data odsouval na samostatnou mašinu, mohl bych ušetřit celkem dost výkonu.

Špičkový programátor, který by dokázal přepsat tu knihovnu, by si za rok mohl vydělat tolik, že by do konce života už nemusel chodit do práce, kdyby nechtěl a to myslím naprosto vážně.

5
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 18. 01. 2020, 13:55:16 »
asi je ti jasný

To ano, ale zrychlení o 100% znamená úsporu strojů.
Možná zkusím použít jiný překladač a nastuduju si nějaké optimalizace, které bych pro GCC mohl zapnout na ten první krok.

možná se na ten mejdan s Carmackem a Bernsteinem budeš muset přidat
Vařím dobrý kafe, to ano, kafe bych jim vařit mohl, ale tím to končí.

Každopádně všem díky, znovu se v tom pohrabu a zkusím část těch nápadů tady ve vláknu.
Děkuju :-)

6
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 17. 01. 2020, 21:44:51 »
Hodnoty jsou vteřiny, puštěno na jednom vláknu (celkem běží 15 vláken), balík 1 milionů zpráv, tj. pokud dobře počítám, na tom Ryzen 3700x dám za vteřinu 10 mil. na proces * 15 vláken. Což je pořád významně méně, než 80 milionů na tom čtyřjádrovém 2500Kčku.

A takhle vypadají hodnoty, pokud proces běží na volném jádru (ostatní procesy vypnu nebo nechám běžet jen 7+1 proceů):

https://imgur.com/iP27yPa

Doplněno: Ať jsou výsledky se zátěží vedle sebe:

https://imgur.com/T9ipzsg

7
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 17. 01. 2020, 21:24:24 »
Ahoj,

nenasadil jsem žádný z filtrů, ale rozšířil jsem vstupní délku klíče.
Tj. beru z čísla delší část, což nakonec zcela vyřešilo můj problém.

A jako poděkování, spíš tak pro zajímavost:


Případně odkaz (kdyby se ukazovala reklama): https://imgur.com/T9ipzsg

Ryzen 1700x vs Ryzen 3700x, oba stejná zátěž, stejná deska, stejný chladič, stejné paměti, stejný Bios. Rozdíl je skutečně jen v tom CPU.
(Stejné výsledky to ukazuje i na jiných strojích, není to unikát.)

První údaj: Získání balíku dat, pouze memcopy.
Naplnění zprávy je její vlastní zpracování. Probíhá v cache, zprávy jsou "malé".
Serializace serializuje zprávu (vytvoří jí ze struktury).
Test 1
Test 2
A nakonec ještě prověření, které má vyloučit, že zpráva už byla použita, to je ten můj test se slovníkem v paměti.

Ty hodnoty jsou dost rozdílné, měřeno pod plnou zátěží (15 vláken), v některých případech je Ryzen 3700x až dvakrát rychlejší. A čím větší zátěž, tím víc se ukazuje rozdíl mezi Ryzen 1700x a 3700x.

Samozřejmě jsem z hodnot nevytvářel žádný graf, hodnoty jsou rozdílné +/- deset procent pro každý test, ale rozdíl 30-50% je vidět v každém testu.

Každopádně mám zase nad čím přemýšlet, testy 1 a 2 dokážu přesunout na grafickou kartu, nebo je upravit a použít AVX.

Naplnění zprávy přepsat nezvládnu, ta knihovna není moje, jako by jí psal o divokém mejdanu Carmack s Bernstainem...

8
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 14. 01. 2020, 23:15:09 »
Tak mám 80 000 000 testů/s, stále bez použití probabilistických filtrů :-)

....já...já...já teď hledám jestli berou u dopravních podniků průvodčí  :-\

9
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 14. 01. 2020, 18:41:28 »
protože procesy nesdílí paměť

Ano, to je pravda, i proto uvažuji o setříděných vstupech.
Nicméně jsem dělal několik vícevláknových aplikací a musím říct, že to není tak snadné, jak to na první pohled vypadá.
Tady mám uptime v řádu měsíců.

ladil(benchmarkoval) jsi nejak ty procesy

Benchmarky mám na porovnání jednotlivých částí aplikace.
Při locknutí procesů na jednotlivá NUMA se objevuje podivné chování, kdy se jádro "zamyslí" a třeba 200msec nic nedělá.
Nepravidelně, nevím proč, prostě stojí. Výkon je měřitelně vyšší, pokud si všech patnáct procesů "plave" z jádra na jádro, proč nevím. Také jsem si původně myslel, že uzamčení procesu na jádro bude znamenat výkonový zisk.
Zajímavé je, že na Intelu se tohle neděje, ale výkon na Intelu je asi o 9% nižší na jádro (i8700), tak mě to netrápí.

10
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 14. 01. 2020, 16:41:38 »
A kdyby to někoho zajímalo, jen tak pro pobavení, pouštím to přes utilitu screen, aby to běželo na pozadí a neskončilo při ukončení SSH session, plus utilita parallel, aby mi běželo 15 úloh na každém fyzickém CPU. (16 zlobí...) To není moc elegantní co? :P Ale funguje to. Psaním vícevláknového serveru jsem se nezatěžoval. :P

Nějaký den omrknu, jestli některé patche, co lezou do jádra, to všechno zase nezpomalily :(
To se děje častěji, než nalezení nevalidního čísla. Budu muset pohledat nějaký aktuální článek, co v jádru všechno vypnout, abych získal pár procent výkonu navíc.  ::)

11
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 14. 01. 2020, 16:24:02 »

Viz:
data se stejně ukládají do pole rychlostí asi 2 GB/s a za hodinu se nezaplní víc než několik 5-7 TB prostoru

To jsou běžné hodnoty na kontroléru (na vstupu), tedy "běžný vstup" je řekněme miliony čísel na vteřinu.
Špičky jsou jinde, navíc je to celé rozložené mezi víc strojů a ověření je jen jednou z úloh zpracování.
Zajímavá by byla možnost i opakování dávek z předchozích dnů. Nicméně, pokud zlepším propustnost celého systému, mohu žádat o víc dat = dostanu víc peněz. A popravdě o to tu jde v první řadě, trochu to zefektivnit nebo se na to podívat říct "líp už to nejde", pak vím, že to musím hnát počtem strojů, které se musí nejen napájet, ale i chladit...

12
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 14. 01. 2020, 01:47:41 »

Díky za nabídku, vážím si jí.
Výhoda Phi je v tom, že na to není potřeba žádný extra kód, ale stačí prosté Cčko.
Nakonec se od toho ustoupilo, protože projekt ještě několik let poběží a Intel s Phi skončil.

https://www.cnews.cz/intel-nahle-zcela-zrusil-vypocetni-karty-xeon-phi-vsechny-zminky-o-nich-zmizely/

Důvod, proč nepoužít FPGA je snadný, jeden programošťoural (já) + hromada hardware, vyjde levněji než to táhnout přes FPGA. Doba opravy +/- desítky minut, nasazení dalšího stroje minuty, v nejhorším objednám v Alza a večer tu budu mít dalších dvacet strojů.

Tím ovšem neříkám, že FPGA se mi nelíbí :-) Osobně bych si na tom někdy něco hrozně rád vyzkoušel, ale asi tam je dost strmá křivka učení, nikdy jsem do toho hlouběji nepronikl a to v jiných (i srovnatelně obtížných) oblastech jsem uspěl...

13
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 13. 01. 2020, 23:59:21 »
Vedel by si poslat ukazkove data? Myslim teda blacklist za jeden den a nejaku "minutu" vstupu?

To by asi nešlo, data nejsou moje.

Ty verze se vyvíjely, původně se ověřovalo pomocí DB, která byla neuvěřitelně pomalá.
(Zase to bylo implementačně jednoduché.)
Pak se přešlo na C# a Python, až pak na čisté C.
Každá nová verze byla řádově rychlejší, C oproti Pythonu 100x ...
B-tree napsaný oproti mé hash tabulce 6x...
Právě protože B-tree podával tak špatné výsledky, jsem trochu skeptický vůči těm filtrům, ale mohu se plést.

14
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 12. 01. 2020, 23:53:50 »

Jo takhle...nezní to špatně!

15
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 12. 01. 2020, 23:25:30 »
spark-u a nabastlit to v tom
Adu ani Spark jsem už dlouho neviděl.

tak imho spark ti to zvladne za polovicny
Spark vs čisté C? a Spark že bude o polovinu rychlejší ???
Spark je interpretovaný jazyk ne? ::)

Už někdo mi říkal, ať to zkusím přepsat v Go nebo Rustu, ale Spark  ???

Stran: [1] 2 3 ... 7

reklama