Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.7.
Wayland byl vydán ve verzi 1.24.0. Jde o menší vydání po více než roce. Více funkcionality bývá přidáváno v průběžných vydáních Wayland Protocols.
Textový editor Geany byl vydán ve verzi 2.1. Jde o udržovací vydání po bezmála dvou letech. Obsahuje drobná vylepšení vyhledávání, aktualizace podpory zvýrazňování syntaxe a dále převážně opravy chyb.
Byly zveřejněny videozáznamy, dostupné také s prezentacemi přímo z programu, a také fotogalerie z open source komunitní konference DevConf.CZ 2025 konané od 12. do 14. června v Brně.
Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
12.12.2019 15:47
Max | skóre: 72
| blog: Max_Devaine
Tohle mělo smysl, když se spoustu času strávilo čekáním na pomalé disky. Nedávno jsem s tím ze zvědavosti trochu experimentoval a vyšlo mi, že při překladu na tmpfs nemá smysl dávat větší počet úloh, než je k dispozici logických CPU.
Konkrétně jsem překládal jádro SLE15-SP2 (což je podobně nové, ale s o dost bohatší konfigurací než defconfig z blogpostu) na Ryzenu 3900X (12 jader, 2 thready na jádro). Od -j24 výš byly rozdíly pod úrovní statistické chyby a i rozdíl mezi -j23 a -j24 už byl menší než jedno procento. Podobně na stroji se staršími Xeony X7560 (4 sloty po 8 jádrech, 2 thready na jádro, tj. 64 logických CPU) se optima dosáhlo někde mezi 60 a 63.
V roce 2009 na osmijádru (2x4 xeon bez HT) to mělo vliv zcela marginální vizSkoda, ze jsi -jN utnul u poctu jader, protoze driv doporucene N byl dvojnasobek jader. Hlavnim duvodem je zcela urcite IO wait, ktery v pripade ram je minimalni, ale i tak by bylo zajimave to videt.Moje zkušenost s tímhle je spíš negativní, zejména u C++ věcí se složitějším kódem, kde je kompilace náročná na paměť. Zvyšování paralelizace nad
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cznproc pak vedlo akorát k tomu, že to žralo brutální množství ramky, ale rychlost lepší nebyla...
-j 32 real 0m57,139s user 20m19,768s sys 2m2,336s -j 64 real 0m49,738s user 31m30,032s sys 3m3,312sgf
Pokud chcete, aby výsledky něco vypovídaly o výkonu procesoru, překlad v tmpfs je nutnost (a i jinak není moc důvodů v tmpfs nepřekládat, pokud máte dost paměti, aby to šlo). Když se podívám na ty vaše výsledky metrikou celkového času CPU (user + sys) děleného dobou překladu (tj. jakési "míry paralelizace"), dostanu v prvním případě 23.5 a ve druhém 41.7, což není úplně moc (ideál by byl 32 a 64). V podstatě to znamená, že 26 resp. 35 procent času procesor na něco čekal.
Pro srovnání, při překladu na tmpfs na 3900X dostanu (i při paměti prozatím běžící s dost neuspokojivým SPD časováním)
real user sys
-----------------------------------------------
-j12 1m3,751s 9m48,272s 1m16,665s 10.4
-j24 0m48,999s 14m4,137s 1m51,504s 19.5
Vezmu-li v úvahu, že ten procesor má dvanáct jader, stál třetinu a má poloviční TDP, je to námět k zamyšlení.
Pro úplnost bych ale ještě dodal, že test buildu s defconfigem není moc šťastně zvolený. Když build zkusím s realističtější distribuční konfigurací, vyjde mi ten poměr s -j12 11.7 a s -j24 22.2, což je o dost lepší.
Nedalo mi to a zkusil jsem ještě osmijádrový 2700X, což by měla být podobná architektura jako 2990WX:
-j8 2m1,050s 13m7,965s 1m40,901s 7.3
-j16 1m28,412s 18m40,589s 2m18,100s 14.2
Oproti 3900X jsou časy přibližně dvakrát pomalejší (podle počtu jader a frekvence by to mělo být 1.54), takže pokrok tam vidět je (kvantitativně asi tak o třetinu).
Teď jsem si ale uvědomil, že při porovnávání výsledků z různých systémů může hrát významnou roli i verze gcc (moje výsledky jsou s gcc 7.4).
Ale frekvence jsou oproti 3970X podle předpokladu nižší (2,9 GHz base oproti 3,7 GHz) a hrubý výpočetní výkon bude cca 35% nad 3970x. Musíš mít tedy naprostou jistotu, že tvůj workload dobře škáluje jinak bude reálný výkon horší než u toho 32jádra.
Tiskni
Sdílej:
