ugrás a tartalomhoz

asm.js

Joó Ádám · 2013. Már. 18. (H), 18.42
Készülő szabvány a JavaScript egy alacsony szintű, nagy teljesítményű részhalmazára
 ■
1

Amit nem értek

vbence · 2013. Már. 19. (K), 14.00
Mi a baj a virtual machine-nal?
2

Mivel mindegyik említett

Poetro · 2013. Már. 19. (K), 14.36
Mivel mindegyik említett nyelvben van egy virtuális gép, nem igazán értem a kérdésedet. Az ASM.js egy "nyelv", amire több nyelvből lehet fordítani (és elméletbe visszafelé is). Alacsonyabb szintű, mivel a JavaScript csak egy kisebb részhalmazát támogatja, viszont azok, amiket támogat nagyon gyorsak a jelenleg elérhető JS motorokon. Van benne fordítás idejű és dinamikus validáció is, ezzel biztosítva a jobb kódminőséget.
3

Pontosítanék

vbence · 2013. Már. 19. (K), 15.32
Arra gondolok, hogy ahelyett, hogy lehatárolunk egy részhalmazt és "fából vas karikát" módon pl: 
x = +x;
hozzáadunk funkcionalitást miért nem egy JVM vagy AVM2 tipusú VM lesz a "szabvány".

Egy olyan VM, aminek kialakításánál a JS-kompatibilitás a fő szempont nekem félmegoldásnak tűnik. Teljesen fölösleges kompromisszum.
4

Mert a JavaScript VM már ott

Joó Ádám · 2013. Már. 19. (K), 15.47
Mert a JavaScript VM már ott van mindenhol.
5

Nem lehet szempont

vbence · 2013. Már. 19. (K), 18.40
Ha a dolog célja, hogy a jövőben komolyabb alkalmazások költözhessenek a böngészőbe akkor nem lehet szempont, hogy most hogy van. Az egész asm.js akkor nyer majd értelmet, ha kijönnek a böngészők jövőbeli kiadásai.

Amúgy nem tudom milyen JS VM-re gondolsz.
6

Az egész mloc.js, meg az

Hidvégi Gábor · 2013. Már. 19. (K), 18.49
Az egész mloc.js, meg az alattunk levő bookmark is azzal foglalkozik, hogy szép meg jó a javascript, csak hosszú távon alkalmatlan arra, amire használják. Mégis sokan erre a lapra tettek fel mindent (Windows RT, Mozilla OS, HTML 5 és társaik), ezért megpróbálnak kihozni belőle, amit csak lehet.

Szerintem arra gondolt, hogy már nem csak kliens, hanem szerveroldalon is van lehetőség ezen a nyelven programozni.
7

Olvastam

vbence · 2013. Már. 19. (K), 20.28
Óh igen, a linkelt cikket olvastam.

Egy épkézláb VM nem hiszem hogy a kompatibilitás útjába állna. A hagyományos, JS-ben írt kódokat a böngésző egyszerűen lefordíthatná a VM utasításaira.

Viszont így megnyílna a lehetőség más nyelvben írt kódok futtatására is a böngészőben (előrefordított bytekód formájában).

Lehetne kiindulni neadjisten egy Java MIDP-ből, ehhez hozzáadni a DOM-ot és néhány elengedhetetlen API-t, ez megoldaná a performasz problémákat, és megnyitná az utat sok más nyelv webes verziója előtt.
8

Az a baj, hogy minden JS VM

Hidvégi Gábor · 2013. Már. 19. (K), 20.52
Az a baj, hogy minden JS VM más-más bájtkódot fordít ugyanabból a forrásból, mert már azt is lehet is és kell a környezethez igazítani.
9

Ez van most

vbence · 2013. Már. 19. (K), 21.23
Ez a jelenlegi helyzet. Igazából egyből natív kódba fordítanak, szóval nincs valódi VM saját bájtkóddal.

A magas szintű nyelv, amit támogatnak a JS, az alacsony szintű pedig az asm.js nyelvezete lenne. - Amit mondok, hogy ennyi erővel az asm.js helyett, lehetne egy valódi, bejáratott VM bájtkódja az alacsonyszintű eszköz. Emellé pluszba (a kompatibilitás miatt) mellékelne a böngésző egy JS fordítót a "régi" oldalakhoz.

Mindkét megoldás feltételez egy konszenszust a böngészőgyártók részéről, valamint az implementáció költségeit. Nem látom mit nyerünk, ha tiszta lap helyett egy JS alapú alacsony szintű eszközt válaszunk.
10

A böngészők fragmentációjának

Hidvégi Gábor · 2013. Már. 19. (K), 21.55
A böngészők fragmentációjának köszönhetően mindenféle kliensoldali fejlesztés (mint ez az asm.js) nagyon nehéz ügy, mert sosem tudod, mikor jut el elég emberhez, így mindenféle wrappert kell írnod hozzá, hogy működjön a lehető legtöbb helyen, ami a fejlesztést mindenképpen bonyolultabbá teszi. Tehát max. ellenőrzött helyen, pl. szerveroldalon érdemes az elején használni, így aztán vagy lesz belőle valami vagy sem.

Ennek fényében valóban igazad van, hogy van-e értelme a JS-be beleerőltetni ezt az egészet.
12

Félreértés

complex857 · 2013. Már. 19. (K), 23.02
Törölve
13

Miért törölted?

Joó Ádám · 2013. Már. 19. (K), 23.22
Miért törölted?
16

Rájöttem, hogy félreértettem

complex857 · 2013. Már. 20. (Sze), 08.30
Rájöttem, hogy félreértettem a threadben írtakat, ráadásul nem is jó helyre válaszoltam (-:
11

Hogyne lenne szempont. Ha egy

Joó Ádám · 2013. Már. 19. (K), 23.01
Hogyne lenne szempont. Ha egy meglévő infrastruktúrát lehet használni egy új kifejlesztése helyett, az éveket spórol meg, ha egyáltalán az új valaha is elterjedne. Mivel ez a nyelv a JS egy korlátozott változata, így az asm.js kód már ma is futtatható mindenhol, viszont a motorok fejlesztői ki tudják majd használni optimalizációhoz.
14

Nem ezt használnánk

vbence · 2013. Már. 20. (Sze), 00.31
Itt pont hogy nem használunk meglévőt. Az új eszköz előnyeinek élvezéséhez szükség van konszenzusra (vagyis szabványra és szándékra), és implementációra. Implementálni kell a böngészőgyártónak és implementáli kell a webprogramozónak. - Ez a képlet ugyanúgy igaz az asm.js és egy szabványosított VM esetén.

Arról nem is beszélve, hogy vannak bejáratott VM-ek. Például van egy aminek van GPL-es implementációja és a gyári böngészők készítői is rendelkeznek hozzá saját implementációval.
15

De igen, mert az asm.js kód

Joó Ádám · 2013. Már. 20. (Sze), 01.23
De igen, mert az asm.js kód szabványos JavaScript kód, ami fut a mostani motorokkal is, ugyanolyan teljesítménnyel, mint bármilyen más szkript, ezért nem kell egy új infrastuktúrát kiépíteni, és az asm.js-t nem támogató böngészőkkel is kompatibilis marad. A motorokhoz azonban folyamatosan tudják hozzáadni az optimalizációt az ilyen kódra.
17

Ennek fényében más a leányzó

Hidvégi Gábor · 2013. Már. 20. (Sze), 09.07
Ennek fényében más a leányzó fekvése. A probléma a JS-sel mindenesetre adott, kíváncsi vagyok, mennyit segít egy ilyen megoldás.
18

Kell infrastrukttúra

vbence · 2013. Már. 20. (Sze), 12.06
Legalábbis a fejlesztőeszközben, ha asmjs kódot szeretnél gyártani, azt validálni kell. - Első látásra persze közelebb van, mert JS alapú, de nem hiszem, hogy szükség van ilyen kompromisszumokra.

Én úgy látom, hogy mindn szereplő a felhőt erölteti szóval a szándék megvan, hogy gyorsabb platform legyen a web.
19

Olyan fordítókra van szükség,

Joó Ádám · 2013. Már. 20. (Sze), 17.05
Olyan fordítókra van szükség, amik asm.js kódra fordítják az általad választott típusos nyelvet. Az ilyen eszközök gyorsabban terjednek, mint amilyen nehézkes egy új nyelv bevezetése a böngészőbe (a Dart sem jutott még sehova, valószínűleg nem is fog). Ez egy eléggé realisztikus megoldás a jelenlegi problémákra.
20

Jelen pillanatban az

Hidvégi Gábor · 2013. Már. 25. (H), 09.41
Jelen pillanatban az asmjs.org nem érhető el (github 404 jelenik meg nálam).

A prog.hu szerint a Firefox éjszakaiba már bekerült az asm.js támogatása.
21

Már rendben az oldal.

Joó Ádám · 2013. Már. 25. (H), 16.51
Már rendben az oldal.
22

Hol lehet ezt igazán

Hidvégi Gábor · 2013. Már. 25. (H), 17.32
Hol lehet ezt igazán kihasználni? Ha jól értem, a matematikai műveleteket lehet vele igazán gyorsítani.
23

Játékok

complex857 · 2013. Már. 28. (Cs), 11.18
A fejlemények alapján játékmotorok tünnek az első célpontnak:
https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/

Anno mloc-js -en is bananabench -el demozták a dolog hatékonyságát (18. perc környéke).
Elvielben mindenféle kódnak jót tehet egyébként tekintve, hogy ilyenkor a vm előre tudhatja, hogy érdemes natív kódót fordítani ebből a részből, plusz nem kell megvárnia míg elég információja gyűlik össze a kódrol, hogy ráeressze jit-et mert a "milyen típusú szokott ez itt lenni" kérdést előre megválaszolják neki.
Ezen felül a generált kódból ki lehet hagyni a "de ha mégsem az amit betippeltünk" feltétel ellenőrzéseket is ami szintét dobhat valamennyit a generált nativ kód teljesítményén.

Ugynézki v8 oldalon is elindultak előkészületek, már van "neve" a gyereknek #2599 alatt.