Hirdetés

  2. Fórumok
  3. Processzorok, tuning
  4. Processzorok 64 biten
Keresés

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

  • #115 #95904256 törölt tag hobizsolti #112
    Új Válasz #115
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    #95904256

    törölt tag

    válasz hobizsolti #112 üzenetére

    A lebegőpontos számításokat eddig is tudott az FPU 32/64/80 biten. A 64 bites üzemmód az SSE/SSE2 (32/64bit) alatt hoz annyiban újat hogy most nem nyolc hanem tizenhat regiszterrel gazdálkodhat a programozó. Ez sacc-per-kábé 0-20% teljesítmény növekményt hozhat a lebegőpontos számításoknál. Persze ha kihasználják...

    Az FPU valóban 80 bites számolásra képes, de nem mindig számol annyin. Pl. egyik látványos dolog a viszonylag hosszú ideig tartó osztás. A 80 bites eredmény előállításához a K8-as magnak 24 órajel kell, de egyszeres illetve dupla pontosságnál 16 illetve 20 órajel is elég. Ha mindhárom esetben 80 biten számolna, majd vágna, akkor mindig 24 órajel után lenne eredmény.

    Sőt, ha az SSE/SSE2/FPU gyökvonásokat hasonlítod össze (32/64/80 bit), akkor még látványosabb ez az időbeli különbség.

  • #114 ddekany veterán hobizsolti #112
    Új Válasz #114
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    ddekany

    veterán

    válasz hobizsolti #112 üzenetére

    A lebegőpontos számításhoz külön 80 bits regiszterek vannak (x86-nál... pontosabban x87-nél, de most mindegy) mióta csak megjelent. Ez független az általános célú regiszerek méretétöl. (Jó, mondjuk átmenetileg lehetnek a lebegőpontos számok általános célú regiszterekben, és akkor most már a 64 bites lebegőpontos számokhoz nem kell két regiszter...)

  • #105 #95904256 törölt tag hobizsolti #95
    Új Válasz #105
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    #95904256

    törölt tag

    válasz hobizsolti #95 üzenetére

    a processzorok a pontosság miatt 10 bájton számolnak, csak a végén visszaveszik az eredményt 4 vagy 8 bájtra. hol van itt a 8 bájtos egész?

    Nem értem az egész számra vonatkozó kérdést, kifejtenéd?

    Amúgy a 80 bites számítás/kerekítés csak az FPU bővített pontosságú üzemmódjában áll fenn. ( Bár az összeadás, kivonás, szorzás a pontatlanabb üzemmódokban is 80 biten történik. )

  • #103 Tibord senior tag hobizsolti #95
    Új Válasz #103
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Tibord

    senior tag

    válasz hobizsolti #95 üzenetére

    Az vesse rám az első követ, aki ugy gondolja hogy azért mert én meg tudom szerelni a trabantot meg a ladát mert megtanultam 10 éve akkor már fasza autószerelő vagy és nem kell nekem megtanulni az újabb autók szerelését. autó autó nem mindegy?
    nem azt mondtam hogy a haver optimalizáljon hanem a programozók.
    Elvégre ezt várja el az ember tőlük.
    Én se szeretem ha új dolgot megtanulnom vagy a megszokot jólbevált módszert fel kell adnom de ez a világ rendje. És ezt diktálja a fejlődés és a józan ész.
    egyébként mért nem érdekel 0.1 másodperc?
    Próbáld megcsinálni 2000szer egmás után mingyárt érdekelni fog.

    ennyit erről. A véleményemet írtam le és ez nem biztos hogy egyezik a tieddel

  • #101 Vertic aktív tag hobizsolti #96
    Új Válasz #101
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Vertic

    aktív tag

    válasz hobizsolti #96 üzenetére

    így van.
    Elég kevesen tolják assemblyben... :) egy átlagos alkalmazásnál meg az ember valami fincsi magasszintű nyelvben kb. leszarja, hogy az a változó amit használ épp, az milyen pontosságú - amíg elég az adott pontosság. Tehát ha elég a 4 bájtos integer, akkor senki nem fog 8 bájtosat használni, tök értelmetlen is lenne.
    A lebegőpontos számoknál már sokszor van értelme double-t használni, de ahol kellett, ott eddig is azt használtak, szóval ezzel nem sok nyereség lesz.
    Leginkább a fordítóprogramok feladata az optimalizálás, de az se tud mit csinálni, ha egyszerűen nincs szükség a szélesebb adatra. Ha trükközni lehet a fordításnál, hogy összefoghatnak esetleg két 32 bites adatot, akkor rendben, mondjuk ennek sem tulajdonítok nagy jelentőséget, de a programozók döntő többsége soha nem kerül ezzel közelebbi kapcsolatba, csak kiválasztja, hogy neki mekkora pontosság kell, és csókolom.
    Az optimalizáció inkább a visszairányba szokott kelleni - tehát ha 32 bites platformra írunk programot, és túl lassú, akkor megpróbáljuk a 64 bites változókat olyan keveset használni, amennyire csak lehet, vagy ha nincs FPU a gépben (mobilokra kell gondolni), akkor mindent integerrel old meg az ember amit csak tud, még ha logikusan lebegőpontos kéne is.
    De olyan optimalizációról még nem hallottam, ami gyorsítana valamit, ahol egyszerűen nincs kihasználva ez.
    Tehát valószínű, hogy a képfeldolgozó-renderelő, illetve a hatalmas memóriát vagy nagy pontosságú számítást igénylő programokon kívül a többi (a mindennapi életben használt programok túlnyomó többsége) soha a büdös életben nem lesz gyorsabb 64 biten, és ez nem a programozók hibája. Ennyi.

  • #88 azbest félisten hobizsolti #71
    Új Válasz #88
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    azbest

    félisten

    válasz hobizsolti #71 üzenetére

    Elolvastam a #10-es hozzászólásban található HUP link tartalmát is (avagy linux és 64bit).

    És hasonló következtetésre jutottam, mint amire te is.

    A 16bit -> 32it váltás teljesen más volt. Ugye a lehetőségek nem duplázótak, hanem 65ezerszereződtek, ma meg 4mrdszorozódás van :DDD A memória-korláton kívül a cíkkben írt dolog (hogy kevesebb művelettel lehet ugyanazt elérni) ott valóban erősen kiütközött. 16 vs 32 bit hatalmas különbséget mutat: a számolásban is eléggé korlátozó a 65535, és az érzékszerveink számára is van különbség egy 16bites és 32 (24) bites kép között.

    A 16 bites procival ugye elég nehézkesen, sok művelettel lehet 32 bites végeredményt kihozni. Ehelyett 32 biten egy lépésben elvégezve a feladatot látványos sebességnövekedést látunk a 16 bites megoldáshoz képest. (valószínűleg nem csak 2szerest).

    32 bit elég jól lefedi a legtöbb igényünket. Csak tudományos / speciális alkalmazások ugranak be, ha valós 64 bit igényről van szó (kivéve a memóriakezelés). Persze ahogy mások írták már a plusz regisztereket felhasználva lehet gyorsítani némileg a programokon (a fordítók optimalizálása erre).

    Egy hasonlat: adott egy személyautó és egy teherautó, a végsebességük egyforma. Ha üresen mennek akkor nem igazán gyorsabb egyik sem a másiknál. Viszont ha sok csomagot kell vinni, a teherautó ugyanolyan gyorsan elviszi egyben az összeset, ezzel szemben a személyautó a kis csomagtartója miatt többször kénytelen fordulni, mire mindent a célba szállít.

    Tehát ha egyszer különbség lesz 32bit és 64bit között, akkor az valószínűleg nem abban jelentkezik, hogy a 64biten gyorsulna, hanem a 32biten sokkal lassabban lehet megoldani a kitűzött feladatokat.
    Ma még a hétköznapokban nem nagyon ismerünk olyan problémát, amit 2^32 légy ne tudna megoldani viszont 2^64 de. A fájl mappingos dolog amiről olvastam érdekes dolog és egyike a ritka, de hasznos kivételnek.

    De ismeritek a mondást:
    A számítógéppel olyan problémákra keressük a megoldást, amelyek számítógép nélkül nem is lennének ;]

    Nem tudom pontosan hogyan történik elektronikai szinten a számolás, de el tudom képzelni, hogy a 64 bitet szét lehetne szedni 2x32-re melyek függetlenül is működhetnek de ha kell 64biten egyesítve is. Persze erről rögtön beugrik a HT és a több mag... de végülis ha csak bizonyos feladatokra kell valóban 64bit, akkor az elektronika egy része valószínűleg nagyon nincs kihasználva - csak 0ákat utaztat.

  • #75 #95904256 törölt tag hobizsolti #71
    Új Válasz #75
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    #95904256

    törölt tag

    válasz hobizsolti #71 üzenetére

    Azokkal a műszaki és gyakorlati dolgokkal amit leírtál teljesen egyetértek, viszont azzal ahogy a cikket szemléled, nem.

    Ez a cikk nem szakembereknek szól, hanem az átlagos felhasználókat kívánja kicsit megismertetni a 64 bit nyújtotta előnyökkel, hátrányokkal, lehetőségekkel. Végülis, ők azok akik a többséget alkotják.

  • #72 pok.tom aktív tag hobizsolti #71
    Új Válasz #72
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    pok.tom

    aktív tag

    válasz hobizsolti #71 üzenetére

    kvp777 hozzászólása az egyetlen, amit ebből a fórumból meg lehet tartani.
    szvsz nem programózok vannak csak itt bocs.. ne haza beszélj..
    és pl nekem de talán még aki idetéved ebernek leglaább 50%a nemolvassa végig a te hszedet azis biztos meg h. a felét nemérti..
    mod: nem off topikba akartad rakni?

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