Új hozzászólás Aktív témák
-
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
-- 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
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
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 ]
-
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
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
-- lehet script-tel egész jól eltologatni. Ha térinformatikai alkalmazásoknak jó volt, akkor jó lesz az máshová is
látom fantázia az van
Új hozzászólás Aktív témák
it A WebGL promóciójára a Google egy látványos alkalmazást választott ki, ám ezt a technológiát jelenleg még egyetlen böngésző végleges változata sem támogatja.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen