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 - registrovany_ava

Stran: 1 ... 9 10 [11] 12
151
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 14. 01. 2020, 22:25:00 »
registrovany_ava:
a i tak je to rychlejší, než Ty filtry, co by se do L2 vejít měly?

Jo, je, taky mě to překvapilo. Možná jsou bídně implementovaný, ale nechtělo se mi zkoušet další implementace  a víc se v tom vrtat, už takhle mi stojí práce..

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

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...

OK, zkusím si tedy vydedukovat, jak rychle to tedy opravdu zpracováváš, tím, že budu ignorovat tvůj první příspěvek o dvou miliardách porovnání za vteřinu, a spočtu si to z těch 2GB/s.

2GB/s ~= 30 000 000 testovaných 64bajtových čísel za vteřinu.

Zkusil jsem si to bez větších chytristik naprogramovat v Rustu.

Slovník 10 000 000 čísel (tím o něco překračuji těch 400MB slovníku, co jsi někde zmiňoval), test kdy je jeden hit na 9999 misses.

Stroj: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, čtyřjádro, tedy dneska skoro kancelářská plečka

Program běží ve čtyřech vláknech.

V opravdu jednoduchoučké verzi dosahuji cca 37 000 000 testů/s

S menší chytristikou se dostanu na 55 000 000 testů/s

Víc jsem nezkoušel, už takhle jsem tím dneska promarnil skoro čtyři hodiny (to se mi nemělo stát, že se objevil takovýhle zajímavý problém)

Jsou to zajímavá čísla, nebo ne? Kolik to teda dělá tobě?


psalo se tu o ruznych algoritmech, co's pouzil ty?
slovnik je v RAM?

HashSet :-) Zkoušel jsem i dvě implementace Cuckoo filteru, co tu zmiňoval Linuxák, ale vycházelo to pomaleji, ta Rustovská HashSet je asi dost optimalizovaná. Slovník je samozřejmě v RAM, ale jen jednou, nikoliv pro každý proces extra jak to má OP, je to vícevláknová aplikace.

Drobnou chytristiku si zatím nechám pro sebe, ale je to vcelku banalita a stejně to výkon nezvyšuje nějak kulervoucím způsobem (asi o 30%).

Ještě omluva. Ve skutečnosti je lepší verze jen asi 38 000 000 testů/s, nikoliv 55 000 000 testů/s. Měl jsem příliš malou testovací sadu (10 000 čísel, pro každé vlákno samozřejmě jiná), kterou jsem recykloval dokola, a nějaký čas se šetřil tím, že byla celá v nějaké L? cache, což samozřejmě v reálu nebude. Zvýšil jsem testovací sadu na 1 000 000 čísel, a výkon spadl na čísla uvedená výše.

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

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...

OK, zkusím si tedy vydedukovat, jak rychle to tedy opravdu zpracováváš, tím, že budu ignorovat tvůj první příspěvek o dvou miliardách porovnání za vteřinu, a spočtu si to z těch 2GB/s.

2GB/s ~= 30 000 000 testovaných 64bajtových čísel za vteřinu.

Zkusil jsem si to bez větších chytristik naprogramovat v Rustu.

Slovník 10 000 000 čísel (tím o něco překračuji těch 400MB slovníku, co jsi někde zmiňoval), test kdy je jeden hit na 9999 misses.

Stroj: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, čtyřjádro, tedy dneska skoro kancelářská plečka

Program běží ve čtyřech vláknech.

V opravdu jednoduchoučké verzi dosahuji cca 37 000 000 testů/s

S menší chytristikou se dostanu na 55 000 000 testů/s

Víc jsem nezkoušel, už takhle jsem tím dneska promarnil skoro čtyři hodiny (to se mi nemělo stát, že se objevil takovýhle zajímavý problém)

Jsou to zajímavá čísla, nebo ne? Kolik to teda dělá tobě?

154
Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2
« kdy: 14. 01. 2020, 10:34:47 »
řeším takový zapeklitý problém, potřebuji extrémně rychle kontrolovat, jestli určité číslo (64 bajtů) není ve slovníku.
Aktuálně stíhám asi dvě miliardy porovnání za vteřinu, ale potřebuji víc, ideálně 10x víc...

Nějak mi neštymujou čísla, ale možná mi něco nedochází:
Chápu správně, že "porovnáním" nazýváš test, zda číslo je nebo není ve slovníku? Tedy aktuálně zpracováváš 2 mld čísel za vteřinu?
Tedy taháš 2 gigaporovnání za vteřinu * 64 bajtů = 128 GB dat za vteřinu.

