Portál AbcLinuxu, 2. května 2025 13:10
Vývojáři Ruffle, tj. open source emulátoru Flash Playeru napsaného v Rustu, vydali zprávu o vývoji za rok 2023. Vylepšena byla kompatibilita. Vyzkoušet lze dema.
Tiskni
Sdílej:
FLEX - ten je ciste OpenSourceVím, že je teď pod Apachem, ale pro běh byl potřeba Flash, ne? Nebo k tomu bylo/je i komplet otevřené běhové prostředí? (nepočítám teď ten Ruffle nebo Gnash) Vždyť se to kompilovalo do .swf a to jsi musel v něčem pouštět (ve Flashi). Koukám, že existuje nějaký FlexJS v betaverzi, ale je otázka, jak dobře to funguje. A určitě to nebylo ve hře, když se tehdy řešila budoucnost Flashe.
„To je jako porovnavat ASM co vygeneruje gcc s ASM co napise clovek“ je tady úplně mimo mísu. (Jinak ten ASM z GCC bude většinou rychlejší, neexistuje moc lidí co by zvládli využít všechny vlastnosti moderní architektury.V tomhle souhlasím. Assembler už dávno není jediná možnost a není to ani jazyk, ve kterém by běžný programátor byl schopný napsat lepší kód, než jaký vygeneruje třeba GCC z Céčka, C++, nebo D, Rust atd. A i u těch nejlepších programátorů, kteří by toho byli schopní, to v naprosté většině není dobrý nápad, protože se to prostě nevyplatí (jejich čas jde jde využít jinak, lépe, a ten zanedbatelný nárůst výkonu za to nestojí). Assembler má dneska smysl leda pro nízkoúrovňovou interakci s HW a extrémně optimalizované věci jako video kodeky nebo šifrování.
Zvlášť když pořád narážím na lidi co se drží představ jako že linked list je rychlejší pro insert a remove prvku z prostředku než ArrayA není snad? Celkem se mi líbí, jak to řeší Java – tam máš rozhraní List (případně obecnější Collection) a můžeš si vybrat mezi různými implementacemi (spojový seznam, ArrayList atd. nebo si napsat vlastní) podle předpokládaného použití (nebo třeba inicializuješ ArrayList s dostatečnou kapacitou, aby se později velikost už nemusela měnit), ale je to schované za tím obecným rozhraním, takže i když zvolíš méně vhodnou implementaci, používá se to pořád stejně (může to být pomalejší, ale většinou je ten rozdíl zanedbatelný, takže i když dáš ArrayList tam, kde měl být LinkedList, není to žádná tragédie – a pokud na tom záleží, tak to později můžeš optimalizovat a pro volající stranu se nic nemění, jen to bude rychlejší).
Ten sdružený typ pro kolekci by mohl být v tomhle teoreticky zajímavý s nějakým chytřejším compilerem, který vybere interní implementaci podle použití.
Proto mám tyhle abstrakce rád. Ono bys novou instanci nemusela vytvářet přes konstruktor, ale přes nějakou továrnu / tovární metodu a ta by vybrala optimální implementaci.
Ale taková úroveň abstrakce by nejspíš motivovala k použití stylem který pořádně nejde optimalizovat žádným směrem.
Asi by to šlo optimalizovat něčím jako GraalVM nebo obecně profilováním za běhu, kdy to chvíli běží nějakým základním způsobem a časem se to překonfiguruje podle toho, jak to používáš.
Zajímavé mi přijde i použití indexů/offsetů místo klasických ukazatelů při vytváření různých struktur. Jsou to vlastně relativní ukazatele a oproti těm globálním to může být menší datový typ a taky to můžeš celé přesunout jinam nebo serializovat a ty relativní ukazatele budou pořád platit.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.