Hirdetés

Új hozzászólás Aktív témák

  • freeapro

    senior tag

    Mi szükség erre egy SoC esetén, 64 biten csak lassabban fog futni minden és több memóriát használ.

  • Male

    nagyúr

    válasz freeapro #1 üzenetére

    A cikk első mondatát elolvastad? Ottvan miért kell nekik.

  • wdtv

    tag

    válasz freeapro #1 üzenetére

    a win8-hoz kell a 64 bit, es igen, lassabb lesz mint a 32 bites, es jobban fogyasztja az aramot is

  • Fooler89

    őstag

    Egy pozitív dolgot szeretnék kiemelni, méghozzá ezzel tuti biztos több tényezős lesz a processzor piac. ami nagyon pozítív az árra nézve. Amire kiváncsi vagyok, hogy vajon az x86 mikor fogja eldobni visszafele kompatibilitást.

    [ Szerkesztve ]

  • Oliverda

    félisten

    válasz freeapro #1 üzenetére

    Lassabban?

    "Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

  • fgordon

    senior tag

    válasz Oliverda #5 üzenetére

    Arra érti szerintem, hogy a regiszterbe berakni/kiolvasni/mozgatni egy 64 bites számot több idő, mint egy 32 biteset, és bizonyos esetben nem indokolt ez, gyorsabb lehet akár a 64 bitesnél az azonos paraméterű 32 bites CPU.

    De mivel ha új architektúra lesz, fejlettebb, gyorsabb, akkor a 64 bites a 32 bites feladatokkal is gyorsabb szokott lenni, mint az előző 32 bites.

    Szervereknél pedig, ahova készül a 64 bites, oda már nélkülözhetetlen a 64 bit.

    ▏▎▍▋▊▉ Gordon (eleinte azt hittem) ▉ ▊▋▍▎▏

  • berVi

    senior tag

    válasz fgordon #6 üzenetére

    bírom ezeket a fogalom nélküli spekulációkat. nyilván lehetséges, hogy valamivel több idő a 64 bites értékeket írkálni (bár hw trükkökkel elég sok mindent meg lehet oldani), de a 64 bites értékből kevesebb kell (->kevesebb írás)! legalábbis egy jó implementációnál ;)

    tessék nézegetni x86 vs x64 benchmarkokat, bizony egyre több szoftver teljesít jobban 64 biten. ahol nem, ott általában csak azért nem, mert az x86 verzió szénné van optimalizálva inline assembly-vel (tipikus példa a LAME mp3 kódoló).

    az egyetlen hátrány, hogy a nagyobb adatszavak miatt nyilván valamivel több memóriát eszik, de ennek csak a betöltésig van szerepe.

    arra meg esetleg gondolhatnátok ti is, hogy a 4GB-os ramot ezek a mobil szarok is nagyon rövid időn belül el fogják érni.

  • ddekany

    veterán

    válasz berVi #9 üzenetére

    "de a 64 bites értékből kevesebb kell (->kevesebb írás)"

    Csak ha közben 2x annyit foglalnak az értékek, akkor ott vagy ahonnan jöttél.

    "valamivel több memóriát eszik, de ennek csak a betöltésig van szerepe"

    A cache-ben is többet foglalnak a 64 bites pointereket (és egyebeket) használó adatstruktúrák.

    Persze a 64 bit, legalábbis memória címeknél, nem lesz hosszú távon megkerülhető.

  • wdtv

    tag

    válasz berVi #9 üzenetére

    elmeletileg ugyanolyan gyors a 32 vs 64bit, legalabbis a vegrehajto egysegek ,de jo ha tudod hogy 4-szerannyi tranzisztor kell a 64 bites aramkorokhoz mint a 32 bitesekhez, emiatt 4-szer annyi a fogyasztas is
    a memoria savszelesseg mind a memorianal mind cache szinten lassul a 64 bites adatok hatasara, persze egy normalis 64 bites programban lehet hasznalni 8, 16, 32 bites adatokat is , nem szuksegszeru mindennek 64 bitesnek lennie

  • szuper-t

    senior tag

    Ideje volt a váltásnak a szűk memória miatt.

    engem már scak az érdekel hány "mag" feldolgozó egység fog dübörögni bennük.

  • Cyberpunk

    félisten

    Hát akkor hamarosan háromszereplős lesz a piac. Kíváncsi vagyok ez hogy tetszik az Intelnek meg az AMD-nek. ;]

    "You said you'd always be there for me.... but you're not..."

  • P.H.

    senior tag

    válasz wdtv #11 üzenetére

    Ezek tipikus sztereotípiák, hogy lassabb 64 biten, mint 32 biten.
    A 64 bites végrehajtáshoz mondjuk kb. ~2x annyi tranzisztor kell, így lehet ugyanannyi idő alatt összeadni két 64 bites számot, mint két 32 bitest. Ez nem lassul, csak esetenként némileg többet fogyaszt (pl. x86 esetében ez úgy van megoldva, hogy ha 32 bites számokon dolgozik az algoritmus, akkor a felső, nem használt 32 bit automatikusan nullázódik; ennek nincs nagy energiaigénye).

    A memóriához, amióta a cache-ek léteznek, nem byte-onként/szavanként fér hozzá a CPU, hanem sokkal nagyobb egységekben (32/64 byte-os cache line pl.): ha hozzá kell nyúlni valahol egyetlen byte-hoz is, akkor is a teljes cacheline-méret (tipikusan 64 byte) beolvasásra kerül; a módosított adatok is ilyen egységekben kerülnek kiírása a memóriába. (Régen, a 90-es években még nagy szó volt a burst memória, azóta mindegyik ilyen alapvetően; erre utal a CL-érték, hogy újracímzés nélkül milyen gyorsan adja/fogadja a memória a folyamatosan egymás után következő értékeket a kívánt méretig).
    És a SIMD-időkben már alap a végrehajtók 64/128 bites cache-hozzáférése, így ez sem növeli a bonyolultságot.

    És természetesen igaz, hogy attól, hogy egy architektúra 64 bitessé válik, még semmilyen forrás- vagy céladata nem fog felduzzadni; a feldolgozott adatok nagy része szabványos (kép- és videoformátumok, adatbázisok, HTML, stb.) :)

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • #95904256

    törölt tag

    válasz P.H. #14 üzenetére

    Megjegyzés: Ott ahol bitről bitre átvitel lehetéseges ( pl. összeadás ), a 64 bites végrehajtók nagyobb késleltetése miatt alacsonyabb órajel érhető el.

  • P.H.

    senior tag

    válasz #95904256 #15 üzenetére

    "nagyobb késleltetése miatt alacsonyabb órajel érhető el.", mint egy kisebb adatméretnél, ugyanazon csíkszélességen - így folytatódna a mondat, nem?
    Talán nem véletlen, hogy a Prescott is csíkszélességváltással hozta be az EM64T-et (és talán ezért is volt sürgős a Netburst-öt a magas órajelben kiforratlan, de alacsony órajelben, Pentium M alatt remeklő 90 nm-re váltani... és ezt a hatást a P4 staggered addere elég jól elrejtette; manapság meg már nem gond sehol ez), ahogy az ARM is összeköti ezzel (2012 = 28 nm). :)

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • Abu85

    HÁZIGAZDA

    válasz P.H. #16 üzenetére

    Szerintem az ARMv8-nál 20 nm-re ugranak. A 28 nm-es gyártástechnológiákhoz a Cortex-A7 és -A15 készül(t). Tekintve, hogy 2014-re mondanak prototípust, simán ugorhatnak ekkorát.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • csib41

    aktív tag

    válasz Abu85 #17 üzenetére

    Nem ide illik, de kb. mikor lesz kézzel fogható teljes értékű processzor 20nm alatt? Mert már elég közel járnak hozzá.

  • Abu85

    HÁZIGAZDA

    válasz csib41 #18 üzenetére

    A pletykált hosszútávú tervek alapján 20 nm alatt ritka lesz a processzor, mint a fehér holló. APU-k és SoC-ok lesznek zömében. De amúgy 2014 után.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Joachim21

    senior tag

    Ezek szerint az Nv Denver projektje is 32bites még?

    Aki kérdez az hülye, de aki nem kérdez az is marad.

  • Abu85

    HÁZIGAZDA

    válasz Joachim21 #20 üzenetére

    Nem tudni pontosan. Abból, hogy az ARM már készített fordítót az A64-re az következtethető, hogy az utasításarchitektúra kész van. Ezt az NV felhasználhatja egy saját tervezésű processzorhoz. Ezzel a Denver már támogathatja az A64-et.

    Azt mindenképp látni kell, hogy az ARM teljes chipdizájnt kínál licenc alatt, mert sokan nem dolgozzák ezt ki (elsősorban pénzhiány miatt, de ez nyilván nem gond), így szimplán változtatás nélkül, vagy minimális változtatással átveszik a magokat. Természetesen aki saját dizájnt akar, az megteheti, hogy csak az utasításarchitektúrát licenceli, plusz ami még kell a fejlesztéshez. Az ARM számára lényegében mindegy, hogy pontosan miért fizetnek a partnerek, csak fizessenek minél többen. Na most saját dizájn mellett akár gyorsabban is piacra dobható egy-egy A64-es mag.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Joachim21

    senior tag

    válasz Abu85 #21 üzenetére

    Érdekes lesz, remélem idővel az ARM megkavarja a PC/mobilPC piacot, amiben előnyük lehet, hogy bárki vehet licencet, bárki hozhat innovatív újdonságokat. Nv mellé kellene még két három erős kihívó, (Qualcom, TI, Apple?, Samsung) akik bevállalják a saját nagyteljesítményű chipek tervezését.

    Aki kérdez az hülye, de aki nem kérdez az is marad.

  • Pikari

    őstag

    válasz P.H. #14 üzenetére

    aha, aztán ha egy pointereken álló valamin lépdelsz végig, pont 2x akkora memóriaterületen lépkedsz át mintha 32 bites szoftvered lenne = azonnal ~50%-os sebességesés csak attól hogy 64 bited van. Szerintem ne ragozzuk :D

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • P.H.

    senior tag

    válasz Pikari #23 üzenetére

    "aztán ha egy pointereken álló valamin lépdelsz végig,"

    Ilyet miért is tennél? Milyen algoritmus igényli ezt?

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • ddekany

    veterán

    válasz P.H. #24 üzenetére

    Egy alkalmazás memória igényének elég jelentős részét tehetik ki pointerek. Nyilván nyelv és alkalmazásterület függő, de teljesen szokványos, hogy van egy tonna objektumod a heap-ben, amiknek meg van egy rakás mezője ami más objektumokra mutat...

  • Abu85

    HÁZIGAZDA

    válasz Joachim21 #22 üzenetére

    A felsorolt gyártók közül csak a Qualcomm esélyes. A TI és a Samsung nem hiszem, hogy annyira extrém ötletekkel erőltetné a saját fejlesztési vonalat. Szimplán használják az ARM IP-k dizájnját, apróbb módosításokkal. A Samsungnak ez teljesen megfelelő, mert saját maguk is képesek gyártani végterméket. A TI már necces. Idővel szerintem eladják az ARM üzletágat, most vannak ebből a szempontból a csúcson, most lehet érte a legtöbb pénzt kérni (érdeklődő lenne szvsz). Ami a problémákat szüli, hogy mindkét vállalatnak hiányzik a saját GPU, ami nagymértékben csökkenti a versenyképességet a heterogén érában. A Samsung ezért megy az ARM Mali felé, mert az egyfajta biztosíték, de a TI egyelőre nem lép ilyen irányba. A jövő szempontjából alapvetően illene. Ezért is feltételezik sokan, hogy itt a TI ARM üzletágának nem lesz sok szerepe.
    Az Apple-t szerintem érdemes kivenni innen. Ők külön ligában vannak. Az igazi erejük a szoftverből ered, és nem a hardverből.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Pikari

    őstag

    válasz P.H. #24 üzenetére

    elég gáz, ha nem tudsz elképzelni egy ilyen helyzetet sem.

    számítógépes játékokról biztos hallottál már :D
    myscene_object->modell_obj[w]->mesh_obj[j]->vertex[k]->geom_coordf_x

    stb...

    ..

    mondtam.. ne ragozzuk... :D

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • P.H.

    senior tag

    válasz Pikari #28 üzenetére

    Mindig "csodáltam" az olyan embereket, akik egy mondatban el tudják mondani egy-egy (mikro)achitektúráról, hogy az vagy rossz. Nekik olyan egyszerű az élet...

    100%-ig meg voltam győződve arról, hogy valami játékos példát fogsz mondani, aminek vajmi kevés köze van ahhoz, hogy "Az ARM elsősorban a mobil termékek piacán ismert vállalat, de kétségtelen, hogy többre vágynak, és a szerverek szegmensét is szeretnék meghódítani" és ahhoz, hogy "Building on the industry standard 32-bit ARM architecture, the new ARMv8 architecture will expand the reach of ARM processor-based solutions into consumer and enterprise applications where extended virtual addressing and 64-bit data processing are required."

    Viszont a leírt példádra tökéletesen alkalmazható az, amit #14-ben leírtam: szétszórt adatoknál/pointereknél semmit sem számít, hogy 4 helyett 8 byte-osak a mutatók, és a feldolgozandó adat még így is legalább egy nagyságrenddel nagyobb (remélem :) ). Én mondjuk nem egy programomban használok akár több millió pointerből álló tömböt (köszi ddekany, tudom, mire jó a pointer, pl. ezzel kiváltom, hogy minden egység azonos méretű legyen, így megspórolok sokszor akár 500 MB memóriaigényeket is), és minden félelem nélkül árírnám 64 bitre.

    A cikkben leírtakhoz képest az ARM többet is közzétett arról, hogy hogyan képzelik el a 64 bites megoldásaikat. Valóban nagyon hasonlít az x64 32 bithez való hozzáállásához, viszont néhány helyen tovább ment - jófelé - annál is:
    - teljes kompatibilitás a megelőző ARMv7-tel (= 64 bites OS alatt a 64 bites és a 32 bites programok futtathatók)
    - az integer registerek méretét 32 bitről 64 bitre növelik, és számukat 64 bit alatt 16-ról 32 emelik, ahogy a 128 bites SIMD/FP registerek számát is, mappelve a meglevőek alsó bitjeire (x64 esetében mindkettő 8-ról 16-ra növekedett, hasonló mappeléssel); mindezt úgy, hogy marad a 4 byte-os utasításméret (x64 esetén 1 byte-tal nőtt az utasításméret a plusz registerek használatánál)
    - szinte teljes IEEE 754-támogatást adnak, a 64 bites (DP) lebegőpontos műveletekkel együtt
    - utasításszintű AES- és hash-támogatás adnak hozzá
    - (az x64-gyel ellentétben) bevezetik a 4 KB-os lapozás mellett a 64 KB-os lapokat is, ami igen jó alternatíva lehet mind a Linux-ok, mind a jövőbeli Windows-ok esetén a felhasználói programokhoz; a 64KB-os lapokkal átlagosan egy nagyságrenddel (~tizedére) csökkenthető a TLB-tévesztések száma és ekkor is csak 2 memóriaolvasás szükséges 42 bites fizikai címzés esetén. A 64 KB-os lapozás kiterjeszthető 48 bites fizikai címzésre is 3 szintű táblával, ez még mindig megegyezik a jelenlegi LPAE igényével, és kisebb, mint az 4 KB-os lapoké, akár ARM-nál, akár x64-nél.
    - egyszerűsítik az atomi és sorbarendezendő memóriaműveletek kezelését

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • Pikari

    őstag

    válasz P.H. #29 üzenetére

    -egy szóval sem mondtam, hogy az ARM64 (a továbbiakban így hívom az egyszerűség kedvéért) JÓ vagy ROSSZ lenne, csupán kijavítottam a hülyeségedet

    -nekem tetszik az ARM64. Jobb most meglépni ezt az egész átállást, még mielőtt elkezdenének a mobilok is kifutni a memóriából. Némelyiket már így is 1 gigával szerelik, nem árt az, ha eljön az idő, lesz egy teljes architektúra ami egykutya, és amire pikk pakk át lehet álni. Szerverek esetében meg musthave.

    -a játékos példa teljesen tökéletes. de mondhattam volna láncolt listákat, vagy akár adatbázistáblákat is, lényegtelen. A példa teljesen a témába vág, egyszerű, érthető, és jól mutatja a tévedésed.

    -én sem félelemmel gondolok a 64 bitre. Csak attól még a tévedésed tévedés marad. A 64 bit jó. Mindenki szépen álljon csak át rá, amikor szűkségét érzi. Sosem állítottam ennek az ellenkezőjét.

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Pikari

    őstag

    válasz Pikari #30 üzenetére

    a hülyeség szó kicsit erős volt a részemről, bocs

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • P.H.

    senior tag

    válasz Pikari #31 üzenetére

    Leírtad, hogy:
    "(I)myscene_object->modell_obj[w]->mesh_obj[j]->vertex[k]->geom_coordf_x(/I)"

    32 biten kb. hozzávetőlegesen így fordul le egy egyszerű fordító által:
    mov eax,[MYSCENE_OBJECT]
    mov edx,[W]
    mov eax,[eax+CLASS0.MODELL_OBJ+edx*04h]
    mov edx,[J]
    mov eax,[eax+CLASS1.MESH_OBJ+edx*04h]
    mov edx,[K]
    mov eax,[eax+CLASS2.VERTEX+edx*04h]
    mov eax,[eax+CLASS3.GEOM_COORDF_X]

    64 biten kb. erre:
    mov rax,[MYSCENE_OBJECT]
    mov rdx,[W]
    mov rax,[rax+CLASS0.MODELL_OBJ+edx*08h]
    mov rdx,[J]
    mov rax,[rax+CLASS1.MESH_OBJ+edx*08h]
    mov rdx,[K]
    mov rax,[rax+CLASS2.VERTEX+edx*08h]
    mov rax,[rax+CLASS3.GEOM_COORDF_X]

    (A CLASSx.xxx értékek mindkét esetben egész számok, amiket a fordító kiszámol az osztályon belüli valós adattartalom függvényében.)
    Erre írtam én, hogy 64 bites számokat összeadni ugyannnyi időbe (órajelbe) kerül, mint 32 biteseket, és beolvasni a cache-ből/memóriából is ugyanannyi idő.

    Ez a Sandy Bridge Optimalization Manual ide vonatkozó része (2-19):

    Látható, hogy 8-16-32-64 bites integer betöltés között nem tesz különbséget, viszont figyelemre méltó a táblázat feletti "These latencies assume the common
    case of flat segment, that is, segment base address is zero. If segment base is not zero, load latency increases
    " mondat. 64 biten teljesen kivezették a szegmentálást, ezért ott biztosan 0 a szegmens alapcím; 32 biten az OS-től függ, hogy használ-e szegmentálást.
    AMD-nél ezt máshogy oldották meg, ott ez nem növeli a címszámítás idejét (saját gyermek az AMD64 :) ):
    The Opteron has a different implementation. The displacement and segment are summed together before the actual address calculation.[...]The segment value is considered a constant and thus, just like the displacement, know during decoding. The addition is made during decoding/dispatch and the result is passed on together with the rest of the instruction bits as a new "displacement field" of the instruction.[...]An exception is generated whenever the segment value does change. The results of operations depending on it are cancelled and the pipeline is restarted from the right point.

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • Pikari

    őstag

    válasz P.H. #32 üzenetére

    A gondolatmenet jó, a táblázat és a tények is stimmelnek! Azonban az, hogy ugyanannyi idő lenne kiolvasni/beírni őket a memóriába/ból, téves, az okát pedig részletezni is fogom. Maradon a számítógépes játékoknál, mint példánál, hisz az adatstruktúra kialakításától függ a dolog. Amit írtál, az addig igaz, amíg 1 és 2 számot olvasol ki. Itt vannak pl a vertexek és a hozzájuk kapcsolódó sok sok adat, amit már amlítettem, tegyük fel hogy mondjuk van a memóriában összesen a pointerek miatt, mindenestrül az egész struktúra 100 mega. (jelen esetben kb fél millió betöltött polygon elkonzumál ennyit, a mai számítógépes játékokban ennél jóval több van, de ha már armról van szó, bőven elég lesz ennyi, a példa szempontjából meg könnyű vele számolni)

    Ha tehát ilyen szerencsétlenül van kialakítva az egész romhalmaz (persze magára vessen, aki így alakítja ki), akkor 64 biten ebből lesz vagy 170 mega. 32 biten még 100 mega volt, emlékezz.

    És nem a címszámítás idejével van a baj, hanem a memória sávszélességével. Ami adott.

    Tehát ha az egészen végigröpül az algoritmus, akkor 32 bit esetén te ezen a 100 megányi adattömegen hussansz végig, azonban 64 bit esetén a fent említett struktúrával 170 megányit kell, hogy bejárjál.

    Teljesen mindegy, hány biten vagy, a memóriavezérlő és a hozzá kapcsolódó memória egy megadott memory read/sec értéken képes csak pörögni. Tehát ha egy adott gép olvasási memória sávszélessége 4 gbyte/sec, akkor az 32 és 64 bit alatt is ugyanannyi lesz. (armon ennél jóval kevesebb szokott lenni, de a példa szempontjából hogy armról vagy x86ról beszélünk -e, az mind1 is)

    Vagyis ha 32 biten a a fent említett struktúra bejárása mondjuk 0.1 másodperc volt, akkor 64 biten 0.17 másodperc lesz.

    Ez a gyakorlatban azt jelenti, hogy bizonyos esetekben, bizonyos kialakítású grafikus motoroknál egy amúgysem kraftos armos mobiltelefonon egy újgenerációs pl autóversenyes játék 24 fpsről leszottyan 16 fps-re. Szopacs. (és természetesen bármilyen szoftvernél, csak ezt használtam példának, mert ez közérthető és egyszerű)

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Drizzt

    nagyúr

    válasz Pikari #33 üzenetére

    Gondolom a memória interfész is 64 bites lesz. Ezesetben pedig egy 32 bájtos adatot olvasni megintcsak pontosan ugyanannyi memóriaolvasási művelet, mint egy 64-est. Tehát ha csak a pointerek mérete változik, s mindeközben az architektúra mind a műveletvégzés, mind a memóriainterfész tekintetében 32-ről 64 bitre nő, akkor műveletszám szempontjából pont ugyanott vagyunk, ahol kiindultunk. És igen, ez egyben azt is jelenti, hogy ami "4 gbyte/sec" volt, az 8 lesz, pusztán a memória interfész szélesítése miatt.

    A tévedés jogát természetesen fenntartom, de meg kell győzni, ha nem igaz. :D

    I am having fun staying poor.

  • Pikari

    őstag

    válasz Drizzt #34 üzenetére

    ,,ez egyben azt is jelenti, hogy ami "4 gbyte/sec" volt, az 8 lesz''

    nem :P összekeverted az adatbusz és a címbusz funkcióját

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • P.H.

    senior tag

    válasz Pikari #33 üzenetére

    Mint ahogy korábban is írtam, a memóriához - mióta a cache-ek léteznek - cacheline méretű, azaz jellemzően 64 byte méretű egységekben fér hozzá a CPU, legyen szó akár egyetlen byte-ról is (szekvenciális feldolgozásnál pedig a hardware-es prefetch-erek is teszik a dolgukat); kivéve a régen MTRRs (Memory Type Range Registers), újabban PAT (Page Attribute Table) által uncached-nek mondott területeket (ilyen pl. az IGP-k esetében az annak dedikált rendszermemória).

    Ott téves a gondolatmeneted (0.1 -> 0.17 mp), hogy ha nem 32/64 bites relációról beszélnénk, hanem arról lenne szó, hogy adott egy 1 millió elemű 8 bites byte-ból és egy szintén 1 milliós, de 16 bites word-ből álló tömb (pl. jobb webcam-ek vagy szkennerek 3x16 bit színadatot tudnak adni pixelenként), akkor te sem mondanád rá kapásból, hogy 2x annyi időbe telik az utóbbi feldolgozása, pedig a méret ilyenkor is 2x akkora.

    És drizzt teljesen jól mondja. Adatbusz és címbusz méretről manapság akkor érdemes beszélni (azon kívül, hogy minden cím adat volt korábban), ha pl. először tisztázzuk magunkban azt, hogy a K10-nél ganged és unganged esetben mekkora is az adatbusz (ugyanaz a hardware, csak a beállításokban van különbség ...ha van :) ).

    [ Szerkesztve ]

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • Pikari

    őstag

    válasz P.H. #36 üzenetére

    nem értek egyet. javaslom, hogy mérjük le :P

    a 8 meg a 16 bitet meg felesleges ide bekeverni, a 16 bites számokkal való tapogatás más okok miatt lesz lassú.

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Pikari

    őstag

    hát akkor a gondolatot tett követte:

    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #ifdef WIN32
    #include <time.h>
    #else
    #include <sys/time.h>
    #endif

    int jelenlegiidovoltmarlekerdezvelinux=0;
    long double elsojelenlegiidolinux=0;
    long double jelenlegi_ido(){
    #ifdef WIN32
    return clock()/1000.0;
    #else
    struct timeval tv;
    gettimeofday(&tv, NULL);
    long double prett_r=(tv.tv_sec * 1000.0 + tv.tv_usec / 1000.0);
    if(!jelenlegiidovoltmarlekerdezvelinux){
    jelenlegiidovoltmarlekerdezvelinux=1;
    elsojelenlegiidolinux=(long double)((long double)prett_r/(long double)1000.0);
    }
    return ((long double)((long double)prett_r/(long double)1000.0)-elsojelenlegiidolinux);
    #endif
    }

    int main(int argc, char *argv[]){

    int lefoglal=1000*1000*20; // 20 millió pointer lefoglalása...

    int ** Pointerhalom;
    printf("Lefoglalas... (%d millio pointer. Ez eltarthat nehany masodpercig.)\n", ((lefoglal/1000)/1000));
    Pointerhalom = (int **)malloc(lefoglal*sizeof(int*));
    unsigned long int csuszka=0, regicsuszka=0;
    for(int foglal=0;foglal<lefoglal;foglal++) {
    // 1 db integer számot foglalok mindnek. a példa szempontjából tökéletes.
    Pointerhalom[foglal] = (int*)malloc(1*sizeof(int));
    Pointerhalom[foglal][0]=argc; // NEHOGY kiopzimizáljon bármit is a compiler!!! Így már nem is fog.
    }
    printf("Szamolas...\n");

    int buzeral=argc+65465;

    // ***********
    // a benchmark
    // ***********
    long double KEZD_IDO=jelenlegi_ido();
    for(int i=0;i<2;i++){
    for(int foglal=0;foglal<lefoglal;foglal++){
    buzeral+= *Pointerhalom[foglal]; // a memóriaterület végigdarálása, és összeadás
    }
    }
    long double VEGE_IDO=jelenlegi_ido();
    // ***********
    // ***********
    // ***********


    printf("%d", buzeral); // NEHOGY kiopzimizáljon bármit is a compiler!!! Így már nem is fog.
    #ifdef WIN32
    system("cls");
    #else
    system("clear");
    #endif
    printf("%f masodpercig tartott az adatstruktura kiolvasasa (kisebb ertek a jobb.)\n", (float)(VEGE_IDO-KEZD_IDO));
    system("PAUSE");
    }

    KONFIG:
    --------

    Linux lapnote 3.0-ARCH #1 SMP PREEMPT Wed Oct 19 10:27:51 CEST 2011 x86_64 4gb RAM Intel(R) Core(TM)2 Duo CPU P7450 @ 2.13GHz GenuineIntel GNU/Linux
    processor : 1
    vendor_id : GenuineIntel
    cpu family : 6
    model : 23
    model name : Intel(R) Core(TM)2 Duo CPU P7450 @ 2.13GHz
    stepping : 10
    cpu MHz : 800.000
    cache size : 3072 KB
    physical id : 0
    siblings : 2
    core id : 1
    cpu cores : 2
    apicid : 1
    initial apicid : 1
    fpu : yes
    fpu_exception : yes
    cpuid level : 13
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts
    bogomips : 4254.09
    clflush size : 64
    cache_alignment : 64
    address sizes : 36 bits physical, 48 bits virtual

    ----------------------------
    64 biten (1.497656 másodperc a pointerek lefoglalásával együtt)
    (g++ main.cpp -o bin64w -o3)
    ----------------------------

    -------------------------------
    32 biten (1.250511 másodperc a pointerek lefoglalásával együtt)
    g++ main.cpp -o bin32w -o3 -m32
    -------------------------------

    konklúzió: a 64 bites pointerek használata miatt a szóban forgó algoritmus futása lassabb, hisz a sávszélesség egységnyi!
    ----------

    konklúzió2: a gondolatmenetetek tévedésen alapul, az enyém a helyes, lásd feljebb.
    -----------

    http://www.ezfasza.com/wp-content/uploads/2011/04/trollface-1.gif

    notice: ha a gettimeofday hülyeségeket ad, írjátok át ilyenre: gettimeofday(&t1, NULL); ... gettimeofday(&t2, NULL);elapsedTime = (t2.tv_sec - t1.tv_sec) * 1000.0; // sec to ms
    elapsedTime += (t2.tv_usec - t1.tv_usec) / 1000.0; // us to ms

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Pikari

    őstag

    válasz Pikari #38 üzenetére

    pointerek lefoglalása nélkül, ahogy a forráskódon látszik (csak az előbb rosszat pasteltem be), csak az algoritmikus bejárás mérve (a lényeg):

    ----------------------------
    64 biten: 283 ms
    (g++ main.cpp -o bin64w -o3)
    ----------------------------

    -------------------------------
    32 biten: 146 ms
    g++ main.cpp -o bin32w -o3 -m32
    -------------------------------

    !!!!
    közel 2x-es lassulás 64 biten a struktúra bejárása közben a megnövekedett pointerméret miatt
    !!!!

    HA a gettimeofday máshogy van implementálva, ez az algoritmus.

    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <sys/time.h>

    int main(int argc, char *argv[]){
    struct timeval t1, t2;
    double elapsedTime;

    int lefoglal=1000*1000*20; // 20 millió pointer lefoglalása...

    int ** Pointerhalom;
    printf("Lefoglalas... (%d millio pointer. Ez eltarthat nehany masodpercig.)\n", ((lefoglal/1000)/1000));
    Pointerhalom = (int **)malloc(lefoglal*sizeof(int*));
    unsigned int csuszka=0, regicsuszka=0;
    for(int foglal=0;foglal<lefoglal;foglal++) {
    // 1 db integer számot foglalok mindnek. a példa szempontjából tökéletes.
    Pointerhalom[foglal] = (int*)malloc(1*sizeof(int));
    Pointerhalom[foglal][0]=argc; // NEHOGY kiopzimizáljon bármit is a compiler!!! Így már nem is fog.
    }
    printf("Szamolas...\n");

    int buzeral=argc+65465;

    // ***********
    // a benchmark
    // ***********
    gettimeofday(&t1, NULL);
    for(int i=0;i<2;i++){
    for(int foglal=0;foglal<lefoglal;foglal++){
    buzeral+= *Pointerhalom[foglal]; // a memóriaterület végigdarálása, és összeadás
    }
    }
    gettimeofday(&t2, NULL);
    // ***********
    // ***********
    // ***********

    printf("%d", buzeral); // NEHOGY kiopzimizáljon bármit is a compiler!!! Így már nem is fog.
    // Compute and print the elapsed time
    elapsedTime = (t2.tv_sec - t1.tv_sec) * 1000.0; // sec to ms
    elapsedTime += (t2.tv_usec - t1.tv_usec) / 1000.0; // us to ms
    printf(" %f", elapsedTime);

    }

    (gratulálok az adminisztrátoroknak az 5 perces szerkesztési limithez, nembaj, talán majd írok 10+ hozzászólást ha rosszat copypastelek :C )

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • #95904256

    törölt tag

    válasz Pikari #39 üzenetére

    (#33) Pikari: "És nem a címszámítás idejével van a baj, hanem a memória sávszélességével."

    Megkérdezhetem, hogy a tesztkonfigod milyen sávszélességgel rendelkezik?

    Csak egy kis számolgatás a tesztprogramod alapján:
    - pointerek száma: 20.000.000
    - pointerméret: 4 - 8 bájt
    - futásidő: 0,146 - 0,283 s
    - sávszélesség: 548 - 565 MB/s

    Megjegyzés: A régi PC100-as SDRAM-os rendszerek tudtak ennyit...

  • Pikari

    őstag

    válasz #95904256 #40 üzenetére

    több helyen is elhibáztad a számolást.

    nézzük a 32 bites esetre a sávszélességet:

    20 millió 4 bájtos pointer az kb 80 megabájt
    PLUSSZ a pointer által tárolt integer amit az alg. kiolvas, az további kb 80 mbyte
    = összesen 160 mbyte memóriaterület (a gyakorlatban nagyobb lesz az oprendszer hülyeségei miatt, de lényegtelen.)

    ez a 160 mbyte adat KÉTSZER olvasódik ki, mivel ott bazsajog egy forciklus i-vel,
    vagyis összesen 320 mbyte-nyi memóriaterület olvasódik ki 0,146 sec alatt.

    a mérés szerint tehát az adott számítógép memóriasávszélessége tehát 2,1+ gbyte/sec

    valójában persze nagyobb, mert ez nem így működik: ez az algoritmus önmagában nem sávszélességmérésre lett kitalálva, a sebességet kiheréli a memcímről másik memcímre mutatás. (bizonyos logika alapján persze ez is egyfajta memory read sávszélesség, pl láncolst listás adatstruktúrákra ez a memóriasávszélesség vonatkozik ezen a gépen)

    (nem, nem mértem meg hogy mekkora a sávszélessége, és nem az enyém a laptop amin mérve lett, szóval erre már nem is fog sor kerülni)

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Pikari

    őstag

    válasz freeapro #41 üzenetére

    szuszáá, ne öld le :D

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • #95904256

    törölt tag

    válasz Pikari #42 üzenetére

    32 bites eset -> 320 MB / 0,146s = 2192 MB/s
    64 bites eset -> 480 MB / 0,283s = 1696 MB/s

    Mitől lett kisebb a sávszélesség?

    szerk.: Másfelől továbbra is érdekelne a tesztkonfigod memóriasebessége. Ugyanis nálam láncolt lista olvasása esetén (ami még szélsőségesebb példa, hiszen ott csak pointerek olvasásából áll az egész ciklusmag) 32-bites esetben 75%, 64-bites esetben 80% körül volt a sávszélesseg kihasználtsága.

    [ Szerkesztve ]

  • Pikari

    őstag

    válasz #95904256 #44 üzenetére

    nem tudom.

    a gyakorlatban a memória sávszélessége kevesebb lesz, mint az elméletben, ezért a 20-30% körüli veszteség nálad a láncolst listával. A laptop tulajdonosával azóta nem találkoztam. de szerintem itt is egy olyan 20%-45% körüli a veszteség. De mérget nem mernék rá venni. A konfigot bemásoltam, talán az interneten írják valahol, hogy mekkora annak a laptopnak a memória olvasási sávszélessége. Esetleg mérd le a bemásolt algoritmussal a te gépeden a sávszélességet, és hasonlítsd össze a gép elméleti sávszélességével, akkor kb-ra megkapod az eredményt amit szeretnél.

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • P.H.

    senior tag

    Én ennyi energiát nem fektettem bele, csak szétnéztem a gépemen, hogy milyen 64 bites programokat használok. Ezeket bárki lefuttathatja, úgyis mindenki a saját szemének hisz. :)

    7zip 32 bites verzió:

    7zip 64 bites verzió:

    WinRar 32 bites verzió:

    WinRar 64 bites verzió:

    50 perces MPEG2 » x264 konvertálás kézzel indítva (a kettő egymás után .bat-ból indítva, időpontok a promptban):
    64 bit: 13 perc 42 másodperc
    32 bit: 14 perc 36 másodperc

    Van épp a gépen egy Cinebench is, kipróbáltam.
    Cinebench R11.5 64 bit: 6.18
    Cinebench R11.5 32 bit: 5.67

    A tömörítőket nem nagyon hatotta meg, hogy 32 vagy 64 bites verziót futtatok, hajszállal gyorsabb a WinRar és kicsitt többel a 7 Zip 64 bit mellett (mérhettem volna ki- és betömörítést, de azok csak ideírt számok lennének). Az x264 és a Cinebench már jobban gyorsult.

    Te írtál egy programot, amiben nemigen teljesült, hogy "a feldolgozandó adat még így is legalább egy nagyságrenddel nagyobb (remélem)", mert nemigen dolgoztál fel semmit (akkor kijönne a + regiszterek jótékony hatása. De nekem mindegy.

    Konklúzió? Szerintem mindenki le tudja vonni. Nekem az, hogy tőled nem szerzek be 64 bites programot. :)

    Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

  • Drizzt

    nagyúr

    válasz Pikari #39 üzenetére

    Szerintem nem azt bizonyítottad, mint amit szerettél volna. Alapvetően a két architektúráról megy a vita, vagyis 32 bites architektúrán a 32 bites program, vs. 64 bites architektúrán a 64 bites program. Épp azt sikerült megmutatnod, hogy 64 bites architektúrán a 32 bites kód nemhogy lassul, hanem gyorsul ebben az adott esetben. A foglalás hosszabb időtartama indokolható azzal, hogy a pointerek kétszeres méretük miatt kétszeres helyet igényelnek. A bejárás gyorsasága sem véletlenül nagyobb, ha kisebb adatokat olvasol, amik egymás mellett helyezkednek el. Alapvetően kétféle magyarázat létezhet: annyira van okos a fordító, hogy a két egymás utáni lépés memóriaműveletét egybevonja, ismervén az összefüggő memóriaterületen való foglalást. Így összességében feleannyi memória olvasás kell összesen, mint amikor kétszer akkorák a pointerek. Másik lehetőség: A fordító nem okos, de az architektúra ebben az estben is feleannyiszor kell, hogy a memóriához nyúljon, mert a 32 bites adatokból pont kétszer annyi fér el egységnyi megcímezhető helyen, mint 64 bitesből. Szép a mérés, de nem a két architektúra különbségét mutatja, hanem 64 bit alatt a 32 bites és a 64 bites program futásának különbségét, erősen sarkított példán.

    Olyat mérni nem hinném, hogy tudnánk, amikor 32 bites architektúrán van ugyanaz a kód, meg 64 bites architektúrán ugyanaz, s a feldolgozó egységek, illetve a memóriabusz szélességén kívül minden egyéb megegyezik, mert szerintem nem csináltak soha így 64 bites változatot valamiből, mindig változik más is.

    Ha van kedved, időd, meg gdb-d, csinálnál egy disassemblyt a futtatható állományról? Kiváncsi lennék mi fordul belőle az egyes esetekben

    I am having fun staying poor.

  • Pikari

    őstag

    válasz P.H. #46 üzenetére

    nekem meg az, hogy nem értetek hozzá (mert nem) :D

    Mondtam egy esetet amikor a 64 bites szoftver sokkal lassabb, nem hittétek el és hülyeségeket magyaráztatok, bizonyítottam, kétségbeesetten bámultatok rá mint borjú az újkapura, most pedig okoskodtok.

    Inkább viseljétek el :D

    64 biten (x86_64) több regisztert tudsz használni, ezért aztán a legtöbb program gyorsabb lesz (kivéve az olyan struktúrákat használó szoftverek mint ami a példa forráskódban implementálva van)!

    Ettől függetlenül persze nagyot tévedtetek, amikor nem ismertétek el a pointerekkel kapcsolatos sávszélességproblémát, gondolom bele se gondoltatok logikusan.

    Drizzt:

    ,,Épp azt sikerült megmutatnod, hogy 64 bites architektúrán a 32 bites kód nemhogy lassul, hanem gyorsul ebben az adott esetben. ''

    nem a 64 bites arhitektúrán gyorsul a 32 bites kód. annak pont így kell futnia ilyen végrehajtási sebességgel és ilyen memóriasebességgel rendelkező 32 bites gépen is.
    nem attól gyorsabb tehát a 32 bites kód, hogy 64 bites arhitektúrán vagyunk !

    ,,A foglalás hosszabb időtartama indokolható azzal, hogy a pointerek kétszeres méretük miatt kétszeres helyet igényelnek. ''
    A foglalás időtartamáról szó sem esett, csak véletlenül került be a tesztelésbe, együtt lett mérve véletlenül az első mérésben a bejárással is. hosszabbnak meg nem lesz hosszabb érezhetően, ebből a szemszögből a kernel a szűk keresztmetszet

    ,,annyira van okos a fordító, hogy a két egymás utáni lépés memóriaműveletét egybevonja''
    32bites bináris, ne fárassz, ez a magyarázat ki van zárva :D

    ,,Szép a mérés, de nem a két architektúra különbségét mutatja, hanem 64 bit alatt a 32 bites és a 64 bites program futásának különbségét, erősen sarkított példán.''
    igen! De azért annyira nem sarkított ez a példa sem.

    ,,disassemblyt a futtatható állományról''
    nem az én laptopom, a kísérletre nem akarok több időt szánni, ami érdekelt azt már kiderítettem. amúgy ott a forráskód, az alapján reprodukálhatod ha akarod, a legújabb (azt hiszem) Arch linux és a benne lévő g++ segítségével.

    [ Szerkesztve ]

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

  • Drizzt

    nagyúr

    válasz Pikari #48 üzenetére

    "nem a 64 bites arhitektúrán gyorsul a 32 bites kód. annak pont így kell futnia ilyen végrehajtási sebességgel és ilyen memóriasebességgel rendelkező 32 bites gépen is."

    De ahhoz, hogy ilyen legyen a memóriasebesség(egy picit problémás ez a megfogalmazás egyébként. Most mit értünk ezalatt? Sávszélesség? Frekvencia?), az kell 32 bites memória-elérés esetén, hogy kétszeres órajelen menjen a memória a 64-bites esethez képest.

    "32bites bináris, ne fárassz, ez a magyarázat ki van zárva". Okés, ebben igazad van, megkavartam magam, csak arra figyeltem, hogy megváltozott a pointer mérete, arra nem, hogy elveszítjük a 64 bites utasításokat.

    ",,Szép a mérés, de nem a két architektúra különbségét mutatja, hanem 64 bit alatt a 32 bites és a 64 bites program futásának különbségét, erősen sarkított példán.''
    igen! De azért annyira nem sarkított ez a példa sem."
    Most akkor igen, vagy nem? Az elején azt írod, hogy a 32 bites architektúrán 32 bites kód ugyanolyan gyors, mint 64 bites architektúrán. Igaz hozzátetted, hogy azonos memóriasebességen. Ha azonos memóriasebesség alatt azonos másodpercenkénti adatátvitelt értünk, akkor igazad van. Viszont ha frekvenciát, akkor nem. A példa meg sarkított, kiváncsi lennék milyen valós programban van legalább annyi pointer, mint adat.

    I am having fun staying poor.

  • Pikari

    őstag

    válasz Drizzt #49 üzenetére

    ,,az kell 32 bites memória-elérés esetén, hogy kétszeres órajelen menjen a memória a 64-bites esethez képest'' + ,,Viszont ha frekvenciát ... '' + ,,az kell 32 bites memória-elérés esetén, hogy kétszeres órajelen menjen a memória a 64-bites esethez képest''

    Az adatbusz Pentium1 óta 64 bites.

    ,,milyen valós programban van legalább annyi pointer, mint adat''

    Ebben elsősorban a 3D-s játékok érintettek, de azokat úgyis 32 bitre hozzák ki.

    A Dunning−Kruger-hatás az a pszichológiai jelenség, amikor korlátozott tudású, kompetenciájú vagy képességű emberek rendkívül hozzáértőnek tartják magukat valamiben, amiben nyilvánvalóan nem azok.

Új hozzászólás Aktív témák