Pánikolnak a .NET- és a Silverlight-fejlesztők a Windows 8 miatt
2011-06-07T12:30:38+02:00
2011-07-19T21:29:36+02:00
2022-07-24T13:11:19+02:00
  • Microsoft itt azt írja: "Az új JavaScript motor kihasználja a több CPU magot" IE9 van szó.

    Ezzel csak az a bajom hogy Microsoft "mondja" a termekéről, aminek nem látok bele a forráskódjába, hogy kezeli a több magot.

    A Firefox és Chromium viszont tényleg nem kezeli, ezt a forráskód is bizonyítja.

    Az hogy melyik cég menyit hazudik azt inkább hagyjuk most, mivel mindegyik hazudik és sokat.

    A lényeg, hogy böngészőknek min. tudni kell kihasználni a több magos processzorokban lévő teljesítmény többletet ahhoz, hogy a enterprise cégek programjaikat átültessék html5-be.
    A Játékfejlesztőknek meg sokkal nagyobb szabadságot adna az, ha a választott platform a böngésző, kihasználja a hardver adta lehetőségeket.
    Már szinte minden készülék több magos, ellenben csak pár böngésző tudja ezt hasznosítani. ez FAIL.

    Kíváncsi lennék mobilon és tableten mi a helyzet?
    Azt tudom, hogy itt is vannak már több magos agyak, de a böngészőket nem ismerem, csak az Opera Mini-t. Az tuti nem kezel ilyesmit. HTML5-t hírből sem ismeri.
    Mutasd a teljes hozzászólást!
  • Kár hogy IE-ben nincs WebGL, kár hogy amit írtál csak a jövőben lesz megvalósítva, jelenleg van az egy mag kihasználás.

    Kár, hogy a WebGL nem előfeltétele se a hardveres gyorsításnak, se a 3D-s grafikának, de még a többszálú működésnek sem. Ezek egymástól teljesen független dolgok - tehát abból, hogy IE-ben nincs WebGL, nem következik az, hogy csak egy magot használ.

    Ennek pont, hogy az ellentetje igaz, már csak azért is, mert minden böngésző erősen párhuzamosan működik, hiszen pl. az erőforrásokat mindegyik több szálon tölti le, és egyértelműen a felhasználói felületet kezelő és a JavaScript kódot futtató rutinok is külön-külön szálban működnek. Sőt, maga a JavaScript fordító ill. motor is lehet többszálú.

    Legalábbis az IE9-ben biztosan az. Ezért is nem emlékszem, hogy valaha is sikerült volna úgy befagyasztanom, hogy ne lehessen normál úton az ablakot bezárni, akkor is, ha magában az ablakban a weblap megdögölni látszott. Amit Firefox-ról nem mondhatok el, mert az ha megdöglik, rendszeresen csontra fagy. (Ezzel éppen a napokban szembesültem ismét, amikor is egy tök sima JS callbackban elhelyezett - egy script elem readyState-jét figyelő - ciklussal simán csontra tudtam fagyasztani úgy, hogy csak kilőni lehetett, bezárni nem; miközben ugyanaz a kód IE9-ben nem bénította meg magát a böngésző felhasználói felületét, így simán le lehetett állítani, sőt, talán asszem működött is úgy, ahogy az ember várná.)

    Szóval nem tudom, hogy az állítás a Mozilla-tól származik -e (ami szerint egyetlen böngésző sem használ több szálat jelenleg), vagy csak a Mozilla és a TechNet között lévő saccperkábé minimum öt közvetítési ponton torzult el az üzenet, de ez a kijelentés ebben a formában nem igaz. Mondjuk nem lepne meg ha a valóban a Mozilla beszélne már megint sületlenséget, mert hogy kb. megalakulása óta ezt teszi (ti. ahol tudja alaptalanul lehúzza a konkurenciát, ezzel leplezve, hogy végig csak kullog mögötte, és hogy "újdonságai" jellemzően olyan dolgok, amiket azok, akiktől másolja, már sokkal régebben és sokkal jobban tudnak).
    Mutasd a teljes hozzászólást!
  • Persze lehet több feldolgozó szálat is indítani, de ez JavaScript-ben sem probléma a Web Workers API révén.

    Ugyanakkor ez egész szálasi, magosdi a JavaScript esetében tök irreleváns az esetek 99%-ában, hiszen - mint ahogy megbeszéltük már - egy JS program esetében a feldolgozás legnagyobb része nem magában a JS-ben megírt alkalmazáskódban, hanem a böngészőben történik. Utóbbi meg mondjuk egy WebGL-es 3D animációt nyilván az összes magot kihasználva is renderelhet - és normális OS és böngésző (például Windows és IE) alatt így is teszi. Amely esetben elmondható, hogy a JS program úgymond képes kihasználni több magot is.


    Kár hogy IE-ben nincs WebGL, kár hogy amit írtál csak a jövőben lesz megvalósítva, jelenleg van az egy mag kihasználás.
    Végre kihasználná a modern processzorokat a Firefox


    Tudom tudom, ne olvassak technet-tet!
    Mutasd a teljes hozzászólást!
  • Tegnap még úgy idéztél belőle, mint ha azt ott leírtak jelenleg is megállnák a helyüket.

    Biztos nem sikerült elsőre megérteni, ezért csak neked és csak itt leírom szájbarágósabban is: az ott leírtak jelenleg is megállják a helyüket. Leírtam az előbb, hogy miért nincs értelme a háromhónapos IE10-et a párnapos/-hetes - nyilvánvalóan már ehhez az új benchmarkhoz is "hozzáigazított" - Chrome-hoz hasonlítani.

    Ugyanakkor mindez mellékág, és tök lényegtelen, mert leírtam azt is, hogy a dolgok nem úgy működnek, hogy ha a Chrome lassabb egy X benchmarkban mint a Java, és egy Y benchmarkban pedig az IE10 lassabb, mint a Chrome, akkor IE10 az X benchmarkban is tuti lassabb lesz, mint a Java. Ezt ugyanis csak méréssel - X benchmark IE10-en futtatásával - tudnád megállapítani. Ha van ilyen eredményed, mérésed, akkor add elő - ha meg nincs, akkor ne akard kiokoskodni, kikövetkeztetni azt, amit valójában nem lehet!

    Érthető már, vagy még egyszerűbben kell elmagyaráznom?
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Csak félig-meddig követtem itt a hozzászólásokat, de ha jól láttam az még senkinek sem jutott eszébe, hogy az ASP.NET esetleg fog tudni HTML5-ös kódot generálni és így éri el a megfelelő multimédiás élményt is és marad a .NET programozás: OOP, EF, Linq, stb.
    Ha egy kicsit okosítanak az ASP.NET-en, akkor tényleg ki tudják vele váltani a SilverLight-ot. És ez már tényleg egy szép új világ lenne.
    Vélemények?
    Mutasd a teljes hozzászólást!
  • LOL

    Azért az ugye megvan, hogy egy másfél hónapos hírről van szó, ami az akkori legfrissebb állapotot tükrözte?


    Ja bocsi ilyen régi a cikk?!
    Tegnap még úgy idéztél belőle, mint ha azt ott leírtak jelenleg is megállnák a helyüket.

    Szép volt, köszönöm!
    Mutasd a teljes hozzászólást!
  • Megkérlek szépen javítsd ki a cikkedet vagy postold újra, mert így nem fedi a valóságok és félrevezeti a gyanútlan cikkolvasót.

    Azért az ugye megvan, hogy egy másfél hónapos hírről van szó, ami az akkori legfrissebb állapotot tükrözte?

    Arról nem is szólva, hogy a most már a Chrome 13-mal is frissített benchmark-eredmények a Chrome esetében mutatják az azóta végrehajtott fejlesztéseket is, az IE10-nél azonban még mindig a lassan már háromhónapos állapotot tükrözik. Szóval a negyedéves, a teszt publikálása előtt egy hónappal kiadott IE10 verzió és a max. alig pár hetes, a teszt publikálása után egy hónappal kiadott - ennek megfelelően nyilván már az ebben a tesztben is jól teljesítésre optimalizált, ráadásul még nem is stabil - Chrome 13 eredményeinek összevetése eléggé dilettáns, attól függetlenül is, hogy mint írtam, a cikk a maga idejében tökéletesen pontos volt. Ezért nincs mit javítani rajta.

    Előre is köszönöm.

    Nincs mit. Alaposabb olvasást, értelmező gondolkodást kívánok!
    Mutasd a teljes hozzászólást!
  • Lehet, hogy lemaradtam valamiről, de mióta van normális OOP (adatrejtéssel és örökléssel) a JavaScript-ben?
    Ha most hirtelen behoznák őket a szabványba, mennyi időbe telne, mire tényleg átírnák az eddigi, szétoptimalizált JS-motrokat úgy, hogy azok támogassák ezeket a feature-öket?
    Van egyáltalán bármilyen előszele annak, hogy normális OOP-t akarnak hegeszteni JS-be?

    Létezik olyan játékfejlesztő cég, aki normális OOP nélkül nekiállna valami igazán ütős, gigantikus játékot alkotni JS-ben?

    Szép a WebGL, de nem lesz messiás. Én biztosan használni fogom, ha gyorsan akarok egy látványos demót összedobni.
    A szomszéd Pistike is használni fogja, hogy a suliban menőzzön a haveroknak.
    Ti is használni fogjátok, ha valami szépet kell villantani a főnöknek, vagy szükségetek van egy interaktív weblapra, ami mondjuk egy épületet modellez belülről.
    Adni fog egy új löketet a böngészőben játszható játékoknak is.

    De hogy a Crysis 3 ebben íródna, az finoman fogalmazva abszurd. A JS már most elég gyors arra, hogy lehessen vele 3D-s demókat csinálni, de sohasem lesz a komolyabb játékok célplatformja. (Hacsak a böngészőt nem alakítják át egy játékmotorrá fizikával és mindennel együtt, amit JS-sel lehet scriptelni. De ez nagy butaság lenne. Nem arra való.)
    Mutasd a teljes hozzászólást!
  • Átlagban min 2 szer lassabb V8. Valószínűleg az IE 10-ben sem lesz sokkal gyorsabb a saját engine.
    Erre azért ne vegyél mérget, mert a nem az általad is hozott szintetikus tesztek, hanem valós életbeli programok alatt nyújtott teljesítményt összemérő benchmarkban egyrészt a V8 bizonyult a leglassabnak, másrészt az IE10 a leggyorsabbnak, ami nem mellesleg előbbinél 7x jobb eredményt ért el. Ami - a te logikádat követve - azt jelenti, hogy ha a V8-nál kétszer volt gyorsabb a Java - ahogy írod -, akor az IE10 JS még mindig legalább háromszor gyorsabb a Java-nál.


    Általam belinkelt Benchmark V8 version 3.3.8.1 verzióját futtatja. Ez a Chrome 13 -as alapértelmezett motorja, nem a 10 -é. Itt lévő JavaScript Benchmark amire te is hivatkoztál a cikkedben, látható hogy a jelenlegi preview IE 10 nem hogy gyorsabb hanem lassabb.

    Megkérlek szépen javítsd ki a cikkedet vagy postold újra, mert így nem fedi a valóságok és félrevezeti a gyanútlan cikkolvasót.
    Előre is köszönöm.
    Mutasd a teljes hozzászólást!
  • "És megindul a böngészőfüggetlenségre való törekedés a játékfejlesztőknél is..."

    El ne képzeljék már, hogy megírnak egy kódot letesztelik és, ha jó akkor kész a meló. Nem úgy megy az kérem szépen. Tessék megtanulni a futóhomokra építkezni mert az olcsóbb. Éljenek az oprendszer, böngésző és a böngészőverziók közötti kompatibilitás problémák.
    Mutasd a teljes hozzászólást!
  • A Microsoft szerint a WebGL öl, butít és nyomorba dönt - Hírek - Prog.Hu

    Ezek a faktorok által azért elég sok eszköz és felhasználó érintett ahhoz, hogy komoly előny legyen az, ha nem kell plugin telepítése valaminek a lejátszásához. És a fentiek a jövőben megjelenő eszközök/platformok egy részére is ugyanúgy igazak lesznek.


    A webgl meg lehet, hogy nem lesz támogatva rendesen a leginkább elterjedt böngészőben, kizárva egy igencsak nagy felhasználótábort?

    És megindul a böngészőfüggetlenségre való törekedés a játékfejlesztőknél is...
    Mutasd a teljes hozzászólást!
  • Én ezt mondtam:

    >Bármennyit is faragnak a js motoron,
    >egy managed kódhoz képest is tetűlassú lesz.

    Ez egyszerűbb emberek számára lefordítva azt jelenti, hogy _még_ egy managed kódhoz képest is lassú lesz. Pont azért mert a js hatványozottan hozza azokat a problémákat amik a managed kódnál is szembe jönnek (nincs idő túl sokat optimalizálni, még annyi sem mint Pl. egy javánál vagy egy C#-nél ahol azért csak egy bytekód megy át és nem a nyers forrás), és ez van megfejelve a dinamikus típuskezelés okozta lassúsággal.
    Mutasd a teljes hozzászólást!
  • a) nem adminisztátor a gépén (pl. céges masinák, amikre nincs joga telepíteni)


    Nem hiszem, hogy céges gépeken jellemzők lennének az fps-ek használata munkaidő alatt. De ahol igen, úgyis megdumálták a rendszergazdival (ilyen projekten voltam már :D).
    Aki meg játszani szokott 3d-s játékokkal, úgyis van hozzá otthon gépe/konzolja.
    Amúgy ennyi erővel le is tilthatnak weboldalakat, vagy akár a javascript használatát weboldalakon.
    Illetve nem tudom, hogy működik, de lehet letiltani majd pl a webgl használatát böngészőkben?



    b) olyan ekoszisztémához tartozó eszközzel rendelkezik
    -b1) amelyre annak gyártója nem engedi be az adott plugint (pl. iPad, iPhone vs. Flash)
    -b2) amelyre az adott plugin gyártója nem készíti el a cuccosát (pl. 2.2 előtti Androidok vs. Flash)
    -b3) amely nem tudja megfelelő sebességgel futtatni az adott, plusz absztrakciós réteget képező ill. nem feltétlenül optimálisan kódolt plugint, de natívan ugyanazt a funkcionalitást simán tudja biztosítani (pl. 1GHz alatti Androidok vs Flash, amiken a YouTube videók Flash appletben kb. 0,2 frame/sec sebességgel játszhatók le, miközben a natív YouTube alkalmazás teljesen simán adja vissza őket)


    Ez igaz, de a unity3d web pluginnal nem hiszem, hogy pc-n kívül más platformot is céloznának. A többi platformra (pc-re is) meg ott van nekik megoldásként a "natív" játék.
    Mutasd a teljes hozzászólást!
  • Szvsz azért azt a plusz 3 kattintást csak megteszi egy játékos, ami egy plugin telepítésével jár, ha játszani akar.

    Kivéve ha
    a) nem adminisztátor a gépén (pl. céges masinák, amikre nincs joga telepíteni)
    b) olyan ekoszisztémához tartozó eszközzel rendelkezik
    -b1) amelyre annak gyártója nem engedi be az adott plugint (pl. iPad, iPhone vs. Flash)
    -b2) amelyre az adott plugin gyártója nem készíti el a cuccosát (pl. 2.2 előtti Androidok vs. Flash)
    -b3) amely nem tudja megfelelő sebességgel futtatni az adott, plusz absztrakciós réteget képező ill. nem feltétlenül optimálisan kódolt plugint, de natívan ugyanazt a funkcionalitást simán tudja biztosítani (pl. 1GHz alatti Androidok vs Flash, amiken a YouTube videók Flash appletben kb. 0,2 frame/sec sebességgel játszhatók le, miközben a natív YouTube alkalmazás teljesen simán adja vissza őket)

    Ezek a faktorok által azért elég sok eszköz és felhasználó érintett ahhoz, hogy komoly előny legyen az, ha nem kell plugin telepítése valaminek a lejátszásához. És a fentiek a jövőben megjelenő eszközök/platformok egy részére is ugyanúgy igazak lesznek.
    Mutasd a teljes hozzászólást!
  • Szvsz azért azt a plusz 3 kattintást csak megteszi egy játékos, ami egy plugin telepítésével jár, ha játszani akar. Főleg, ha kirakják az oldalra a linket.

    Pl én a battlefield play4free-vel játszom néha, amit webes játékként is reklámoznak (nem az, csak böngészőből vmi activex szerűséggel elindítják a játékot), ettől függetlenül telepíteni kell, és egyáltalán nem esett nehezemre felrakni a játékot. És ahogy eddig tapasztaltam jó pár másik játékosnak sem.
    Mutasd a teljes hozzászólást!
  • Böngésző plugint telepíteni kell. Itt minden arról szól, hogy ha van 2 technológia, egyik kapásból megy mindenhol (HTML5+JS), míg a másiknál kompatibilitási hibák vannak vagy bíbelődni kell a telepítéssel vagy egyáltalán nem megy egy platformon vagy nem csak annyi, hogy FBn rákattintasz egy linkre és már be is jött, akkor vesztett ügyed van. Ez a fene nagy térhódítása a webnek többek között.
    Mutasd a teljes hozzászólást!
  • Nincs ipadom, de igazad van.

    Ha már multiplatform, akkor esetleg még unity3d?
    Elvileg ezeket tudja:
    pc, xbox, ps3, wii, ios, android, és van egy böngésző pluginja is.
    Mutasd a teljes hozzászólást!
  • Láttam már, de nem mennek vele semmire. A Rage motorral, platformfüggetlenséggel meg a szabványos OpenGL Es-ből származó interfésszel messze a WebGL a jobb alternatíva.

    Futtattad ezeket a demókat IPad-on is? Ja, hogy azon ez nincs.
    Mutasd a teljes hozzászólást!
  • és a WebGL-hez képes elég szegényke, szóval bukó


    Háát, próbáltad már az új bétát amiben a molehill is megtalálható?

    Gyúrják már a magasabb szintű 3d-s motorokat rá, pl flare3d, alternativa3d, away, stb.

    Pl itt egy demó, kiraktak, több mint 1000 karaktert, nálam teljesen akadás mentesen rúgkapálnak. Kell az incubator béta verziója hozzá:

    http://flare3d.com/product/79-skin-flare3d-2-0-molehill

    De volt már faxa autóversenyzős demo is (ott van a demó url-je a vidijó alatt):

    AlternativaPlatform's Adobe Flash "Molehill" MAX Racer demo

    Nyilván ez még csak béta valami, meg azért a rá épülő 3d-s környezeteteket is gyúrják még...
    Mutasd a teljes hozzászólást!
  • A nem azt jelenti hogy nem állítottam én sem mást. Soha, sehol. Te valamiért valamelyik hsz-em alapján úgy vélted hogy én összekötöm ezt a két, valóban egymástól független dolgot

    Ezt nem én vélem így valamiért, hanem minden magyarul beszélő ember. Te szó szerint azt állítottad, hogy a JS motoron futó mindig is lassabb lesz, mint a managed kód, mert a dinamikus típuskezelés mindig is lassabb lesz, mint a statikus. Ezzel összekötötted a JS-t a dinamikus, a managed kódot pedig a statikus típuskezeléssel - ami ugye, mint tudjuk, teljesen téves. Ez is tény - ezt is felesleges tagadni, mert nem változtat semmin.

    Nem.
    1. dolog ami miatt lassú, az a dinamikus típuskezelés.
    2. dolog ami miatt lassú, az hogy forráskódot küldesz a kliensre.

    Megint mellébeszélsz. Senki nem azt mondta, hogy ezt nem mondtad - hanem azt, hogy emellé azt is mondtad (a kijelentésedben implikáltad), hogy a managelt kód meg feltétlenül statikus típuskezelésű, ami nem igaz.

    Még akkor sem ha egy úgymond szigorúan típusos nyelvet használsz (pl. C#) és ha magában az alkalmazásodkódodban nem használsz dinamikus típusokat. Mert még akkor is pl. adatbázisműveletek igen nagy részben kvázi dinamikus típuskezeléssel futnak legalább onnantól és addig, hogy a statikus típusú alkalmazásváltozóidból/-ba betöltöd a műveletek paramétereit/eredményeit.
    Mutasd a teljes hozzászólást!
  • Még a mono-hoz képest is többszörös a különbség.
    Mutasd a teljes hozzászólást!
  • A nem azt jelenti hogy nem állítottam én sem mást. Soha, sehol. Te valamiért valamelyik hsz-em alapján úgy vélted hogy én összekötöm ezt a két, valóban egymástól független dolgot, de őszintén szólva nem tudom honnan jött ez le neked. Az hogy a js és a PHP épp mindkettő dinamikus és forráskódként közlekedik (bár a PHP-re most a Facebook csinált egy PHP to C++ fordítót többszörös sebességnövekedést érve el ezzel, kár hogy néhány fontos dolog még hiányzik belőle (Pl. eval()), ezért a jobb frameworkök (Pl. yii) még nem használhatók vele).

    De, mert azzal indokoltad, hogy - szerinted - a JS sosem érheti utol a menedzselt kódú programokat (úgy általában), mert hogy dinamikus típuskezelést használ.

    Nem.
    1. dolog ami miatt lassú, az a dinamikus típuskezelés.
    2. dolog ami miatt lassú, az hogy forráskódot küldesz a kliensre.

    A két dolog egymástól független, a két hatás összeadódik. De én sehol nem mondtam azt hogy ezek összefüggenek, azon túl hogy a javascriptben mindkettő jelen van.
    Mutasd a teljes hozzászólást!
  • "te a dinamikus típuskezelést szembeállítottad a menedzselt kóddal, aminek semmi értelme, mert a kettő nem zárja ki egymást, ezek egymástól független jellemzői egy programnak."
    Nem.

    De. Ha tetszik neked, ha nem, a dinamikus típuskezelés és a kód menedzseltsége egymástól teljesen független jellemzők. Pont. Ezen nincs mit vitázni, mert tény.

    Mindkét tényező hatással van a sebességre, de én azt soha nem mondtam hogy ezek bármilyen összefüggésben lennének egymással.

    De, mert azzal indokoltad, hogy - szerinted - a JS sosem érheti utol a menedzselt kódú programokat (úgy általában), mert hogy dinamikus típuskezelést használ. Ami értelmetlen kijelentés és indoklás, mert a menedzselt kód nem zárja ki a dinamikus típuskezelést - ergo, nem is lehet őket egymással szembeállítani.
    Mutasd a teljes hozzászólást!
  • Hogy ne beszéljünk a levegőbe itt egy jó statisztika ara, hogy mennyi idő alatt fut le egy adott program, különböző technológiákat használva.

    Ez nem programokat vizsgál, hanem szigorúan kizárólag feldolgozó műveleteket végző benchmarkokat futtat. Amikről éppen az előbb lett elmondva, hogy miért teljesen irrelevánsak a valós életbeli programok vonatkozásában (ti. mert azok az idő 99%-ában felhasználói bevitelre, adatbázisból származó adatra, kirajzolás befejezésére, stb. várnak ill. ezzel terhelik a gépet, nem az alkalmazáskód részét képező feldolgozó műveletekkel).

    Átlagban min 2 szer lassabb V8. Valószínűleg az IE 10-ben sem lesz sokkal gyorsabb a saját engine.

    Erre azért ne vegyél mérget, mert a nem az általad is hozott szintetikus tesztek, hanem valós életbeli programok alatt nyújtott teljesítményt összemérő benchmarkban egyrészt a V8 bizonyult a leglassabnak, másrészt az IE10 a leggyorsabbnak, ami nem mellesleg előbbinél 7x jobb eredményt ért el. Ami - a te logikádat követve - azt jelenti, hogy ha a V8-nál kétszer volt gyorsabb a Java - ahogy írod -, akor az IE10 JS még mindig legalább háromszor gyorsabb a Java-nál.

    Persze ez a dolog nem így működik - de a te általad írottaknak és a hozott benchmarkoknak sincs semmi teteje és teljesen irrelevánsak a valós életbeli programok vonatkozásában.

    .NET 4.0 -hez képest meg valószínűleg még nagyobb a különbség. (megj: a MONO != .NET)

    Nincs olyan, hogy valószínű. Mérések, tények alapján lehet valamit mondani. Ha ezek nem állnak rendelkezésre, akkor felesleges találgatásokba bocsátkozni.

    A .NET 4.0 és a JavaScript összehasonlításának ráadásul semmi értelme sincs, mivel ezek nem összemérhető valamik. A .NET 4.0 egyrészt egy keretrendszer, másrészt egy futtatóplatform és annak konkrét implementációja, míg a JavaScript egy nyelv, ami azonban önmagában még egy konkrét implementációt (pl. egy konkrét futtatókörnyezet, böngészőt) sem jelöl meg. Mondhatni, a JavaScript és a .NET 4.0 gyakorlatilag diszjunkt fogalomkörök, így semmi értelme és lehetetlen összességében és általánosságban összevetni őket.

    Nagyon nagy hátránya a JavaScriptnek hogy, legmodernebb enginek (V8) is csak 1 magot képesek meghajtani. (megj: Én így tudom, tapasztalat)

    Ez minden más program és nyelvre is igaz. Ez alól egyedül a legújabb fejlesztések - pl. C++0x - a kivételek, amelyek már nyelvi szinten támogatják a párhuzamosítást.

    Persze lehet több feldolgozó szálat is indítani, de ez JavaScript-ben sem probléma a Web Workers API révén.

    Ugyanakkor ez egész szálasi, magosdi a JavaScript esetében tök irreleváns az esetek 99%-ában, hiszen - mint ahogy megbeszéltük már - egy JS program esetében a feldolgozás legnagyobb része nem magában a JS-ben megírt alkalmazáskódban, hanem a böngészőben történik. Utóbbi meg mondjuk egy WebGL-es 3D animációt nyilván az összes magot kihasználva is renderelhet - és normális OS és böngésző (például Windows és IE) alatt így is teszi. Amely esetben elmondható, hogy a JS program úgymond képes kihasználni több magot is.

    Tehát ez megint egy olyan vélt hátránya a JS-nek, ami egyrészt nem létezik (mert ő is tud kvázi több szálat indítani ill. mert a feldolgozások, megjelenítések mehetnek több szálon függetlenül attól, hogy a JS-kód maga úgymond egy szálon fut), másrészt mert a legtöbb program esetében nincs is szükség többszálú feldolgozásra ill. nem szokás ilyenre megírni más platformokon, nyelveken sem őket. Akkor sem ha amúgy lehetne. Mert az esetek 99%-ában nem érdemes.
    Mutasd a teljes hozzászólást!
  • Kösz, hogy leszögezted a nyilvánvalót. Ez ugyanakkor nem változtat semmit azon, hogy te a dinamikus típuskezelést szembeállítottad a menedzselt kóddal, aminek semmi értelme, mert a kettő nem zárja ki egymást, ezek egymástól független jellemzői egy programnak.


    Nem. Ezek párhuzamos, a sebességet meghatározó tényezők. Egy tényező hogy valami natív vagy bytekód alapú JIT-es, vagy forráskód alapú JIT-es rendszer. A másik hogy valami dinamikus vagy statikus típuskezelést használ. Mindkét tényező hatással van a sebességre, de én azt soha nem mondtam hogy ezek bármilyen összefüggésben lennének egymással. Az már egy másik kérdés, hogy mind a php mind a js a forrásban terjedő dinamikus típuskezelésű nyelvek - szvsz meglehetősen szerencsétlen - családjába tartozik. De azt soha nem állítottam hogy ne léteznének egyéb kombinációk.

    Ezek szerint akkor megegyezhetünk abban, hogy a sakkprogram kivételével gyakorlatilag minden más program JS-ben is elég jó sebességűre megírható.

    Ja. A bolhának meg ha levágják az összes lábát, megsüketül. Na itt fejeztem mára a dolgot
    Mutasd a teljes hozzászólást!
  • Hogy ne beszéljünk a levegőbe itt egy jó statisztika ara, hogy mennyi idő alatt fut le egy adott program, különböző technológiákat használva.

    Példaként vizsgáljuk meg a google v8 javascript engine-t az
    Oracle java 6 -tal szemben (linux 32 bit):

    Benchmark

    Átlagban min 2 szer lassabb V8. Valószínűleg az IE 10-ben sem lesz sokkal gyorsabb a saját engine.

    .NET 4.0 -hez képest meg valószínűleg még nagyobb a különbség.
    (megj: a MONO != .NET)

    Ez csak akkor lényeges ha komplex számításokat végez a programunk! PL: EKG jeleket kell kiértékelnünk. Kardiológiai szoftverek amelyek csak tárolásra használják a szervert.

    Nagyon nagy hátránya a JavaScriptnek hogy, legmodernebb enginek (V8) is csak 1 magot képesek meghajtani. (megj: Én így tudom, tapasztalat)
    Mutasd a teljes hozzászólást!
  • Egy játék esetén akkor is dolgozik a gép, ha te nem csinálsz semmit (legfeljebb idő előtt elkapnak a szörnyek). Egy olyan proginál ami az user inputra vár és arra reagálva tesz valamit (Pl. ügyvitel) valóban az user inputra vár (Pl. nyomógomb) utána viszont lépni kell mint az olajozott istennyila.

    Oké, és ennek mi köze a menedzselt és a JavaScript kódok közötti különbséghez? Semmi, hiszen amikor már fut a program akkor már mindkét esetben natívan fut a JIT-nek köszönhetően.

    >>Ja. Csak nagyon nem mindegy hogy egy IL-ből fordítasz gépi kódra, vagy nyers forráskódból. <<
    "Na már ugyan miért nem? Gondolod, hogy a forrásból JIT-elés az annyival lassabb? Mi alapján gondolod ezt? Mi teszi olyan lassúvá?"
    Nagyjából ugyanaz amit a C# fordító csinál az alatt amíg a cs fájlból obj lesz. Szimbólumtábla felépítés, ciklus optimalizáció, stb.

    Ez a megállapításod is a dinamikus típusokkal és kései feloldással történő futás (amik a JS-re is jellemző) lényegének abszolút meg nem értését tükrözi. Utóbbi esetén ugyanis a szimbólumtáblák nyilvántartása és vezetése nem a "fordítási" folyamat része - ergo, a fordítást nem is lassíthatja.

    A ciklusoptimalizációnak pedig az a formája amiről te beszélsz (ti. ami fordítási időben végezhet), pedig gyakorlatilag nem igényel feldolgozókapacitást - ill. annyit, amennyit egy egészkivonás igényel: mondjuk 2 órajelciklust a másodpercenként 2-3 milliárdból. Ezt is ugye csak egyszer, a JIT fordítás végrehajtása során.

    Felhívnám a figyelmedet a képest és a tetűlassú közt dekkoló is szócskára. Azt értettem alatta, hogy a js. még a managed kódhoz képest is tetűlassú lesz

    Na, de hát éppen ez az, hogy amiket leírtál, azok eleve nem a kód manageltségének vagy nem manageltségének - hanem attól független faktorok (pl. dinamikus típuskezelés, távoli futtatás, stb) - sajátosságai, következményei. Innentől kezdve az "is" szócska is értelmetlen, hiszen még a konkrét példára sem igaz amit leírtál.

    (nem szólva a C++-os natív kódról)

    Terelj, ha már az eredeti állítást nem tudod védeni!
    Mutasd a teljes hozzászólást!
  • Az hogy van dinamikus típuskezelés (ami egyébként szvsz a MS egyik nagy melléfogása volt) nem jelenti azt hogy _csak_ az van.

    Kösz, hogy leszögezted a nyilvánvalót. Ez ugyanakkor nem változtat semmit azon, hogy te a dinamikus típuskezelést szembeállítottad a menedzselt kóddal, aminek semmi értelme, mert a kettő nem zárja ki egymást, ezek egymástól független jellemzői egy programnak.

    Ez azért megint csak függ attól is, hogy mit csinál a program. Ha egy gomb ami egy query-t indít el a szerveren akkor valóban nem. Egy js-ben írt sakkprogram ami a felhasználó gépén számol, más más kérdés.

    Ezek szerint akkor megegyezhetünk abban, hogy a sakkprogram kivételével gyakorlatilag minden más program JS-ben is elég jó sebességűre megírható.

    Mindenesetre akár kalóz szervert, akár cheat kódot jóval egyszerűbb úgy csinálni, ha ott a forráskód.

    Ez abszolút nem igaz, hiszen egy programban, játékban nem feltétlenül lehet attól csalni, hogy megvan a teljes forrásod hozzá. Pl. a sakknál maradva attól a lépések vonatkozásában még nem fogsz tudni csalni, hogy megvan a játék forráskódja. Kártyajátékok, kalandjátékok, stb. dettó. Amivel tudsz csalni az külső - esetleg gépi - segítséget vonsz be (pl. a lépések kiszámolására, a kijátszott kártyák nyilvántartására, valószínűségek számolására, stb.), de ehhez abszolút nem kell a forráskód és a forráskód megléte ezek megvalósítását nem segíti számottevően vagy egyáltalán.

    Ezen kívül sok legtöbb csalás abszolút nem az eredeti program kódjának, algoritmikus működésének módosításán keresztül működik (hanem pl. textúrák, modellek manipulálásával).

    Igazából nem is tudok elképzelni hirtelen olyan multiplayer csalást, ahol az eredeti játék forráskódjának megléte számottevően elősegítené a csalás elkészítését. De te majd biztos mondasz ilyent. Függetlenül attól, hogy ez aztán megint nem olyan dolog, ami bármennyiben a JS és a menedzselt kód ellen szólna, hiszen a JS kód is összezavarható és a managelt kód is igen jó hatásfokkal visszafordítható forrássá.
    Mutasd a teljes hozzászólást!
  • Egyrészt C#-ban is van dinamikus típuskezelés, ezt is megbeszéltük már.

    Az hogy van dinamikus típuskezelés (ami egyébként szvsz a MS egyik nagy melléfogása volt) nem jelenti azt hogy _csak_ az van.

    Másrészt ha egy program az idő 99%-ában felhasználói bevitelre vár, akkor nagyon mindegy, hogy amikor arra kell valamicske keveset reagálnia, akkor azt 1ms vagy 5ms alatt teszi, mert a kettő között a felhasználó nem fog érdemi különbséget észlelni.

    Ez azért megint csak függ attól is, hogy mit csinál a program. Ha egy gomb ami egy query-t indít el a szerveren akkor valóban nem. Egy js-ben írt sakkprogram ami a felhasználó gépén számol, más más kérdés.

    Gondolod, hogy az aki forrás nélkül hajlandó fizetni érte az már nem hajlandó ha a forrás is elérhető? Vagy azt, hogy forrás nélkül nem lehet cheateket készíteni egy játékhoz?

    Mindenesetre akár kalóz szervert, akár cheat kódot jóval egyszerűbb úgy csinálni, ha ott a forráskód.
    Mutasd a teljes hozzászólást!
  • Abszolút nem tudom értelmezni ezt a mondatot. Segítenél?

    Egy játék esetén akkor is dolgozik a gép, ha te nem csinálsz semmit (legfeljebb idő előtt elkapnak a szörnyek). Egy olyan proginál ami az user inputra vár és arra reagálva tesz valamit (Pl. ügyvitel) valóban az user inputra vár (Pl. nyomógomb) utána viszont lépni kell mint az olajozott istennyila.

    Mi teszi olyan lassúvá?

    Nagyjából ugyanaz amit a C# fordító csinál az alatt amíg a cs fájlból obj lesz. Szimbólumtábla felépítés, ciklus optimalizáció, stb.

    Nem a fenét nem. Hiszen közölted, hogy "bármennyit is faragnak a js motoron, egy managed kódhoz képest is tetűlassú lesz

    Felhívnám a figyelmedet a képest és a tetűlassú közt dekkoló is szócskára. Azt értettem alatta, hogy a js. még a managed kódhoz képest is tetűlassú lesz (nem szólva a C++-os natív kódról).

    A fizika megint olyan amit a játéktól független - nyilván natív kódú, halálra optimalizált - könyvtárak biztosítanak a jelenlegi játékokban is.

    Ami nyilván nem fog menni js alatt. Erről beszéltem.
    Mutasd a teljes hozzászólást!
abcd