Jak to dokážeš protáhnout RAMkou? A už vůbec nerozumím, jak to ukládáš na disk?

155
Může být pokus o snížení google rankingu té původní stránky. Když vytvoříte duplikát, který google oindexuje dřív než tu původní stránku, sníží se její ranking.

Hmm, zajímavé, to jsem nevěděl. Ale nezdá se mi, že by to byl případ konkrétně těchto stránek - nevypadají, že by duplikovaly nějakou konkrétní původní stránku. Weby "Komínová klapka elektrická"? "Kempingový vozík skládací"? To se mi nezdá.

156
Odkladiště / Co je to za (automaticky generované) stránky?
« kdy: 12. 01. 2020, 11:44:10 »
Nevíte náhodou někdo, kde se berou tyhle stránky? Párkrát jsem na ně náhodou narazil..

https://spika-audit.ru/
http://aquaraki.ru/

Přijde, mi, že je to automaticky generované z různých českých webů, ale - kdo a proč? Nemáte náhodou někdo tucha?

157
Kup si tuhle knížku: https://knihy.heureka.cz/kompletni-navod-k-vytvoreni-ekozahrady-a-rodoveho-statku-jaroslav-svoboda_2/#

a vyprdni se na trávníky a techniku, udělej si okolo baráku radši nějakou pěknou přírodu.

158
Vývoj / Re:Návrh frontend/backend model-view-controller
« kdy: 10. 12. 2019, 18:20:33 »
Já dělám něco podobného, měřicí aplikaci co sbírá data z různých snímačů, něco nad nimi počítá, ukládá je na disk, celé se to v realtime někde ukazuje, měření se dá spustit s nějakými parametry a ukončit.

Aplikace je rozdělená na dvě nezávislé části jako klient/server, na GUI(klient) a něco co interně nazýváme "jádro"(server). Jádro se stará o samotné spouštění/ukončování měření, vyčítání zpracování ukládání dat.

GUI a jádro spolu komunikují výhradně po TCP zprávami zabalenými do Protocol buffers (dnes bych asi použil FlatBuffers). Konkrétní podoba zpráv je na tom skoro to nejdůležitější, vlastně ti určuje celou architekturu aplikace. Při návrhu zpráv se držíme zhruba těchto zásad:

 - Veškerá komunikace je Request(GUI) - Response(jádro)
 - GUI je možné kdykoliv ukončit a později znovu spustit, případně je dokonce možné mít připojených víc GUI najednou, aniž by to nějak ovlivnilo běh jádra. Když se GUI pustí později, dovede od jádra vyčíst stav a ukázat příslušné ovládaci a zobrazovací prvky.
 - jádro a GUI spolu nemohou komunikovat nijak jinak, tj. GUI má např. zakázané hrabat do uložených datových nebo konfiguračních souborů. Tím je mj. možné mít obojí puštěné na různých počítačích.

 V praxi je implementován request "Jádro, v jakém jsi stavu", to odpoví něco jako "připraven měřit, spouštím měření, měřím, ukončuji měření, ..". GUI se na stav periodicky ptá, protože se kdykoliv může přihodit, že nějaká externí událost (selhání měření, jiný klient) stav změní.

 Dále je implementován request "Jádro, pošli (poslední) odměřená data", který dává smysl jen ve stavu "měří se".

 Dále jsou implementovány povely jako "spusť měření, ukonči měření" atp. Důležité je, že OK odpověď od jádra neznamená "OK, spustil jsem měření", ale "OK, přijal jsem povel ke spuštění měření". GUI nesmí po přijetí kladné odpovědi na spuštění měření předpokládat, že měření skutečně běží a třeba změnit obrazovku, to dělá pouze v reakci na request "Jádro, v jakém jsi stavu".

Je toho samozřejmě mnohem víc, ale tohle je ten důležitý základ.


Tenhle přístup se nám dost vyplatil, během let jsme dokonce postupně úplně přepsali GUI (Scala -> C#) i jádro (C++ -> Rust), a nové GUI nám funguje se starým jádrem a naopak, to bylo dost praktické. Striktní oddělení a protokol jasně definují zodpovědnosti.

V principu by, abych se obloukem vrátil k původní otázce, klidně bylo možné udělat GUI klienta jako webovou aplikaci. Jestli máte prostor pro experimentování, určitě zauvažujte nad použitím jazyka Elm.

159
Vývoj / Re:objektové úložisko...
« kdy: 10. 12. 2019, 17:53:43 »
No, řekl bych, že klíčové rozhodnutí bude:

Mají data povahu stromu (jsou hierarchická)? Jestli jo, bude ti stačit nějaká dokumentová databáze (Mongo atp), jestli jde o obecný graf (jsou tam cykly, článek obsahuje seznam komentářů a ty zas říkají, v jakém článku jsou), potřebuješ něco sofistikovanějšího. Doporučil bych se držet hierarchických dat, pokud je to možné.

Teď budu možná mít blbě terminologii, ale objektová databáze umožňuje ukládat objekty ve smyslu OOP, tj "data + kód" v databázi. Tak to alespoň dělá GemStone. To je něco ještě o úroveň složitějšího než co jsi tu popisoval, představ si třeba, že Virtual Machine nějaké běžící Java aplikace zároveň vykonává kód z více klientů najednou, a zároveň se persistuje na disk, když se vypne zapne počítač, je možné ji obnovit v tom stavu, v jakém byla před vypnutím.

Ale to je bohužel spíš zajímavost ze světa Smalltalku/GemStone, nevím jestli se to dnes někde jinde v praxi používá. Úvod je třeba tady: http://www.laputan.org/pub/sag/gem.PDF

160
/dev/null / Re:Těžké OOP problémy
« kdy: 08. 11. 2019, 09:13:02 »
"All problems in computer science can be solved by another level of indirection ...except for the problem of too many layers of indirection."

161
Vývoj / Re:Rust v ČR
« kdy: 07. 11. 2019, 16:48:34 »
Já dělám v Rustu asi poslední rok a půl, ne-GUI část drážního měřicího a vyhodnocovacího SW v malé firmě. Když jsem nastupoval, řekl jsem, že to budu dělat buď v Rustu nebo vůbec (už jsme se znali předtím, takže jsem si to mohl dovolit), a rozhodně nelituju. Předtím se o to párkrát pokoušeli různí C++kaři a vždycky to bylo nestabilní, zabugovaný a ošklivě napsaný (pokud v C++ nedělá opravdu špičkový programátor, řekl bych že to tak dopadá poměrně často), teď to docela funguje.

162
A ještě možná jeden dotaz - stojí za to vynalézat kolo? Nic z např.

http://kibosh.org/
https://thegeekpage.com/17-best-free-karaoke-software-for-your-pc/

nevyhovuje?

163
Přál bych si, abych mohl naskočit vždy nový nebo předchozí CELÝ odstavec.

No tak si z toho XML udělej jednotlivé odstavce, a na stisk klávesy vyměňuj html stránku s odstavcem? Z popisu fakt není moc jasný jak to má vypadat a v čem je problém, vágní novotvary jako "strukturální pohyb" vcelku nic nevysvětlují..

164
Nechápu jak otázka souvisí s Wordem nebo s PDF. Nechceš si z toho textu v XML prostě udělat HTML a zobrazit to?

165
Hardware / Re:Pomoc s výběrem audio sestavy
« kdy: 22. 10. 2019, 17:15:43 »
Kdyz poridis zesilovac s optickym vstupem, tak staci levna USB zvukovka - prevodnik do optiky SPDIF. Staci opravdu velmi levna, prevadi to jen digital na digital, neni co zkazit. Opticky kabel je plastovy a nevede ani zadne ruchy po zemneni.

Mel jsem to takhle zapojene z pocitace na zasilovac Onkyo NR-509 a fungovalo to fajn. Zesik bych koupil novy a bedny z bazaru. Ale je to asi jedno.

Souhlas, připojení USB zvukovky místo integrované byl ze zvukového hlediska naprosto zásadní krok, přitom to nestálo skoro nic. Koupil jsem https://www.muziker.cz/behringer-xenyx-302-usb , je to malá krabička co mám na stole vedle monitoru, jako bonus mám díky tomu možnost mít připojená sluchátka i bedny zároveň a měnit jim hlasitost nezávisle na sobě, kvalitní mikrofonní vstup, a kdybych chtěl tak si k tomu ještě připojím kytaru. Napájí se to přímo z USB, což je super. Mám k tomu připojenou malou věž JVC z druhé ruky jako zesilovač a rádio, a k tomu starší bazarové větší teslácké bedny (ARS 830), není to super zázrak, ale na slušné ozvučení obýváku to stačí, hudba i filmy se na tom poslouchají příjemně, vypadají pěkně, a celé to dohromady stálo pár tisíc.

Stran: 1 ... 9 10 [11] 12