Společnost OpenAI představila GPT-5 (YouTube).
Byla vydána (𝕏) červencová aktualizace aneb nová verze 1.103 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.103 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Americký prezident Donald Trump vyzval nového generálního ředitele firmy na výrobu čipů Intel, aby odstoupil. Prezident to zdůvodnil vazbami nového šéfa Lip-Bu Tana na čínské firmy.
Bylo vydáno Ubuntu 24.04.3 LTS, tj. třetí opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na Discourse.
Byla vydána verze 1.89.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Americká technologická společnost Apple uskuteční v USA další investice ve výši sta miliard dolarů (2,1 bilionu korun). Oznámil to ve středu šéf firmy Tim Cook při setkání v Bílém domě s americkým prezidentem Donaldem Trumpem. Trump zároveň oznámil záměr zavést stoprocentní clo na polovodiče z dovozu.
Zálohovací server Proxmox Backup Server byl vydán v nové stabilní verzi 4.0. Založen je na Debianu 13 Trixie.
Byla vydána nová verze 1.54.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Jan Václav.
Knižní edice správce české národní domény přináší novou knihu zkušeného programátora Pavla Tišnovského s názvem Programovací jazyk Go. Publikace nabízí srozumitelný a prakticky zaměřený pohled na programování v tomto moderním jazyce. Nejedná se však o klasickou učebnici, ale spíše o průvodce pro vývojáře, kteří s Go začínají, nebo pro ty, kdo hledají odpovědi na konkrétní otázky či inspiraci k dalšímu objevování. Tištěná i digitální verze knihy je již nyní k dispozici u většiny knihkupců.
OpenAI zpřístupnila (en) nové nenáročné otevřené jazykové modely gpt-oss (gpt-oss-120b a gpt-oss-20b). Přístupné jsou pod licencí Apache 2.0.
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:
