JavaScript vs C++ sebesség off
2013-10-26T18:44:57+02:00
2013-11-08T02:03:15+01:00
2022-07-19T04:01:54+02:00
  • Tehát itt is megint megvan a magyarázat, hogy miért nem is lassabb a lassabb C++, és miért nem is gyorsabb a gyorsabb JS. És hát ez a lényeg, nem?

    Próbáltam korrekt lenni és elmondani, hogy van egy ilyen. Volt is róla cikk a Hacker News helyen.

    Így ma is nyugodtan hajthatod álomra fejed, abban az édes tudatban, hogy az egyetlen nyelv amihez konyítasz valamit, minden más nyelvnél jobb, mindenre.

    Gratulálok a stílusodhoz én ilyen szintre azért nem süllyedek le. Azt azért nem mondanám hogy egy nyelvű vagyok. Ellenben olyan képtelenségeket állítasz folyamatosan, hogy nem tudom eldönteni, hogy komolyan gondolod, vagy provokálsz és csak a hozzászólásokat pörgeted. Szerintem őszintén el is hiszed amit írsz. Hát ezen nem tudok segíteni, pláne érvekkel, meg tényekkel.
    Mutasd a teljes hozzászólást!
  • Tehát itt is megint megvan a magyarázat, hogy miért nem is lassabb a lassabb C++, és miért nem is gyorsabb a gyorsabb JS. Így ma is nyugodtan hajthatod álomra fejed, abban az édes tudatban, hogy az egyetlen nyelv amihez konyítasz valamit, minden más nyelvnél jobb, mindenre. És hát ez a lényeg, nem?
    Mutasd a teljes hozzászólást!
  • Egyébként az egyik esetben gyorsabb a JavaScript, méghozzá a regex-es tesztben, ugyanis a Google lecserélte a regex engine-t alatta valami újra nemrégiben, amit persze C++-ban írtak és a C++-os verzió még a régin re2-es engine-t használja.
    Mutasd a teljes hozzászólást!
  • Tanulni inkább neked kellene.
    Mutasd a teljes hozzászólást!
  • De jó is lenne, ha legalább csak minden harmadik mondatból amit leírok akár csak a felét is értenéd. Képzeld mennyit tanulhatnál nap, mint nap!
    Mutasd a teljes hozzászólást!
  • Ezek szerint az elmúlt pár hétben sem néztél annak utána, hogy miként működnek a modern JavaScript futtatómotorok.

    Tulajdonképpen mikor volt utoljára amikor valami újat tanultál vagy egyáltalán csak megértettél az informatika világából? 15 évvel ezelőtt?

    Ezt inkább tőled kérdezném? Persze ha úgy állsz hozzá, ahogy a tesztekhez is és becsukod a szemed és le sem futtatod őket, úgy nehéz tanulni. A modern JS motorok sem képesek csodára, ha a bemenet egy dinamikus adatstruktúra.

    Vannak elismert benchamark tesztek:
    http://benchmarksgame.alioth.debian.org/

    pl. itt ez a teszt eset, na, melyik a gyorsabb, mennyivel?
    http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody

    Ezek alapján sem látom, hogy annyit fejlődtek volna a JS motorok, mint amennyire állítod.
    Mutasd a teljes hozzászólást!
  • Amit te mutattál az nem pool volt, hanem leak. Mert hogy pl. soha a büdös életben nem szabadította fel a memóriát. Nem mellesleg adott esetben a plusz 10 sor is igen jelentős növekedést jelentett a program kódjának méretében, hiszen az egész pártíz soros volt.

    Mert nem is kell olyankor felszabadítani, mert felszabadul a poolal együtt, ami eleve a stacken volt. De wazze, a noheap verzióban nem is volt heap allokálás!! Mit kéne felszabadítani, a semmit??!

    Nem ezt mondja.

    Nem tudom van-e rá hivatalos definició, de a lényege kb. ez.

    Orvost!

    Jól vagy?

    Papot!

    Jól vagy? Vagy ennyire újdonságként ér, hogy a típusos nyelvek tudják az objektumok méretét? A vallást meg ne keverjük ide.

    Amit éppen a konkrét példa cáfolt. A JS 3x gyorsabb volt a C++ kódnál.

    Ami mellett ott volt a gyorsabb C++ változat, amit le se futtattál, majd amikor adtad egy teljesen hasonló noheapest, azt se futtattad le. De ismételgesd csak, hoy 3x gyorsabb a JS.

    Már megint befordultál a sarokba

    Minekután Te nem voltál hajlandó lefuttatni, lefutatta a topicba más is. Az eredményét nem vitattad, a topic lezárult. Most meg előszeded és hivatkozol rá.
    Mutasd a teljes hozzászólást!
  • Leírtuk már ezerszer, a menedzselt memória és a dinamikus adatszerkezetek.

    Nem "leírtuk", hanem "leírtad". És leírhatod 1001.-szer is, attól ugyanolyan hülyeség marad.

    Hiszen két hete még azt mondtad, hogy a - te megfogalmazásodban - "menedzselt memória" volt az ami miatt a JS gyorsabban végzett a binarytree benchmarkban, mint a C++. Most meg azt mondod, hogy attól lesz lassabb? Ismét magadat cáfolod. Döntsd már el, hogy mit is akarsz bizonygatni!

    A másik, hogy JavaScript-ben is vannak nem dinamikus (ún. típusos) szerkezetek. Ugyanakkor nyilván egy C++ programban is lehet, sőt, szinte mindig kell is valamilyen dinamikus szerkezetet kezelni. Tehát ebből megint nem vonható le általános érvényű konklúzió.

    Nem tud címet számolni a fordító, ill. fel kell készülni arra, hogy az objektum megváltozik.

    Ezek szerint az elmúlt pár hétben sem néztél annak utána, hogy miként működnek a modern JavaScript futtatómotorok.

    Tulajdonképpen mikor volt utoljára amikor valami újat tanultál vagy egyáltalán csak megértettél az informatika világából? 15 évvel ezelőtt?
    Mutasd a teljes hozzászólást!
  • Mutattam neked 10 soros memory poolt is, ami nem más bájt tomb

    Amit te mutattál az nem pool volt, hanem leak. Mert hogy pl. soha a büdös életben nem szabadította fel a memóriát. Nem mellesleg adott esetben a plusz 10 sor is igen jelentős növekedést jelentett a program kódjának méretében, hiszen az egész pártíz soros volt.

    Nem tudom miről beszélsz

    Ez teljesen nyilvánvaló volt eddig is. Nem tudom miért írod meg.

    A RAII filozófia meg annyit mond, hogy mindenki tartozik valahová, azaz minden objektum egy másik objektumban van.

    Nem ezt mondja.

    Ez azért jó módszer, mert ha belerakod az objektumot a másikba, akkor nem kell allokálni sem mert a fordító tudja az objektum méretét.

    Anyám, borogass!

    Az csak a menedzselt nyelvek sajátja, hogy egyáltalán allokálásra szükség van mindig, azaz hívni kell egy new operátort.

    Orvost!

    C++ alapból előre kiszámított helyre rakja az az objektumot, vagy egy másik objektumba, vagy a stackre.

    Papot!

    Ha JS, C++ ra célzol, akkor még mindig az van, hogy a JS általában 2-70x lassabb, mint a C++-os társa

    Amit éppen a konkrét példa cáfolt. A JS 3x gyorsabb volt a C++ kódnál.

    Ezt persze azzal ütöd el, hogy a gyorsabb megoldásokat le sem futtatod.

    Már megint befordultál a sarokba.
    Mutasd a teljes hozzászólást!
  • Hát, persze, hogy nem te. Te csak nem vagy hajlandó tudomást venni a számodra nem kedves tényekről.


    Én nem veszek tudomást? Le sem futtattad az általad belinkelt tesztet, amikor kiderült hogy az gyorsabb. Mégis, ez milyen viselkedés?

    És mégis szerinted mi az a tervezési sajátosság amiből ez következik?

    Leírtuk már ezerszer, a menedzselt memória és a dinamikus adatszerkezetek. Nem tud címet számolni a fordító, ill. fel kell készülni arra, hogy az objektum megváltozik.

    Látom megint visszaestél a "befordulok a sarokba és elkezdem ismételgetni magamnak a hülyeségeimet/hazugságaimat (úgy mintha igaz lenne és nem cáfolták volna már ezerszer), hátha akkor nem kell szembenézni a valósággal" rutinba. Kár. Jó lenne már túllépned ezen.

    Na, akkor ki nem vesz tudomást a valóságról??!
    Mutasd a teljes hozzászólást!
  • 50000%-kal (mert egy komplett új memóriamenedzsert kell írni egy nyomorult rendezéshez)

    És még én túlzok?! Mutattam neked 10 soros memory poolt is, ami nem más bájt tömb. Csak egymás mellé kell rakni a példányokat, de erre számos kész megoldás van. Illetve a RAII elv miatt eleve ilyenben gondolkodnak a fejlesztők.

    Ezen feladatok jellemzően mind-mind más adatstruktúrák, memóriamenedzsment, feldolgozási minta mellett végezhetők el a leghatékonyabban - viszont utóbbiak keverésére a legritkább esetben van mód, vagy ha lehetséges is a legritkább esetben hatékony (mert az illesztések mentén keletkező feldolgozási és adminisztrációs többleten elvesztjük azt, amit amúgy nyernénk).

    Nem tudom miről beszélsz, allokálni csak egyszer kell. A RAII filozófia meg annyit mond, hogy mindenki tartozik valahová, azaz minden objektum egy másik objektumban van. Ez azért jó módszer, mert ha belerakod az objektumot a másikba, akkor nem kell allokálni sem mert a fordító tudja az objektum méretét. Az csak a menedzselt nyelvek sajátja, hogy egyáltalán allokálásra szükség van mindig, azaz hívni kell egy new operátort. C++ alapból előre kiszámított helyre rakja az az objektumot, vagy egy másik objektumba, vagy a stackre. Miután elkészült az objektum, jellemzően pointert, referenciát állítunk rá és azzal hivatkozunk rá. De a gyakorlat is azt mutatja, hogy ez a leggyorsabb és leghatékonyabb mód. Arról nem is beszélve, hogy a destruktálás is ddeterminisztikus. Nem véletlen, hogy dobta az Apple is a menedzselt memóriát, meg a garbage collectort.

    Persze, mint már annyiszor mondtam, a lóláb ott lóg mindig egyes embereknél, hogy ők csak akkor jönnek rá az olyan alapigazságokra, hogy a feladathoz választjuk az eszközt vagy hogy a nyelvhez igazítjuk a feldolgozási mintánk, amikor egy általuk lenézett technológia, nyelv ver rá köröket amúgy egy általuk sokra tartott másik technológiára, nyelvre.

    Ha JS, C++ ra célzol, akkor még mindig az van, hogy a JS általában 2-70x lassabb, mint a C++-os társa, max ki lehet hozni, az az, hogy nagyon megközelíti sebességben egyes kis tesztekben. Ezt persze azzal ütöd el, hogy a gyorsabb megoldásokat le sem futtatod.
    Mutasd a teljes hozzászólást!
  • Én nem vagyok ilyen elvakult

    Hát, persze, hogy nem te. Te csak nem vagy hajlandó tudomást venni a számodra nem kedves tényekről.

    de egyszerűen a felépítéséből akad a JS lassúsága, ez már tervezésekor eldőlt.

    Aha. És mégis szerinted mi az a tervezési sajátosság amiből ez következik?

    Konkrétan a múltok te linkelted be nekem azt a tesztett ami gyorsabb volt, majd amikor kiderült hogy gyorsabb egyszerűen nem futtattad le, majd egy másik lassabb tesztet kezdtél elemezni, mondván az jobban közelíti az eredetit.

    Látom megint visszaestél a "befordulok a sarokba és elkezdem ismételgetni magamnak a hülyeségeimet/hazugságaimat (úgy mintha igaz lenne és nem cáfolták volna már ezerszer), hátha akkor nem kell szembenézni a valósággal" kényszeres hárítási rutinjába. Kár. Jó lenne már túllépned ezen.
    Mutasd a teljes hozzászólást!
  • Ejj, de buta vagy! Hát, nem érted meg, hogy az a teszt, amiben az jön ki, hogy a JavaScript gyorsabb vagy akár csak közel is olyan gyors, mint a C++, az - definíció szerint - rossz és hibás?! Mert olyan nincs. Az csak mérési hiba ha mégis.


    Én nem vagyok ilyen elvakult, de egyszerűen a felépítéséből akad a JS lassúsága, ez már tervezésekor eldőlt.

    Ha ilyen tesztet, benchmarkot, rutint találsz, akkor addig kell hegeszteni, optimalizálgatni a C++-os változatot (és szigorúan csak azt) amíg az nem lesz a gyorsabb.


    Konkrétan a múltok te linkelted be nekem azt a tesztett ami gyorsabb volt, majd amikor kiderült hogy gyorsabb egyszerűen nem futtattad le, majd egy másik lassabb tesztet kezdtél elemezni, mondván az jobban közelíti az eredetit.
    Mutasd a teljes hozzászólást!
  • Persze ha az adott platformon van chrome. pl. Samsung Galaxy Mini-n még az sincs.
    Mutasd a teljes hozzászólást!
  • Mielőtt még tovább oktatsz: Direkt az a rész van mérve, ahol nincs allokacio, hogy ne a 2 rendszer eltero memoriamanageret hasonlitsa ossze.


    Én a cacheről beszéltem, nem a memória menedzserről. Egyszerűen memóriára várnak a procik.
    Mutasd a teljes hozzászólást!
  • Srácok! Így hajnal 1kor eszembe jutott valami!

    Hülyeség az egész! :D

    Ha megnézel egy Chrome böngészőt egy 1 magos tableten és azon futtatod a JS random prím generálást, piszok lassú lesz.

    Ha egy új Win8 tableten az új IE alatt akkor mivel erre van kihegyezve, gyanítom C++ közeli lesz az élmény!

    Tehát a JS futtató motorjától nagyban függ a kódsebesség!

    De általánosságban elmondható talán, hogy UI specifikus alkalmazások és játék appok esetén, pontosan a JS kódsebességének a kiszámíthatatlansága miatt nem jó választás, fejlesztési szempontból a JS.
    Mutasd a teljes hozzászólást!
  • Aminek meg nyilván semmi értelme sincsen, hiszen egy normális programozó úgyis úgy írja meg a programját, hogy a lehető legtöbbet hozza ki a nyelvből.

    Vagy nem. Mert vannak peremfeltételek amiknek meg kell felelnie és amin nem tud változtatni. Pl. dolgok, amiket a használt alap-keretrendszer (STL, MFC, CLR), a használt külső könyvtárak, komponensek, az operációs rendszer vagy a ki- és bemeneti formátumok, az illeszkedések más rendszerekkel rá kényszerítenek. Az, hogy olyan memóriamenedzsmentet, olyan adattárolási struktúrákat, stb. használok amit csak akarok, az csak addig igaz és lehetséges, amíg kizárólag az én általam írt kódok dolgoznak az adatokon és azokat sehova nem adják át.

    De amint ez nem teljesül, már az sem lesz igaz, hogy szabad a kezem, és úgy írom át a kódot ahogy akarom, és a nyelvhez tudom optimalizálni annak minden részletét, sajátosságát. Márpedig manapság egy tipikus programban bőven 1% alatt van annak a kódnak a mennyisége, amit az alkalmazásprogramozó ír meg ahhoz a kódhoz képest, amit a program teljes egésze futtat. Innentől kezdve dőreség azt gondolni, hogy a valós világban megoldandó feladatok vonatkozásában megengedhető ill. értelmes egy olyan összehasonlítás, amiben úgy alakítom át a feldolgozás menetét és jellemzőit, ahogy csak akarom. Mert hogy a valós életbeli programok esetében ez a legritkább esetben van így.

    De ha még történetesen 100% is lenne a kód ami felett kontrollt gyakorol a programozó és teljesen szabad keze lenne egy adott nyelven, platformon belül a kód és a feldolgozási struktúra alakításában (ami persze soha nincs így már évtizedek óta), még akkor is ott van a másik dolog, hogy nagyon nem mindegy, hogy mennyi kódot is kell neki bepötyögnie az adott eredmény eléréséhez.

    Ha a C++ csak úgy tud közel olyan gyors vagy gyorsabb lenni, mint a JavaScript kód, hogy benne ugyanazon feladat ellátásához 10-20-30% vagy akár 50000%-kal (mert egy komplett új memóriamenedzsert kell írni egy nyomorult rendezéshez) több kódot kell írni, akkor nyugodtan kijelenthetjük, hogy az adott feladat megvalósítására egyszerűen a C++ nem jó, nem hatékony eszköz.

    Arról akkor még nem is beszéltem, hogy egy-egy alkalmazáson belül jellemzően a legkülönbözőbb karakterisztikájú feldolgozások keverednek. Pl. általában minden programban kell számításokat végezni, kell szöveges adatokon vagy információkon feldolgozást végezni, kell adatokat kiírni és beolvasni, szerializálni és deszerializálni, esetleg betömöríteni és kitömöríteni, grafikus adatokat létrehozni és manipulálni, stb. Ezen feladatok jellemzően mind-mind más adatstruktúrák, memóriamenedzsment, feldolgozási minta mellett végezhetők el a leghatékonyabban - viszont utóbbiak keverésére a legritkább esetben van mód, vagy ha lehetséges is a legritkább esetben hatékony (mert az illesztések mentén keletkező feldolgozási és adminisztrációs többleten elvesztjük azt, amit amúgy nyernénk).

    Ez is az ellen szól, hogy értelmes lehetne az, hogy úgy hasonlítjuk össze nyelvek, platformok hatékonyságát, hogy igen apró és egyszerű részfeladatokat végeztetünk el velük, külön-külön tesztekben és úgy, hogy minden esetben külön-külön megengedjük a kód ill. a program és az általa teremtett működési környezet az adott (rész)feladathoz szabását, optimalizálását, még olyan alapvető és általános érvényű jellemzők vonatkozásában is, mint pl. a memóriamenedzser vagy az általa alkalmazott allokációs stratégia. Mert hogy egy valós programban ez nem vagy csak igen korlátosan és költségesen lehetséges, az alapvetően eltérő környezetet igénylő (ill. azok mellett optimálisan működő) feladatok sokféle, egymásnak gyakran ellentmondó elvárásai miatt. Tehát egy valós programban sosem fognak tudni az azt felépítő részfeladatok a számukra legoptimálisabb környezetben és feltételek mellett működni, hanem többé vagy kevésbé egy a többi részfeladattal közös, megosztott, kvázi legkisebb közös nevezőt képezi környezeten és (kód)infrastruktúrán futnak majd. Amiben nyilván teljesen eltérő karakterisztikák mellett dolgoznak és eltérő sebességet produkálnak majd, mint a külön-külön választott tesztekben.



    Persze, mint már annyiszor mondtam, a lóláb ott lóg mindig egyes embereknél, hogy ők csak akkor jönnek rá az olyan alapigazságokra, hogy a feladathoz választjuk az eszközt vagy hogy a nyelvhez igazítjuk a feldolgozási mintánk, amikor egy általuk lenézett technológia, nyelv ver rá köröket amúgy egy általuk sokra tartott másik technológiára, nyelvre. Mert akkor ugye hirtelen meg kell tudni magyarázni, hogy az összehasonlítás miért nem volt jó, az eredmények miért irrelevánsak, és miért nem is lassabb és rosszabb a kedvenc eszközük, az általuk utált másiknál.

    Amikor viszont ugyanez fordítva van, és az általuk úgymond evidensnek és kívánatosnak tartott papírforma jön ki egy ilyen összehasonlításban, akkor sose jutnak eszükbe ugyanezek az okosságok. Az meg pláne nem, hogy elkezdjék keresni, hogy miért volt inkorrekt a teszt az alulmaradt nyelvvel szemben, vagy milyen optimalizációkat, hozzáigazításokat nem hajtottak végre annak esetében, ami akár alapvetően meg is változtathatta volna az eredményeket.
    Mutasd a teljes hozzászólást!
  • Egy rendes tesztben a feladat és a kívánt eredmény van leírva, oszt' minden rendszer oldja meg úgy, ahogy tetszik, csak az eredemény legyen meg.

    Ha ez így lenne, akkor is értelmetlen és inkorrekt maradna az összehasonlítás, pusztán annál fogva, hogy ez a hozzáigazítás a nyelvhez ill. az optimalizációk átvezetése csak a C++ változat esetében történt meg, a JavaScript esetében nem.

    Mert olyan nincs, hogy egy-egy rendszernek nincsenek előnyei és hátrányai.

    Örülük, hogy végre megértetted. Mert, hogy pár héttel ezelőtt még olyan kijelentésekre ragadtattad magad, ami szerint "az igazán fontos, maradandó, jelentős és értékes szoftverek mind C/C++ alapúak" - ami nyilván összeegyeztethetetlen a mostani kijelentéseddel.

    Ha meg olyan a teszt "játékszabálya", hogy az egyik rendszernek akarunk kedvezni és ezért annak az előnyei játszanak, a hátrányait pedig ki lehet hagyni a mérésből, az nem teszt, hanem egy nonszensz.

    Örülük, hogy végre elfogadtad az álláspontom, és most már te is azt szajkózod. Még ha úgy is próbálod beállítani, mint ha nem pontosan ez lenne a helyzet lenne.
    Mutasd a teljes hozzászólást!
  • "Egy benchmark definíció szerint úgy működik, hogy minden megmérendő rendszeren, környezetben lefuttatjuk pontosan ugyanazt a művelesort (kódot), megmérjük mennyi idő volt szükséges ehhez, és ebből vonunk le következtetést a rendszerek eltérő komponenseinek feldolgozási sebessége vonatkozásában."


    Hát itt nagyot tévedsz.

    Egy rendes tesztben a feladat és a kívánt eredmény van leírva, oszt' minden rendszer oldja meg úgy, ahogy tetszik, csak az eredemény legyen meg.

    Mert olyan nincs, hogy egy-egy rendszernek nincsenek előnyei és hátrányai.
    Ha meg olyan a teszt "játékszabálya", hogy az egyik rendszernek akarunk kedvezni és ezért annak az előnyei játszanak, a hátrányait pedig ki lehet hagyni a mérésből, az nem teszt, hanem egy nonszensz.

    Ez nagyon emlékeztet néhány multi benchmark marketingjére... láttam már ilyet, azt sem hittem el, miután megmutatták a "játékszabályokat" (pl. az egyik adatbáziskezelőt default módon telepítették, a másikat rákonfigurálták az adott hardverre).

    Mutasd a teljes hozzászólást!
  • Ebben az egész veszekedésben az a röhej, hogy az ilyen összehasonlításnak csak és kizárólag akkor van értelme, ha az adott problémára adott nyelvenkénti leggyorsabb megoldásokat hasonlítjuk össze.

    Így ez csak egy szánalmas sárdobálás, hiszen bármikor lehet találni olyan implementációt (egymásra legjobban hasonlító forráskódokkal), amelyikkel a JS a gyorsabb, meg amelyikkel a C++ a gyorsabb.

    Aminek meg nyilván semmi értelme sincsen, hiszen egy normális programozó úgyis úgy írja meg a programját, hogy a lehető legtöbbet hozza ki a nyelvből.
    Mutasd a teljes hozzászólást!
  • Ejj, de buta vagy! Hát, nem érted meg, hogy az a teszt, amiben az jön ki, hogy a JavaScript gyorsabb vagy akár csak közel is olyan gyors, mint a C++, az - definíció szerint - rossz és hibás?! Mert olyan nincs. Az csak mérési hiba ha mégis.

    Ha ilyen tesztet, benchmarkot, rutint találsz, akkor addig kell hegeszteni, optimalizálgatni a C++-os változatot (és szigorúan csak azt) amíg az nem lesz a gyorsabb. A JavaScript kódban pedig csak lassítóciklusok berakása megengedett. Aztán ha ezekkel megvagy, akkor lefuttathatod a két teljesen különböző kódot, és ezek alapján megállapíthatod, hogy a C++ a jobb és gyorsabb nyelv. Mindenre.

    Látod milyen egyszerű? Péter kolléga is szépen bemutatta ezt. Így kell hiteles és megalapozott nyelvek közötti össszehasonlítást csinálni, szakmai reputációt építeni!
    Mutasd a teljes hozzászólást!
  • Mielôtt még tovább oktatsz: Direkt az a rész van mérve, ahol nincs allokacio, hogy ne a 2 rendszer eltero memoriamanageret hasonlitsa ossze.

    ---------------------------------------------------------
    goph-R

    En is kivancsi voltam, hogy hogy megy a gepemen: (3ghz phenom2 512MB L2 cache :( )

    chrome (win7 64bit): 23607ms
    mscv 2012 -O3 win32: 23389ms abszolut minimalis ez a kulonbseg.

    pretty close, huh
    Viszont a nagyon kics cache-ba a 800K eppenhogy nem fert bele, emiatt 50000 elemmel is probaltam tesztekek:

    chrome:5901
    mscv: 5671 kicsit nagyobb, de elegge minimalis a kulonbseg az en gepemen.

    Erdekes lenne megvizsgalni a 2 mainloopot asm-ban.

    Es itt gondoltam egyet, es kiprobaltam Delphi XE win32-vel is:
    22322ms A nagy kulonbseg oka pedig az, hogy (legalabbis win32 targetre) a Delphi nem fordit olyan kodot, ami az 1 vektorhosszusagu SSE utasitasokkal kezeli a double-kat, hanem a jo oreg 'deprecated' FPU utasitasokat hasznalja.

    Es akkor még kiprobaltam, hogy mi van, ha std::vector helyett Qt5.1 QVector-t hasznalok kontenerkent: A 23ms-es 100ezer elemu teszt ekkor felment 100sec fölé . Valahogy kezd meginogni az az elkepzelesem, hogy a Qt-ban mindent a leheto leggyorsabbra optimizaltak le. :S Szoval nekem ez most tanulsagos volt, van par programoreszem, ami erosen hasznalgatja a QVector, hátha érdemes lenne lecserelni azokat std::vector-ra...

    Ps: Ha valaki az Intel forditoval is le tudna forditani es merni az jo lenne.
    Mutasd a teljes hozzászólást!
  • Native Code Performance and Memory: The Elephant in the CPU

    Ezt az előadást érdemes végig pörgetned, szerintem nagyon hasznos.
    Mutasd a teljes hozzászólást!
  • Nem néztem honnan méred, csak kiszúrta a szememet az a megoldás. Mindenesetre 800 000 bájt ígyse, úgyse fog beférni a cache tárolókba így a processzor jórészt memóriára fog várni.

    A JS amúgy a dinamikus szerkezetei miatt lesz lassabb, meg a menedzselt memória miatt. Szóval ha objektumokat, meg memória foglalásokat csinálsz, ezeket jól egymásra halmazod, jól összegubancolod, akkor jönnek ki csúnya eredmények.
    Mutasd a teljes hozzászólást!
  • Most tényleg nem érted, vagy csak a hozzászólások számát akarod növelni? A JavaScrip-ben Garbage Collector van meg menedzselt memória. Nem kapsz memóriacímet. C++-ban meg a te felelősséged az adatok okos elhelyezése és erre rengeteg lehetőséged van.

    JavaScriptben a GC felelőssége, hogy az adatokat a stack-re vagy heapre vagy akárhova rakja. C++ azért tud gyorsabb lenni mint a JS, mert a már fordításkor tudott adatok alapján alakíthatod az adatok elrendezését. C++ amúgy alapból a stackre rak minden objektumot, ilyet a JS-ben nem is lehet kérni, pont a GC miatt.

    Másrészt az ominózus tesztet Te linkelt be nekem, amit szerző mellékelt és ami amúgy az ismert benchmark gameből ered, ahol szintén allokátoros jelölt van C++ oldalán.

    Ezért nem tudom hova akarsz kilyukadni. Nyilván a fentiek miatt gyorsabb a C++. a JS nem ad lehetőséget gyorsabb kód írására, mert nem ad lehetőséget a memória kézi vezérlésére. Ez tervezési filozófia a nyelvnél, feláldozták a sebességet a védettebb memória és a könnyebb tanulhatóság oltárán. Ezek amúgy korrekt előfeltételei egy script nyelvnek.
    Mutasd a teljes hozzászólást!
  • Nem teljesen értem. Az elején teszem be az összes elemet. Az időmérés csak a bubbleSort-ra van. A megvalósítás meg azért ilyen, mert egy szinte teljesen megegyező kódot akartam JS és C++ -ban. Egyébként sem használnék for ciklus feltételében size()-t, ha nem muszáj, meg egy olyan feladatra, ahol ismert az elemek száma, vectort sem. Double-t is csak ha nagyon muszáj
    Mutasd a teljes hozzászólást!
  • Ez a teszt inkább memória sávszélességet, meg cache memória méretet tesztel semmint processzort.

    Ugyanakkor azt tudod, hogy miként viselkedik az std::vector ha nem előre foglalod le a méretét, hanem folyamatosan növelgeted? Ha elér egy limitet, akkor foglal magának egy nagyobb memóriaterületet, majd átmásolja oda magát. Szóval a programod közepén több száz kilobájtot másolgat most a memóriában.

    vector<double> a;

    helyett foglald le előre a teljes méretet:

    vector<double> a(10000);
    Mutasd a teljes hozzászólást!
  • JavaScript (Chrome 30)
    10000 elem: 304ms
    100000 elem: 30601ms

    MSVC++ 2010 (Ox)
    10000 elem: 234ms
    100000 elem: 23915ms

    JS:
    <html> <head> <script> var a = new Array(); function bubbleSort() { var swapped; do { swapped = false; for (var i=0; i < a.length-1; i++) { if (a[i] > a[i+1]) { var temp = a[i]; a[i] = a[i+1]; a[i+1] = temp; swapped = true; } } } while (swapped); } function yep() { for (i = 100000; i > 0; i--) { a.push(i); } document.writeln(Date.now() + "<br>"); bubbleSort(a); document.writeln(Date.now()); } </script> </head> <body onload="yep()"></body> </html>

    C++:
    #include <iostream> #include <vector> #include <Windows.h> using namespace std; vector<double> a; void bubbleSort() { bool swapped; do { swapped = false; for (int i=0; i < a.size()-1; i++) { if (a[i] > a[i+1]) { double temp = a[i]; a[i] = a[i+1]; a[i+1] = temp; swapped = true; } } } while (swapped); } int main(int argc, char* argv[]) { for (int i = 100000; i > 0; i--) { a.push_back(i); } cout << GetTickCount() << endl; bubbleSort(); cout << GetTickCount() << endl; }
    Mutasd a teljes hozzászólást!
  • "Ennyi erővel ragaszkodhatnák (a forrásazonosság szent jelszavával), hogy JS-en futtasd az én C-s pointer aritmetikával gyártott kódomat.
    Bibíííí, az enyim' volt előbb, most te futtasd ugyanezt a forrást"

    Azt csak az ertelmetlen programozo gondolhatja, hogy amit C-ben lehet, de JS-ben nem lehet, azt szabad egy JS>Cpp topicban. Azt nyilvan csak egy Cpp>JS topicban szabad. :D

    A lényeg az, hogy Sting bármilyen értetlenkedő hozzaszolast képes önmagát megcáfoló möbius szalaggá alakítani, ezáltal rövidrezárva az ertelmetlen programozót, aki aztán megsül szégyenében .
    Mutasd a teljes hozzászólást!
  • Értelmes programozó a forrást(!) úgy alakítja, hogy az a feladat megoldáshoz hatékony és ideális legyen.

    Értelmes programozónak eljut az agyáig, hogy ez egy benchmark, aminek a célja a nyelvek sebességének megmérése. Egy benchmark definíció szerint úgy működik, hogy minden megmérendő rendszeren, környezetben lefuttatjuk pontosan ugyanazt a művelesort (kódot), megmérjük mennyi idő volt szükséges ehhez, és ebből vonunk le következtetést a rendszerek eltérő komponenseinek feldolgozási sebessége vonatkozásában.

    Értelmes programozó tudja, hogy egy benchmark teljesen értelmetlen abban az esetben, ha a fenti feltételek a műveleti azonosság vonatkozásában nem teljesülnek, illetve hogy a benchmark mindig csak a futási menetek, mérések között eltérő, változó elemek összességének összehasonlítását teszi lehetővé, de ha egyszerre több változó elem is van, akkor azokét külön-külön nem. Tehát ha egy benchmark mérési menetei között nem csak a nyelv, de az algoritmus is változik, akkor onnantól kezdve a benchmark nem a "nyelv"-ek, hanem a "nyelv+algoritmus"-ok sebességeit fogja összehasonlítani, ami a "nyelv"-ek sebességeinek vonatkozásában semmilyen következtetés levonására nem lesz alkalmas (hiszen nem fogjuk tudni, hogy a mérési eredményekből, különbségekből mekkora a "nyelv" és mekkora az "algoritmus" része, következménye).

    Ezen kívül értelmes programozó belátja, hogy egy olyan összehasonlítás, amelyben az egyik nyelvi változatot elkezdjük módosítgatni, optimalizálni, nem csak hogy értelmetlen, de egyenesen inkorrekt is, ha közben a másik nyelvi változaton hasonló módosításokat, optimalizációkat meg se próbálunk elvégezni.

    Értelmes programozó mindezeket megérti elsőre, és nem kell neki elmondani újra és újra, zsinórban kb. hatodszor is, csak azért, hogy még mindig ne értse meg, és jöjjön az értelmes programozóval és azzal, hogy utóbbi a forrást hogyan igazítgatja a feladat hatékony megoldásához.
    Mutasd a teljes hozzászólást!
abcd