- Folytatja a leépítéseket a Tesla
- Mobilinternet
- Milyen routert?
- Aliexpress tapasztalatok
- Xiaomi AX3600 WiFi 6 AIoT Router
- Anyagi katasztrófára figyelmezteti az Apple-t a brit média
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Synology NAS
- Windows 11
- Vizsgálják a Waymo robotautók váratlan viselkedését
- antikomcsi: Való Világ: A piszkos 12 - VV12 - Való Világ 12
- sziku69: Fűzzük össze a szavakat :)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- Luck Dragon: Asszociációs játék. :)
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
Ú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.
-
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 ]
-
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 ]
-
floatr
veterán
válasz WonderCSabo #11 üzenetére
HD3470 és minden esetben simán pörög
-
floatr
veterán
válasz WonderCSabo #14 üzenetére
Ubuntu 10.10 dev chromiummal
-
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
-
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 ]
-
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 ]
-
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.
-
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 ]
-
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ú.
-
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. -
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 ]
-
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
- Samsung Galaxy A52 128GB, Kártyafüggetlen, 1 Év Garanciával
- 4. - 6. generációs i7 / xeon Mini Tower gépek RAM 8-64 Gb, ssd/hdd, akár 8 Gb VGA kedvező áron
- Lenovo X1 Carbon 7th - i5-8265U 1.6GHz 512GB SSD 16GB 14" WQHD (2560 1440) Kijelző
- ZTE Blade A31 Plus 32GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy S21 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest