Keresés

Aktív témák

  • Chain|Q

    tag

    Szerintem ennek az egész 64bites mizériának nagyobb a füstje mint a lángja. A fő probléma az egésszel az, hogy önmagában az hogy 64bites valami, még nem jelent egyértelműen sebességnövekedést, sőt bizonyos esetekben akár lassulást is jelenthet. Ez az egyik. A másik az, hogy a jelenlegi x86-64 implementációk korántsem jelentenek jelentős architektúrális változtatást a korábbi CPU-khoz képest, mindössze a CPU-kban lévő mikrokód van úgy módosítva hogy ismerje az új utasításokat is. Mivel végeredményben ugyanazok az adatok kerülnek ugyanazokhoz a végrehajtó egységekhez, látványos gyorsulásra szerintem nem kell számítani és nagyjából ezt igazolják az első tesztek is. Az új utasításkészlet egyébként nem rossz, sőt olyanok vannak benne, amiket az Intelnek már a 386-osba illett volna implementálni (pl. 16db integer regiszter), a baj csak az vele hogy az x86 architektúrán már ez sem segít és azt kell mondjam sajnos tovább nyújtja az Ghz-n futó XT-k korszakát... Kicsit nevetséges már, hogy a G4/1Ghz-es procim raw számítási teljesítményben lazán lever egy bármilyen 2Ghz-s x86-ot, miközben a teljesítményfelvétele 9,5watt...

    Jelenleg egyetlen desktop kategóriájú valódi 64bites CPU van a piacon, ez pedig az IBM PowerPC 970 (a.k.a. G5). Tudja ezt az M$ is, nem véletlenül lesz ilyen CPU pl. az XBox2-ben, meg tudja ezt a PC ipar többi szereplője is, nem véletlenül görcsölnek az Apple reklámjai ellen. Mellesleg megjegyzem, hogy a 64bitre váltás Mac részről is inkább marketingfogás mint tényleges fejlesztés, hiszen a G5 nem annyival gyorsabb a régi G4-eknél mint azt a 64bit, meg az órajel emelkedése, valamint az egyéb fejlesztések indokolnák...

    Viszont tény hogy a 64 szép szám, remekül eladható... :D

    Egyébként a 64bites Windows késését én is marketingfogásnak, meg a régi szövetséges Intel bevárásának tartom inkább, mivel 1., 64bites Windows elég régóta van, hiszen már a 3-as NT-ből is volt Alpha-s verzió, az Alpha pedig (isten nyugosztalja) világ életében 64bites CPU volt. 2., Az M$ már szállítja az XBox2 DevKitet, ami nem más mint egy G5-os PowerMac, csak éppen MacOSX helyett egy 64bites Windows van rajta, annak a rendszernek az előfutára, ami majd az XBox2 fogja hajtani... Go figure...

    Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu

  • Chain|Q

    tag

    válasz Parci #46 üzenetére

    Én egyébként azon sem csodálkoztam volna, ha az Intel richtig mást csinál, tekintve hogy ez a dolog már a legkevésbé sem szól a technológiáról, ellenben a marketingről, a presztízsről meg a hatalomszerzésről annál inkább. Szerencsére túl későn kapcsoltak, addigra az AMD gyakorlatilag sikerre vitte az x86-64-et. Nem kétséges, hogy az Intel az Itaniumot féltette, ezért várt az utolsó pillanatig, de így most mindkét fronton elveszítette ezt a csatát. Persze a háborút távolról sem.

    A 3DNow! vs. SSE tényleg teljesen más volt. Az a baj, hogy az már az MMX-et megjelentetni sem lett volna szabad abban a formában amiben megjelent végül, mivel mai szemmel nézve kb. semmire nem jó, és csak egy további szoftverfejlesztési zsákutcát jelentett. A 3DNow! annyiban volt jó, hogy végre használhatóvá tette az egyébként (IMHO) elégge használhatatlan MMX-et, de éppúgy zsákutcát jelentett, mint az MMX, amire épült. Újabb ballasztot, amit a CPU-k évekig hurcolhatnak majd magukkal, pedig az új szoftverek már réges rég az SSE-t preferálják, érthető okból. (Most nem akarok megint a PPC-vel példálózni, de azért érdemes megnézni az AltiVec utasításkészletet, na az ér valamit, nem is kellett hozzányúlni évek óta.)

    Az x86-64 meg az SSE3 körül most kísértetiesen hasonló dolgok játszódnak le, akkörül a néhány utasítás körül, ami különbözik az Intel és az AMD CPU-iban. Most késhegyre menő csata zajlik néhány órajel körül, amit ezekkel az utasításokkal nyerni lehet, miközben a gyenge fordítóprogramok és a hanyag programozás (meg az x86 egyéb gyengeségei) miatt milliószor annyi teljesítményt (és ezzel együtt energiát) önt ki a világ az ablakon. Szóval ismét megy a sok hűhó a semmiért. Nemtom ki hogy van vele, én speciel nagyon unom...

    Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu

  • Chain|Q

    tag

    válasz Dozer #50 üzenetére

    Nyugi bele, hogy nem lenne ugyanolyan foltozott. Ugyanis a tervezői ismerték a rugalmasság fogalmát. Pl. van ilyen hogy ''optional instruction''. Ez azt jelenti, hogy az adott utasitást nem kell feltétlenül implementálni, ezáltal csökkentve a processzor méreteit, viszont megoldották azt, hogy az OS szintjén emulálhatók legyenek ezek az utasítások. Így a régi, nem használt marhaságok egyszerűen elhagyhatók a CPU-ból, szoftver (OS) oldalon biztosítva a kompatibilitást. Vagy pl. így lehet embedded PowerPC-t tervezni, amely felhasználói szempontból mégis kompatibilis nagyobb testvéreivel. Korábbi példákat a 680x0 CPU családból hozhatnánk, amely gyakorlatilag egyidős a 8086-al, mégis ugyanezek a dolgok megvannak benne... Bár persze ehhez az is hozzátartozik, hogy ezekhez a CPU-khoz mindig is olyan OS-háttér tartozott, amiben ez megvalósítható volt, míg ugye a DOS sem éppen a flexibilitás mindaképe...

    Na jó ez már erősen offtopic.

    Mindenesetre ajánlott olvasmány: PowerPC Microprocessor Family: The Programming Environments for 32-Bit Microprocessors, MPCFPE32B/AD Rev.1 - (C) Motorola, 1997 - [L]http://e-www.motorola.com/files/if/cnb/MPCFPE32B.pdf[/L]

    Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu

  • Chain|Q

    tag

    válasz Raymond #53 üzenetére

    Sajnálom hogy ki kell ábrándítsalak, de a PCWorld-féle Athlon64 vs. G5 tesztnek semmi köze a valósághoz. A Maces programokból a régi, 9.2-re írt változatot tesztelték OSX alatt, (Premiere-ből és Office-ból biztosan) ami gyakorlatilag ugyanaz, mintha egy Athlon64 + Win2003 teljesítményét azáltal akarnád lemérni, hogy hogyan működik alatta egy Clipperben írt DOS-os program. (A régi 9-es progikhoz készült CarbonLib eléggé fáj az OSX-nek.) Arról nem is beszélve, hogy így pl. a dual CPU előnye sem ütközik ki. Rá kell nézni az értékekre, hogy lássuk, semmi sem használta a tesztben a dual CPU-t). Arról nem is beszélve, hogy a G5-öt nem az időközben megjelent, 10.3-as MacOS X-el tesztelték, amely rengeteg optimalizációt tartalmaz hozzá, hanem a régi 10.2-vel, amely G4 optimalizált lévén _SOKKAL_ lassabb G5 esetén. Az csak a hab a tortán, hogy miközben a PC-kben stripe-es RAID volt, az Apple gépek sima hétköznapi IDE HDD kezeléssel szálltak harcba. Ennek RAM elfogyás (swap, lásd nagy Photoshop kép) és videofeldolgozás (lásd Premiere) esetén is óriási jelentősége van, ezt talán nem is kell részletezni. Az meg hogy egy Quake3 bencsmark mennyit ér, had ne minősítsem. (Messze nem a CPU számít, hanem a grafkártya teljesítménye.)

    És még sorolhatnám a további elkövetett marhaságokat az ügy kapcsán, de felesleges. Aki egy egész kicsit is ért a Machez, az az idézett cikk kapcsán kb. lekaparja az arcát kínjában, de semmi esetre sem tekinti azt mérvadonak...

    Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu

  • Chain|Q

    tag

    válasz Power #55 üzenetére

    Ez egy masszív tévhit, hogy 64 biten gyorsulás várható.

    Persze hogy az. Ezt mar enis elmondtam egy korabbi hozzaszolasban. Az optimalizaciot nem a 64bitre ertettem, hanem arra hogy mig a G4 relativ rovid pipelineos CPU, a G5-ben ezek a pipelineok joval hosszabbak, es a szamuk is mas, ezert a manapsag kemenyen G4-re optimalizalt kodokat jelentosen at kell irni hogy a maximum teljesitmenyt gyomoszoljek ki a 970-bol. Mert ugye egy RISC CPU joval kevesbe optimalizalja maganak a futtatando kodot, mint egy CISC.

    Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu

  • Chain|Q

    tag

    válasz Power #63 üzenetére

    És akkor még ott vannak a driverek, ahol eléggé elterjedt az assembly.

    Na ez viszont egy massziv tevhit. Manapsag szinte semmit sem irnak assemblyben, meg relativ kicsi rendszereken sem, egesz egyszeruen azert, mert felesleges. En pl. rovid ideig dolgoztam egy cegnel, ahol GBA-ra (GameBoy Advance) irtunk programot, es a teljes low-level HW vezerles (DMA, meg hasonlok) is C-ben volt, egesz egyszeruen azert, mert nem lett gyorsabb ha asm-ban csinaltuk. Pedig a GBA 16Mhz-s es 32+256K RAM van benne...

    Arrol nem is beszelve, hogy desktop rendszereken meg igyis ugyis lassuak az I/O utasitasok, ergo a buszra var a CPU barmit csinalsz. Szoval szinten total felesleges az asm. Arrol nem is beszelve, hogy ezeken az Athlon/P4/G5 szintu hiperkomplex CPU-kon nincs elo ember aki figyelembe tud venni minden optimalizalasi tenyezot mikozben assemblyben kodol, szoval eleg nagy a valoszinusege, hogy egy atlagos kod lassabb lesz kezzel irva, mintha egy C fordito csinalna. Kicsit vicces, de tenyleg igy van. Persze vannak olyan optimalizaciok es algoritmusok, amelyek mindenkeppen gyorsabbak lesznek asmban csinalva, de egyszeruen nem eri meg egy komoly fejlesztesnel ezeket figyelembe venni. Mar csak azert sem, mert a mai CPU-k annyira a C forditokhoz vannak igazitva, hogy a legtobb regi assemblys trukk nem is mukodik. Ilyen pl. a regi ROR/ROL bitforgatos maszkolos trukkok, amelyek iszony lassuak lesznek P4-en, mert kivettek a HW bitforgato egyseget a P4-bol, egyszeruen azert, mert egy C fordito kvazi sosem general bitforgatast. Es meg lehetne sorolni.

    De hogy egy talan joval kezzelfoghatobb peldat emlitsek, ott a Linux kernel, nezzetek bele a forrasaba. A device-driverek abszolutt tulnyomo resze egyaltalan nem tartalmaz assemblyt, es valtoztatas nelkul fordul pl. PPC-re es x86-ra is.

    Felreertes ne essek, en szeretek assemblyben kodolni, eleg sokmindent kodoltam mar asmban a 6502-tol kezdve a 8086-on at a 680x0 szerian es a PPC-n at Athlonokig, de ettol meg teny, hogy manapsag a driverekben sem hasznalnak assemblyt, mert felesleges.

    Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu

Aktív témák