Příspěvky

1

Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2

« kdy: 16. 01. 2020, 01:43:18 »

Máš v zásadě dvě možnosti. Jedna už padla někde na začátku - seřadit čísla i databázi a zvýšit tak šanci na cache-hit. Nemusí být nutně řazeno lexikograficky, může být podle hash apod - takže řazení může být konstantní operace (resp zařazení - v podstatě radix sort).

Druhá možnost, je klasická hash tabulka, ale trochu chytřeji orientovaná. Hash nesmí být per entry, ale musí být součástí indexu a měl by být taky dostatečně velký. Část hash (nebo případně agregovaný přes shift + xor + mask) se použije jako index do indexovací tabulky, najde se seznam teoretických záznamů v indexu, ale ještě u těch pointerů je uložený kompletnější hash, který eliminuje false hit. Až když větší hash odpovídá, jde se teprve na skutečnou entry, která může obsahovat zbytek hash (i index může obsahovat třeba jen 4-6 byte hash kvůli minimalizaci paměti) a samozřejmě kompletní data pro klíč a hodnotu. Použil jsem podobné řešení kdysi na persistentní mapovanou DB (takže o to horší, že data vlastně nebyly ani v RAM) a ten krok s umístěním hash do indexu zvedl performance o řády (klíčem bylo mít dost RAM aspoň na udržení indexu). Tady bude pořád limit cache a paměťová náročnost je samozřejmě daná počtem záznamů v databází, nikoli počtem look-ups.

2

Sítě / Re:Výběr routeru

« kdy: 19. 10. 2019, 23:14:11 »

Asi bych měl přejmenovat téma, ale zajímavostí je, že WL-500W je asi relativně v pořádku, dokonce i kondenzátory vypadají dobře. Předtím, než jsem začal měnit nastavení, tak většina zařízení jela celkem v pohodě. S vyjímkou Toshiba laptop, s Intel Wireless AC-3160. Trocha hledání a problém vyřešen:

Kód: [Vybrat]

options iwlwifi 11n_disable=4 bt_coex_active=0 swcrypto=1 power_save=0
Nejpodstatnější je asi ten 11n_disable=4 (disable RX aggregation, ještě fungovala 1 (full), naopak 8 s malým efektem). Rázem je z toho 7Mb/s. Vypadá to jako častý problém Intel AC-3160, na druhé straně to může být i v kombinaci s router, kdy v době vypuštění na trh bylo 802.11n ještě pořád draft...

3

Sítě / Re:Výběr routeru

« kdy: 18. 10. 2019, 00:48:09 »

Kondenzátory jsem nekontroloval, zdroj mi už ale chcípnul dvakrát. Při posledním jsem koupil snad 18W místo původního 12W (asi) a od té doby dalších 6 let funguje. Ale aktuální stabilita Wifi je jeden z problémů, takže případnou opravu stejně nezvažuju...

V každém případě díky všem za tipy!

4

Sítě / Výběr routeru

« kdy: 17. 10. 2019, 00:24:00 »

Můj stařičký Asus WL-500W s 32MB RAM se začíná chovat čím dál podivněji (Wifi připojené, ale občasně tragicky nestabilní i v rámci lokálního spojení na web settings routeru), tak zvažuju náhradu.

Uvítal bych zkušenosti, co je aktuálně použitelné z hlediska hardwarového i softwarového. Z hardwarového samozřejmě stabilita, rychlost není podstatná, ta je primárně limitovaná přístupem zvenku (50Mb/s a stejně výjimečně využiju víc než 10-20%). Externí připojení je na modem přes ethernet.

Software je předpokládám větší oříšek - ideálně aspoň aktuální verzi bez známých děr (a velkých bot typu zapsané heslo ve zdrojáku). Pravidelné bezpečnostní updaty by byly hezké, ale v nejhorším případě jsem schopen hlavní díry ochránit firewallem (vnitřní uživatelé jsou relativně spolehliví). Předpokládám použití původního firmware, s instalací alternativ se mi nechce ztrácet čas. Tedy, obecně minimální údržba, když bude firmware vyžadovat upgrade, nějaké TFTP či USB či upload přes web je samozřejmě ok.

NAS a jiné devicy neřeším, zajímá mě čistě síťový router, všechno ostatní doma komunikuje mezi sebou přímo (tedy přes síť toho routeru, opět traffic minimální (tiskárna apod), takže extra performance ani zde netřeba).

S minimalistickými požadavky pochopitelně koukám i na cenu, ideálně v rámci 500-2000 CZK, vyšší hranice v případě zřetelných výhod (když bude mít potenciál vydržet 10 let jako můj předchozí WL-500W, tak se vyšší cena rozprostře).

Letmo jsem viděl reviews na hlavní značky, TP-Link vypadá často na mizernou stabilitu, NetGear hardwarově ok, o updatech těžko říct.

Díky za náměty!

5

Vývoj / Re:GitHub: fork vs. vlastní branch

« kdy: 05. 06. 2019, 23:34:17 »

Fork se na github běžně používá k vlastní větvi vývoje a následnému vytvoření pull request. V zásadě je fork obyčejný clone do vlastního účtu.

Výše uvedené je samozřejmě možné, git nijak nerozlišuje, odkud branch pochází - zda jde o lokální branch nebo remote branch. Pokud budou repositáře a branch sdílenou historii, tak se dá libovolně merge-ovat tam a zpátky. Samozřejmě, čím víc budou repositáře diverge-ovat, tím bude víc práce s konflikty. V případě jednoduchých bugfixes se dá předpokládat spíš minimum. Viz například: https://help.github.com/en/articles/merging-an-upstream-repository-into-your-fork , konkrétně remote merge:

Kód: [Vybrat]

git pull remote-repo-URL BRANCH_NAME
Udělá merge do aktuálního lokálního branch. Může být případně zcela nový, aby se stáhla čistá historie z remote repositáře. A poté až třeba merge-ovat lokálně.

6

Hardware / Re:Spotřeba energie stále běžícího notebooku

« kdy: 02. 03. 2019, 06:39:43 »

Kdysi jsem měřil. Core2Duo ULV 14" cca 12W, s přidanou pamětí +4GB později stouplo na 18W (ale to mohlo být tím, že narostlo výrazně teplo a pravidelně běžel větrák). V zatížení (2 jádra) šel na cca 60W.

Teď Core i7 U 12", cca 10W. V zatížení (4 jádra) šel někde na 55W.

Vypnutá obrazovka měla u obou zanedbatelný vliv (1W, tedy na hranici přesnosti měření).

Router (WL-500W, 2009) žral myslím 11W, externí HDD přidal dalších 2-3W.

10W kdysi stálo 1Kč/den. Novější paměti můžou být efektivnější, performance řada CPU může sežrat pro změnu víc.

7

Vývoj / Re:Editace textu pomocí XPath v SVG

« kdy: 25. 01. 2019, 23:14:37 »

Druhá možnost je porovnávat QName přímo ve výrazu, ale pak nemůžete použít zkrácený zápis: //*[@id="TEXT1_ID"]/*[name() = 'tspan']/text(). Tím výrazem *[name() = 'tspan'] řeknete, že hledáte všechny elementy, které splňují podmínky v hranatých závorkách, tedy že jejich plné jméno (včetně prefixu) je tspan. Protože tspan je v defaultním jmenném prostoru, nemá žádný prefix.

To bude fungovat pouze za předpokladu, že svg je default namespace. Pokud chcu porovnávat jenom element name (bez namespace), je třeba použít local-name() . Pokud chcu porovnávat celé element name, je nejlepší si namespace v XPath zaregistrovat. Tohle je mix, který bude nejspíš dlouho fungovat, až se jednoho dne na jiných, ale přesto stejných datech, rozbije.

8

Vývoj / Re:Otázka pro javisty.

« kdy: 08. 01. 2019, 17:48:45 »

Stačí porovnat Math.floor(value) == value . Nemá-li nic za desetinnou (binární) tečkou, tak zaokrouhlení vrátí zcela stejné číslo. Porovnání s MIN_VALUE nebo nějakou deltou má smysl u něčeho, co číslo mění (aritmetické, konverze atd.).

Původní kód s cast na long bude fungovat pouze v případě, že původní hodnota je v rozsahu long, tedy +-2^63. double má rozsah +-2^1024.

9

Desktop / Re:Leaking RAM? na Linuxu

« kdy: 27. 12. 2018, 20:34:25 »

oom-killer by měl fungovat konsistentně a zabít "největší" proces. Důkladnější popis včetně různých nastavení viz například zde: https://unix.stackexchange.com/questions/153585/how-does-the-oom-killer-decide-which-process-to-kill-first

Typicky to dneska sežere web browser (nebo několik oken web browserů), ne nutně vinou browseru, ale spíš chybou leaku ve webovém kódu. S novou architekturou rozdělení do různých procesů je hezké, že oom-killer sestřelí jenom jedno okno, na druhé straně to jedno špatné okno nemusí být v paměti dostatečně velké, aby přebilo ostatní systémové procesy (SQL servery, X server, web server či cokoliv většího na systému běží).

Řešením je nenechat otevřené prasečí stránky (což může být těžké identifikovat), případně nastavit limity na paměť pro stránku / tab (nějaké nastavaní má Chrome, ale do detailu jsem nikdy nešel).

Swap v zásadě nemá smysl nezapínat, pokud je k dispozici dostatek RAM. Jak už někdo napsal, prakticky to problém pouze oddálí a ještě k tomu učiní systém prakticky nepoužitelným, neboť ta špatná aplikace vytlačí ty skutečně důležité části (speciálně viditelné na rotačních discích kvůli zpoždění).

OOM killer lze spustit i manuálně, když dochází k nejhoršímu a systém zatuhává - Alt-SysRq-F (na novějších systémech může být nutné povolit - https://en.wikipedia.org/wiki/Magic_SysRq_key#Configuration ).

10

Hardware / Re:Notebook na mieru

« kdy: 21. 09. 2018, 23:53:08 »

Většina velkých výrobců má konfigurátor. Kromě toho, že to trvá nějakou dobu doručit, tak je to obvykle o dost dražší než pultový kus - běžně 20-40% navíc. Takže většinou má větší smysl vybrat co nejpodobnější kus a doplnit RAM či disk.

11

Vývoj / Re:Proč je čtení ze Socketu blokjící operace?

« kdy: 02. 08. 2018, 04:14:49 »

Problém není v zásadě klasická web aplikace, která je stejně ve výsledku synchronní. Typické použití asynchronního network IO je v IoT, případně v messaging (websocket) aplikacích. Tam se connection drží klidně minuty až hodiny a traffic je přitom minimální.

Vytvářet thread pro něco, co je většinu času mrtvé, je zcela zbytečné. Samotná cena za thread není tak velká, řekl bych, že OS je dokáže povětšinou ignorovat a paměťově je to kernel stack, user stack, skoro prázdný page table entry a nějaká malá struktura v kernelu - tedy řádově pár stránek paměti. Problém je ale context switch - když je třeba něco poslat, je třeba thread probudit, udělat skoro nic a zase uspat. I když jde o stejný proces, tak jde o obnovení registrů, postupné vyčerpání cache, TLB cache atd. Když pošlu broadcast na spoustu klientů, tak skoro nic umoří ... cokoliv.

Pro detaily viz C10k problem, případně benchmark netty vs javascript.

12

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 01. 07. 2018, 05:30:18 »

POSIXový write může vrátit 0 i v případě, že je požadován zápis nenulového počtu bajtů. A znamená to jen, že bylo zapsáno nula bajtů – není to chyba.

On success, the number of bytes written is returned (zero indicates nothing was written).  It is not an error if this number is smaller than the number of bytes requested; this may happen for example because the disk device was filled.  See also NOTES.

On error, -1 is returned, and errno is set appropriately.

Vrácení 0 by měl být výjimečný případ, ale počítá se mezi úspěšné výsledky volání. Nekonečnému cyklu zabrání to, že takový stav by byl jen dočasný, a v některém z příštích cyklů by write mělo něco zapsat nebo skončit chybou.

Zapsání nula bytes chyba je a OS by měl vrátit důvod, proč k tomu došlo. Podobné je to u interrupted by signal - pokud se aspoň jeden byte zapsal, vrací délku zapsaných dat, v opačném případě vrátí chybu EINTR. Návratová hodnota "nic se nepovedlo, ale neřeknu proč" není hodna implementace slušného OS. Jak jsem psal výše, něco takového by vedlo k busy loop a nesmyslnému aplikačnímu kódu. write() může skončit úspěšně i v případě předchozí chyby, proto tam ty chybové kódy jsou, aby se aplikace mohla rozhodnout, co má zkusit znovu a jak (EAGAIN, EINTR, ENOSPC).

Na druhé straně je třeba říct, že dokumentace (citace je z Linux man page, nikoliv POSIX specifikace) by mohla být napsaná jasněji, že jde o speciální případ prázdných dat (které můžou mít u speciálních file descriptors zvláštní význam - například EOF).

13

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 21:44:06 »

0 jako korektní hodnota je nesmysl, protože vždycky se musí něco zapsat.

Je možné, že nadstavba PHP chování mění, ale standardní POSIXový write může vrátit i nulu jako normální hodnotu – zapsat se nic nemusí. Při nedostatku místa OS vrátí -1 a v errno bude ENOSPC.

Při zápisu do souboru se bude OS snažit zapsat vše, ale nemusí se mu to podařit. O to je to horší, že to bude skoro vždy fungovat, ale pak se někdy „nepochopitelně“ zapíše jen část.

POSIXový write() může vrátit 0 v případě, že velikost zapisovaných dat byla 0. Pokud OS nemůže nic zapsat v případě neprázdných argumentů, má vrátit chybu EAGAIN, aby program mohl počkat přes select() (nebo podobnou funkci) na to, až zápis bude možný. Kdyby vracel 0, tak by to skončilo bez kontroly v busy loop.

To, že PHP si překládá chybu na 0, je jiná věc (nejspíš, aby se dalo snadno testovat v podmínce), ale v zásadě to na věci nic nemění - zapisovat prázdné data je stejně nesmysl.

14

Vývoj / Re:Zjištění chyby při neúspěchu fwrite()

« kdy: 30. 06. 2018, 19:05:06 »

fwrite() return values jsou docela zmatené, obojí false a 0 znamenají chybu. false je chyba v parametrech, zatímco 0 je chyba provádění (typicky chyba vrácená OS - out of space apod.). Více detailů první komentář v dokumentaci. 0 jako korektní hodnota je nesmysl, protože vždycky se musí něco zapsat. V případě, že by došlo k blokování a je nastaven NONBLOCK, vrací se chyba EAGAIN. Předpokládám, že v rámci "kompatibility" je dobré ošetřít false a 0 stejně :-)

V tom kódu je třeba zpracovat error_get_last na místě, kde se vyhazuje výjimka, tam se vrátí asi finální chyba. Kromě toho jsou tam k opravě následující:

• loop while writte != 0 místo jednoho if (i když technicky vzato běžné OS zapíšou všechno co jde, pokud jde o normální soubor, jinak je to u pipe, socket apod)/li]
  
  • nevím, jak je to u php s konverzí znakových sad a DOS/UNIX konverzí, soubor musí být v každém případě otevřen jako binary.
  • ... a podobně jako v předchozím - viz poslední argument, který vypíná magic chování, které rovněž může ovlivnit délku zápisu.

15

Vývoj / Re:Unzip v Javě skoro tak rychlý jako 7zip?

« kdy: 09. 06. 2018, 16:48:11 »

Předpokládám, že oba používají Deflater ze standardní Java, který je založený na zlib napsaný v C.

Takže pomalost bude v něčem jiném. Za prvé původní algoritmus vyžaduje random access, v závislost na velikosti souborů a různých cache může být pomalejší. Hlavně bych ale zavíral input stream, možná se Java snaží otvírat víc file handlers než je nutné nebo je tam přebytečná synchronizace:

Kód: [Vybrat]

    try (InputStream entryInput = archive.getInputStream(entry)) {
                Files.copy(entryInput, entryDest);
    }

Jako další možnost do benchmark bych zahrnul ještě novější commons-compress, a multi-thread k tomu. Kdysi jsem tam posílal commit, který eliminoval lockování při paralelním čtení z více threadů (za předpokladu, že jde o standardní FileChannel).