V Lucemburku byly oznámeny výsledky posledního kola výzev na evropské továrny pro umělou inteligenci neboli AI Factories. Mezi úspěšné žadatele patří i Česká republika, potažmo konsorcium šesti partnerů vedené VŠB – Technickou univerzitou Ostrava. V rámci Czech AI Factory (CZAI), jak se česká AI továrna jmenuje, bude pořízen velmi výkonný superpočítač pro AI výpočty a vznikne balíček služeb poskytovaný odborníky konsorcia. Obojí bude sloužit malým a středním podnikům, průmyslu i institucím veřejného a výzkumného sektoru.
Byla vydána (𝕏) zářijová aktualizace aneb nová verze 1.105 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.105 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Ve Firefoxu bude lepší správa profilů (oddělené nastavení domovské stránky, nastavení lišt, instalace rozšíření, uložení hesla, přidání záložky atd.). Nový grafický správce profilů bude postupně zaváděn od 14.října.
Canonical vydal (email) Ubuntu 25.10 Questing Quokka. Přehled novinek v poznámkách k vydání. Jedná se o průběžné vydání s podporou 9 měsíců, tj. do července 2026.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzi 1.5.0.
Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
V cem jsou generovane ty obrazky?Doplnil jsem do repa přímo zdrojáky: code_context.plantuml & frames.planuml.
byly mi známé následující přístupy:Vsechny tri varianty jsou ekvivalentni a navzajem prevoditelne. Hezky to jde videt na prevodu AST<-> stack-based bytecode, coz je trivialni operace. Hlavni rozdil je v tom, jak moc je ktera reprezentace vhodna pro urcity typ transformace/optimalizace nebo analyzy. AST je dobre na optimalizace vyrazu, bytecode pro registrovy virtualni stroj je zase fajn pro optimalizace postavene na toku data a CFG (obzvlast, pokud to mas formou SSA). Stack-based bytecode je takovy kompromis mezi tim, mas tam explicitne vyjadrene rizeni vypoctu (to v tvem pripade asi neresis) a je z nej trivialni zase ziskat AST vyrazu pro dalsi transformace. Registrove virtualni stroje maji jeste tu vyhodu, ze je snazsi jejich konverze do instrukci sady klasickych procesoru. Ale pokud delas preklad (pred provedenim) jeste pres nejaky jazyk nebo jiny bytecode, tato vyhoda pada.
- Interpretace AST
- Interpretace imperativního bajtkódu
- Interpretace stack based bajtkódu
Bajtkód, anglicky bytecode, je od slova byte. Samozřejmě nemusí mít přesně jeden bajt, ostatně moje instrukční sada by se mohla vejít do čtyř bitů. Do budoucna by ale mohlo interpreter zrychlit, kdybych provedl rozvoj všech často používaných instrukcí a převedl je z několika-bajtových parametrizovaných na jedno-bajtovové.Tim moc rychlosti neziskas. Mnohem uzsi hrdlo, ktere to bude brzdit, jsou operace se zasobnikem. Pokud muzu radit, udelej si zasobniky co nejjednodussi. A pokud se mas v planu odchylit od minimalisticke instrukcni sady, pouvazuj nad tim, jak napr. skupinu casto pouzivanych instrukci pracujicich se zasobnikem prevest na jednu (byt slozitejsi) instrukci, ktera se explicitni manipulaci se zasobnikem vyhne.
A pokud se mas v planu odchylit od minimalisticke instrukcni sady, pouvazuj nad tim, jak napr. skupinu casto pouzivanych instrukci pracujicich se zasobnikem prevest na jednu (byt slozitejsi) instrukci, ktera se explicitni manipulaci se zasobnikem vyhne.Jo, nad tímhle uvažuji.
A pokud se mas v planu odchylit od minimalisticke instrukcni sady, pouvazuj nad tim, jak napr. skupinu casto pouzivanych instrukci pracujicich se zasobnikem prevest na jednu (byt slozitejsi) instrukci, ktera se explicitni manipulaci se zasobnikem vyhne.Momentálně mám dvě různé implementace, jak jsem psal. Ta ve výsledku rychlejší by měla být prealokované statické pole, kde se jen updatuje index pointer, akorát že v benchmarku s JITem to momentálně vychází trochu pomaleji. Myslím že to ale chce přidat jen víc hintů ohledně toho co je statické / immutable a tak podobně. Rád bych přidal právě instrukce, které obcházejí práci se zásobníkem a konkrétní věci si berou z tabulky literálů. To by mohlo kód trochu zrychlit, ale vidím to že jen asi tak o 17% max. Udělal jsem si takový jednoduchý benchmark na milion while cyklů, kde tělo je blok a podmínka je blok (tedy obojí je v podstatě lambda). Když jsem dopsal naivní implementaci, tak to trvalo asi dvacet vteřin. Momentálně jsem se po měsíci optimalizací dostal pod jednu vteřinu, s tím že podle cfbolze z #pypy by se mělo jít hravě dostat pod 100ms, pokud správně dodám JITové hinty. Podle callgrindu momentálně nejvíc času žere parent lookup, a to i přesto že už jsem ho zoptimalizoval, přidal cacheování a prohledávání jen změněných částí grafu. Myslím že přepsáním na hierarchickou cache (momentálně cacheuje každý objekt sám za sebe a při lookupu prohledává jen odminule změněný graf (to pozná podle verzí objektů), ideální by bylo, kdyby se spoléhal i na cache v objektech které prohledává, což se teď neděje) se to ještě může zrychlit. Minulý týden jsem zkoušel proof of concept dynamického rekompilátoru, který se snažil ty cache parent lookupů staticky inlinovat, ale nakonec jsem to celé vzal a zahodil, protože to bylo docela komplikované, fallback z nopovaného kódu, kde byly odstraněny PUSH_LITERAL instrukce byl docela komplikovaný a právě ta parent cache se ukázala jako vcelku dobrá sama o sobě. V brzké době o tom vydám článek, všechny ty optimalizace jsem si poznamenával. Chci se teď zaměřit zase spíš na rozvoj funkcionality, když jsem rychlost dostal pod tu jednu vteřinu, což mi přijde pro další rozvoj jako proof of concept že to není úplně marné.
Rekurzi můžeš nahradit nejen zásobníkem, ale i vlákny.Ok, ale jakou to má souvislost?
Pokud máš úlohy, kde dává smysl sestavit vlastní DSL a záleží na výkonu, tak asi nejlepším přístupem je právě překlad do jiného jazyka namísto psaní interpretu. To může být záležitost na pár dní, nikoliv pár roků, a přitom to bude velmi dobře funkční i efektivní.Transkompilátory afaik dávají smysl jen za předpokladu, že děláš funkčně něco hodně podobného tomu podkladovému jazyku. Tedy jak píšeš, DSL. Nebo například jsem tu kdysi psal blog o brythonu, který transkompiluje za běhu python do javascriptu, což jde a má to smysluplnný výkon, protože oba jazyky jsou si alespoň přibližně podobné co do dynamičnosti a brythonu v podstatě stačí používat restriktivní javascript. Obráceně už bys to ale dělal hůř, například transkompilovat javascript do pythonu by asi chtělo pěkný kus hackování a výkon by šel do kytek. To samé se Selfem - jak jsem psal v tom druhém seriálu, kdysi vznikl Smalltalk implementovaný nad Selfem, který běžel rychleji než tehdejší smalltalky. Naopak to lidi taky zkoušeli, ale výkon byl tragický, protože právě řešení parentů musí být z principu dynamické a nemáš ho moc na co namapovat ve většině jazyků. Co je ale killer feature toho graalu, co nikdo jiný afaik nemá, je interop. Tedy tvůj jazyk bude umět pracovat s datovými strukturami a funkcionalitou všech ostatních věcí napsaných v graalu. Tedy pythonem, ruby, C, javascriptem a kopou dalších projektů. A celé to bude mít velmi dobrý výkon. Například jsem viděl benchmark kde javascriptový kód volal generátor v ruby a celé to běželo asi 20x rychleji, než samotné ruby a jen o trochu pomaleji než optimalizované C. A teď se člověk zamyslí, že generátor v ruby je něco úplně jiného v javascriptu a oba dva používají jiné formaty intů, které to vracelo a je jasně vidět ten potenciál. Jaroslav Tulach viděl ty moje články o tinySelfu a vybral si jako semestrální projekt Self, kde killer feature bude že to narozdíl od původního Selfu bude mít k dispozici nejen Selfí stdlib, ale všechno pro python, ruby, javascript, C, .. Přitom tam sice musíš psát interpreter, ale nemusíš jít za implementaci AST. Tedy ti stačí lexer, parser, AST strom s .eval() metodami a jsi hotový.
V brzké době o tom vydám článek, všechny ty optimalizace jsem si poznamenával.Tak jo, tady: tinySelf performance gains 2019/4.
LightWeightDict
mi připomíná SmallVector
/ SmallString
, jestli to dobře chápu, je to stejná strategie...
TwoPointerArray
` mi připadá, že je prostě Ring buffer, jestli to dobře čtu...
Možná by se stejná optimalizace jako ten LightWeightDict / SmallVector / etc. dala použít i pro stack, tj. že bys měl prealokované pole pro prvních N položek a jakékoli další by šly do toho spojáku. Otázka je, jestli by to reálně bylo rychlejší (special casing → více branchování).Můžu na to mrknout.
Možná vůbec nejlepší, co se rychlosti týče, udělat si statistiky nejpoužívanějších sekvencí instrukcí a ty pak optzimalizovat... Ale to se blbě dělá bez reálných programů v tinySelfu.Mno, ideálně chceš aby za tebe tohle řešil nějaký backend, ala ten JIT.
Btw. ten `TwoPointerArray` mi připadá, že je prostě Ring buffer, jestli to dobře čtu...Není to úplně ring buffer, je to jednoduše prealokované pole, kde se při .pop() a .append() posouvají dva indexy zleva a zprava. Princip je podobný, ale není to cirkulární.
Tiskni
Sdílej: