Vlákno názorů k článku PyScript: další technologie umožňující využití Pythonu v prohlížeči od atarist - Tyjo to vypadá líp než Brython. Akorát pokud...
-
WebAssembly právě zrychluje načítání stránek, protože se kompiluje mnohem rychleji než JavaScript (a se zlomkovým množstvím RAM). Koneckonců dnešní webové stránky se loadujou na pomalých počítačích a mobilech dlouho ne kvůli rychlosti internetu, ale kvůli rychlosti CPU. WASM nemůže za to, že ho někteří používají stylem, že k aplikaci přibalí bez přemýšlení, co je z toho potřeba, 10+ MB frameworku a knihoven.
-
Pavel TišnovskýZlatý podporovatelJe to tak. On ten projekt je hodně nový a píšou tam, že se snaží o urychlení. Ale vždycky tam nějaká pauza bude, to se současnou architekturou prohížečů nejde odstranit (IMHO). Taky celý WASM je ještě docela v plenkách :/ (po všech těch letech a "slavném" odpojení JVM bajtkódu je to docela zklamání).
-
Je tedy WASM v běžných prohlížečích skutečně pomalejší než JVM? V případě JVM byl AFAIK spíš problém v problematických appletech, tedy v tom rozhraní (jinak je to z těch VM asi nejdál, řekl bych).
PS: WASM je dneska spíše trošku zklamáním. Už skoro deset let se tvrdí, že to bude další masivně podporovaná platforma, ale tedy nic moc zatím (to je škoda imho).
-
Tak masivně celkem podporovaný je (např. už funguje všude včetně iOS a Android). Akorát je na lidech, jestli technologie na něm postavené budou používat (přímo v assembleru asi nikdo nepíše). A ta pomalost? Není to jen tím, že *některé* technologie postavené na WASM si staticky bez přemýšlení přikompilují tunu standardních knihoven? Zvyklé z desktopů a serverů (kde otočení aplikace trvá minuty - ale pak jede hodiny/dny/měsíce).
-
Pavel TišnovskýZlatý podporovatel
To by bylo zajímavé vyzkoušet (a vlastně i lokálně, jak se RustPython chová v praxi).
Ono je u toho PyScriptu vidět, že trvá hlavně dotažení celého NumPy a Matplotlibu, ale to se není co divit, tam je strašně moc závislostí (což je u NumPy škoda, to by se dalo rozsekat a třeba jen natahovat to, co lidi potřebují, tedy maticové operace, a třeba LAPACK-like věci nedotahovat).
PS: jako není to ideální řešení, ale takto jsme to v IT dopracovali - co nejede v browseru (tedy původně prohlížeči statických dokumentů), se nasazuje blbě a zbytek GUI hodně zkomírá.
-
Když on je ten browser tak pohodlný. I primitivní html form bez JS, co vygeneruje get na py script s parametry, je tak pohodlný. Jen rozeslat URL - tady to je, hotovo. Místo obcházení stanic, instalací pythonů, ještě různé OS verze, kopírování skriptů...
Jo, kdyby to čék uměl, asi by to nějakým nástrojem na centrální správu šlo. Ale ten browser ... sériový port tam je, nějaká podpora USB taky a bude moct všechno běžet v browseru. Prasárna, ale tak pohodlná.
20. 9. 2022, 21:04 editováno autorem komentáře
-
Pavel TišnovskýZlatý podporovatel
jj ja naprosto souhlasim, ovsem stale plati ten povzdech "sem jsme to v IT dopracovali". A to po desitkach let vyvoje programovacich jazyku, virtualnich stroju, spravcu pameti atd. atd.
Proste styl Henryho Forda - jasne muzete si v browseru spoustet appky psane v jazyce, ktery si vyberete ... za predpokladu, ze si vyberete JavaScript.
-
Pavel TišnovskýZlatý podporovatel
Jako jo a je to zvláštní - programátorský instinkt mě říká, že prostě WASM musí být už z principu rychlejší, než interpretace omezeného JS. asm.js se provádí hodně rychle, takže JIT JavaScriptového VM je asi hodně dobrý oproti WASMovskému interpretru/JITu (ale blíž jsem to ještě nezkoumal, trošku se snažím si držet od frontendu odstup :-)
-
Já to trochu zkoumal a ano, ten JIT překladač (přinejmenším JSC a V8) je dobrý, ale rychlý kód z principu generuje jen pro typově stabilní kód. Je to jako v Julii, která je taky dynamicky typovaná, ale pro typově stabilní (nebo dokonce typově ukotvený) kód generuje hodně rychlé binárky (na úrovni C++ a Rustu). Jenže Julia má typové anotace, kdežto v asm.js jde o ošklivé a vesměs nahodilé hacky. Ale princip je stejný, jen typově stabilní kód lze přeložit efektivně.
-
Pavel TišnovskýZlatý podporovatel
jj ty typové triky (x = +x, y = y|0, nějaký kontroly, jestli jsou pole homogenní a další věci, na které jsem zapoměl) jsou určitě zajímavé - na čistě dynamicky typovaný jazyk.
Ale stejně si pořád říkám, že WASM (nebo jiný podobný bajtkód, tedy vlastně hlavně JVM) už tyto operace má předpřipravené, tedy obsahuje "typové" instrukce v bajtkódu. S tudíž by přeskočením této operace měl být rychlejší.
Takže jde spíš o to, že do JITu JS se už nainvestovalo spousta úsilí, kdežto WASM asi velcí hráčí až tak nepotřebují, tak se to moc neřeší (a nebo se převodem do bajtkódu informace ztrácí - což je pravda - takže je JIT trošku ve špatné pozici).
-
Mě se celkem líbí jupyter-lite, jen by to chtělo zapracovat na backend storage (aby si například člověk mohl otevírat notebooky přes WebDAV, S3, whatever). Pak by to byla ideální platforma na sdílení notebooků. Z představy, ze bych provozoval jupyterhub na mě padají mrakoty. Už vidím, jak uživatele bojují o server resources, protože nejsou nejostrejsi tužky v penále a přes pandas sql si nactou do paměti tabulku s bilionem záznamu. Když si odstřelí svůj vlastní browser/PC je mi to vcelku jedno.
-
Tak ono i v pomerne kontrolovanem prostredi korporace, zajistit a zmanagovat resources pro BI oddeleni, kdy analyst neresi, co se stane kdyz naleje do pandas nekolik stovek milionu radku. V tu chvili vsichni ostatni maji tendenci na vas kricet cosi o vasi kvalite a vy jim mate chut rict, uklidte si mezi sebou. A toto plati i v databazich, mel jsem ve sprave server co mel 2TB RAM na SQL server pro BI analytiky a stejne se mezi sebou prali o resources a to jsme je managovali pres resource governor workload groups a stejne to nepomohlo. 20 lidi bylo schopno poslat ten server do kytek. Clovek se muze snazit vest je k optimalizacim jak chce, ale vetsinou bez vysledku, oni optimalizuji jen v okamziku, kdy uz neni zbyti a dotaz jim proste nebezi vubec.
-
imho poznámky k "urychlení":
1. Použití pyodide v pyscriptu je v současné verzi implementována nevhodně, kdy vm pythonu běží ve stejném threadu jako browser a interpretace pythonu, tak blokuje ui.Pyodide přitom má podporu [web worker]
(https://pyodide.org/en/stable/usage/webworker.html), ale pyscript ji na rozdíl od jiných projektů (založených na pyodide) nepoužívá...2, Rychlost načítání cpythonu, modulů etc: (pokud neuvažujeme bloatware dodaný pyscriptem) je pro "čisté" pyodide následující:
At present a first load of Pyodide requires a 6.4 MB download, and the environment initialization takes 4 to 5 seconds. Subsequent page loads are faster since assets are cached in the browser. Both of these indicators can likely be improved,
pyodide roadmap3. Rychlost samotného běhu pythonu ve wasm:
Pyodide is currently around 3x to 5x slower than native Python.
At the same type, C code compiled to WebAssembly typically runs between near native speed and 2x to 2.5x times slower..pyodide roadmap
