Új hozzászólás Aktív témák
-
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
- Kerékpárosok, bringások ide!
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Horgász topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- gban: Ingyen kellene, de tegnapra
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- Házi hangfal építés
- Pécs és környéke adok-veszek-beszélgetek
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen