Új hozzászólás Aktív témák
-
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
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 ]
-
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
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 ]
-
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 ]
-
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 ]
-
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. -
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 ; ) ).
Új hozzászólás Aktív témák
- Júliustól kötelező biztosítást kell fizetni egyes rollerek után is!
- Vezetékes FEJhallgatók
- Az Xbox Series X|S konzolnak három új verziója jön idén
- PlayStation 5
- Tippmix
- Milyen TV-t vegyek?
- EAFC 24
- Elektromos rásegítésű kerékpárok
- Skoda, VW, Audi, Seat topik
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen