Új hozzászólás Aktív témák
-
floatr
veterán
Ennél jóval többre lesz szükségük, hogy népszerűsítsék a technológiát, amit egyelőre szinte senki nem támogat release formájában.
-
doc
nagyúr
nekem nem megy Safarival
amugy az otlet nagyon jo, eljenek a platformfuggetlen, telepitest nem igenylo 3D jatekok -
floatr
veterán
Gondolom hasonlóképpen engedélyezni a safari esetében is, akár a chrome release-ben. [link]
De a chrome/ium dev channeles változatában ott van már.
Mellesleg ugyebár nem csak játékok esetében lesz jó a júzernek, de még a közelmúltban is sokan huhogtak, hogy egy rendes játék motort nem fognak tudni megírni JS-ben. (egyrészt senki nem vár végletekig kidolgozottat, másrészt alakulnak az erőforrások erre is rendesen)
[ Szerkesztve ]
-
dajkopali
addikt
a wiki szerint ez kell hozzá
"fácánjava calvadosban/teljesítünk, egyre jobban " - Konok Péter
-
WonderCSabo
félisten
Firefox 4-el megy, 3 napja néztem. Csak lassú, és nincs AA, bár az utóbbiról tudom, h. ki lesz javítva.
Majd meglesem a Chrome dev sebességét, és pingelem az Fx fejlesztőket.
[ Szerkesztve ]
-
floatr
veterán
válasz WonderCSabo #6 üzenetére
Gördülékeny, de megeszi a p8400 egyik magjának 30%át
Itt jön el az a pont, amikor majd néhányan kezdik megérteni a V8 teszt értékét. Itt kicsit többet kell számolgatni, összetettebb kódot kell fordítani, és sok js motor itt elvérzik, mert a SS-re gyúrtak a legtöbben.
[ Szerkesztve ]
-
WonderCSabo
félisten
válasz WonderCSabo #8 üzenetére
Kipróbáltam, kb. ugyanannyira szaggat a test alsóbb komplexebb rétegein mind a kettő.
-
Fecow
aktív tag
válasz WonderCSabo #9 üzenetére
Milyen videó kártyával? Nekem intel x3100-zal döcög, viszont ati 4770-el, meg se rezzen.
szerk:
Igen chrome beta 8 mind2 gépen, simán le-fel tologaton a nézeteket, oda-vissza pörgetem a modellt asztali gépen meg sem látni, hogy webes a felület. Notebookon akad, de hát ott a videókártya sem acélos.[ Szerkesztve ]
Nyergeld meg a nagyot
-
floatr
veterán
válasz WonderCSabo #11 üzenetére
HD3470 és minden esetben simán pörög
-
MODERÁTOR
Lecsekkoltam, Linux alatt is megy Chromiummal (10.0.612.1). Egész jó, csak semmi újdonságot nem mutat a videó után.
<-ƘƘ->
-
julius666
addikt
Ez nagyon klassz, a layerek átlátszóságának állításakor kicsit beakad azért a felület, de amúgy "works like a charm"
az ígéretek szerint a közeljövőben az összes böngészőbe be lesz építve a támogatás.
Az IE-be is?
-
floatr
veterán
válasz WonderCSabo #14 üzenetére
Ubuntu 10.10 dev chromiummal
-
veterán
Testterkep? miez? Prison Break?
-
Finwe
őstag
Nem lehet mozgatni a végtagokat és a gerincet, pfff de gagyi....
Egyébként nálam alig terheli a procit, a vga órajelet viszont felrántja, szépen fut.Finwe
-{PoH}- Patriots of Hungary
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #11 üzenetére
Egyelőre csak az AMD-nek van hivatalos OpenGL ES 2.0-t támogató meghajtója. Ennek megfelelően hardveres gyorsításra WHQL driverrel csak a Radeonok képesek. Minden más terméken a CPU számol. Ezért olyan lassú.
(#23) vamzi: Az AA az problémába ütközik az OpenGL ES 2.0 specifikációi miatt. A mai kártyák a DX szabványban javasolt megoldást használják, ami nem jó ide. Megoldható a probléma, de időbe telik, addig az MLAA-t érdemes használni, ami nálam működik, de az csak HD 5000 és 6000 esetén van.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fecow
aktív tag
Aha, ez érdekes.
Mi a helyzet az Intel GPU-kkal? (pl x3100) Ott sincs GPU gyorsítás? Azért kérdezem, mert a notebookomban egy olyan van, és bár akad , de a CPU szinte soha nem megy 50% processzor használat fölé, sőt a frekvenciát sem emeli meg. Ebből én arra következtettem, hogy itt is a GPU-t használja, csak hát gyenge szegény, de lehet, hogy tévedek.
Antialiasing: Nekem x3100-on szinte ordít az antialiasingért, borzasztó "fűrészes", ati HD 4770-en, viszont szinte észre sem veszem, ez mitől lehet?[ Szerkesztve ]
Nyergeld meg a nagyot
-
Abu85
HÁZIGAZDA
Az Intel egyelőre nem kívánja támogatni a WebGL-t. Ezt a rendezvényen mondták, hogy bizonytalan a jövője. De ha lesz rá igény, akkor megírják a drivert. Az NV-ről tudom, hogy már van OpenGL ES 2.0 driverük, csak még tesztelik, de valamikor a következő év elején ki lesz adva. A saját rendezvényükön Quake 2-őt futtattak WebGL-en, az egész jól ment.
Persze, mert a GPU gyorsítás nagyobb felbontást is garantál. A CPU-s renderelés nem szép, mert ha jól nézne ki, akkor nagyon lassú lenne.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
proof88
addikt
Leterheli a CPU-dat és azért nem megy 50% fölé, mert csak az egyik magot használja gondolom. A másik mag meg kb pihen. Az 50%-os proci használatnál, ha kétmagos a proci és csak az egyik mag van használva, az azt jelenti, hogy maxon pörög a mag és bírkózik vele. Tehát ez gyakorlatilag 100%-os CPU használat lenne egy 1 magos procin, csak azért jelzi 50-nek mert kétmagosod van és csak 1 mag dolgozik.
-
Fecow
aktív tag
válasz WonderCSabo #31 üzenetére
Miért nem? Mit számítanak processzek abból a szempontból, hogy 1 vagy 2 magot használ, mikor látszik, hogy 2-t, mit számít a processz, abból a szempontból, hogy nem emeli meg a cpu a frekvenciát, ha egyszer akad. Értem én, hogy ez teljes processzorterhelést mutat, de ha egy magot használna csak látszódni kéne az összterhelésen is, nem? De parancsolj, bár nem tudom miért relevánsabb egy pillanatnyi érték, mint egy hosszabb időintervallumon mért időskálás ábrázolás. A kép úgy készült, hogy megfogtam egyik oldalt majd megpörgettem (már amennyire az akadozás miatt lehetett), majd nyomtam egy print screent, és mint látszik 11%-os értéket sikerült elcsípjek, de a maximum amit kiírt az sem volt 46-nál több.
Nyergeld meg a nagyot
-
WonderCSabo
félisten
Egy magot használ, a Google Chrome sincs, ahogy a piacon egyetlen böngésző sincs felkészítve a többmag kihasználására.
Természetsen ha több processz van, akkor egyik futhat az egyik magon, másik a másikon, de egy process-t nem dolgozhat 2 mag. Jelen esetben a GPU process a lényeg, ez egy db magon megy, és természetesen a GPUn is.Mellesleg nézd inkább a Windows Taskmanagerét, a Chromeé sajnos nem az igazi.
[ Szerkesztve ]
-
Fecow
aktív tag
válasz julius666 #34 üzenetére
Most akkor nem értem, ezekszerint mégis csak GPU-t használ? Mert akkor nincs semmi probléma, (illetve van de semmi meglepő) csak abu85 azt mondta, hogy minden nem ati cpu-t használ mit furcsálltam, mert mint linkeltem a proci mérések nagyon nem ezt támasztják alá.
WonderCSabo:
Elhiszed, hogy ha elindítom a bodybrowsert akkor egyszerre emelkedik mind2 mag kihasználtsága átlag 40%-ra, úgy hogy semmi más teljesítmény igényes külön alkalmazás nem fut a browserben? De ha nem is futhat 1 processz 2 magon, akkor sem változtat azon a tényen, hogy azt az egyet sem használja ki teljesen.[ Szerkesztve ]
Nyergeld meg a nagyot
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #29 üzenetére
Semmi köze a DX-hez ennek. A WebGL szabvány az OpenGL ES 2.0-ra épül. [link] OpenGL ES 2.0-t támogató driver kell hozzá. Ellenkező esetben a platform szoftveres módban fut.
(#27) Fecow: Erre képes a WebGL az automatikusan kiválasztott szoftveres módban. Azért az mindenképpen fontos szempont, hogy az OpenGL ES 2.0-t nem PC-re tervezték. A szabványt főleg az ultramobil termékekbe szánt grafikus magok támogatják. Nyilván ezek sokban nem különböznek a PC-s GPU-któl, így a támogatás ott is megoldható, de egy processzornál más a helyzet. A sebességért a minőség is fel van áldozva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #38 üzenetére
A fő gond, hogy nincs semmilyen OpenGL-es hívás. OpenGL ES 2.0-ra épül az API. Azért nincs gond a Radeonokon, mert ott van hardveres gyorsítás. Majd a GeForce-okon is lesz valamikor a következő év elején. Ezt az NV mondta nekem, hogy még nem áll készen a driver, de jól működik, így a terveknek megfelelően hamarosan bemutatják.
A rendezvényen meg is lehetett nézni, hogy mit megy a Quake 2 az új Firefox és a Chrome alatt.
Azt nem tudom, hogy a Chromonium hogyan oldja meg, mert sosem használtam, de hivatalosan OpenGL ES 2.0 támogatás kell hozzá a driverben. A Chrome és a Firefox így fog működni (illetve az elérhető béta programok így működnek).[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
WonderCSabo
félisten
Felőlem ne hidd el, h. Direct3D-vel megy a kirajzolás jelenleg Windowson a legújabb Firefox-al és Chrome-al, de ettől még ez így van. Lehet, h. rosszul fejeztem ki magamat.
Mellesleg nem a kisujjamból szoptam ez az infót - személyesen a Firefox fejlesztő mondta ezt nekem, aki megírta az Fx ANGLE támogatását...
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #40 üzenetére
Ha ez így menne, akkor mindenhol ugyanaz lenne hardveres gyorsítás. Ehhez képest csak a Radeonokon száguld a WebGL. Ez attól van, hogy eddig csak az AMD építette be a driverbe a natív OpenGL ES 2.0 támogatást. De mint mondtam, az NV is megjegyezte a rendezvényén, hogy nem kell pánikba esni, mert jön a WebGL driverük, és meg is mutatták, hogy megy a WebGL-es Quake 2 a fejlesztett driverrel.
Egyébként nem értem, hogy a böngésző fejlesztője miért választana egy köztes megoldást a WebGL-re, amikor az AMD és az NV natívan tervezi támogatni az OpenGL ES 2.0-t. Az persze elképzelhető, hogy azoknak jó a köztes megoldás, akik nem fogják natívan támogatni az OpenGL ES 2.0-t. Mondjuk az a gyártó hülye, vagy csak stratégiailag nem érdeke, hogy a GPU fő láncszemmé váljon az internetes böngészésben.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
WonderCSabo
félisten
A Google és a Mozilla szeretné, h. amikor szállítják a WebGL támogatást stabil böngészőikben, akkor mindegyik VGAn elfogadható sebességgel fusson. Jelenleg még mindig nem lehet tudni, h. az Nvidia, pláne az Intel mikor hozza ki a drivereit. Simán lehet fél év, akár 1 is. Ezek a böngészők addigra már elvileg rég megjelennek. És az Intel és Nvidia azért többségben van a piacon...
Látom, Téged nem lehet egyszerűen meggyőzni... Last try.
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #42 üzenetére
Már írtam, hogy az NV-nél személyesen voltam az előző héten, és ott beszéltem Lars Weinanddal, aki mondta, hogy nagyon hamar kész lesz az OpenGL ES 2.0-t támogató meghajtójuk. Ezzel futtatták a WebGL-es Quake 2-őt, ami nagyon szépen ment Chorme és FF alatt. Itthon szintén tudom ezt futtatni a Radeonon, natív gyorsítással. Minden szempontból száguldanak a WebGL-es alkalmazások.
Ahol elérhető lesz ott natív támogatás lesz, mert ez a leggyorsabb. A köztes fordítgatós megoldás jó dolog, ha nincs támogatás, de baromira lassú. Ezt fentebb te is részletezted, hogy akadozik néhol. Nálam egyáltalán nem akad sehol sem. Ez a különbség ha valami natívan van támogatva.
Az Intel szerintem nem fogja a WebGL-t erőltetni. Ezt hiába is várjuk tőlük. Azt el s mondták, hogy az OpenCL és a WebGL esetében egyelőre csak puhatolóznak, és csak akkor kezdik el a támogatást, ha tényleg terjedni fog.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
WonderCSabo
félisten
Nyilván gyorsabb a natív támogatás, de ahol nincs driver, ott sokkal gyorsabb az ANGLE. Az okokat ne firtassuk, de ANGLEt használnak, ez tény.
Mellesleg nálam Nvidián azért elég gyors Chrome-al, csak akkor időnként bedöcög, ha pörgetem a komplexebb layereket ezerrel. Kizártnak tartom, h. a proci ilyen sebességet elérne. Sajnos Firefox-al jóval szarabb, talán még nincsi alapértelmezetten bekapcsolva az ANGLE.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #44 üzenetére
Én Chromemal nézem. 9-es béta verzió. Egy döccenés sincs. A 10.12-es Catalyst van fent, de ment a korábbi 10.9-sel is. Ha jól emlékszem a 10.8-től van natív WebGL támogatás, de erre nem esküszöm meg. Most úgy is vissza kell tennem a 10.4-et pár OpenGL állományért. Azon is megnézem.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
WonderCSabo
félisten
Én 10 dev Chrome-al néztem, és Fx4 tegnapi builddel 8800GTn.
mellesleg Firefox-ban ki és be tudom kapcsolni az ANGLEt (ez most a HD4330)
ANGLE be:
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Dec 18 2010 03:45:44)
ANGLE ki:
WebGL Renderer: ATI Technologies Inc. -- ATI Mobility Radeon HD 4300 Series -- 3.3.10317 Compatibility Profile Context
Oks, kipróbáltam:
HD 4330:
GL: szupergyors
ANGLE: időnként beszaggat8800GT
GL: iszonyat lassú, szinte kifagy a böngi
ANGLE: időnként beszaggatSzóval ahogy írtam, ott van értelme az ANGLE, ahol nincs még megfelelő driver.
[ Szerkesztve ]
-
proof88
addikt
lényeg a lényeg, ha az OpenGL ES is natívan támogatva lesz PC-n akkor egyszerűbb lesz olyan mobil készülékekre fejlesztgetni amik az ES-t támogatják csak? Szal kevesebbet kell mobilon OpenGL-es progit tesztelni mert többet tesztelhetem a PC-n?
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #46 üzenetére
Megnéztem a 10.4-es meghajtóval. Ott néha akad, érezhető, hogy nem folyamatos. Az ANGLE-t nem babráltam.
(#47) proof88: Eddig is PC-n fejlesztettek a mobilokra a devkitek segítségével. Ezen a WebGL és a natív OpenGL ES 2.0 támogatás nem változtat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
WonderCSabo
félisten
Sajnos hibáztam a tesztelésnél, az ANGLE mindkét kártyán lassú. Kiderült, h. ez egy Fx4 bug, szóval egyelőre nem lettünk okosabbak.
Az ANGLEnek az Fx4-en van egy nagy előnye még:
On Windows, D3D is used for compositing, hence once comment 2 (using ANGLE allows us to bypass a really expensive readback when using a D3D9/D3D10 layer manager) is implemented, there's inherent benefit in using ANGLE for WebGL as that interoperates better with it
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz WonderCSabo #49 üzenetére
Natív támogatás kell, anélkül nem lesz tökéletes az eredmény, azt a 10.4-es meghajtón is látni, ami még nem támogatja az OpenGL ES 2.0-t. Csodát nem lehet tenni a hívások fordításával.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
WonderCSabo
félisten
-
floatr
veterán
Néha én is őszintén csodálkozom, hogy az a mamutcég, aki korábban sokszorosan bizonyította, hogy mlyen fasza interpretereket, és compilereket tud írni, és megmutatta a sunnak is, hogy hogyan kell JIT compilert optimalizálni, már több mint 10 éve látványosan szenved, amikor a javascript feldolgozásról van szó. Persze érdeke nem volt benne. Majd ha lesz időm, csinálok pár kisebb benchmarkot.
Amúgy nem csak egyszerű alkalmazások készültek valamilyen script nyelvvel, hanem olyan számításigényes alkalmazásokat -- mint pl autocad, vagy excel -- lehet script-tel egész jól eltologatni. Ha térinformatikai alkalmazásoknak jó volt, akkor jó lesz az máshová is
-
torzsmokus
csendes tag
ezzel (maverick+chr.10) próbálkozom én is, de még szoftveresen sem sikerül életre keltenem :S
libEGL warning: unable to load st_GL.so
libEGL warning: use software fallback
[1851:1851:5992565877:ERROR:app/gfx/gl/gl_context_egl.cc(341)] eglCreateContext failed with error EGL_SUCCESS
[1851:1851:5992566171:ERROR:gpu/command_buffer/service/gpu_processor_linux.cc(42)] GPUProcessor::Initialize failedilyet neked nem dobált? ha igen, hogy oldottad meg?
(végtelenül vacak, integrált s3 videóm van, de örülnék, ha legalább 0.1 fps-sel működne...) -
floatr
veterán
látom fantázia az van
De arról van szó, hogy nem fekete-fehérben kell látni ezt sem. Egyelőre a flash/SW kategóriás szutykokkal kéne összehasonlítani, nem a Black Ops-hoz mérni. Ennek is megvan a felhasználási területe, és ha nem is képes millió számra produkálni a koordinátákat a motor, de egy egyszerűbb geometriával képes lesz megbirkózni, pláne GLSL-el a háta mögött.A ms meg úgy jön a képbe, hogy vicces, ahogy régóta a sor végén kullog az interpreterével, miközben mást várna tőlük az ember. Tisztában voltak vele, hogy amíg ők nem foglalkoznak vele, addig a júzerek nagy százaléka legyint a scriptes alkalmazásokra, és a fejlesztők sem tudnak vele mit kezdeni. Csak sajnos egyre meredekebben dől befelé az exploder, így elő kellett venni ezt a témát is, bármennyire is nem vágott a RIA-profiljukba. Most nézem h a statcounter utolsó két heti statisztikája szerint az állás IE 47%, FF 31%, Ch 15%; a verzió szerinti bontás alapján meg november végén IE8 30%, FF3.6 25%, Ch7 12%
-
floatr
veterán
válasz torzsmokus #53 üzenetére
Nekem egy integrált hd3470-esem van, amihez 3.3.10237-es OGL, és 3.30-as GLSL jut az októberi driverrel. Nekem úgy tűnik, hogy itt a legnagyobb gond az OGL teljes hiánya, legalábbis ilyent akkor láttam, amikor valami olyan video kari volt a gépben, hogy csak az alapinstallos általános driver hajtotta meg.
-
floatr
veterán
Lefuttattam egy vérgagyi tesztet, ami véletlenszerűen generált számokkal 2D-s forgatásokat végez. Sajnos natív kódot már igazán régen írtam, arra most nem vállalkoznék, hogy valamennyire is értékelhetőt készítek, de java-hoz tudtam első körben hasonlítani.
Java:
public static void rotate(Point p, double th) {
p.x = p.x * Math.cos(th) - p.y * Math.sin(th);
p.y = p.x * Math.sin(th) + p.y * Math.cos(th);
}
public static void main(String[] args) {
Point p = new Point();
long t = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
p.x = Math.random() * 1000;
p.y = Math.random() * 1000;
rotate(p, Math.random() * Math.PI);
}
System.out.println(System.currentTimeMillis() - t);
}
public static class Point {
double x, y;
}JS:
function rotate(p, th) {
p.x = p.x * Math.cos(th) - p.y * Math.sin(th);
p.y = p.x * Math.sin(th) + p.y * Math.cos(th);
}
var t = new Date().getTime();
var p = {x : 0,y : 0};
for (var i = 0; i < 10000000; i++) {
p.x = Math.random() * 1000;
p.y = Math.random() * 1000;
rotate(p, Math.random() * Math.PI);
}
document.writeln(new Date().getTime() - t);Tudom, hogy sok ponton bele lehetne kötni, de annyit legalább mutat a dolog, hogy mi mivel van egyáltalán partiban. A js kód nagyjából feleannyi ideig fut V8 alatt, mint a java kód. Kipróbáltam FF3.6-al is, ott kb a java teljesítményének a negyedét hozta.
10000000 iterációra a következő idők jöttek ki:java - 5751 ms
chromium 10.0.613 - 2849ms
ff 3.6.13 - 23297ms
szerk. opera 11 - 7130ms (nehogy elfogultsággal bélyegezzenek meg)Bár igazán nagyon messzemenő következtetést ebből nem igazán lehet levonni, de szerintem ez a "tetűlassú"-tól elég távol áll. Legalábbis ha a V8-ról van szó...
[ Szerkesztve ]
-
Inv1sus
addikt
És a bőrfelszín kimarad? Az én ruhám nincs hozzánőve a bőrömhöz
*** WEBDESIGN, GRAFIKUS DESIGN, FRONT-END PROGRAMOZÁS ***
-
FTeR
addikt
a flash ugyanazt a szutyok script nyelvet* használja (lásd ECMA), de még annak is látványosan jobb a teljesítménye.
a silververlight és a java is számos számítási fajtában jobb eredményt produkál**, mint a natív c és a többiben sem marad el látványosan, így úgy vélem az elvárásaim nem túl elrugaszkodottak figyelembe véve, hogy az új html5-ösdi és társai pont ezen RIA platformok kiváltását túzte ki egyik fő céljaként.ebben a vitában nem kivánok időt pazarolni az ms fóbiádra, mert legyen bármilyen lassú is az ie (és mint azt ie9-nél láthatjuk egyáltalán nem az, sőt),a kiindulási alap az volt, h még a fürgének tartott chrome is tatűlassú, amihez az ms-nek rohadtul semmi köze.
* az kétségtelenül a nyelv szerkezetének javára írható, h lehetőséget adtak olyan fw-k megalkotására, mint pl a jQuery. sajnos azonban a legnagyobb igyekezet ellenére is, az ilyen fw-k a teljesítményre meglehetősen rossz hatással vannak.
** a java jó példa arra, hogy ugyan számítási teljesítményben meglehetősen jó, maga a plugin rengeteg sebesség problémával küszködik. -
floatr
veterán
Ezt a "látványosan jobb a teljesítménye" kijelentést nem ártana alátámasztani valamivel (mondjuk egy hasonló teszttel, számokkal), szerintem ez már rég nem igaz, max olyan alkalmatosságok állnak a rendelkezésére a runtime-on keresztül, ami jelenleg a böngészőnek nem. A SL/Java max a C++ generált kódjával szemben tud jobb lenni, illetve multiprocesszes környezetben bizonyos esetekben. Ráadásul még csak nem is pluginről beszéltem az imént, hanem szimplán csak egy Java alkalmazásról, mint amilyenekhez hasonlókat androidos telefonokra készítenek a "lúzerek" manapság. A tesztben egyszerűen csak javac-t (1.6.0.20 hotspot) használtam, elvileg akkor a tetűlassú crankshaft szénné alázta (sajnos natúr js motor futtatással nem tudom tesztelni, mert a nodej.js példányomban egy régebbi V8 van), ami szerinted a natív c-nél is gyorsabb. Ez az egész inkább szól a te JS-fóbiádról.
Az IE9 jó példa arra, hogy mire lehet képes a ms, ha "megtalálja" a fejlesztőit, és elkezd akarni csinálni valami versenyképeset. Eddig arra voltak képesek az elmúlt pár évben, hogy biztonságosan szét próbálták szedni darabjaira a bűvkör ajánlásait/szabványait. Ez ES4 esetében sikerült, a többi esetben nem. Többek közt ez is egy példája annak, hogy a ms sem éppen a legnagyobb rajongója a netscape találmányának, és a reformjainak.
Ha a fentieket elolvasod egyébként rájöhetsz, hogy most sem épp a chromium sebességével volt a probléma.
Amúgy meg lehet nézni, hogy az IE8 mire képes ebben a kis tesztben, de akkor ne felejtsd el megmérni mellé valamelyik másik említett tesztalanyt is, hogy lehessen mit mihez hasonlítani.
-
floatr
veterán
Na kiküzdöttem nagy nehezen egy C++ kódot is, és lett meglepi:
#include <sys/time.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
typedef struct {
double x;
double y;
} Point;
void rotate(Point& p, double th) {
p.x = p.x * cos(th) - p.y * sin(th);
p.y = p.x * sin(th) + p.y * cos(th);
}
main() {
Point p;
struct timeval tv, tv2;
srand((unsigned)(time(0)));
gettimeofday(&tv, NULL);
for (int i = 0; i < 10000000; i++) {
p.x = 1000 * rand() / (double(RAND_MAX) + 1);
p.y = 1000 * rand() / (double(RAND_MAX) + 1);
rotate(p, 3.141592 * rand() / (double(RAND_MAX) + 1));
}
gettimeofday(&tv2, NULL);
printf("%ld\n",(tv2.tv_sec - tv.tv_sec) * 1000 + (tv2.tv_usec - tv.tv_usec) / 1000);
}Végrehajtási ideje 2868 ms. Bár nyilván elkúrtam az egészet várom továbbra is a velős magyarázatokat, hogy miért is lenne a V8 javascript tetűlassú, amikor erre a kis feladatra nagyjából natív sebességet produkált ráadásul úgy, hogy (nekem) a cpp "fejlesztési idő" töredéke alatt sikerült megszülnöm a kódot -- ez a része mondjuk szubjektív, de nem elhanyagolható. Azt sem bánom, ha vannak optimalizálási javaslatok, amivel nagyságrendileg lehet gyorsítani a fenti kódrészleteken.
[ Szerkesztve ]
-
FTeR
addikt
kb 2 éve foglakoztam utoljára mélyrehatóbban ezzel a kérdéssel, most így hirtelen ezt a cikket találtam a témában: [link], de ha beírod a varázsszavakat kedvenc keresődbe, akkor elég sok anyagot találni a neten a témában.
többször azt írtad, h ms képtelen rendes fordítot írni böngészőbe, erre most azt írod, h ie9 jó példa arra, h tud ha akar.
nincs js fóbiám, igaz, h mint natív nyelvet egyáltalán nem kedvelem, de pl jQuery-s cucc meglehetősen tetszeik.
az ellenkezést az váltja ki belőlem, h szerintem nem hoz akkora (sőt egyáltalán nem hoz) megváltást, mint ahogy többek között te is vizionálod.
ez nem jelenti azt, h a sebesség növekedés nem kedvemre való és azt sem, h ms felzárkozását nem tartom örvendetesnek, pusztán arról van szó, h mindez semmi olyat nem hoz, amit eddig ne lehetett volna, akár sokkal jobban is megcsinálni, az egyetlen húzó érv a dejure-ságából fakad, melynek előnyeit én alapjaiban vitatom. -
FTeR
addikt
SL:
public MainPage()
{
InitializeComponent();
Point p = new Point();
long t = DateTime.Now.Millisecond;
Random random = new Random();
for (int i = 0; i < 10000000; i++) {
p.X = random.Next() * 1000; p.Y = random.Next() * 1000; rotate(p, random.Next() * Math.PI);
}
this.Timer.Text = (DateTime.Now.Millisecond - t).ToString();
}
public static void rotate(Point p, double th)
{
p.X = p.X * Math.Cos(th) - p.Y * Math.Sin(th);
p.Y = p.X * Math.Sin(th) + p.Y * Math.Cos(th);
}231ms
szerk: a teljesítmény nem túl stabil, 160 és 280 között ingadozik.
[ Szerkesztve ]
-
floatr
veterán
Nem azt írtam, hogy hülye hozzá, ez max a te olvasatod. Megváltásként sem emlegettem, egyszerűen arról van szó, hogy van egy olyan eszközöd, ami egyre univerzálisabb. Minél több helyen futtatható egy böngésző, annál több platformon, eszközön elérhető, amit arra gyártasz. Ennek a sikerét pedig nagyban hátráltatja a ms korábbi tevékenysége -- annak a maradéka -- miközben iszonyat tempóban növekedik az alternatíva. Ennyiről van szó csupán.
Továbbra sem értem miért mondod, hogy tetűlassú. A mérésedet meg meg kéne toldani pár másikkal is, mint említettem, mert így max annyit tudunk, hogy az IE9 és a SL milyen relációban van egymáshoz a gépeden. Spec jobban örültem volna egy egyszerű c# alkalmazásnak.
-
FTeR
addikt
módosítottam SL kódot, mert sztem a dead code removal bekavar és az ms vonogatást lecseréltem dátumosra:
public MainPage()
{
InitializeComponent();
Point p = new Point();
var t = DateTime.Now;
Random random = new Random();
for (int i = 0; i < 10000000; i++) {
p.X = random.Next() * 1000; p.Y = random.Next() * 1000;
p = rotate(p, random.Next() * Math.PI);
}
this.Timer.Text = (DateTime.Now - t).Milliseconds.ToString();
this.Timer.Text += " // "+ p.ToString();
}
public static Point rotate(Point p, double th)
{
p.X = p.X * Math.Cos(th) - p.Y * Math.Sin(th);
p.Y = p.X * Math.Sin(th) + p.Y * Math.Cos(th);
return p;
}így 667ms +/- 20ms
[ Szerkesztve ]
-
floatr
veterán
Szvsz a másodpercek lemaradtak kissé, inkább így:
long t = 1000 * DateTime.Now.Second + DateTime.Now.Millisecond
Ugyanez volt a cpp kódnál is az egyik buktató. Amit próbáltam:
class Geotest {
public static Point rotate(Point p, double th) {
p.X = p.X * Math.Cos(th) - p.Y * Math.Sin(th);
p.X = p.X * Math.Sin(th) + p.Y * Math.Cos(th);
return p;
}
public static void Main() {
Point p = new Point();
long t = 1000 * DateTime.Now.Second + DateTime.Now.Millisecond;
Random random = new Random();
for (int i = 0; i < 10000000; i++) {
p.X = random.Next() * 1000;
p.X = random.Next() * 1000;
p = rotate(p, random.Next() * Math.PI);
}
long t2 = 1000 * DateTime.Now.Second + DateTime.Now.Millisecond;
Console.WriteLine(t2 - t);
}
}Ez 2400 ms körül ingadozik elég erősen.
-
floatr
veterán
Enivéj, nekem egyre inkább úgy tűnik, hogy a JS nem tetűlassú (firefox 4 beta-t nem néztem) a megfelelő körülmények között. Engem inkább meglep a cpp kódhoz való viszonya...
Amúgy a dead code elimination-nek nem lett volna szabad "optimalizálnia", mivel referencia alapján ment a paraméter, aminek a tartalmát egyben módosította is. Így gyakorlatilag a két kód egyenértékű.
[ Szerkesztve ]
-
FTeR
addikt
engem annyira nem, mivel ez is JIT-es.
szvsz egy fps alapú tesztnek több értelme lenne, mert pl hiába számol gyorsan, ha a dom-ot lassan tologatja.
a meglévő demókon meg jól látni a grafikai különbséget.vki nem doban össze egy flash-t? most már kíváncsi lennék rá.
[ Szerkesztve ]
-
floatr
veterán
Na akkor ott tartunk, hogy a JS nem tetűlassú, és ez nem lep meg, mert JIT-es -- pipa.
Említetted a DOM-ot, és a JQuery-t. Ezeket viszont nem muszáj dolgoztatni, ha nincsen rá szükséged. Egy JS fejlesztési metodika szerint osztályokat, objektumokat és referenciákat kell kezelni, az érdemi DOM objektumokat pedig komponensként. Itt akkor ezek sem játszanak a képbe, a következő szűk keresztmetszet az interfész, ami a webgl-es api hívásokat biztosítja, és adja át az ogl es drivernek. Ezt abu említette, hogy ha van ilyen driver, akkor elég jó teljesítménye van, ha nincsen, akkor WonderCsabo-ra hagyatkozva marad a DX wrapper réteg.
Mi maradt még ki...? A végén kijukadunk oda, hogy mégse lassú.
-
julius666
addikt
Mivel fordítottad? Bekapcsoltad a kódoptimalizációt? Mondjuk nálam kb. semmit sem ért, bekapcsolva és kikapcsolva egyaránt 3200 ms környékén végzett a program gcc-vel.
Amúgy ha utánagondolsz, hogy a js-ből rögtön tárgykódot generál a V8, nem lehetetlen hogy megközelítse a C++ eredményét, csak a fordítás overheadje az extra. Az pedig ilyen kis kód esetén nem lehet túl vészes.
Mondjuk a te példádban valami tényleg büdös, szerintem az időlekérdezés a tetű lassú C++ban. Ha a megfelelő részeket kikommentezem, akkor ~700 ms körül fut le a kód (Code:: Blocks kiírja úgyis a futási időt).
[ Szerkesztve ]
-
floatr
veterán
válasz julius666 #74 üzenetére
Csak natúrba lefordítottam. Generált egy 7kb-os futtathatót, oszt kész. Sztem 2-3 másodpercig nem tart az idő lekérdezése de a JIT valóban generálhat jobbat. Nem vagyok cpp guru
Mindegy, nem is ez a lényeg, hanem az h a js minden, csak nem lassú, pláne crankshaft-tal. Ha lenne egy glxgears teszt webglben, az pontosabb lenne. -
FTeR
addikt
nem fogunk. azt aláírom, h ebben a kis matek tesztben meglehetősen jól teljesít és jobban mint vártam, de ennek ugyanúgy semmi értelme, mint az összes ilyen típusú tesztnek.
a natív js DOM kezelés egy olyan cucc, amire csak a mazohisták indulnak be. örömteli, h már nem csak id, hanem class alapján is megtalálja adott elemeket, de ez még továbbra is elképesztően körülményes ahhoz képet, ahogy a css és jquery is működik.
valóban nem muszáj, mint ahogy C++ sem az, hiszen ott az asm, mégsem utóbbira izgulunk rá egy átlag appnál. -
floatr
veterán
Ez a kis matek teszt a lelke a webgles appoknak. Érdekes h a V8 teszt eredményeihez hasonlít, amit kaptam.
A vicces az h most elégedetten hátradőlsz h na ugye pedig csak kreáltál magadnak egy problémás esetet, mert végül kiderült h nem a js a gond hanem a fw, amit használsz.
A magam részéről nem gerjedek a JQueryre, többre értékelem a komponens alapú szemléletet.[ Szerkesztve ]
-
FTeR
addikt
egy weblap kliensoldalin funkcionalitását 3 dolog lassította:
- nehézkes nyelv
- lassú számítási teljesítmény
- lassú DOM kezelésmost eljutottunk addig, h:
- van jQuery
- már jó a számítási teljesítmény
- lassú DOM kezelésa 1. kapcsán fontos megjegyezni, h jQuery nem önmagában lassú, csak pusztán arról van szó, h a DOM-ot továbbra is a natív js hívások érik el, csak a jQuery a megadott feltételek szerint mindig végig iterál az összes elemen és megnézi, h melyik attributumaira érvényesek. persze lehet optimizálni, pl nem hagyjuk, h mindig az összes elemen végigmásszon, hanem csak adott elem gyerekein, meg ha vmit többször akarunk elérni, akkor eltároljuk egy változóban (de ezt sem lehet mindig, főleg ajaxosdinál). mennyivel jobb lenne, ha ezeket natív tudná.
a 2.-ra világítottál rá, pontosabban ebből a kis teszt szorozatból feltételezem, h a többi számítási típusnál sem szerepelne rosszabbul.
a 3.-nál is látványos a javulás és már hw gyorsításnak is örvendhetünk, de korlátok továbbra is alacsonyak. ezt a legjobban olyan teszteknél látni, ahol egy adott css effektet képezünk le js-ben vagy egy beépített függvény helyett egy sajátot használunk. ez pusztán nyelv script jellegéből fakad, ami nem is fog változni. ez az ami pl .net-nél nem áll fent, mert a gyári és saját fv között nincs technikai különbség (és ez alatt nem azt értem, h a gyári fv is olyan lassú mint a saját ; ) ).
-
floatr
veterán
Jó, tehát akkor vehetjük tárgytalannak ezt a részét...
A magam részéről két dolgot találok lassúnak a böngészőkben alkalmazásoknál. Az egyik a rajzolás, bármilyen képi elemről is van szó -- ez nemsokára talán megoldódik. A másik maga a layout motor, amit sok framework megjelenítésre használ. Statikus megjelenítéskor még elmegy a sebessége, de változó tartalom esetében ez az egyik legnagyobb probléma.Amúgy firefoxnál benéztem valamit. A firebug-ot nem kapcsoltam ki, amiatt volt annyira lassú. Így 4359 ms alatt végzett, ami lényegesen barátibb.
Új hozzászólás Aktív témák
- exHWSW - Értünk mindenhez IS
- Battlefield 2042
- Fotók, videók mobillal
- Sok teljesítmény kell a Microsoft Copilot lokális futtatásához
- Milyen videókártyát?
- Az amerikai hadsereg lát fantáziát az OLED kijelzős hordozható eszközökben
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Shield TV-t csinált a Shieldből az NVIDIA
- Poco X6 Pro - ötös alá
- gban: Ingyen kellene, de tegnapra
- További aktív témák...