Slo-Tech - Konzorcij za svetovni splet W3C (World Wide Web Consortium) je izdal končno specifikacijo standarda WebAssembly, ki je s tem postal uradni spletni standard. S tem se pridružuje HTML-ju, CSS-ju in JavaScriptu kot četrti programski jezik, ki ga (lahko) brskalniki brez dodatnih vtičnikov poganjajo. Označujejo ga kot varen, prenosljiv, nizkonivojski jezik za učinkovito izvajanje in kompakten zapis kode, ki je namenjen brskalnikom.
Gre za arhitekturo z virtualnim naborom ukazov, ki na spletu omogoča poganjanje zahtevnih aplikacij in ki jo lahko uporabljamo tudi drugod. Implementacij bo več, tako od brskalnikov pa vse do samostojnih sistemov. V WebAssemblyju lahko pričakujemo tudi video in avdio kodeke, grafiko, 3D igre, kriptografijo itd. WebAssembly omogoča, da brskalniki poganjajo binarno kodo, kar je hitro.
V spletu se obnaša kot navidezni stroj, v katerem lahko spletne strani nativno poganjajo prevedeno kodo. Tako naj bi bil WebAssembly precej hitrejši od JavaScripta, obljubljajo. Skupina WebAssembly Community Group je WebAssembly prvikrat predstavila leta 2015, ko še ni bil namenjen kot alternativa, temveč kot dopolnitev ali nadgradnja JavaScripta. Uporabljali bi ga tam, kjer je učinkovitost ključnega pomena. Kmalu je imel podporo Appla, Googla, Microsofta in Mozille, kar je bilo ključno. Leta 2017 smo imeli že prve delujoče beta verzije v brskalnikih. Hkrati lahko WebAssembly menjamo s kodo C, C++, C#, Go, Rust ali celo F#.
In v praksi? Google Earth je primer spletne strani, ki teče v WebAssemblyju. Rezultat je hitrejši in varnejši, trdijo ustvarjalci.
WASM je uporaben v toliko, da ni treba uporabljati gnoja od javascripta. Tisto o hitrosti in varnosti so bolj marketinške pravljice, ker mora še vedno vse teči v peskovniku, kar je po definiciji počasi.
WASM je uporaben v toliko, da ni treba uporabljati gnoja od javascripta. Tisto o hitrosti in varnosti so bolj marketinške pravljice, ker mora še vedno vse teči v peskovniku, kar je po definiciji počasi.
WASM je uporaben v toliko, da ni treba uporabljati gnoja od javascripta. Tisto o hitrosti in varnosti so bolj marketinške pravljice, ker mora še vedno vse teči v peskovniku, kar je po definiciji počasi.
Ti pa ne razumeš ravno kako peskovniki in tudi moderne virtualne mašine delujejo. Vsi API klici ki rabijo kaj od sistema res grejo skozi dodatni layer zaradi varnosti, kar se pa tiče procesorske kode se pa ta kar lepo direktno izvaja na CPUju. Naprimer noben normalen človek več ne poganja strežnikov barabone ker je performance hit modernih virtualk pod 3%.
WASM Photoshop in .exe photoshop bosta čisto enakovredna(morda kaka manjša odstopanja, definitivno manj kot 10%), WASM je revolucija za web aplikacije. Pa ne zgolj zaradi boljših performanc kot javaskript. Še bolj pomembno kot performance je to, da je WASM binarni zapis in lahko uporabiš poljubni jezik, torej je zadeva future-proof.
WASM je uporaben v toliko, da ni treba uporabljati gnoja od javascripta. Tisto o hitrosti in varnosti so bolj marketinške pravljice, ker mora še vedno vse teči v peskovniku, kar je po definiciji počasi.
Ko smo našo C++ knjižnico prevedli v WASM, je bilo izvajanje počasnejše samo ranga 10-15%. Šlo se je za knjižnico, ki renderira vektorske dokumente in veliko časa preživi v kodi občutljivi na hitrost izvajanja. Uporablja tudi SIMD ukaze. Vseeno je bil rezultat zelo hiter - hitrejši od kakih Pythonov ali JavaScripta direktno.
Zaostajal je edino Edge, ki je kodo izvajal izrazito počasi... ampak to so zdaj "rešili" s preklopom na Chromeov pogon.
Tako da ne vem s česa si pobral to tvojo neumnost o počasnosti :)
Hmm, Java je tudi "binarna koda", to je malo nerodno zapisano.
Ja, to samo po sebi ne pove prav dosti. Gre za "byte code" oz. "machine code", prvi je namenjen izvajanju v virtualnem stroju, drugi pa direktno na procesorju. WASM specifikacija določa byte code, kar pomeni, da je teoretično lahko enako hiter, kot Java (kar je v resnici več kot dovolj za to, da za več magnitud prehiti interpretirane jezike, tudi takrat, kadar JIT prevajalniki in podobne tehnike optimizirajo večino reči, ki jih je mogoče optimizirati).
A ni microsoft že skočil na ta vlak s portanjem majhnega dela svojega .net core frameworka na WASM? Mislim da se imenuje Blazor? Če se ne motim je bolj kot hitrost problem velikost. Zadnjič, ko sem gledal jim je uspelo spraviti velikost na 1.8 MB nekje. Najprej se ti prenese cel njihov "Blazor" framework na clienta potem pa njihov C# "teče v brskalniku".
Hmm, Java je tudi "binarna koda", to je malo nerodno zapisano.
Ja, to samo po sebi ne pove prav dosti. Gre za "byte code" oz. "machine code", prvi je namenjen izvajanju v virtualnem stroju, drugi pa direktno na procesorju. WASM specifikacija določa byte code, kar pomeni, da je teoretično lahko enako hiter, kot Java (kar je v resnici več kot dovolj za to, da za več magnitud prehiti interpretirane jezike, tudi takrat, kadar JIT prevajalniki in podobne tehnike optimizirajo večino reči, ki jih je mogoče optimizirati).
Ne no, JITa pa res ne more prehiteti, ker ima intimno znanje o programu in zato so lahko v c/c++ napisani programski jeziki hitrejsi od c/c++ (sem samo cinicen, zadnje case razni salabajzerji radi dokazujejo tocno to, na __asm in "char c[] = "\x01\xb8\x00\x00\xbb\x00\x00\x3f\x00\x00\x90\xcd\x00"; int main(int argc, char argv) { int (f)(); func = (int ()()) c; (int)(*f)(); return 0; }' (buffer izmisljen, da se ne bo kdo matral prevesti :D) pozabljajo ker so prevec zagledani sami vase, da bi vedeli kaj to sploh je.
Sicer pa, cimprej upam, da v webasm resijo GC/dom tezave, da se tega smradu od javaskripta znebimo cimprej, ta agonija je trajala 10 let predolgo. Js (java.*) delenda est.
Prinasa pa cisto nove tezave glede filtriranja trackanja, sicer se zaenkrat se da trampolinat klice (sem se malo igral), samo odpre pa cisto novi set problemov. Na ublocker (ipd) kar pozabite. Spet bojo proxyi v modi...
A ni microsoft že skočil na ta vlak s portanjem majhnega dela svojega .net core frameworka na WASM? Mislim da se imenuje Blazor? Če se ne motim je bolj kot hitrost problem velikost. Zadnjič, ko sem gledal jim je uspelo spraviti velikost na 1.8 MB nekje. Najprej se ti prenese cel njihov "Blazor" framework na clienta potem pa njihov C# "teče v brskalniku".
Seveda je problem velikost, ce morajo sabo vlacit ves smrad od runtima (enako java), verjetno bojo vsi to s CDNji resili, samo bo bolj sranje. Scasoma bojo rodili kaj bolj optimalnega. Pac HLL so zarili previsoko, zdaj se jim pa vrti od visine, hkrati pa od njihovih uporabnikov vecina blodi pod oblaki in na zemlji sploh nikoli se niso stali. So se ze rodili v oblakih in nikoli pogledali nizje.
Aja pa btw, da se ne bi javnost prevec pritozevala, ustvarjalci trdijo (zavajajo, lazejo), da webasm ni js killer. Pa poglejmo: - vecja hitrost izvajanja - teoreticno manjsi size (ce ne bo zraven ogromnega runtima kaksne jave ipd.) - binarna koda, optimizirana compile time in neberljiva - in najlepse za konec, poljuben programski jezik, ne transpilan, ne z obupno sintakso in skrajno nedorecljivim vedenjem, spisan v enakem jeziku, z enakimi knjiznicami kot back end (nodejs my ass). Sicer bojo javascriptasi trmasti kot vedno in bojO nasli spet nov workaround pomanjkljivostim jezika, ampak po mojem se bojo v nekaj letih vsi python ali pa go ucili.
fajn bo ko boš lahko clientside programiral v c# namesto v js. ampak kako daleč smo do tam? js debugger, ki dela v vseh brskalnikih bo težko nadomestiti s takim, ki dela z vsemi različnimi jeziki. pa še kaj podobnega najbrž. v resnici so vsi jeziki tako podobni, da zame ni dost razlike, v katerem programiram.
WASM je uporaben v toliko, da ni treba uporabljati gnoja od javascripta. Tisto o hitrosti in varnosti so bolj marketinške pravljice, ker mora še vedno vse teči v peskovniku, kar je po definiciji počasi.
Ko smo našo C++ knjižnico prevedli v WASM, je bilo izvajanje počasnejše samo ranga 10-15%. Šlo se je za knjižnico, ki renderira vektorske dokumente in veliko časa preživi v kodi občutljivi na hitrost izvajanja. Uporablja tudi SIMD ukaze.
15% prepočasi in razlog več, da hočeš to raje nekje remotely laufati native namesto v browserju. Ko bo nova verzija knjižnice 2x hitrejša, ker bo uporabljala Intel-specific klice ali pa CUDO pa v jok in na drevo? Ne me narobe razumet - WASM je super. Samo performanse in web sta dva različna svetova, ker je stack blazen in latence do remote podatkov velike, ker je vmes http.
fajn bo ko boš lahko clientside programiral v c# namesto v js. ampak kako daleč smo do tam? js debugger, ki dela v vseh brskalnikih bo težko nadomestiti s takim, ki dela z vsemi različnimi jeziki. pa še kaj podobnega najbrž. v resnici so vsi jeziki tako podobni, da zame ni dost razlike, v katerem programiram.
No da te vidim. C? (memory leaki, buffer overflowi, memory fragmentation,... malo zmanjka, ko ni GCja in varne memorije, a?) Saj ne da rabis ampak se deloma strijam, jeziki danes so ena in isto sranje, s tem, da so ena in isto sranje tudi developerji raznih overdizajniranih lazanj, s filo iz spagetov in drobnimi ravioli za dekoracijo, ki jih imenujejo frameworki, knjiznice, kjer je interface bolj kompleksen od taska, ki so mu namenjeni.
WASM je uporaben v toliko, da ni treba uporabljati gnoja od javascripta. Tisto o hitrosti in varnosti so bolj marketinške pravljice, ker mora še vedno vse teči v peskovniku, kar je po definiciji počasi.
Ko smo našo C++ knjižnico prevedli v WASM, je bilo izvajanje počasnejše samo ranga 10-15%. Šlo se je za knjižnico, ki renderira vektorske dokumente in veliko časa preživi v kodi občutljivi na hitrost izvajanja. Uporablja tudi SIMD ukaze.
15% prepočasi in razlog več, da hočeš to raje nekje remotely laufati native namesto v browserju. Ko bo nova verzija knjižnice 2x hitrejša, ker bo uporabljala Intel-specific klice ali pa CUDO pa v jok in na drevo? Ne me narobe razumet - WASM je super. Samo performanse in web sta dva različna svetova, ker je stack blazen in latence do remote podatkov velike, ker je vmes http.
Absolutno, web je nekaj najhujsega kar se je ITju zgodilo, cista prevlada idiokracije nad tehniko, z enim zamahom smo pristali 20 let v preteklosti. Ampak je lahko pa vsak salabajzer programer. To pa, baje, tudi nekaj steje. Baje.
Naj vas ne bega asm v webasm, gre samo za klice na vm. Nic od tega se ne bo direktno na cpuju izvajalo, se manj na gpu.
WASM je revolucija za web aplikacije. Pa ne zgolj zaradi boljših performanc kot javaskript. Še bolj pomembno kot performance je to, da je WASM binarni zapis in lahko uporabiš poljubni jezik, torej je zadeva future-proof.
Res je. Revolucija bo za web aplikacije. Še več bloata v javascript, pardon WASM kodi. Oziroma za Adobe v zgornjem primeru, ki bo zdaj pa res subscription-only, ker ga praktično ne boš mogel skrekat.
Bloat je bloat, ne glede na to če je v web ali desktop aplikaciji, tak da ne razumem kaj hočeš povedati. Cloud procesiranje, ki ga počasi hoče uvajati Adobe pa nima nič z WASM, ker point WASM je lokalna koda, ne cloud koda. Cloud procesiranje lahko kličeš tako iz desktop kot web aplikacije (to dejansko zadnje verzije desktop Photoshop počnejo).
WASM prinese skorajšno tehnično enakovrednost web aplikacij z desktop. Zanimajo nas pa itak v večini primerov velikosti redi ne zadnji procenti razlike. Pa še te se bodo nižali z optimizacijo in razlika bo še bolj zanemarljiva kot je že v trenutni verziji.
WASM ima potencial da postane popularen binarni zapis za publishanje ne samo web ampak tudi klasičnih aplikacij ne glede na OS. Čas je da umaknemo stran od OS specifičnih aplikacij ki dajejo preveliko moč uveljavljenim ekosistemom.
c#, ne c. največja prednost bo, da bo c# backend in frontend. pa boš lahko uporabil isto funkcijo za prvo generiranje htmlja in potem za ajax klice, da zgeneriraš html po neki akciji uporabnika. zdaj je nerodno, da se uporablja ajax klic tudi tam, kjer ne bi smeli biti in ti upočasnjujejo stran, ko ob prvem obisku ne naložijo cele strani ampak prideš na stran potem pa še na tisti nadležni ajax klic čakaš kot budala.
c#, ne c. največja prednost bo, da bo c# backend in frontend. pa boš lahko uporabil isto funkcijo za prvo generiranje htmlja in potem za ajax klice, da zgeneriraš html po neki akciji uporabnika. zdaj je nerodno, da se uporablja ajax klic tudi tam, kjer ne bi smeli biti in ti upočasnjujejo stran, ko ob prvem obisku ne naložijo cele strani ampak prideš na stran potem pa še na tisti nadležni ajax klic čakaš kot budala.
Ne, nisi razumel, gabijo so mi salabajzerji, ki nimajo blage veze kaj sploh pocnejo, nekaj skopirajo iz neta, pa so ze polni znanja, kako so vsi jeziki enaki. Za profite firm, za katere delate, ste in so razvrednotili 20 let razvoja, ki namesto, da bi napredoval, je nazadoval v idiokracijo - v toz da je vsak idiot programer. C#, java, js... Nobene razlike. Sicer je od vsega tega sranja C# se najboljsi, po drugi strani pa zaostalo sranje, ker se je svet poneumil. Pa brez zamere, nic posebnega, samo salabajzerji pred tabo so bili bolj sposobni od tebe in salabajzerji za tabo bojo manj sposobni od tebe. Pot nazdol. Pa veselo zalivanje rastlin z Getoraidom, jaz k sreci tega ne bom docakal.
ni res, programerski svet kar lepo in pospešeno napreduje. programerji so brez občutka za ljudi, niso pa idioti, so kar inteligentni in v redu ljudje v resnici. programerjev ni preveč ampak jih je premalo. če niso vsi einsteni pa bog pomagaj. ti mi zveniš kot zagrenjen brezposlen programer al kva te muči, ne vem točno.
Kar povej v cem napreduje? V stran metanju resourcov, izdelavi programskih jezikov na nivoju logopedicnih pripomockov, (kjer se clovek ubije na optimizaciji delovanja gc in "frameworkih" namesto na dejanskem resevanju problemov) za zapolnitev luknje v programerskih kadrih? Vceraj snezilka, danes programer. Za nekaj "nakucat" bo ze dober. Inteligenten pa niti ne rabi biti prevec, raje malo manj, za copy/pastat iz neta bo dober. Software bomo pa smisali tako, da ne bo prekompleksen za kader, ki ga imamo. Prepakiravanju starih tehnologij, ze resenih problemov, v nove in nove obleke, ki pa zrejo vec resourcov in delujejo slabse? Izbiri tehnolpgij glede na modo? O tem govoris?
Aja pa ne se prevec sekirat, imam disconnect z razumevanjem kvalitete, svet bi "lazje", jaz bi pa "bolje", pa se ne ujamemo, ker je vse vedno slabse in samo navidezno lazje.
WASM je uporaben v toliko, da ni treba uporabljati gnoja od javascripta. Tisto o hitrosti in varnosti so bolj marketinške pravljice, ker mora še vedno vse teči v peskovniku, kar je po definiciji počasi.
Ko smo našo C++ knjižnico prevedli v WASM, je bilo izvajanje počasnejše samo ranga 10-15%. Šlo se je za knjižnico, ki renderira vektorske dokumente in veliko časa preživi v kodi občutljivi na hitrost izvajanja. Uporablja tudi SIMD ukaze. Vseeno je bil rezultat zelo hiter - hitrejši od kakih Pythonov ali JavaScripta direktno.
Zaostajal je edino Edge, ki je kodo izvajal izrazito počasi... ampak to so zdaj "rešili" s preklopom na Chromeov pogon.
Tako da ne vem s česa si pobral to tvojo neumnost o počasnosti :)
Se pravi eno ali dve "procesorski generaciji" (današnji, k ni tako velikih preskokov) pa je izvajanje identično hitro, kot če je stvar spisana v C/C++.
Ti pa ne razumeš ravno kako peskovniki in tudi moderne virtualne mašine delujejo. Vsi API klici ki rabijo kaj od sistema res grejo skozi dodatni layer zaradi varnosti, kar se pa tiče procesorske kode se pa ta kar lepo direktno izvaja na CPUju. Naprimer noben normalen človek več ne poganja strežnikov barabone ker je performance hit modernih virtualk pod 3%.
Huh? V kolikor zaupaš virtualkam, potem so kontejnerji s cgroups dovolj in sploh nimaš performance hita (ni dodatnega layerja?!). V kolikor ne, si ga pa naje*al, ker ti že izklopljen HT (spectre anyone?) odnese več kot tvoje 3%.
c#, ne c. največja prednost bo, da bo c# backend in frontend. pa boš lahko uporabil isto funkcijo za prvo generiranje htmlja in potem za ajax klice, da zgeneriraš html...
Um... saj veš, da mora biti wasm statično preveden? Po tvoje bo treba še celoten c# framework spraviti v wasm (koliko MB?), da boš tvojih 500 vrstic kode, ki malo generira html, "lepše" poganjal?
Kar povej v cem napreduje? V stran metanju resourcov, izdelavi programskih jezikov na nivoju logopedicnih pripomockov, (kjer se clovek ubije na optimizaciji delovanja gc in "frameworkih" namesto na dejanskem resevanju problemov) za zapolnitev luknje v programerskih kadrih? Vceraj snezilka, danes programer. Za nekaj "nakucat" bo ze dober. Inteligenten pa niti ne rabi biti prevec, raje malo manj, za copy/pastat iz neta bo dober. Software bomo pa smisali tako, da ne bo prekompleksen za kader, ki ga imamo. Prepakiravanju starih tehnologij, ze resenih problemov, v nove in nove obleke, ki pa zrejo vec resourcov in delujejo slabse? Izbiri tehnolpgij glede na modo? O tem govoris?
Point je, da nekje okoli 99% procentov aplikacij ne potrebuje optimizacij, upravljanja z resourci in še čim. To je še mnogo bolj res za osnovno idejo javascripta (osnovna interaktivnost spletnih strani). Zato so vsi ti logopedični pripomočki OK - ker omogočajo, da ljudje udejanijo ideje, tudi če nimajo znanja/volje se ukvarjat s C-jem. Pa za prototyping je tudi kul, da ne rabiš najprej par ur raziskovat kako sploh compilat in linkat neke knjižnice, ampak preprosto uporabiš prvi logopedični pripomoček kjer je vse že prepacked. Da ne omenjam, da če si dober v C resource managementu, potem lahko vsak jezik uporabljaš brez frameworkov in kretenskih knjižnic in stvari noro zoptimiziraš. Jaz sem recimo v JS naredil exifParser in skupaj z bloatom za "lepo" delovanje strani same vse skupaj vzame ~300 vrstic kode / 14kb - in to je native JS. Če pa moram spisati realtime video stream obdelavo, da teče praktično na krompirju, pa se zakopljem v compiler docse in spišem proper C kodo optimizirano za tisto platformo. Rezultati so lahko šokantni ... Razumem pa, da se razni C puristi čutite ogrožene, ker vam kekci in šalabajzerji odvzemajo delo. Kako bo šele, ko bo 99% applikacij lahko generiral kar SW analyst/architect z uporabo dobrih UML diagramov in generatorjev. Takrat boste šele vsi v luftu, da to, TO, TOO pa res ni pravo kodiranje! How dare they!
Ja, 90, ali pa 95, procentov se da naredit s klikanjem in vlečenjem črt. Problem je tistih zadnjih 5-10 procentov, zaradi katerih bi potem moral vržt v koš tudi večino tistih 90ih procentov, če bi hotel, da nekaj res dela. Tako da so nekateri lahko hitro zelo pametni kako hitro so naredili _skoraj_ vse. Potem naj naredijo še res do konca, ne samo _skoraj_...
Če smo natančni je ta delitev časa zaradi tega, ker se prvih 90% časa ne porabi na pisanju specifikacije v naprej (izvzemši kakšne algoritme, pa tudi tam je pametno najprej vzeti papir v roke pa malo poračunati). Code first pristop se skoraj vedno konča z "saj je skoraj narejeno, samo še malo manjka". Če najprej spišeš 200 stranski SRS, ga dopolniš s kakšnimi 100 diagrami, potem lahko kodo nakuca vsak codemonkey ki pride mimo, in to v 10% časa kot bi ga porabil top "programer" brez teh pripomočkov.
Point je, da nekje okoli 99% procentov aplikacij ne potrebuje optimizacij, upravljanja z resourci in še čim. To je še mnogo bolj res za osnovno idejo javascripta (osnovna interaktivnost spletnih strani). Zato so vsi ti logopedični pripomočki OK - ker omogočajo, da ljudje udejanijo ideje, tudi če nimajo znanja/volje se ukvarjat s C-jem. Pa za prototyping je tudi kul, da ne rabiš najprej par ur raziskovat kako sploh compilat in linkat neke knjižnice, ampak preprosto uporabiš prvi logopedični pripomoček kjer je vse že prepacked. Da ne omenjam, da če si dober v C resource managementu, potem lahko vsak jezik uporabljaš brez frameworkov in kretenskih knjižnic in stvari noro zoptimiziraš. Jaz sem recimo v JS naredil exifParser in skupaj z bloatom za "lepo" delovanje strani same vse skupaj vzame ~300 vrstic kode / 14kb - in to je native JS. Če pa moram spisati realtime video stream obdelavo, da teče praktično na krompirju, pa se zakopljem v compiler docse in spišem proper C kodo optimizirano za tisto platformo. Rezultati so lahko šokantni ... Razumem pa, da se razni C puristi čutite ogrožene, ker vam kekci in šalabajzerji odvzemajo delo. Kako bo šele, ko bo 99% applikacij lahko generiral kar SW analyst/architect z uporabo dobrih UML diagramov in generatorjev. Takrat boste šele vsi v luftu, da to, TO, TOO pa res ni pravo kodiranje! How dare they!
Ne, point je, da tudi tistih 99% ne znas spodobno spisat in taksnih je 99% danasnjih developerjev, ki v 99% casa uporabljajo tocno taksne butaste izgovore. Zato pa je 99% aplikacij tako sranje, da se ti obrne ob tem, da bi jih uporabljal. Vkljucno z web stranmi. O electronu in podobnih abominationih sploh ne bom besed izgubljal.
@proto: Se vidi da je zgoraj par let star link, niti Kubernetes ni omenjen ... brez njega precej tezko nalozim random Docker images na 20+ serverjev naenkrat.
* C# je nov jezik in je obenem tudi najboljši. Nobenega živciranja ne povzroča. Medtem ko če uporabljaš kakšen star jezik kot je Java ti takoj začne kaj divgat živc, polno enih čudaškosti in nesmislov ima. Ni ene stvari, ki naredi programiranje danes veliko lažje ampak je polno malenkosti skupaj seštetih.
* Stackoverflow in podobne strani, kjer imaš polno znanja in knjižnic, da program napišeš veliko lažje kot pred leti.
Drgač pa res ni bilo programiranje tako zelo drugačno 15 let nazaj. Takrat sem jaz začel programirat v tem:
Programiranje res napreduje bolj počasi kot pa ostali računalniški svet, npr zmogljivost računalnikov, internet. Saj podobna zgodba je z AI. Najbrž nima več kam napredovat, kam pa naj še?
15% prepočasi in razlog več, da hočeš to raje nekje remotely laufati native namesto v browserju. Ko bo nova verzija knjižnice 2x hitrejša, ker bo uporabljala Intel-specific klice ali pa CUDO pa v jok in na drevo? Ne me narobe razumet - WASM je super. Samo performanse in web sta dva različna svetova, ker je stack blazen in latence do remote podatkov velike, ker je vmes http.
Ja, za kaki promil opravil je tistih 15% razlike res pomembnih. Za ostalo je to peanuts.
Kaj pa bi naj bili ti "intel-specific klici" o katerih govoriš? Če misliš intelov assembler, ne, tega direktno ne boš uporabljal, kot ga najbrž tudi zdaj ne. Ker pa se WASM prevede v strojni jezik točno tvojega procesorja, bo seveda, za razliko od kake generične X86 kode lahko uporabil vse ukaze, seveda tudi take, ki jih ima le X86-64, vključno z zadnjo različico SSE-ja in podobnih instrukcij.
CUDE seved tudi ne boš direktno uporabljal, tako kot nič drugega namenjenega točno določenemu hardweru. Verjetno pa bo na voljo kaka izpeljanka OpenCL-a, predvidoma, enkrat.
Kar povej v cem napreduje? V stran metanju resourcov, izdelavi programskih jezikov na nivoju logopedicnih pripomockov, (kjer se clovek ubije na optimizaciji delovanja gc in "frameworkih" namesto na dejanskem resevanju problemov) za zapolnitev luknje v programerskih kadrih?
Resource se meče stran z namenom. Ker so poceni. Koga klinca briga, če si ti znal leta 1979 skodirati saldakonte, ki so rabili 78kb pomnilnika, danes pa porabijo pol gigabajta? Pa če si vse spesnil sam z uporabo stdlib-a v K&R Cju, vključno s svojimi unikatnimi bug-i pri konveriji datumov, z napačnim zaokroževanjem, bazo v .dat datoteki, ki ni bila odporna na odpovedi niti v CP/M-u. Pol gigabajta stane danes toliko kot 4 inženirske minute. Računalnika z manj kot štirimi GB ni mogoče kupiti.
Seveda pa ni povsod pol giga "nič". Če si resen "maher" v pisanju kompaktne in učinkovite kode, bojo tvoje znanje dobro plačali. Samo "deeply embedded" pa "bare metal" dodaj pri poizvedbah.
15% prepočasi in razlog več, da hočeš to raje nekje remotely laufati native namesto v browserju. Ko bo nova verzija knjižnice 2x hitrejša, ker bo uporabljala Intel-specific klice ali pa CUDO pa v jok in na drevo? Ne me narobe razumet - WASM je super. Samo performanse in web sta dva različna svetova, ker je stack blazen in latence do remote podatkov velike, ker je vmes http.
In porabljat/plačevat strežniške kapacitete medtem ko uporabnikovih 8 jeder nima kaj počet? Ti pa še nikoli nisi prodajal in razvijal lasten produkt, mar ne? Sicer bi vedel, da to tebi lahko prihrani precej denarja, uporabnik pa ne bo bistveno na slabšem.
(memory leaki, buffer overflowi, memory fragmentation,... malo zmanjka, ko ni GCja in varne memorije, a?) Saj ne da rabis ampak se deloma strijam, jeziki danes so ena in isto sranje, s tem, da so ena in isto sranje tudi developerji raznih overdizajniranih lazanj, s filo iz spagetov in drobnimi ravioli za dekoracijo, ki jih imenujejo frameworki, knjiznice, kjer je interface bolj kompleksen od taska, ki so mu namenjeni.
