Včera večer měl na YouTube premiéru dokumentární film Python: The Documentary | An origin story.
Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Ř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í.
ve flamu na rootu jsem nasel krasnou vecicku o niz jsem ani netusil, ze ji gcc umi -- optimalizace podle vysledku profileru. pri beznych optimalizacich nema tradicni prekladac (nemlouvim ted o JIT kompilaci) sanci zjistit, jak ktere casti kodu budou volany casto, z jakych mist a podobne... a proste jen hada a tipuje. nicmene, pomoci vcelku zastrcenych direktiv prekladace -fprofile-generate
a -fprofile-use
jde situace velice hezky zmenit a hodne pozitivnim smerem.
-fprofile-generate
(aby se mohly generovat profilacni informace)-fprofile-use
(aby se vyuzily optimalizace)CFLAGS+=${PROFILE_ARGS} ... optimal: make clean make PROFILE_ARGS=-fprofile-generate make test0 PROFILE_ARGS=-fprofile-generate make clean make PROFILE_ARGS=-fprofile-use rm *.gcda rm *.gcno
vysledky jsou opravdu "vau!":
jako test jsem pouzil svuj interpretr schemu s temito dalsimi nastavenimi:
-Wall -Winline -O3 -std=c99 -pedantic -finline-limit=100000 --param large-function-growth=100000
Tiskni
Sdílej:
btw. chudaci uzivatele gentoo ... s takovou by meli kompilovat cely system na dvakratJá bych to pro těch pár procent klidně udělal
-fprofile-generate
, pak se s ním zkompiluje kernel s -fprofile-generate
, pak se bude kernel chvíli používat, pak se kernel zkompiluje pomocí -fprofile-use
a v tu chvíli budeš mít v GCC nasbíraný vhodný profil, aby sis GCC mohl zkompilovat s -fprofile-use
. "btw. chudaci uzivatele gentoo ... s takovou by meli kompilovat cely system na dvakrat ;-] "U OpenOffice.org se to ale vyplatí, ne?
btw. chudaci uzivatele gentoo ... s takovou by meli kompilovat cely system na dvakrat ;-]Spíše natřikrát. V prvním kroku se zdrojáky prostě spustí/přeloží pomocí tcc (aby člověk nemusel čekat na doběh kompilace). Potom se na pozadí spustí kompilace s -fprofile-generate a nakonec třetí kompilace tentokrát už s -fprofile-use. Ještě by to chtělo nějakého démona, který pozná špatně profilovanou binárku a na pozadí ji rekompiluje
problem jak z kvantove fyzikyOno už to, že se nějaký profiling dělá, značně mění podmínky. Zvlášť u programů, kde je něco časově kritického.
ten kod na kterem jsem to testoval, je rucne optimalizovany snad na maximum (agresivni inlining, optimalizace na predavani argumentu pres resgistry,....) ...Ale to není ručně optimalizované vůbec. Zkus kouknout, co žere nejvíc času a přepsat to efektivněji, i kdyby se měl kód zesložitit. Pak se začnou dít zázraky a stovky procent budou jen lítat.
Ale to není ručně optimalizované vůbec.a ze si jste tim tak jisty! ;-] jenom nekolik clovekodni jsem stravil pri hledani vhodne struktury pro zasobnik -- a ze jich bylo a ze jsou mezi nema rozdily ;-] btw. vsechno zere vicemene jedna velka smycka, ktera prehazuje hodnoty z jednoho zasobniku na druhy, protoze tam nic jineho neni ;-] (viz moje predchozi posty) ta hranice, kdy se jedna jeste o optimalizaci a kdy o jiny algoritmus, je opravdu hodne nezretelna.... brano ad absurdum, tak nejlepsi optimalizaci by to bylo prepsat z interpretru na prekladac... ;-] ale to uz by nebylo ono, protoze s tim delam dalsi divociny ;-]
"make -j2"
, to same minesota mapserver a najdou se dalsi.... ale co je dneska idealni?!
$ more x.c test(a) { if (a & 1) return fun_1(a); return fun_2(a); }Moc se ale nevyznám ve výstupu. Evidentně LPBX1 je 32 byte, které fungují jako čtyři 64-bitové countery, které počítají průchody čtyřmi základními bloky oné funkce. LC0 je taky jasné, jméno modulu. trojka a čtverka by mohly být čísla řádků... Ostatní se mi ale jeví jako binární šum bez špetky logiky..
.local .LPBX1 .comm .LPBX1,32,32 .section .rodata .LC0: .string "x.gcda" .data .align 4 .LC1: .long 3 .long 1555776990 .long 4 .align 32 .type .LPBX0, @object .size .LPBX0, 52 .LPBX0: .long 875573616 .long 0 .long 1901502412 .long .LC0 .long 1 .long .LC1 .long 1 .long 4 .long .LPBX1 .long __gcov_merge_add .zero 12 .text .type _GLOBAL__I_0_test, @function _GLOBAL__I_0_test: pushl %ebp movl %esp, %ebp subl $8, %esp movl $.LPBX0, (%esp) call __gcov_init leave ret .size _GLOBAL__I_0_test, .-_GLOBAL__I_0_test .section .ctors,"aw",@progbits .align 4 .long _GLOBAL__I_0_test .align 4 .long _GLOBAL__I_0_test