Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Aha pardon, ja si neuvědomil na co se vlastně ptáš. Ty čtyři instance, které jsem zmínil to jsou 4 současně spuštěné procesy lišící se jen písmenkem které na začátaku vypisují. Prostě
time ./p1 & time ./p2 & time ./p3 & time ./p4
(nechtělo se mi hrát s va_args )
Teorie je taková, že by měl GCD inteligentně zasáhnout a pro každý proces povolit jen 2 thready ale neudělá to a povolí pro každý 8 threadů- Kdyby ty procesy více komunikovaly s pamětí tak by si navzájem přepisovaly TLB a obsah cache. Tohle určitě není optimální řešení...
Ok, takto som to aj pochopil, ale je-lepší-si-bejt-jistej-než-potom-litovat
Podle mě to je fér. Jak chcete ošetřit třeba to, že na začátku spuštění úlohy jsou využité sice všechny jádra jiným procesem, který se ale za chvilku uklidní. Takto se sice vytvoří hodně vláken, které může OS spustit každé po sobě, takže v nejhorším případě by to mělo trvat jen o trochu dýl, než v případě jedno vlákna (o čas potřebný na synchronizaci / spuštění úloh).
Jediná možnost jak využít pouze dostupný potenciál je nějaká komunikace s OS (něco takového existuje zatím jen pro Windows 7).
Přesně to Apple ve svých materiálech (nejen těch marketingových) slibuje - GCD má mít přehled o stavu front v celosystémovém měřítku a přidělovat prostředky na základě momentálního vytížení a znalosti všech front. Když spustím 8 instancí té aplikace tak se dostanu na load 64. Epic fail actually.
Jste si jist, ze to skutecne vytvorilo 32 threadu? Vidite to v process manageru nebo to jen odhadujete z toho, ze se Vam spustilo 32 uloh pred prvnim ukoncenim?
Bude se to chovat stejne, kdyz globalni (konkurentni) frontu vymenite za vlastni serializovanou?
Jsem, Mac OS ochotne praskne kolik ma proces threadu navic při 4 procesech load spolehlivě vyleze až na 32 a při 8 procesech na 64.
Když vyměním frontu za serializovanou tak se spustí jediný thread.
OK. O to mi slo. Ze samotneho vystupu programu to totiz bez znalosti implementace globalni (konkurentni) fronty urcit nelze.
Cili to znamena, ze GCD optimalizuje nikoliv pro system, nybrz pro proces. Otazkou ale je, zda je to spatne ci ne -- priklad:
Procak se 4 jadry.
V systemu bezi 8 procesu, ktere aktivne vyuzivaji asynchronni GCD.
i) V pripade optimalizace pro system dle Vasi predstavy: GCD vytvori (az) 4 vlakna, na nichz se bude tech 8 procesu nejakym zpusobem stridat.
ii) V pripade optimalizace pro proces: GCD vytvori az 4 vlakna pro kazdy proces (dle aktualniho vyuzivani async dispatche kazdym procesem), ktere jsou dedikovany pro dany proces. Celkove v systemu v jeden cas az 32 vlaken specialne pro GCD.
ad i) Dovedu si predstavit, zvlaste tehdy, kdy exekuce jednoho tasku je casove netrivialni zalezitosti, ze nektere aplikace by naopak mohly ztratit na responsivite.
ad ii) Muzou existovat pripady, kdy bude v jednu dobu v systemu pomerne znacne mnozstvi vlaken specialne jen pro GCD, ktere budou vsechny aktivni. Scheduler se z toho pak mozna zblazni a responsivita aplikaci pujde zrejme take ke dnu. Otazkou je, zda je pocet GCD vlaken pro proces dynamicky menitelny ci nikoliv, tj. zda maji vzdy staticky thread pool nebo jeho kapacitu v runtimu prizpusobuji.
Pocitam, ze vysvetleni bude asi takove:
1) Bud je to jiz finalni verze implementace GCD presne podle predstav Apple vyvojaru. A pak bych jim veril, ze maji jednotlive varianty zmerene skrz naskrz a vysledkem je ta nejlepsi.
2) Nebo jde o prvni, neuplnou implementaci GCD, ktera jeste muze v dalsich (sub)releasech Mac OS X doznat zmen.
Ha, nasel jsem na applovskym mailing listu pomerne rozsahlou diskusi na prakticky stejne tema. Jeste jsem se ji neprokousal, takze zatim bez komentare jen odkaz:
lists.apple.com/archives/PerfOptimization-dev/2009/Sep/msg00003.html
Aha, pak je ale otázka, jestli je to vůbec možné. Podle mě není problém 8 vláken na proces, který něco počítá. Pokud má OS mnoho běžících procesů, tak ty vlákna zavolá sekvenčně, a výsledek bude trochu horší, než optimalizovaný pro jedno vlánko (ale asi né o moc horší).
V knihovně Fog jsem dělal multivláknové vykreslování, celkem jsem s tím experimentoval (nastavoval jsem u vláken i affinity a tak), ale dospěl jsem k závěru, že je lepší to nechat na OS. Pokud je OS zatížený, tak si ty vlákna zavolá postupně a je z toho prakticky jednovláknové vykreslování. Pokud má volné prostředky, tak to pustí na všechny jádra a výsledný čas je lepší.
Zjistil jsem, že pro náročnější úlohy (momentálně je to rasterizer) je největší problém memory management a L1/L2/L3 cache. Například u některých benchmarků na noťasu mi vychází, že při použití více vláken na jednodádru je vykreslení rychlejší, než při použití jen jednoho vlákna (hlavního). Vysvětlení je takové, že jednotlivé vlákna sice byly spuštěné postupně (sekvenčně), ale jejich práce se vešla do cache procesoru, takže výsledný čas byl třeba o 40% lepší (i přes minimální overhead způsobený synchronizací).
Troufám si dokonce tvrdit, že všechny SW grafické knihovny (je to můj obor:) ), co jsem viděl, jsou navržené s ohledem na dnešní procesory špatně, a teď nemluvím jen o cairu nebo GDI+, ale zapadá sem přes veškeré optimalizace i Fog a mnoho dalších knihoven / rasterizerů, které vykreslují věci postupně (bez analýzy). Možná se i někdy dopracuju k ideálnímu řešení.
Zjistil jsem, že pro náročnější úlohy (momentálně je to rasterizer) je největší problém memory management a L1/L2/L3 cache.ve svem dusledku tady tyto veci nema moc cenu resit... protoze kazdy procesor si to resi po svem... je rozdil, jak se chova k pameti vicejadrovy notebookovy procesor typu core duo a jak se chova viceprocesorovy stroj s xeony... a to nemluvim o tom, ze uplne jinak se chovaji opterony. a to se pohybujeme jenom v ramci jedne architektury...
Například u některých benchmarků na noťasu mi vychází, že při použití více vláken na jednodádru je vykreslení rychlejší, než při použití jen jednoho vlákna (hlavního).docela casto podobne situace nastavaji pokud je potreba delsi dobu cekat na nejake I/O.
V mém případě se jedná o čistý benchmark bez IO atd. Ten memory management jsem zmínil proto, protože u některých úloh hodně záleží na velikosti cache (a v grafické knihovně je celkem silný předpoklad, že data se do cache nevejdou), takže i celkem triviální přepis může znamenat výkonnostní rozdíl v desítkách procent.
Ještě bych upřesnil, že používám architekturu x86/x64. Ostatní architektury pro mě v současnosti nejsou zajímavé.
Tiskni
Sdílej: