Byla vydána nová verze 8.7.0 správce sbírky fotografií digiKam (Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení (NEWS). Nejnovější digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.
Před 30 lety, k 1. 7. 1995, byl v ČR liberalizován Internet - tehdejší Eurotel přišel o svou exkluzivitu a mohli začít vznikat první komerční poskytovatelé přístupu k Internetu [𝕏].
Byla vydána (𝕏) nová verze 7.4 open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Balíček s příkazem sudo byl vydán ve verzi 1.9.17p1. Řešeny jsou zranitelnosti CVE-2025-32462 (lokální eskalace práv prostřednictvím volby host) a CVE-2025-32463 (lokální eskalace práv prostřednictvím volby chroot).
Do služeb Seznam.cz se lze nově přihlásit pomocí služby MojeID [𝕏].
Bezpečnostní výzkumníci zveřejnili informace o osmi zranitelnostech, které postihují více než 700 modelů tiskáren, skenerů a štítkovačů značky Brother. Bezpečnostní upozornění vydali také další výrobci jako Fujifilm, Ricoh, Konica Minolta a Toshiba. Nejzávažnější zranitelnost CVE-2024-51978 umožňuje útočníkovi vzdáleně a bez přihlášení získat administrátorská oprávnění prostřednictvím výchozího hesla, které lze odvodit ze
… více »Společnost Oracle vlastní ochrannou známku JAVASCRIPT. Komunita kolem programovacího jazyka JavaScript zastoupena společností Deno Land vede právní bitvu za její osvobození, viz petice a otevřený dopis na javascript.tm. Do 7. srpna se k nim má vyjádřit Oracle (USPTO TTAB).
Byl představen samostatný rádiový modul Raspberry Pi Radio Module 2 s Wi-Fi a Bluetooth.
Certifikační autorita Let’s Encrypt ukončila k 4. červnu zasílání e-mailových oznámení o vypršení platnosti certifikátů. Pokud e-maily potřebujete, Let’s Encrypt doporučuje některou z monitorovacích služeb.
Přemýšlíte, jak začít prázdniny? Už v úterý 1. července se bude konat Virtuální Bastlírna, tedy online setkání bastlířů, techniků, vědců i akademiků, kde se ve volné diskuzi probírají novinky ze světa techniky, ale i jiných zajímavých témat.
Za poslední měsíc jsme byli svědky plamenů několika raket. Zatímco malá raketa od Hondy se úspěšně vznesla a opět přistála, raketa od SpaceX se rozhodla letět všemi směry najednou. Díkybohu méně … více »
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:
