- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
Hirdetés
-
Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
ph A megfizethető, szivacsokkal jól megpakolt modell ötfajta kapcsolóval és kétféle színösszeállítással/kupakprofillal szerezhető be.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Mozgásban az Arena Breakout: Infinite (PC)
gp A korábban csak mobilokra/tabletekre megjelent FPS hamarosan PC-n is elérhető lesz.
Aktív témák
-
perla
csendes tag
? Nem ertelek, hiszen mindenki arra hajt, hogy melyik proci gyorsabb. Igen, ezen az egy teruleten, hogy melyik proci a gyorsabb, a G5 a nagyon jo, a tobbi meg szarabb. Nem azert vesz senki intelt vagy amd-t, mert azok a leggyorsabbak, hanem mert elsosorban x86 kompatibilisek, masodsorban meg mert azokra vannak optimalizalva, vagy egyaltalan a proggik. Amugy a G5 annyira fasza, hogy gyakorlatilag akarmilyen proggit irsz, G5-re meg lehet irni gyorsabbra. Hogy veszik-e a faradtsagot, az mas kerdes.
-
Fiery
veterán
Mondjuk ha egy egesz gepparkot csereltek le, es a teljesitmeny donto tenyezo, akkor talan evaluationre kellett volna kerni 2-3 ilyen uj Cerka-2000-es gepet. Hamar kibukott volna, hogy nem eleg jo, es akkor vehettetek volna gyorsabbat inkabb :)
Vagy nem vagy donteshozoi jogkorben, vagy nem erzodik az, hogy a technologiai erdeklodes melle kello alapossag is tarsulna az esetedben :U
Ha nem rajtad mult az egesz, az persze megint mas tema, a fonokok altalaban hulyek :D
Fiery
[Szerkesztve] -
Fiery
veterán
''Amugy a G5 annyira fasza, hogy gyakorlatilag akarmilyen proggit irsz, G5-re meg lehet irni gyorsabbra. Hogy veszik-e a faradtsagot, az mas kerdes.''
Ja, es ez semmit sem jelent. Nezd csak meg, a gepedre telepitett szoftverek hany szazaleka teljesitmeny-kritikus!
Az enyemen a telepitett es hasznalt szoftverek 90 %-a hasonlo tempoval menne egy Duron-600-on is. Az ilyen szoftvereket csak azert sosem fogjak Macre portolni, hogy azon majd gyorsabban futnak...
Es pont ez a baj a Mackel: szep meg jo, de a libego ablakokon meg a technologiai csilli-villiken kivul nem nyujt tobbet, mint a PC a legtobb juzer szamara.
Fiery -
Fiery
veterán
Ezt irtad:
''Amugy a G5 annyira fasza, hogy gyakorlatilag akarmilyen proggit irsz, G5-re meg lehet irni gyorsabbra. Hogy veszik-e a faradtsagot, az mas kerdes.''
Ezzel kapcsolatban merult fel bennem az a kerdes, vajon hogyan ''irsz egy progit gyorsabbra'' G5-on :)
Mert egy ''progi megirasa'' tobbnyire abbol all, hogy C-ben vagy Object Pascalban (Delphi), esetleg Javaban firkalgatod a forraskodot. Ez ugye _elvileg_ nagyon hasonloan megy Macen es PC-n is -- azonban pl. egy Visual C-ben osszetakolt pure C/C++ progi egyszeru portolasaval nem tul valoszinu, hogy latvanyos gyorsulast ernel el a G5-re valo ugrassal. Az optimalizacio megint mas tema, de az meg baromi sok melo, es nem feltetlenul eri meg...
Arrol nem is beszelve, hogy a portolas sem egyszeru melo -- hacsak nem Linuxrol beszelunk.
Fiery -
Chain|Q
tag
Keso van, de ezt inkabb a fonokomnek magyarazd el, mer az szok ilyeneket mondani. :D
Mac... Ugyan. Nekem 1db Macem van, egy regi 8500/AV, 604e/200-as processzorral, csucsul a sarokban es LinuxPPC-vel tuzfalat jatszik, mer' masra nemjo. :D A Pegasosrol beszeltem.
Egyebkent szerintem az egesz vitanknak, vagy inkabb beszelgetesunknek ebben a mondatodban van a kulcsa:
Vagy rakjak ra Linuxot? Az alatt meg baromira nem erzodik, hogy olyan nagy durranas lenne a Mac...
Teljesen igy van, es teljesen igazad van ebben. Viszont egyben ravilagitottal a szoftvertamogatas gyengesegeire. Teny hogy amig egy platformon (esetunkben az x86-os pC, rajta futo tetszoleges OS-el) jelen allapotaban alkalmatlan mindazokra a feladatokra, amiket egy szoftveres emulacio raruhazna, egyszeruen sem a hardver, sem a szoftver nem eleg rugalmas hozza, es az elonyok helyett inkabb a dolgok hatranyait hangsulyozna ki. Igy tenyleg semmi ertelme sincs, mert nem technologiai szepseget jelentene, hanem tovabbi bugok es lassusag forrasat, pedig az mar van igyis eppen eleg.
Egyebkent milyen Mac az? Ha 5-os IE fut rajta, akkor az mar PPC-s kell hogy legyen, azon meg futni kene fejlettebb OS-nek is, kiveve ha valami 601...Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu
-
perla
csendes tag
Hat ezekben teljesen igazad van. De mondjuk ennyi erovel azt is mondhatnank, hogy ne vegyen senki 3 gigas p4-et mert a 2 gigas mindenre eleg. Es ez amugy igaz is. Kiveve a jatekok. De amugy az koztudomasu, hogy ezt az egesz intel/amd/nvidia/ati vilagot a jatekok mozgatjak. Ebbol a szempontbol meglepo is, hogy a G5 ennyire fasza. Nezzuk csak meg az SGI-t vagy az alfat, sunt stb. Ok nincsenek benne ebben a jatek bizniszben, le is maradtak szepen, pedig valaha ok voltak a janik.
-
Chain|Q
tag
Vagy nem vagy donteshozoi jogkorben, vagy nem erzodik az, hogy a technologiai erdeklodes melle kello alapossag is tarsulna az esetedben
Hat egyreszt nem vagyok donteshozoi jogkorben, masreszt meg pece-pece egykutya, fogyo eszkoz. Nem hat meg. Legalabb van mit fikazni. :DDPegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu
-
-
Fiery
veterán
Mac OS 9.1 fut egy Power Mac 7300-on, 32 mega RAM-mal.
Az igazsaghoz hozzatartozik az is, hogy engem az olyan aprosagok is borzasztoan tudnak idegelni, hogy pl. nincs egergorgo meg jobb gomb meg ilyesmi... Emiatt sem csipem a Mac OS-t meg ugy altalaban a Maceket.
---
Magat az x86-ot szerintem mar nem nagyon fogjak tudni elpusztitani a mi fiatalsagunkban :) -- 128 bites x86 proci 2015 kornyeken me'g biztosan lesz, erre barmennyiben mernek fogadni. Majd talan az unokaink mar mast fognak latni :D
Fiery -
Fiery
veterán
''De mondjuk ennyi erovel azt is mondhatnank, hogy ne vegyen senki 3 gigas p4-et mert a 2 gigas mindenre eleg.''
Megsem, mivel:
- a gyorsabb procihoz gyorsabb memoria es altalaban gyorsabb diszk alrendszer is tarsul
- bar a gyorsabb procin a nem teljesitmeny kritikus szoftverek egyenkent nem feltetlenul futnak erezhetoen gyorsabban, azonban az altalanos felhasznalas soran (pl. a szoftverek indulasa, leallasa, dokumentumok betoltese/mentese) megis tapasztalhato az uj rendszer nagyobb osszteljesitmenye
- vannak a jatekokon kivul is teljesitmeny igenyes feladatok, pl. video enkodolas/dekodolas... Egy kedves baratom most valtott K6-III/450-rol AXP 2200+-ra, es vegre meg tudta nezni a DiVX 5-os es XViD-es filmjeit :D Pedig az office feladatokkal, de me'g a Visual Studio-val se volt baja a regi gepen
Fiery -
Chain|Q
tag
Juuuj... 32 mega az fajhat. Az oreg 8500-ban 64 van, de az se eleg semmire. (Pegasosom fel gigaval repeszt, az mar ugy ''eleg jo'' van honnan-hova lapatolni az Altivecnek. :) ) Az egergorgo-jobbgomb c. moka mondjuk megoldhato USB-s patkannyal, nem is tul dragan, es megeszi a gep a mezei PCboltban kaphato USB cardot is, bar az egesz nem er annyit, hogy nagyon szetkoltekezzen miatta az ember. Halistennek az ujabb Macikon mar default az USB, csak fel kell nyomni neki a patkanyt oszt megy. Egyebkent ezert talan lenne erdemes Linuxot feltenni a macre, persze szigoruan csak konzolost - ott nem kell az egerhez nyulni.
Egyebkent lehet hogy igazad van a 128 bitben, mert mar a 64 bitnek sincs sok ertelme gyakorlati szempontbol - desktop felhasznalaskor szinte semmi, csak a valodi poverjuzerek fogjak hasznat latni. Szoval a 128 bit mar tenyleg annyira ertelmetlen lenne, hogy mar csak ezert is tutibiztos megcsinaljak. :DPegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu
-
Fiery
veterán
Van Linux is a Macemen :)
---
A 64 bitnek meg baromi sok ertelme van, ha tullepsz a bitek szaman, es inkabb azt nezed, milyen alapveto valtozasok vannak az AMD64-ben (NX bit, 16 SSE2 regiszter, 16 altalanos celu regiszter, elszakadas az x87-tol, 4 GB cimezheto tartomany kiterjesztese). A K9-ben remenyeim szerint ezt tovabbviszik, a 128 bites x86 kiterjesztes pedig minden bizonnyal le fog razni az x86-rol me'g tobb regi, elavult sz*rsagot -- vagyis ezek nem csak az x86 kiterjesztesei, hanem egyben annak megreformalasai is.
Fiery
[Szerkesztve] -
Chain|Q
tag
Persze igazad van, de ennek nem a 64bit miatt van ertelme, hanem amugy. :D Ahogy mondtam volt, ezek nagyreszet mar a 386-ba ildomos lett volna behelyezni, mivel a konkurencia (akkor leginkabb a 68k) mar akkor tudta ezeket (konkretan a sok regisztert, normalis fpu-t, etc). Ez persze nem von le az AMD erdemeibol, hogy mit kihoztak az ocska x86-bol, csak kicsit spanyolviasz-szaga van szamomra a dolognak, ahogy a nep orul neki mint szenzacios ujitasnak.
Na jolvan, kellemes tovabbi x86-ozast mindenkinek, a PPC-m, az oreg 060-am, es sajat magam is megpihentetem mara, joejt. :)Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu
-
Fiery
veterán
''Ez persze nem von le az AMD erdemeibol, hogy mit kihoztak az ocska x86-bol, csak kicsit spanyolviasz-szaga van szamomra a dolognak, ahogy a nep orul neki mint szenzacios ujitasnak.''
Szenzaciorol nincs szo, manapsag nem is igazan tema az AMD64... Majd talan az ev vegen, ha vegre megjon az AMD64-es WinXP.
Arrol nem is beszelve, hogy ha megfigyeled, a legtobb piaci siker nem vadi uj otletekbol szarmazik -- kituno pelda az M$, aki masok altal mar reg kitalalt otleteket vadiuj (sajat otletkent) beallitva vitte sikerre a Windowst.
Joejt! :)
Fiery -
DcsabaS
senior tag
Nagyon nehez megbecsulni, hogy a moduloknak mi lehetne a minimalis es az optimalis merete, mielott letrehoznank oket. (A soksejtu elolenyek moduljai, vagyis az egyes sejtek pl. eleg bonyolultak.) Mindenesetre nekem ugy tunik, hogy millios darabszam alatt megoldhato egy-egy modul tranzisztorszama, vagyis az ujfajta procik ilyenbol sok-sok ezret tartalmazhatnak.
(Meg egy erdekes osszehasonlitas. Az emberi agykereg is modularis felepitesu. A modulok szama kb. 1-2 millio, es kb. 10-50 ezer idegsejt van bennuk. Az egyes modulok szamos mas modultol kapnak bemeno jeleht, tehat nemcsak a szomszedos moduloktol, de a kimeno jeluk az osszesen 1 fele (!!!), (azaz mondhatni ''1-bites''), de persze ez az 1 fele jel (az ingerulet) nagyon sok mas modulhoz eljut, elagazik.)
''azonban az uzemfeszultseg drasztikus csokkentesebol szuleto problemak kezelesere nem lesz hasznalhato -- pont azert nem, mert a bithibak barhol elofordulhatnak, nem csak az ECC-vel ''vedett'' adatutakon.''
Akkor meg mindig nem erted. Ha hibazik egy modul, akkor a munkajanak az eredmenyet egyszeruen figyelmen kivul hagyja a processzor egesze.
********************
''Nem, egyaltalan nem felejtem el. De engem a technologiai szepseg erdekel.''
Ha-ha. Ez igaz lehet, es meg osszesen vagy alig 1 szazaleknyian igy gondoljak. (A Mac piaci reszaranya.)
********************
''Annyit tudok hozzatenni, hogy ezek a cegek bezartak magukat az x86 szuk kis dobozaba, es azota sem tudnak kijonni.''
Ez is jo (:). A 99 szazalek a doboz, az 1 szazalek meg a szabad kulvilag...
*******************
(#185) Chain|Q
Senki sem mondta, hogy a regi Mac-ek komponensei nem voltak szabvanyosak. Azt irtam (he lennel kedves pontosabban elolvasni), hogy nem voltak PC kompatibilisek. Es ez az, aminek meg kellett valtoznia, kulonben a Mac nem maradhatott volna fenn. Hasonlo sors var az utolso bastyara is, a CPU-jara, csak ido kerdese. (Vagy legfeljebb az oprendszere maradhat meg specialis - egy darabig.) -
anulu
félisten
az a baj, hogy az AMD tudna mit gyártani, csak nincs hol, az Intel viszont gyárt, tolja ki a procikat, de fene se érti, hogy minek...
öööö, asszem egy kicsit régi hsz-ra válaszoltam. mind1... :)
[Szerkesztve]"Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 14Pro 256GB | iPad Pro 2017 64GB
-
Chain|Q
tag
Hasonlo sors var az utolso bastyara is, a CPU-jara, csak ido kerdese.
Almodj kiralylany... :D A Microsoft pont most tesz egyszerre 3db 3Ghz-s dual CPU magos IBM PowerPC-t az XBox2-be, es G5-os Maceket osztogat PowerPC-s Windowssal DevKit gyanant. Az IBM most hozta ki a Power5 CPU-t, ami ennek a szerver verzioja, a Motorolarol levalt Freescale is egymas utan jelenti be az ujabbnal ujabb PPC fejleszteseket... Az egymas utan feltunedezo olcson beszerezheto alternativ PPC-s alaplapokrol nem is beszelve. Lehet hogy majd mas CPU-ra valt az Apple egyszer a PPC-rol, de abban egesz biztos vagyok, hogy nem mostanaban, es abban is hogy ez a mas CPU nem x86 lesz...
Egyebkent meg mint irtam, a PC lett olyan mint egy Mac, mert a Mac mar a 90-es evek elejen azokat a felepitesbeli tulajdonsagokat mutatta, mint napjaink PC-i... Az OS meg mar reges reg sokkal kevesbe specialis mint mondjuk egy Windows, hiszen a MacOSX kvazi egy Unix, szoval igen konnyu ra portolni mindenfele Unixos programot (lasd pl. Fink project). Ennel jobban nemhiszem hogy valaha is kompatibilis lesz a MacOS valami massal.Pegasos II/G4 -=- Amiga 2000/060 -=- Amiga 1200/060 | hosting www.amigaspirit.hu and www.pegasos.hu
-
DcsabaS
senior tag
''A Microsoft pont most tesz egyszerre 3db 3Ghz-s dual CPU magos IBM PowerPC-t az XBox2-be, es G5-os Maceket osztogat PowerPC-s Windowssal DevKit gyanant. ...''
Persze, probalkoznak a fiuk. Volt mar ilyen a tortenelemben.
''de abban egesz biztos vagyok, hogy nem mostanaban, es abban is hogy ez a mas CPU nem x86 lesz...''
Ehhez kepest vagy 2 eve is mar komolyan felmerult, hogy a legujabb Mac-ekben az x86-os Opteron egy valtozata lenne. Mas kerdes, hogy az IBM kozbelepett, es ezzel nehany evre elodazta a kerdest.
''Egyebkent meg mint irtam, a PC lett olyan mint egy Mac, mert a Mac mar a 90-es evek elejen azokat a felepitesbeli tulajdonsagokat mutatta, mint napjaink PC-i...''
Nem a ''valamilyen fajta tulajdonsagokrol'' van szo, hanem a KOMPATIBILITASROL. A mai Mac-ek dontoen PC (kompatibilis) alkatreszeket hasznalnak, nyilvan kenyszerusegbol, de akkor is.
Oprendszer:
E teren is van helye bizonyos ''onalloskodasnak'', ennek koszonheti a letet a Linux is. De azert nagyon kell kuzdeniuk. -
''Nem, egyaltalan nem felejtem el. De engem a technologiai szepseg erdekel.''
Ha-ha. Ez igaz lehet, es meg osszesen vagy alig 1 szazaleknyian igy gondoljak.
''Annyit tudok hozzatenni, hogy ezek a cegek bezartak magukat az x86 szuk kis dobozaba, es azota sem tudnak kijonni.''
Ez is jo. A 99 szazalek a doboz, az 1 szazalek meg a szabad kulvilag...
Hát valahogy így... mindig a fanatikus kisebbség a leghangosabb.And As It Is Such, So Also As Such Is It Unto You
-
perla
csendes tag
Latom, nem nagyon latod at a dolgokat. Pont azert van a doboz, mert ez adhato e a piac 99%-an. A faszik (intel es amd is) tele vannak egy csomo otlettel, latjak, hogy milyen fasza procit tudnanak csinalni, es az x86 visszahuzza oket. Igy a nagyon kiraly otletekbol meg a sok munkabol epp hogy egy kicsivel jobb procit sikerul osszehozniuk (legalabbis ahhoz kepest, amit x86 nelkul tudnanak). Rohoghetsz rajta, de ez a valosag. Vagy szerinted ha nullarol indulnanak, egy ilyet tudnanak csak osszehozni, mint az x86? Fraszt, sokkal jobbat, ok se hulyek. De muszaj ezt csinalniuk, mert ez kell a nepnek. Hiaba probalkoznak, hogy masfele tereljek oket, a piac (ami x86-ot akar) visszahuzza oket. Ez a doboz.
Ja ezt valojaban DcsabaS 217-es hozzaszolasara irom.
[Szerkesztve] -
''Rohoghetsz rajta, de ez a valosag.''
Én ezeken a tirádákon röhögök.
Az x86 olyan, amilyen... sok marhaság maradt benne ''for hysterical raisins'', de ez van. Ahogy mondod, ''ez a valóság''. Ész nélkül fikázni minden egyes adódó alkalommal (és ha nincs ilyen, akkor teremteni) se nem produktív, se nem különösebben érett gondolkodást sejtető hozzáállás.And As It Is Such, So Also As Such Is It Unto You
-
perla
csendes tag
Esz nelkul fikazni? Te mirol beszelsz? Szerintem olvasd el, amiket irtam, mielott beszolsz, mert igy te magad tunsz eretlennek. Ez amit ide irtal, tok kamu szoveg. Idezd be, milyen alkalmat teremtettem, amikor nem volt? Mi volt az esz nelkul fikazas (ami nem volt megindokolva)? Semmi. Ugyhogy a reszedrol ez egy erv nelkuli beszolas volt. Ez az ami nem produktiv es ovodas (ha mar igy elmentunk szemelyeskedesbe).
-
Ezt még a szerkesztésed előtt írtam, amikor még valamiért (:F) Nekem címezted a hozzászólásodat, és ha megfigyeled, nem is a Te megnyilvánulásaidra hegyeztem ki a mondanivalómat. De ha kicsit visszaolvasol a témában, ne adj' Isten a témák között, megtalálhatod azt a pár notórius alakot akik ezeknek a Motorola / PPC / whateva igehirdetéseknek a döntő hányadáért felelősek...
Ami persze nem baj, minden humorforrást meg kell manapság becsülni. :PAnd As It Is Such, So Also As Such Is It Unto You
-
DcsabaS
senior tag
A nullarol indulva termeszetesen konnyebb tervezni, hiszen semmi sincs, ami a szarnyalo fantaziankat korlatozna. Amde:
1.) pont ez szokta azt eredmenyezni, hogy a dolog ugyan onmagaban szep, de nem igazan jo a szukseges dolgokra
2.) tul gyakori ismetlodes eseten (mindig a nullarol indulni) tul sokba is kerul
Az x86 kompatibilitas egyebkent NEM huzza vissza dramaian sem az Intel, sem az AMD procikat. Hardveresen relative csak csekely mennyisegu tobblet tranzisztort jelent, amikor meg eppen nem azt a reszt hasznaljak a procik, akkor vegkepp semmit sem huz vissza.
A kerdes inkabb az, hogy ki mennyire talalja el, mire van piaci igeny es mekkora. Az asztali PC-k x86-os CPU-nak fejleszteset manapsag leginkabb a 3D teljesitmeny tamogatasa, illetve nemileg kisebb mertekben a nagyobb multimedialis sebesseg motivalja. Az AMD ezt az Opteron csalad megalkotasanal kiegeszitettek az erosen javitott szerver teljesitmennyel, es a sokkalta nagyobb RAM kezeles lehetosegevel, amivel szerintem speciel nagyon jo lora tettek (de nem reszletezem).
Az Intel inkabb megmaradt a media kodolas tovabbi hangsulyozasanal. Hasonlot latok az Apple G5-nel is. Valamint az utobbinal meg azt a felismerest, hogy a tarsadalom egy resze (talan 1 szazalek?) erosen sznob, mindegy mije van, csak mondhassa, hogy valamilyen elitnek szamito dologban gyorsabb/szebb, mint a mase.
Valaki dicserte itt valahol a G5 tudomanyos kepessegeit is. Na az is vicces (:). Ugyanis a valodi tudomanyos programokra abszolut nem jellemzo, hogy barmire is optimalizalva lennenek, ugyanis a kutatokra egyaltalan nem jellemzo, hogy az optimalizalassal lenne kedvuk veszodni, de az sem, hogy programozokat fizessenek meg az optimalizalasert. Igy hat a hardver es az oprendszer szempontjabol az jelenti a kihivast, hogy a kimondottan ''ganyolt'' tudomanyos programoknak is megfeleloen kell futniuk.
Na ez az, ahol az x86 nagyon jo, az Athlon/Athlon64 pedig kulonosen. -
perla
csendes tag
Tobb dologgal nem ertek egyet.
1. Ezek a nullarol indulasrol kozhelyek. Ha megnezed az Intelt, hogy mennyi mellekvagany volt az utobbi idoben, ami nem lett sikeres, vagy amit becanceltek, lathatod, hogy tobb nullarol indulas is kitelik belole.
2. Igenis az x86 kompatibilitas visszahuz. Akar a mar emlitett bonyolult flagrendszert nezed, ami szopatja a pipeline-t, akar egy csomo mast, ezek nelkul igenis dramian gyorsabb es olcsobb procit lehetne csinalni. Es nem tudsz olyat csinalni, hogy ezt megkerulod, illetve egy modon, sse2 hasznalataval.
3. Ezzel spec egyetertek, legnagyobb igeny x86 procikra van, illetve azon belul minel nagyobb jatek es multimedia teljesitmenyre (a jatek meg logikusan 3d-t is jelent). Jo ideig ez a jovo, errol szolt a dobozba zartsag.
3. Intel es media kodolas, ez ugye az sse2. Hogy most a G5 hasonlo-e vagy nem, azon lehet vitatkozni, az a kozos, hogy mindketto simd, es ezutan ki is merult. Ennek spec semmi koze nincs az x86 architekturahoz, ez mindket prociban extension. En mind2-t hasznalom, a G5-os szinte mindenben jobb. Hogy mondjak peldakat: adatok reorganizalasa sokkal jobb, vegezheto muveletek (arra gondolok, hogy a G5 utasitasai nem destruktivak, tehat tudsz olyat csinalni, hogy a forrasoperandusok megmaradnak, mig sse2-ben az egyik felulirodik), sebesseg (G5-ben egy v4=(v1+v2)*v3 jellegu muvelet 1 utasitas, sse2-ben minimum 2, de az adat fuggoseg miatt meg szopatod is a procit, illetve a G5 orajelenkent tobb utasitast is vegre tud hajtani, p4 nem). Az egesznek az a lenyege, hogy G5-re sokkal gyorsabb kodot lehet irni.
4. Sznobsag nem tudom, hogy jott ide. Ezt gondolom az mondatja veled, hogy nem ismered a G5-ot, es ezert ha valaki azt dicseri, arra azt mondod, sznob, mert amugy amit mond nem hiszed el, szal nyilvan aki mondja, elfogult.
5. Ez tokre nem igy van a tudomanyos programokkal kapcsolatban. Igen, van ilyen amit te mondasz, es van olyan, amikor pont a szamitasi teljesitmeny a lenyeg, vagy legalabbis kulcsfontossagu. Gondolj pl. titkositasra, kepfeldolgozasra, barmire, amihez nagy szamitasi teljesitmeny kell. Minek epitenek szuperszamitogepeket? Gondolod, hogy elkoltenek ra a nepek egy csomo penzt, es utana nem optimalizalt programokat futtatnak rajta? De egyebkent az elozonel is szetvalasztanam, hogy x86 (vagyis az architektura), illetve athlon 64/p4 (vagyis egy-egy megvalositas). Ugyanis, legalabbis szerintem, az x86 nem tul jo erre (nem tul optimalis, egy risc valszeg jobb lenne), a megvalositasok viszont tenyleg tok jok, vagyis pl. az athlon64 olyan faszan valositja meg az x86-ot, hogy az kikompenzalja az x86 korlatjait. Nem tudom, ertheto-e amit mondani akarok.
Mit jelent neked az opteron erosen javitott szerver teljesitmenye? Azt, hogy 8 procit is lehet egy gepbe tenni? -
DcsabaS
senior tag
1.) Most trefalsz?!? Az Intel ezen lepeseit (pl. az RDRAM erolteteset) pont az motivalta, hogy szerettek volna elhagyni a kompatibilitast. De nem am azert, mert az olyan nehez volna, hanem mert azt hittek, hogy eronek erejevel az egesz iparagat a sajat utcajukba kenyszerithetik, es akkor aztan csak annak adnak (vagy nem adnak) licenszet, akinek akarnak, az altaluk onkenyesen megszabhato csillagaszati aron. Szerencsere a vasarlok nem honoraltak, hogy sokkal tobb penzert kapjak meg ugyanazt (vagy alig jobbat). Ezek a mellekvaganyok tehat nem a kompatibilitas miatt, hanem pont annak elhagyasara valo torekvesek miatt szulettek.
2.) Nem huz vissza dramai modon, ahogyan az Athlon64-et sem huzza. Az SSE2, 3, 4, 5, stb. lehetosegeit sem korlatozzai.
3.) SIMD media kodolas: pontosan arrol van szo, hogy ez a G5-ben is ugyanugy extension, mint ahogy a P4-ben, vagy az Athlon-ban. Szoval nem igaz, hogy az x86 visszahuzna. Az egy teljesen mas kerdes, vagyis fuggetlen az x86 kompatibilitastol, hogy milyen teljesitmenyu SIMD kiterjesztes megvalositasat latja a CPU gyartoja indokoltnak. (Szemely szerint en tamogatom, hogy legyen minel gyorsabb, de - egyelore - a kisebbseghez tartozom.)
4.) Hogyne ismernem. Tegnap is villogott itt valaki vele, egy amolyan fonok. (MAX-Lab, Lund).
5.) Ez tokre ugy van, ahogy leirtam. Tapasztalatbol beszelek, kutatokent. Amit viszont Te irtal, az csak a kivulallok fantazialasa. (Ismetlem, optimalizalast csak nagyon ritkan vegeznek. Inkabb elmennek egy szuperszamitogephez...) Kozonseges esetekben pedig olyan gepeket igyekeznek hasznalni, amelyek egyreszt megbizhatoak (termeszetesen, no tuning es hasonlok), masreszt a ''ganyolva'' megirt programokat is jol futtatjak.
6.) Opteron: architekturalis okokbol nem fogy ki belole a savszelesseg tobb procis kialakitasnal, ami egyreszt jo szervereknel, masreszt nagyon gyors klasztereket lehet belole osszerakni (szimulacios szamitasokhoz), es megvan a lehetoseg arra is, hogy a tobb core-os verziok hasznalhatok legyenek az eredetileg az 1 core-os verziokhoz keszult alaplapokban (ismet csak kompatibilitas). -
Fiery
veterán
''Opteron: architekturalis okokbol nem fogy ki belole a savszelesseg tobb procis kialakitasnal, ami egyreszt jo szervereknel, masreszt nagyon gyors klasztereket lehet belole osszerakni (szimulacios szamitasokhoz), es megvan a lehetoseg arra is, hogy a tobb core-os verziok hasznalhatok legyenek az eredetileg az 1 core-os verziokhoz keszult alaplapokban (ismet csak kompatibilitas).''
Iszonyu pongyolan fogalmazol, raadasul elfelejted, hogy a processzorok szamanak novelesevel (egy rendszeren belul) problemat jelent a cache-ek konzisztenciajanak megorzese is.
Az Opteron pedig valoban jobban teljesit tobbprocesszoros rendszerekben, mint mondjuk egy Xeon vagy Athlon MP -- azonban ne feledjuk el azt sem, hogy ennel sokkal-sokkal jobban is lehetne csinalni.
Fiery -
Egon
nagyúr
Tetszik, hogy a sok kárörvendkedés és flém után, egy valóban hasznos, szakmai topic alakult ki, kulturált eszmcserével, amiből sokat lehet tanulni...:) Csak így tovább!!! :)
"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)
-
Raymond
félisten
OFF
Erdeklodessel olvasom a topic-ot, csak nem latom ertelmet beszallni ilyen ''Haboru es beke'' meretu hozzaszolasoknal :) Nem volna idom valaszolgatni.
ON
''azonban ne feledjuk el azt sem, hogy ennel sokkal-sokkal jobban is lehetne csinalni.''
Yep. SGI Altix, HP Superdome stb.. Az mar azert, mas kategoria nem ? Az ilyen 4 processzoros gepeknel az ar/teljesitmeny aranya verhetetlen az Opteronoknak. Ez nem vita, csak megerositeni szerettem volna ami irtal...:P
OFF2
Gratula az ''uj'' melodhoz.
ONPrivat velemeny - keretik nem megkovezni...
-
Fiery
veterán
''Az ilyen 4 processzoros gepeknel az ar/teljesitmeny aranya verhetetlen az Opteronoknak.''
Hat igen, 1500 dolcsi egy 4 procis Tyan alaplap, megpakolva fincsi cuccokkal... Mikozben 2000 dolcsi korul van egy 2 procis I2 alaplap, szinten Tyan.
Es ugye a 4 procis Opteron alaplapba be lehet hamarosan rakni 4 db dualcore Opteront :DD
Fiery -
erdoke
titán
OFF
Fiery, szerinted elképzelhető az, hogy a dual core Opteronnak sokkal inkább szüksége van a kétcsatornás memóriavezérlőre, mint a mostaninak? Most ugyanis nagyon keveset profitál ebből, összevetve pl. egy azonos órajelű, szintén 1 MB L2 cache-es A64-gyel (pl. 3200+ vs. Opteron 146). :FA legjobb aláírás a héten
-
rATdrAgOn
senior tag
Nocsak, nocsak, nocsak?!
Mit is obegatok mar egy ideje? :)
Na, most az Intel is belatta. :)
Lesz itt meg nagy szivas, mikor kijonnek majd az uj proccok... x86 kompatibilitas megy a levesbe... de ez nagyon is helyes! :DDDA pC vajommi?! A kindoz vajommi?! A szittyozium.hu jó. Amigát használok, commodoreos (c)(r)(tm)-al. Meg nextgent. Meg bármit. :D
-
#240
Don Vittorio
őstag
DcsabaS
#165
Don Vittorio
őstag
''''Ha a visszafelé kompatibilitás valaminek a feje, akkor már nagy a baj!''
Ne hulyeskedjunk mar(!
A fejlesztes lenyege a visszafele valo kompatibilitas, kulonben nem is fejlesztenenk, hanem csak eldobnank a regit es kitalalnank valami teljesen mast. (Egyebkent pontosan ezt a mindig a kalyhatol valo elindulast alkalmaztak a tortenelem elotti civilizalatlan idokben. A civilizacio pedig akkor indult, amikor az ujabb elkepzelesek nem a semmire, hanem a korabbiakra epultek ra.)''
Nono! Nézd csak meg a G5-ös Maceket! Már nem fut rajtuk az OS 9.2.2 + az azon futó alkalmazások, hanem csak az új, Unix alapú oprendszer, az X, és a kifejezetten arra írt dolgok. Mégis veszik, használják. Most akkor ez hogy van?
Ugyanakkor a Windög alatt folyton emlegetik a kompatibilitást, közben meg már a Win95 is csak akkor és úgy volt DOS-kompatíbilis, ha kiléptél a Win95-ből a DOS-ba... :) Azóta ezt nyögjük, de minek? Semmi értelme nem volt.
Ráadásul a történelem és a társadalmi változások nem keverendők ezzel össze, mivel a társadalmi változások - ahogy a név is mutatja -, a társadalom mozgása alapján történnek. Egy oprendszert vagy egy hardvert meg jobb esetben egy fejlesztői csoport, rosszabb esetben egy megalomán multimilliárdos dob ki az ablakon, vagy fejleszt tovább. Mi, a társadalom, meg csak benyeljük. Egyszerűen merni kellene változtatni ezen a hülye öncsaló baromságon, amit kompatibilitásnak hívnak. Amióta van Windows, azóta nincs igazi, jól működő kompatibilitás, de ezt mi mind tudomásul vettük, és így szeretjük, útáljuk, használjuk. Minek ezt nyomatni, amikor úgysem igaz? Mindenki tudja, hogy egy új oprendszerre tutti, hogy kiadják az új alkalmazásokat is, és mindenki fel is teszi az újat. Ennyi.40 éve csillagász akartam lenni, de kiderült, hogy színtévesztő vagyok, így nem lehettem. Az élet furcsa fintora és öröme is egyszerre, hogy mióta emberi lelkekkel és tudatokkal foglalkozom, megtaláltam a sötétségnek azt a fokát, amit csillagászként sose tudtam volna testközelből tanulmányozni.
-
#241
Don Vittorio
őstag
rATdrAgOn
#239
Don Vittorio
őstag
válasz
rATdrAgOn
#239
üzenetére
Hogy-hogy mit? :)
Csak a tűzfújással vigyázz!40 éve csillagász akartam lenni, de kiderült, hogy színtévesztő vagyok, így nem lehettem. Az élet furcsa fintora és öröme is egyszerre, hogy mióta emberi lelkekkel és tudatokkal foglalkozom, megtaláltam a sötétségnek azt a fokát, amit csillagászként sose tudtam volna testközelből tanulmányozni.
-
Fiery
veterán
Mindenkepp nagyobb lesz a difi a single es dual DDR kozott, ez egyertelmu. A nagyobb problema azonban az, hogy mennyi cache-t fog integralni az AMD ezekbe a procikba. Ha csak 1 MB-ot fejenkent (mert ugye dedikalt L2 cache lesz a dualcore procikban, azaz mindket core-nak sajat L2 cache-e lesz), az keves lesz...
Fiery -
#243
Fiery
veterán
Don Vittorio
#240
Fiery
veterán
válasz
Don Vittorio
#240
üzenetére
Ne feledd, hogy a Mac eleg specifikus celkozonseg szamara keszul, akik sokkal kisebb mennyisegu szoftverbol valogat(hat)nak, mint a PC-s tarsadalom.
Ha pontosan tudni lehetne, hogy a Windows felhasznalok 95%-a max. 100-200 fele szoftvert hasznalnak, sokkal konnyebb lenne kihajitani az eddigi stuffokat, es nullarol kezdeni mindent.
Fiery -
erdoke
titán
Ja, Opteron 146, de ekoder néven már írtam a hwsw-en, hogy majd küldök eredményt.:P
Zalman CNPS7000-Cu alatt van az Opteronom, miért kell hakkolni? Le kell szerelni a keretet a lapról, osztjóvan...:))
BIOS-ban 39 fok, pedig ez az újabb fajta animált AMI BIOS by Asus (rühellem:D). Más monitorozó progit még nem volt időm telepíteni, az Everestet pedig lusta vagyok még1x letölteni, majd áthúzom a laptopról.:D
[Szerkesztve]A legjobb aláírás a héten
-
Fiery
veterán
Ize, olyan konnyen rahakkolhato a Zalman? Aszittem mashol vannak a rogzitok, ez igy nagyon jol hangzik :D
Oszinten szolva az egyetlen gondom az Opteronnal eddig az volt, hogy nem akarok gyari hutot hasznalni -- de ezek szerint most mar nincs gond :)
Koszi az infot! ICQ listamra felraktalak :P
Fiery -
erdoke
titán
Leszedtem a műanyag keretet, betekertem a nagy sárga csavarokat, megnéztem, passzolnak-e távolságban. Miután az eredmény pozitív volt, yoól rászereltem a Zalmant. Eddig még nem esett le.:D
ICQ előtt dobj mailt, mert csak elvétve vagyok fönt, ha valaki kifejezetten óhajtja, és időm is engedi.
Állítólag a gyári hűtő is jó, de meg se próbáltam.:PA legjobb aláírás a héten
-
DcsabaS
senior tag
1.) Mi volt iszonyu pongyola?
2.) Az Opteron-nal miert volna nehezebb az osszehangolas, mint mas prociknal?!?
''azonban ne feledjuk el azt sem, hogy ennel sokkal-sokkal jobban is lehetne csinalni.''
Barmit lehet jobban csinalni, de a tesztek szerint az Opteron egyaltalan nem csak a Xeon-hoz es az Athlon MP-hez kepest skalazodik jobban multiprocesszoros hasznalatkor.
(Annal inkabb sajnalom, hogy az AMD - megfelelo felvezeto gyarak hianyaban - nem tud erosebben nyomulni a dual core-os procija fele.)
**********
''elképzelhető az, hogy a dual core Opteronnak sokkal inkább szüksége van a kétcsatornás memóriavezérlőre, mint a mostaninak? ''
Magatol ertetodoen.
***********
''Nono! Nézd csak meg a G5-ös Maceket! Már nem fut rajtuk az OS 9.2.2 + az azon futó alkalmazások, hanem csak az új, Unix alapú oprendszer, az X, és a kifejezetten arra írt dolgok. Mégis veszik, használják. Most akkor ez hogy van?''
Akkor is lenne ra bizonyos szamu vevo, ha a doboza ures lenne, rajta egy almaval. Szoval csak egy bizonyos reteget szolgal ki. Es aki csak egy bizonyos retegre specializalodik, az sok mindenrol lemondhat. De ezt mar k+1-szer megbeszeltuk.
*************
''Ugyanakkor a Windög alatt folyton emlegetik a kompatibilitást, közben meg már a Win95 is csak akkor és úgy volt DOS-kompatíbilis, ha kiléptél a Win95-ből a DOS-ba... ''
Nagy tevedes! Nem a Win95-bol valo kilepes, es nem is a DOS ablak adta a ''jo'' DOS-t, hanem ha nem toltotted be a GUI-t.
''Azóta ezt nyögjük, de minek? Semmi értelme nem volt.''
Miert ne lett volna? Meg most is van.
''Egyszerűen merni kellene változtatni ezen a hülye öncsaló baromságon, amit kompatibilitásnak hívnak....''
Ezek mar annyira vicces szovegek voltak, hogy gondolom nem is varsz ra igazi valaszt... -
perla
csendes tag
1. ? Az rdramnak mi koze a kompatibilitashoz? Szerintem semmi. Amugy tobb mellekvagany is van/volt, van amelyik a kompatibilitasi uton (pl. a topikindito cikk is errol szol), van amelyik nem (pl. itanium).
2. Ez igaz, marmint hogy sse2 stb.-t nem korlatozza. Tobbi reszet a procinak igen. Szal ez azt jelenti, hogy ha nem optimalizalsz (pl. siman c-ben programozol), akkor azok korlatozva lesznek, ha optimalizalsz akar optimalizalt konyvtarak hasznalataval, akar sajat koddal, akkor nem leszel korlatozva.
3. Persze, ezt abszolut nem huzza vissza. Itt csak arra probaltam utalni, hogy a SIMD a legjobban a 3 kozul a G5-ben van megoldva, masodik a p4, harmadik az amd64.
4. Ok, tovabbra se ertem, hogy jott a sznobsag a proci sebesseghez. Meg ez, hogy valaki villogott vele, nekem azt jelenti, hogy hallottal mar rola. De nem hasznaltad, nem fejlesztettel ra, szal nem tudod osszehasonlitani massal. Nyilvan, ha nem igy van, akkor visszavonom, bar szerintem ha valaki kiprobalja a G5 simd extensionjet es osszehasonlitja a p4-evel, akkor egyreszt le kell essen az alla, meg akkor tudnia kell, hogy mirol beszelek.
5. Nem gondolnam, hogy kivulallo vagyok a temaban, epp kepfeldolgozassal foglalkozom, es epp sse2 meg altivec optimalizalast csinalok, sima 2 processzoros gepeken meg 16-32 processzoros clusteren. Nem erzed butasagnak, elfecserelt idonek szuperszamitogepen nem optimalizalt kod futtatasat? Amugy az oke, hogy az egyet merek, kettot osztok feladathoz nem kell tul nagy szamitasi teljesitmeny, es a ganyolt program is megoldja (es ettol ez meg lehet tok tudomanyos, szamtalan olyan tudomany, illetve feladat van, amihez nem kell szamitasi teljesitmeny). Pl. Idojarast szimulalni viszont nem fogsz igy. Real-time kepfeldolgozasi feladatok se mennek igy. Amennyire en tudom (bar szuperszamitogep nem volt meg a kezemben, de cluster igen) szokas valamilyen api-t hasznalni, amiben optimalizalt fuggvenyek vannak, amit a kododban hasznalhatsz. Ily modon a kodod is optimalizalt. Amugy nem is ertem, minek allok le ezen vitazni. Azt akarod nekem bemeselni, hogy senki senmmilyen feladatra nem hasznal optimalizalt kodot? Ez nyilvanvalo hulyeseg. Szerinted soha senki nem hasznalt meg sse2-t? De meg csak egy libraryt se, ami optimalizalva volt? Es en fantazialok? Az, hogy te nem hasznalsz, az nem jelenti azt, hogy mas se hasznal. Tok sok optimalizalt library van. Akar ha csak egy FFT-t nezek, szerinted mindig mindenki leall ezt ujra megirni, vagy hasznalnak egy mar letezot? Ha esetleg letezot hasznalnak, akkor vajon egy gyorsabb, simd utasitasokat hasznalot fognak hasznalni, vagy direkt egy lassabbat? Ehh...
6. Ok, vilagos, en is erre gondoltam, azt hittem, valamirol kimaradtam. Mondjuk erdekes, hogy itt talalsz peldat, amit clusteren erdemes futtatni, bar gondolom, hogy szerinted itt se hasznal senki sse2-t, ugye? -
#252
rATdrAgOn
senior tag
Don Vittorio
#241
rATdrAgOn
senior tag
válasz
Don Vittorio
#241
üzenetére
O-ooo...
Honnan tudod, hogy megint nincs szakallam mert leegettem?! (Gazkonvektor rulez!!!! :DDD) :)
Leborulok nagysagod elott! :)A pC vajommi?! A kindoz vajommi?! A szittyozium.hu jó. Amigát használok, commodoreos (c)(r)(tm)-al. Meg nextgent. Meg bármit. :D
-
#253
Don Vittorio
őstag
rATdrAgOn
#252
Don Vittorio
őstag
válasz
rATdrAgOn
#252
üzenetére
T'od, hogy van ez...
40 éve csillagász akartam lenni, de kiderült, hogy színtévesztő vagyok, így nem lehettem. Az élet furcsa fintora és öröme is egyszerre, hogy mióta emberi lelkekkel és tudatokkal foglalkozom, megtaláltam a sötétségnek azt a fokát, amit csillagászként sose tudtam volna testközelből tanulmányozni.
-
#254
Don Vittorio
őstag
DcsabaS
#250
Don Vittorio
őstag
Te DcsabaS, te...
''Nagy tevedes! Nem a Win95-bol valo kilepes, es nem is a DOS ablak adta a ''jo'' DOS-t, hanem ha nem toltotted be a GUI-t.''
Szerinted én ezt írtam? Ehhh. :(
Bántóan kioktató vagy, közben meg folyamatosan csúsztatsz, ahogy itt folyamatosan látom. Finoman szólva nem szép dolog.
''''Azóta ezt nyögjük, de minek? Semmi értelme nem volt.''
Miert ne lett volna? Meg most is van.''
Semmi értelme. Mióta nem lehet normálisan megcsinálni a könyvelő programokat Win2000 DOS-ablakban, mindenhol azt csinálom, hogy van egy átkapcsolóval váltható Win2000-es gép, és van a régi, filléres DOS-os. Ismétlem, semmi értelme nincs a DOS-ablakkal bohóckodni. Normálisan működő oprendszer konzolja nem keverendő össze azzal a viccel, amit a Microsoft ''DOS-ablaknak'' hív. Az maga a borzalom.
''''Egyszerűen merni kellene változtatni ezen a hülye öncsaló baromságon, amit kompatibilitásnak hívnak....''
Ezek mar annyira vicces szovegek voltak, hogy gondolom nem is varsz ra igazi valaszt...''
Akkor jó nevetést. Egyébként nem kérdés volt, amire választ várhatnék, hanem kijelentés, amire reakciót. De azt meg nem várok. Ilyen stílusban nem.40 éve csillagász akartam lenni, de kiderült, hogy színtévesztő vagyok, így nem lehettem. Az élet furcsa fintora és öröme is egyszerre, hogy mióta emberi lelkekkel és tudatokkal foglalkozom, megtaláltam a sötétségnek azt a fokát, amit csillagászként sose tudtam volna testközelből tanulmányozni.
-
DcsabaS
senior tag
(#251) perla!
1.) ''Az rdramnak mi koze a kompatibilitashoz? Szerintem semmi''
Nagyon is sok koze van. Az RDRAM annak jegyeben szuletett, hogy szakitsunk az SDRAM tovabbi fejlesztesevel, dobjuk el, es csinaljunk helyette mast, valami olyat, amiert - ha sikerul elterjeszteni - majd jo sok licensz dijet lehet kovetelni, de amelyik ceg nem ugy tancol ahogy futyulunk, annak el sem adjuk.
De nezd meg a Rambus mostani ajanlatat, micsoda palfordulas! Mostmar olyan RAM interfeszt terveztek, amely kepes kiszolgalni az SDR SDRAM-tol kezdve az XDR-ig mindent (magyarankompatibilis veluk)! Ezt kellett volna csinalniuk kezdetben is! Ez optimalis kifutasat adja az egyes RAM technologiaknak, es akkor kovetkezik be a valtas, amikor a felhasznaloknak legjobban megfelel!
2.) Optimalizalas: az x86-os kodot az Athlon-ok kulonosebb optimalizacio nelkul is nagyon jol futtatjak, mert maga a proci olyan. (Az Intel P4 vonulatra ez nem jellemzo, meglehetosen egyenetlen teljesitmenyeket mutat fel.)
Ha olyasmire akarjuk hasznalni a CPU-t, ami valojaban nem igenyelne x86-ot, lasd pl. szerverek es 3D, tortenetesen az x86-ttal egyutt is nagyon jo az Athlon(64).
Marad tehat a dompingszeru multimedia, ott tenyleg nem eleg az x86, ugyanakkor nincs akadalya a megfelelo SIMD kiterjesztesnek.
(Hogy mit es mennyit lehet ''nyerni'' (:) a korlatozott x86 kompatibilitassal, arra remek aktualis peldaval szolgal az Itanic tortenete.)
3.) Igen, SIMD szempontbol a G5 a legjobb, a P4 a masodik, es az Athlon 64 csak a harmadik. Kar erte, mert szerintem ez is fontos. (Talan egyszer majd ebben is elre tor az AMD.)
Hogy dicserjem a G5-ot: az mindenesetre nagyszeru benne, hogy azon idiotakkal (mar bocsanat) szemben, akik szerint nincs szukseg 64 bitre, meg multiprocesszoros gepekre desktop celokra, segit hamarabb bebizonyitani, hogy igenis van.
4.) Itt van a laborban, meg lehet nezni (a gazdaja szereti mutogatni (:) ), ugyanakkor semmi erdemlegesre nem hasznalja, valoszinuleg Power Point szeru prezentaciokat fog vele gyartani. A ficko videoban teljesen jaratlan, ugyhogy neki a SIMD semmit nem hasznal. Ha a gep olcsobb lenne, akkor valoszinuleg tobben megvehetnek, olyanok is, akik ki tudnak erdemben hasznalni.
5.) ''Nem erzed butasagnak, elfecserelt idonek szuperszamitogepen nem optimalizalt kod futtatasat? ''
Barmilyen vicces, nem. Ugyanis tudomanyos temakban az adott kerdeshez erto ember ideje a legnagyobb ertek, aki ezert nem tokolhet holmi program optimalizaciokkal. Aki pedig tud es szeret is programozni (informatikus), az meg nem ert magahoz a tudomanyos kerdeshez, es ugy optimalizalna, hogy kozben keverne a jezuskat a geppuskaval, ezert bar szep lenne a programja, de a lenyeg szempontjabol rosszul mukodne. Altalanos tapasztalat.
(Nemileg hasonlo folyamat zajlott le ugy 15-20 evvel ezelott. Elotte a ''tudos'' lediktalta a cikket a gep es gyorsiro nonek, aztan atnezte, bejelolte a javitasokat (jezuska-geppuska cserek), ujra legepeltette, stb. A PC-k megjelenesevel ennek vege lett. A kutatok maguk irjak a cikkekket, ha osszesen csak 2 ujjal is, de szamitogepen, es ha vannak is benne hibak, inkabb csak esztetikai jelleguek, gyors es gepirot meg nem alkalmaznak.)
Egy erdekes adalek: 95-ben (vagy 96-ban) a szamitogepes sakk vilagbajnoksagon eloszor fordult elo, hogy a PC-k nagyon eloretortek a sakkgepekkel szemben. Az elso 10-ben 8 db PC volt! A 2 db nem PC kozul az egyik a frissen debutalt IBM szuperszamitogep, a Deep Blue (vagy 3000 db 64 bites CPU-val!), a 2. helyezett meg egy 4 Alpha processzoros gep volt. Na most a Deep Blue holtversenyben vegzett az elso helyen az akkor szinten ujnak szamito Fritz 1.0 sakkprogrammal, amely viszont csak egy x86-os, 90 MHz-es Pentiumon futott (:)))!!! Na most nyilvan nem arrol van szo, hogy a Deep Blue nem eleg eros gep, vagy hogy a sakkozas nem jol parhuzamosithato, hanem arrol: aki hozzafer egy szuperszamitogephez, annak eszebe sincs optimalizalni.
''Amugy az oke, hogy az egyet merek, kettot osztok feladathoz nem kell tul nagy szamitasi teljesitmeny, es a ganyolt program is megoldja ''
Akkor meg mindig nem vagy kepben (:). Gondolj arra, hogy a tudomanyos meroberendezeseket es (muszereket) altalaban modulkent, nagyon sokfele celra hasznaljak, hol igy, hol ugy osszerakva. Ugyanakkor ma mar nem lehet meglenni a meresek szamitogepes felugyelete, es az adatok szamitogepes feldolgozasa nelkul. A rugalmassag es a teljesitmeny szinkron igenyet pl. ugy lehet osszehangolni, hogy a LabVIEW rendszert (vagy mas hasonlot) hasznalnak, ami ugyebar arrol szol, hogy az adott feladatnak megfeleloen, egy kimondottan magas szintu programnyelven allitja ossze a kutato, hogy mit es hogyan szeretne csinalni, a szamitogeppel meg elvegezteti. Ez nagyon sok adat folyamatos begyujteset es processzalasat, valamint eszkozok vezerleset jelentheti, de megsem lehet sebessegre optimalizalni, mert nem lehet kobe vesni semmit, hiszen barmikor modositani kellhet rajta. Marad tehat az, hogy egy megfeleloen gyors gepet kell vasarolni a feladathoz. Ez menni szokott.
A G5 vonatkozasaban ez pl. azt is jelenti, hogy amennyiben tudna fogadni a megfelelo interface eszkozoket, es futna rajta a LabVIEW, akkor mindjart megnone a valodi tudomanyos erdekessege. (Addig legfeljebb csak szimulaciokra lehetne hasznalni, ami persze szinten nagyon fontos es hasznos, de csak egy reszterulet.)
''Azt akarod nekem bemeselni, hogy senki senmmilyen feladatra nem hasznal optimalizalt kodot? ''
Nem. Hanem azt mondom, hogy sebessegre a tudomanyban csak ritkan optimalizalnak. Inkabb vesznek/berelnek gyorsabb gepeket.
''Tok sok optimalizalt library van. Akar ha csak egy FFT-t nezek, szerinted mindig mindenki leall ezt ujra megirni, vagy hasznalnak egy mar letezot?''
Dehogy. Ami optimalizacio kesz van, vagyis a gyerto cegek megcsinaltak, azt szivesen felhasznaljak. Csak hat az a helyzet, hogy a tudomany frontvonalaban hiaba mondod, hogy 1 ev mulva majd lesz optimalizacio, ha egyszer most lenne jo. 1 ev mulva mar gyorsabb gep is lesz.
''Ha esetleg letezot hasznalnak, akkor vajon egy gyorsabb, simd utasitasokat hasznalot fognak hasznalni, vagy direkt egy lassabbat? Ehh...''
Nem azok a feladatok igenylik a legtobb CPU erot, amelyeket SIMD-del gyorsitani lehet, hanem inkabb azok, amelyekhez tovabbi CPU-k kellenenek (parhuzamositas). Ezert a G5-ben vonzobb a dual procis felepitese, mind a hatekony SIMD.
*************
(#254) Don Vittorio!
''Szerinted én ezt írtam? Ehhh. ''
Szerintem Te ezt irtad: ''ha kiléptél a Win95-ből a DOS-ba... ''
Marpedig, ha a Win95-bol lepsz ki a DOS-ba, ahelyett, hogy teljesen ujrainditanad a gepet es megallitanad a boot-olas folyamatat a GUI elott, akkor nem tisztul ki teljesen a memoria (foleg helytelenul installalt Windows-os driver-ek eseten), es akkor NEM LESZ teljes erteku DOS-od. Ez egy lenyeges korulmeny, amirol a jelek szerint Te nem tudtal, erre fel szemelyeskedni kezdesz (plane HAZIGAZDA-kent), es meg csusztatsz is. Finoman szolva nem szep dolog.
''Ismétlem, semmi értelme nincs a DOS-ablakkal bohóckodni. ''
Ebben latod egyetertunk. -
Fiery
veterán
''2.) Optimalizalas: az x86-os kodot az Athlon-ok kulonosebb optimalizacio nelkul is nagyon jol futtatjak, mert maga a proci olyan *** milyen? x86 optimalizalt vagy mi a gyik?? *** (Az Intel P4 vonulatra ez nem jellemzo *** mi nem jellemzo rajuk?? ***, meglehetosen egyenetlen teljesitmenyeket mutat fel *** ugyanigy a K7/K8 is, attol fuggoen, mit futtatsz rajta ***.)
Ha olyasmire akarjuk hasznalni a CPU-t, ami valojaban nem igenyelne x86-ot *** x86-os procinal fura lenne, ha nem igenyelne x86-ot ***, lasd pl. szerverek es 3D *** szerverek nem igenyelnek x86-ot?? ***, tortenetesen az x86-ttal egyutt is nagyon jo az Athlon(64). *** fura lenne, ha x86 nelkul is jo lenne ***
Marad tehat a dompingszeru multimedia *** mar ahol, ugye... meg marad a jatek, ami legalabb ilyen nagy huzoagazat ***, ott tenyleg nem eleg az x86 *** kezdem erteni, szted az x86-nak nem reszei az x86 kiegeszitesek, pl. SSE??? ***, ugyanakkor nincs akadalya a megfelelo SIMD kiterjesztesnek *** miert lenne akadalya barmilyen kiterjeszetesnek? de attol me'g x86 marad, nem lesz RISC vagy mittomen ***''
Ez a szoveg LOL!
Lehet, hogy sakkban nagy vagy (bar az a P90-es benyogesed ezt is kisse megingatja), de hogy szakszeruen nem tudsz egy szintnel bonyolultabb CPU architekturalis problemat elmagyarazni, az is biztos...
Fiery
[Szerkesztve]
[Szerkesztve] -
DcsabaS
senior tag
''milyen? x86 optimalizalt vagy mi a gyik?? ''
Olyan, hogy pl. a P4-nel azonos orajelen hatekonyabb az integer resze, kisebb a latenciaja, kevesbe hatranyos szamara, ha surun keverednek az FPU es ALU utasitasok, mikozben sokkal gyorsabb az FPU-ja is (register renaming, out of order tripple issue FPU stb.). Ilyen es hasonlo okok miatt:
Az Athlon gyors:
- ha integer szamitasokat kell vegeznie
- ha FPU szamitasokat kell vegeznie
- ha surun keveredik is a ketto
- ha olyan kodot kell futtatnia, amelyik nincs optimalizalva hosszu pipeline-okra
''(Az Intel P4 vonulatra ez nem jellemzo *** mi nem jellemzo rajuk??''
Az Intel P4:
- lassubb azonos orajelen integer szamitasokban
- az FPU-ja katasztrofalisan lassu
- ha az integer es az FPU muveletek surun keverednek, meg lassubb
- akkor is lassu, ha a kod nincs optimalizalva a hosszu pipeline-okra
- egyedul akkor gyors (viszonylag), ha SSE2-t kell vegrehajtania
Ezert az olyan kodok, amelyek nincsenek SSE2-re optimalizalva, es ''esz nelkul'' keverednek bennuk az FPU es az integer muveletek, egeszen kiabranditoan futhatnak. (Akar egy nagysagrendnyi(!) lemaradas is osszejohet az Athlonhoz kepest.)
''meglehetosen egyenetlen teljesitmenyeket mutat fel *** ugyanigy a K7/K8 is, attol fuggoen, mit futtatsz rajta ***.)''
Ez NEM igaz. A K7/K8 ugyan lassubb SSE/SSE2 kod futtatasanal, de akkor sem sokkal. A P4 ezt is ugy eri el, hogy magasabb frekin, nagyobb fogyasztassal megy. Azonos felvezeto technologian gyartott es azonos fogyasztasu Athlon es P4 eseten SSE-ben sincs kulonbseg, csak SSE2-ben.
''Ha olyasmire akarjuk hasznalni a CPU-t, ami valojaban nem igenyelne x86-ot *** x86-os procinal fura lenne, ha nem igenyelne x86-ot ***, ''
Csakhogy itt nem az x86-os procikrol volt am szo, hanem az x86-os es a nem x86-os G5, avagy mas procik osszehasonlitasarol!
Az allitasom pedig az volt, hogy bar a 3D-hez, vagy a szerver funkciokhoz abszolute nem kell x86-osnak lennie a procinak, a dual Opteron megis jobb, mint a G5, noha az is 64 bites, es az Opteron meg x86-os. Szoval az Opteron annak dacara gyorsabb, hogy x86-os!
''*** szerverek nem igenyelnek x86-ot?? ***, tortenetesen az x86-ttal egyutt is nagyon jo az Athlon(64). *** fura lenne, ha x86 nelkul is jo lenne ***''
A szerverekhez nem kell x86. Sot, meg CISC sem. Egyebkent lasd az elobbi szakaszt!
''Marad tehat a dompingszeru multimedia *** mar ahol, ugye... meg marad a jatek, ami legalabb ilyen nagy huzoagazat ***, ott tenyleg nem eleg az x86 *** ''
A jatek NEM marad meg, mert abban nem a G5 a gyorsabb. Csak a SIMD multimedia kodolasban. Amelynek viszont semmi koze ahhoz, hogy x86-os-e a proci, vagy sem.
''kezdem erteni, szted az x86-nak nem reszei az x86 kiegeszitesek, pl. SSE??? ''
NEM. Az csupan egy kiegeszites. Az x86-os procikat is ki lehetne egesziteni mondjuk egy olyan SIMD vegrehajto egyseggel, mint a PowerPC 970-ben van, vagy akar meg jobbal. A lenyeg az, hogy az x86 kompatibilitas ezt nem akadalyozza meg, vagyis ha hatalmas SIMD teljesitmenyt akarunk is, attol meg nem kell lemondani az x86 kompatibilitasrol. Egyszeruen nincs miert.
''***, ugyanakkor nincs akadalya a megfelelo SIMD kiterjesztesnek *** miert lenne akadalya barmilyen kiterjeszetesnek? de attol me'g x86 marad, nem lesz RISC vagy mittomen ***''''
Pontosan arrol van szo, hogy az x86 kompatibilitas mellet igenis meg lehet rendkivul hatekony SIMD-re kepesre csinalni a proci, sot, ha mar a RISC-et emlitetted, az a korabbi nota sem bizonyult igaznak, hogy le kell mondanunk a CISC procikrol, ha a RISC procik hatekonysagara vagyunk, ugyanis pl. az Athlon remekul otvozi a kettot. (Belul RISC, kifele CISC.)
''Ez a szoveg LOL!''
Csak az biztos, hogy a Prohardveres fiukhoz hasonloan Te sem tudsz eleg figyelmesen OLVASNI.
''Lehet, hogy sakkban nagy vagy (bar az a P90-es benyogesed ezt is kisse megingatja),''
Akkor olvass egy keveset. (Ez ugyan egy masik verseny, da nagyjabol abbol az idobol.)
[L]http://www.cs.unimaas.nl/icga/news/events/pastevents/WCCC8/latest.html[/L]
''de hogy szakszeruen nem tudsz egy szintnel bonyolultabb CPU architekturalis problemat elmagyarazni, az is biztos...''
Gondolom nem az a cel, hogy az ember ''magas szinten magyarazzon'', hanem hogy ertheto legyen. E teren nyilvan kudarcot vellottam, ha ennyire nem voltal kepes megerteni, amit irtam. De szerintem ehhez nagyban hozzajarul az is, hogy nem olvasol eleg figyelmesen. -
Power
senior tag
Én nem akartam reagálni, de egyre azé mégis:
DcsabaS:
''Egy erdekes adalek: 95-ben (vagy 96-ban) a szamitogepes sakk vilagbajnoksagon eloszor fordult elo, hogy a PC-k nagyon eloretortek a sakkgepekkel szemben. Az elso 10-ben 8 db PC volt! A 2 db nem PC kozul az egyik a frissen debutalt IBM szuperszamitogep, a Deep Blue (vagy 3000 db 64 bites CPU-val!), a 2. helyezett meg egy 4 Alpha processzoros gep volt. Na most a Deep Blue holtversenyben vegzett az elso helyen az akkor szinten ujnak szamito Fritz 1.0 sakkprogrammal, amely viszont csak egy x86-os, 90 MHz-es Pentiumon futott ()!!! Na most nyilvan nem arrol van szo, hogy a Deep Blue nem eleg eros gep, vagy hogy a sakkozas nem jol parhuzamosithato, hanem arrol: aki hozzafer egy szuperszamitogephez, annak eszebe sincs optimalizalni''
Fiery:
''Lehet, hogy sakkban nagy vagy''
Aligha.
1. A Deep Blue processzor számát illetően erősen el van tájolva a kollega.
2. 1995-ben volt Fritz-Deep Blue, amely azonban messze nem ugyanaz volt, mint a Kaszparovval mérkőző 97-es(a kettő között jelentős számításbeli különbség volt).
3. A két program elve teljesen más, ezért volt köztük különbség és nem az optimalizálás a különbség. Az optimalizálással nem lehet nagyságrendet javítani, mert akkor az nem optimalizálás, hanem fejlesztés(vagyha igen, akkor az egy szar program volt). Esetünkben sem optimalizálásról volt szó, hanem az enginek különbsége jött elő.
4. A Deep Blue nem klasszikus szuperszámítógép. Speciális sakkprocesszorok voltak benne, amelyeket Power processzorok vezéreltek(minden RS/6000-es node-ok 16 sakkproci kapcsolódott).
[Szerkesztve]Power
-
DcsabaS
senior tag
''1. A Deep Blue processzor számát illetően erősen el van tájolva a kollega.''
Meglehet, ellentmondo adatok voltak. Mindenestre a legelso, fejlesztes alatt allo Deep Blue volt, amelyet tulajdonkeppen reklamozni akartak, ezert sakkoztattak.
''2. 1995-ben volt Fritz-Deep Blue, amely azonban messze nem ugyanaz volt, mint a Kaszparovval mérkőző 97-es(a kettő között jelentős számításbeli különbség volt).''
Ki beszelt az ember elleni merkozesrol?!? Vagy hogy a Deep Blue-t kesobb hova fejlesztettek?
''3. A két program elve teljesen más, ezért volt köztük különbség és nem az optimalizálás a különbség. ''
A 2 program nyilvan teljesen mas volt, de a lenyeg: a Deep Blue-ra irt program aligha hasznalta ki a Deep Blue hatalmas parhuzamos szamitasi kapacitasat, noha az a sakknal elvben jol kihasznalhato. Erre irtam azt, hogy nem optimalizaltak a sakkozo programjukat, csak irtak egy sakkozo programot a szuperkomputerukre, es azzal szinte elintezettnek tekintettek a dolgot. Ahogyan ez tudomanyos korokben szokas is.
''4. A Deep Blue nem klasszikus szuperszámítógép. Speciális sakkprocesszorok voltak benne, amelyeket Power processzorok vezéreltek(minden RS/6000-es node-ok 16 sakkproci kapcsolódott).''
Aligha voltak benne specialis ''sakkprocesszorok'', ugyanis eredetileg idojarasi es gazdasagi folyamatok elemzesehez konstrualtak. -
Power
senior tag
1. De közelében sem volt a 3000-nek, nemhogy 95-ben, még később sem.
2. Rendben, de Deep Blue-nak tulajdonképpen a 97-est tekinthetjük, csak érdekességként említettem.
3. Kihasználta. Pont erre épített, egy több, mint 40 éves algortimust használt cél hw-re.
4. Csak ne volnál tájékozatlanul ennyire magabiztos. :)
Az IBM és a hozzáértők máshogy tudják(de biztos neked van igazad).
Nézz csak ide:
[L]http://www.research.ibm.com/deepblue/press/html/g.6.4.html[/L]
[Szerkesztve]Power
-
DcsabaS
senior tag
''1. De közelében sem volt a 3000-nek, nemhogy 95-ben, még később sem.''
Lehet, ezt akkor egy ujsagcikkben olvastam, es sokfele adat keringett a pontos felepitesrol. Az mindenesetre biztos, hogy nagyon sok procit hasznaltak, nem x86 osokat, es megsem teljesitett jobban a 90 MHz-es Pentiumnal. Magatol ertetodoen a szoftver miatt. A peldat eppen arra hoztam, hogy a Deep Blue sakkprogramja nyilvan nem volt kelloen optimalizalva az adott hardverre.
''3. Kihasználta. Pont erre épített, egy több, mint 40 éves algortimust használt cél hw-re.''
Akkor legyunk pontosak. Ha ez igaz, akkor ''egy több, mint 40 éves algortimus''-ra optimalizaltak, es nem a Deep Blue hardverere, amire kellett volna.
Hogy most mennyire hasznalja ki, az is vitathato, ugyanis a PC-s Fritz aktualis verzioja most is versenyben van vele.
Az altalad megadott linkbol erdemes felfigyelni arra, hogy az IBM a Deep Blue tortenetet ugyesen a Kaszparov elleni (96-os) meccsel inditja, igy nem kell irnia arrol, hogy korabban alulmaradt egy 90 MHz-es Pentium-mal szemben. -
Fiery
veterán
''Az allitasom pedig az volt, hogy bar a 3D-hez, vagy a szerver funkciokhoz abszolute nem kell x86-osnak lennie a procinak, a dual Opteron megis jobb, mint a G5, noha az is 64 bites, es az Opteron meg x86-os. Szoval az Opteron annak dacara gyorsabb, hogy x86-os!''
Gyongyszem... Az x86 alatt tok jo lenne tudni, hogy mit ertesz, plane amikor belekeversz G5-ot is mar a kepbe. No meg eleve nem ertem, miert ''kellene'' egy procinak x86-os procinak lennie -- habar az Opteron meg a P4 is az ugyebar.
''Pontosan arrol van szo, hogy az x86 kompatibilitas mellet igenis meg lehet rendkivul hatekony SIMD-re kepesre csinalni a proci, sot, ha mar a RISC-et emlitetted, az a korabbi nota sem bizonyult igaznak, hogy le kell mondanunk a CISC procikrol, ha a RISC procik hatekonysagara vagyunk, ugyanis pl. az Athlon remekul otvozi a kettot. (Belul RISC, kifele CISC.)''
Jah, jooo nagy kompromisszumokkal, amit a marketing szovegeddel szepen elrejtesz :) ...
''A jatek NEM marad meg, mert abban nem a G5 a gyorsabb''
Van egyaltalan osszehasonlitasi alap? (At)irtak G5-re olyan jatekot, amit kihegyeztek dual procira, optimalizaltak a G5 architekturajahoz es hasonlok?
Fiery -
Power
senior tag
1. 1997-ben pontosan 32 db processzor Power2SC processzort 135MHz-en plusz az 512 sakkprocesszort. Ezt a processzort 1996-ban fejlesztették ki, szóval már 1995-ben aligha használhatták, valószínű a sakkprocesszora sem a végleges volt.
Annyit sikerült találnom, hogy 1995-ös prototípus csupán 2 node-os volt és nem 8, hanem csak 6 engine proci volt 1 node-on. Ezért nyílvánvaló, hogy hw-s sem nagyságrendekkel gyorsabb, mint egy P90. Ráadásul az engine is egész más célhw-re készült, nem meglepő hogy nem lett első(kb. 1/50-ed akkora teljesítménye volt, mint a 97-esnek). A DeepBlue programja tökéletesen optimalizálva volt a hw-re, nem kétéves hülyegyerekek írták a szoftvert sem.
Ez egy kifejezetten rossz példa volt a nem optimalizálásra.
3.
Még mindig nem érted? Ez egy célszámítógép volt!!!
Teljesen más elveken működött, mint a Fritz. Látom problémákba ütközöl, hogy eltérő a hw-hoz eltérő megközelítés és eltérő megvalósítás nem feltétlenül azt jelenti, hogy nincs maximálisan kihasználva.
A játékerő nem egyenlő a kihasználtásggal vagy az optimalizáltsággal.
A Deep Blue már múzeumba van, nem hiszem hogy bármilyen összehasonlítási alap lehet egy 1997-es sakkszámítógép, egy jelenlegi bármilyen maival.
Azért kezdődik 96-ban, mert a prototípus az prototípus. Remélem Papp Laciról sem annyi szűrődött le benned, hogy az első edzésén alaposan megverték.Power
-
DcsabaS
senior tag
''Gyongyszem... Az x86 alatt tok jo lenne tudni, hogy mit ertesz, plane amikor belekeversz G5-ot is mar a kepbe. ''
Te most szandekosan ertetlenkedsz?!? Felelmetes vagy. De ime tagoltabban:
1.) Valaki azt allitotta, hogy az x86 kompatibilitas nagyon visszafogja a procik teljesitmenyet, ezert eleve jobb a G5, mint a dual Opteron.
2.) Erre szamba vettem nehany jellemzo teljesitmenyigenyes alkalmazast, ugy mint: szerver, 3D es media kodolas.
3.) Az elso kettonek a megvalositasa eleg eros fuggvenye az x86-os felepitesnek, megis, a dual Opteron teljesit jobban, nem a G5.
4.) A media kodolasban a G5 ugyan gyorsabb, de a SIMD lenyegeben fuggetlen az x86 kompatibilitastol, szoval egy x86-os prociba is lehetne olyan SIMD kiterjesztes, amely legalabb olyan gyors, mint a G5 (PowerPC 970) fele.
5.) A tanulsag pedig az, hogy az x86 kompatibilitasrol _NEM_ latszik, hogy nagyon visszafogna a sebesseget.
''Van egyaltalan osszehasonlitasi alap? (At)irtak G5-re olyan jatekot, amit kihegyeztek dual procira, optimalizaltak a G5 architekturajahoz es hasonlok?''
Hogyne lenne, hiszen ossze lehet hasonlitani altalanos irodai programokkal (a dual Opteron a gyorsabb), grafikus programokkal, mint pl. a Photosop (a dual Opteron a gyorsabb), FTP es WEB szerver programokkal (a dual Opteron a gyorsabb), 3D jatekokkal (a dual Opteron a gyorsabb), es media kodolassal (a G5 a gyorsabb).
Ami az optimalizalast illeti:
A G5 oprendszere maris 64 bites es allitolag optimalizalt (a media kodolo resze biztos), a dual Opteron viszont kenytelen volt egy kiforratlan, ''alig 64 bit-es'' (driverek hianyaban) oprendszerrel versenyezni.
A dual procira valo optimalizalassal is hasonlo a helyzet. Szoval en ugy latom, hogy inkabb az Opteron fog meg tovabb gyorsulni.
*************
''Ezt a processzort 1996-ban fejlesztették ki, szóval már 1995-ben aligha használhatták, valószínű a sakkprocesszora sem a végleges volt.''
Mint irtam, mar annak idejen is ellentmondasos hirek jelentek meg arrol, hogy pontosan milyen hardverrel is rendelkezik a Deep Blue. De 1995-ben mar letezett es versenyeztettek is, barmilyen procikbol is raktak ossze.
''Ezért nyílvánvaló, hogy hw-s sem nagyságrendekkel gyorsabb, mint egy P90. ''
Ez ugye attol fugg, hogy mire es hogyan hasznaljak. Nyilvan tudod, hogy ha pl. egy 32 bit-es CPU kifut a kozvetlenul kezelheto RAM-bol (mondjuk 4 GByte), es a HDD-hez kenytelen nyulkalni egy komolyabb szimulacional vagy adatbazisnal, akkor egy 64 bit-es CPU pusztan azzal is tud lenni nagysagrendekkel gyorsabb, hogy mondjuk 16 GByte RAM-ot kezel.
Az IBM-esek akkortajt nem azt allitottak, hogy egy kicsit gyorsabb gepet csinaltak, hanem azt, hogy egy supercomputert.
''Ráadásul az engine is egész más célhw-re készült, nem meglepő hogy nem lett első''
En mindenesetre meglepodtem rajta, mint ahogy alighanem (#256) Fiery-nek is meglepo volt. Azzal egyetertek, hogy hiaba a ''supercomputer'', ha nincs a feladatra optimalizalva a szoftvere. Az egesz tortenetet csak azert ideztem, hogy vilagos legyen: igenis van olyan (plane tudomanyos korokben), hogy adva van a nagyszeru hardver, es viszonylag rosszul megirt, azaz nem, vagy nem jol optimalizalt programokat futtatnak rajta.
''A DeepBlue programja tökéletesen optimalizálva volt a hw-re, nem kétéves hülyegyerekek írták a szoftvert sem.
Ez egy kifejezetten rossz példa volt a nem optimalizálásra.''
A Deep Blue operacios rendszere feltehetoen optimalizalt volt. Csakhogy itt most a sakkprogramrol van szo, amit rajta futtatak!
''Még mindig nem érted? Ez egy célszámítógép volt!!!''
Plane szegyen, hogy milyen rosszul muzsikalt egy x86-os Pentiummal es a ra ganyolt programmal szemben (:)... -
Power
senior tag
''Mint irtam, mar annak idejen is ellentmondasos hirek jelentek meg arrol, hogy pontosan milyen hardverrel is rendelkezik a Deep Blue. De 1995-ben mar letezett es versenyeztettek is, barmilyen procikbol is raktak ossze.''
Tudod, ahhoz hogy megjelenhess valamivel tesztelni kell, edzeni. Nekik Kasparov volt a céljuk, elérték. A kezdeti szárnypróbálgatásokat felesleges szajkózni.
''Ez ugye attol fugg, hogy mire es hogyan hasznaljak. Nyilvan tudod, hogy ha pl. egy 32 bit-es CPU kifut a kozvetlenul kezelheto RAM-bol (mondjuk 4 GByte), es a HDD-hez kenytelen nyulkalni egy komolyabb szimulacional vagy adatbazisnal, akkor egy 64 bit-es CPU pusztan azzal is tud lenni nagysagrendekkel gyorsabb, hogy mondjuk 16 GByte RAM-ot kezel.''
Jaj! Már megint az általánosság. Itt és most konkrét dolgokról van szó, ne menekülj az általánosságokba.
''Az IBM-esek akkortajt nem azt allitottak, hogy egy kicsit gyorsabb gepet csinaltak, hanem azt, hogy egy supercomputert.''
A Deep Blue 1997-ben az is volt.
''En mindenesetre meglepodtem rajta, mint ahogy alighanem (#256) Fiery-nek is meglepo volt. Azzal egyetertek, hogy hiaba a ''supercomputer'', ha nincs a feladatra optimalizalva a szoftvere.''
Figyú. Ha valamit 256 cél-hw-re optimalizálva tervezel 6 évig, akkor a 4-dik évben nem biztos, hogy 14-en optimálisan kifutja magát.
''Az egesz tortenetet csak azert ideztem, hogy vilagos legyen: igenis van olyan (plane tudomanyos korokben), hogy adva van a nagyszeru hardver, es viszonylag rosszul megirt, azaz nem, vagy nem jol optimalizalt programokat futtatnak rajta.''
Azért írtam, hogy ez egy kifejezetten rossz példa volt. A nagyon nagy arcok alkották a DeepBlue-t.
''A Deep Blue operacios rendszere feltehetoen optimalizalt volt. Csakhogy itt most a sakkprogramrol van szo, amit rajta futtatak!''
Az is tökéletes volt a koncepcióhoz. Az egy más kérdés, hogy közben ''forradalom'' zajlott le a sakkprogramozásban, mind a pc-k fejlődésében, de ez 90-ben még nem látszott.
''Plane szegyen, hogy milyen rosszul muzsikalt egy x86-os Pentiummal es a ra ganyolt programmal szemben (...''
Más gép ellen játszani és más ember ellen. A DeepBlue Kasparov ellen tökéletes volt, 96-ban(97-ben) a Fritz-et is megverte volna. Az x86-os pentiumról meg csak annyit, hogy nagyjából azonos volt a fixpontos teljesítménye, mint a Power2-es procié.Power
-
Power
senior tag
''Mint irtam, mar annak idejen is ellentmondasos hirek jelentek meg arrol, hogy pontosan milyen hardverrel is rendelkezik a Deep Blue. De 1995-ben mar letezett es versenyeztettek is, barmilyen procikbol is raktak ossze.''
Tudod, ahhoz hogy megjelenhess valamivel tesztelni kell, edzeni. Nekik Kasparov volt a céljuk, elérték. A kezdeti szárnypróbálgatásokat felesleges szajkózni.
''Ez ugye attol fugg, hogy mire es hogyan hasznaljak. Nyilvan tudod, hogy ha pl. egy 32 bit-es CPU kifut a kozvetlenul kezelheto RAM-bol (mondjuk 4 GByte), es a HDD-hez kenytelen nyulkalni egy komolyabb szimulacional vagy adatbazisnal, akkor egy 64 bit-es CPU pusztan azzal is tud lenni nagysagrendekkel gyorsabb, hogy mondjuk 16 GByte RAM-ot kezel.''
Jaj! Már megint az általánosság. Itt és most konkrét dolgokról van szó, ne menekülj az általánosságokba.
''Az IBM-esek akkortajt nem azt allitottak, hogy egy kicsit gyorsabb gepet csinaltak, hanem azt, hogy egy supercomputert.''
A Deep Blue 1997-ben az is volt.
''En mindenesetre meglepodtem rajta, mint ahogy alighanem (#256) Fiery-nek is meglepo volt. Azzal egyetertek, hogy hiaba a ''supercomputer'', ha nincs a feladatra optimalizalva a szoftvere.''
Figyú. Ha valamit 256 cél-hw-re optimalizálva tervezel 6 évig, akkor a 4-dik évben nem biztos, hogy 14-en optimálisan kifutja magát.
''Az egesz tortenetet csak azert ideztem, hogy vilagos legyen: igenis van olyan (plane tudomanyos korokben), hogy adva van a nagyszeru hardver, es viszonylag rosszul megirt, azaz nem, vagy nem jol optimalizalt programokat futtatnak rajta.''
Azért írtam, hogy ez egy kifejezetten rossz példa volt. A nagyon nagy arcok alkották a DeepBlue-t.
''A Deep Blue operacios rendszere feltehetoen optimalizalt volt. Csakhogy itt most a sakkprogramrol van szo, amit rajta futtatak!''
Az is tökéletes volt a koncepcióhoz. Az egy más kérdés, hogy közben ''forradalom'' zajlott le a sakkprogramozásban, mind a pc-k fejlődésében, de ez 90-ben még nem látszott.
''Plane szegyen, hogy milyen rosszul muzsikalt egy x86-os Pentiummal es a ra ganyolt programmal szemben (...''
Más gép ellen játszani és más ember ellen. A DeepBlue Kasparov ellen tökéletes volt, 96-ban(97-ben) a Fritz-et is megverte volna. Az x86-os pentiumról meg csak annyit, hogy nagyjából azonos volt a fixpontos teljesítménye, mint a Power2-es procié.Power
-
perla
csendes tag
1. Ja, ok, ugy ertem, x86-hoz nincs koze. Amugy ja, hat a rambus egy nagy beszopas volt (annak ellenere, hogy ebben a gepben is rdram van, amin ezt irom). Ez sokszor elofordul, hogy valaki kitalal valamit, es probalja a tobbieket lehuzni, erre azok szarnak ra, es fejlesztenek mast.
2. Nem tudom, hova akarunk itt eljutni. Igen, az a64 jol futtatja az x86 kodot. Amugy a p4-ek is egesz jol, csak az a64 jobban. Bar a pentium M is egesz jol futtatja. Ettol meg x86 nelkul szebb es gyorsabb a vilag.
5. Itt nagyon elbeszelunk egymas mellett. Annyit tudok mondani, hogy www.top500.org. Ott megtalalod a linkeket a szuperszamitogepek oldalaihoz. Van ahhol talalsz informaciot a szuperszamitogepek mukodeserol is. Ha megnezed, latod, hogy a kis pc potyogott programok nem is futnanak ezeken. Szal ugy kell a proggykat fejleszteni, hogy az adott gepen futtassad. Mi ez, ha nem optimalizacio?
Kevered az informatikust a programozoval. A Fritz 1.0 nem ismerem, de nem lehet, hogy algoritmikus szinten is mas volt?
Nem tudom, nekem ugy altalaban az az erzesem, hogy meg sose lattal cpu clustert, nem is hasznaltal. Ebbol adodnak az ilyenek, hogy ''A G5 vonatkozasaban ez pl. azt is jelenti, hogy amennyiben tudna fogadni a megfelelo interface eszkozoket''. Nyilvanvalo, hogy egy cpu clusternek nem feladata interface eszkozoket fogadni. Nagy sebessegu halozat kell inkabb, es a specko interfaceeket meg mashova teszed. Az meg, hogy a cpu cluster milyen altalanos cpukat tartalmaz, azt meg a feladat valasztja ki. Ha simd feladat van (amihez tok jo konyvtarak leteznek), akkor g5 a legjobb valasztas. Ennyirol van itt szo. -
perla
csendes tag
Ebben azert sok csusztatas van. En allitottam, hogy az x86 kompatibilitas visszafogja a procik teljesitmenyet. Azt is, hogy a G5 simd-ben gyorsabb a tobbi procinal, de a kettot csak te kototted ossze. Arrol volt szo, hogy x86 nelkul faszabb procit lehetne csinalni. Nem csinalt meg senki ilyet. A G5 csak egy pelda, amilyen iranyba lehetne menni, de messze nem tart ott (csak simd-ben), mint mondjuk az opteron. Volt mar errol szo, ennek egyszeru oka, hogy a jatekok okan nagyon sok penz megy az intel/amd/ati/nvidia cegek fejlesztesi budgetjebe.
-
Fiery
veterán
''Arrol volt szo, hogy x86 nelkul faszabb procit lehetne csinalni. Nem csinalt meg senki ilyet.''
Itanic. Intel megcsinalta. Pont az x86-tol valo elszakadas es a brutalis eloallitasi koltsegek miatt nem tudta felvaltani az x86-os procikat (es nem is fogja egyhamar, talan sosem).
Fiery -
perla
csendes tag
Hat annyiban igaz, hogy nem x86, de szerintem gyorsabb lenne, ha riscet fejlesztettek volna, es nem is kerulne annyiba az eloallitasa.
Nagy teritett betlit ad elo az Intel minden szinten. Itanic bukta, sok fejlesztes lelove, es meg egy kurva 800-as fsb-s xeont se tudnak osszehozni a fiuk, nemhogy 64 bitet. Persze a bemondasok mennek, marketing mukodik, de ennyi. Sose volt nagyobb eselye az AMD-nek az eloretoresre, mint most. -
Power
senior tag
''Hat annyiban igaz, hogy nem x86, de szerintem gyorsabb lenne, ha riscet fejlesztettek volna, es nem is kerulne annyiba az eloallitasa.''
A RISC nem megoldás, ugyanazon problémákkal küszködik, mint az x86.
Egyébként nem az előállítási költségek a jelentősek az Itaniumnál, hanem a fejlesztési költségek. A kettő között több nagyságrend különbség van.Power
-
perla
csendes tag
Vajon az Itanium es egy risc proci fejlesztesi koltsegei hogy viszonyulnak egymashoz szerinted? Nyilvan a risc olcsobb. Masreszt egy kisebb lapkameretu proci hosszutavon is olcsobba bir valni a nagyobb kihozatal stb. miatt. Es igaz ugyan, hogy az eladott kb. 18 db Itanium procinal a fejlesztesi koltseg dominal, de egy piacvezeto procinal mar sokkal jelentosebb az eloallitasi koltseg (mint az Itaniumnal, nyilvan a fejlesztesi koltseg sokaig meghatarozo az arban).
Amugy mit ertesz 'a risc' alatt? Szerintem csak siman risc van, es termeszetesen nem ugyanazok a gondok vele, mint az x86-nal. -
Power
senior tag
''Vajon az Itanium es egy risc proci fejlesztesi koltsegei hogy viszonyulnak egymashoz szerinted?''
Ez attól függ, hogy mi a fejlesztés célja.
''Nyilvan a risc olcsobb.''
Nem biztos!!!
''Masreszt egy kisebb lapkameretu proci hosszutavon is olcsobba bir valni a nagyobb kihozatal stb. miatt.''
1. Egyáltalán nem biztos, hogy egy RISC proci kisebb
2. A lapkaméret és a kihozatal között nincs egyenes összefüggés
''Es igaz ugyan, hogy az eladott kb. 18 db Itanium procinal a fejlesztesi koltseg dominal, de egy piacvezeto procinal mar sokkal jelentosebb az eloallitasi koltseg (mint az Itaniumnal, nyilvan a fejlesztesi koltseg sokaig meghatarozo az arban).''
Az összes felső kategóriás processzornál a fejlesztési költség dominál.
''Amugy mit ertesz 'a risc' alatt? Szerintem csak siman risc van, es termeszetesen nem ugyanazok a gondok vele, mint az x86-nal.''
Az 'a' pusztán névelő volt a mondat elején. :)
A teljesítmény növelés szempontjából az x86-nak ugyanazok a gondjai, mint a risc-nek. Az intel ezért nem RISC-et csinált, mert azzal semmiféle előrelépést nem tett volna.
[Szerkesztve]Power
-
perla
csendes tag
1. Egy risc proci kisebb (most a cacheket hagyjuk). Mitol lenne nagyobb?
2. Ha minden egyforma (technologia, csikszelesseg stb.), akkor ugyanazert a penzert a kisebb lapkameretubol tobbet lehet gyartani.
Persze, csak nem a felso kategorias processzorokon van a haszon. Nyilvan nem akkor kaszal a ceg, amikor meg a fejlesztesi koltseget termeli vissza.
Pl. egy mostani Celeron proci arat szerinted mi hatarozza meg? Szerintem foleg az eloallitasi koltseg es a piac. Fejlesztes mar nem nagyon jatszik.
Mar volt szo rola, de nem ugyanazok a gondok. Pl. egy risc procinal nincsenek olyan nagy gondok, mint az x86 pipeline szopato flagallitasai. Szerintem ha riscet fejlesztettek volna, akkor mar most 4-5 gigahertznel tartananak, es teljesitmenyben meg legalabb 2x-nel. Az intel nem ezert nem csinalt riscet, hanem mert azt nem tudta volna eladni, az x86-ot meg igen. -
Power
senior tag
''1. Egy risc proci kisebb (most a cacheket hagyjuk). Mitol lenne nagyobb?''
Melyik???
A risc nem azt jelenti, hogy kisebb vagy jobb :)
Az USP-IV illetve a PA-8800 majdnem akkora, a Power5 pedig picivel nagyobb, mint a Madison. Ha a cache-eket hagynánk, akkor a Madison még kisebb lenne hozzájuk képest.
''2. Ha minden egyforma (technologia, csikszelesseg stb.), akkor ugyanazert a penzert a kisebb lapkameretubol tobbet lehet gyartani.''
Ezek mindegyikénél ugyanaz a csíkszélesség.
A másik meg az, hogy nem mindegy mi van benne, nagyban függ attól, hogy mennyire egyszerű a gyártás vagy sem. A méret csak 1 dolog.
''Mar volt szo rola, de nem ugyanazok a gondok. Pl. egy risc procinal nincsenek olyan nagy gondok, mint az x86 pipeline szopato flagallitasai. Szerintem ha riscet fejlesztettek volna, akkor mar most 4-5 gigahertznel tartananak, es teljesitmenyben meg legalabb 2x-nel. Az intel nem ezert nem csinalt riscet, hanem mert azt nem tudta volna eladni, az x86-ot meg igen.''
Dehogynem.
Hadd ne menjek bele, hogy a mai x86 processzorok mennyire hasonló felépítésüek, mint a mai RISC-ek.
A 4-5 GHz-es procinak nincs értelme, a memória nem tudja követni az IPC nem lenne magasabb, sőt. A mai RISC processzorok is mehetnének 3GHz-en, de nem mennek, mert teljesítményben rosszabb eredményeket ad egy nagyon hosszú pipeline cserében jóval több hőt termel.
A RISC és az x86 architechtúrák fejlesztésének egyetlen kiútja a SMT és CMP, ez eléggé behatárolja az elkövetkező éveket.
Az Itaniumban elméletileg azonban sokkal nagyobb lehetőségek vannak.
Az más kérdés hogy nem biztos, hogy megéri a rögös út. :)Power
-
Dale
aktív tag
Sziasztok! Ez most kicsit talán offtopic lesz, sajnos még csak úgy az első 100 hozzászólást olvastam el. Den aggódott amiatt hogy ha a procikban órajelnövelés helyett architekturális fejlesztések lesznek a domináns változások, újra kell majd fordítani minden programot hogy megérezze a felhasználó a sebességnövekedést. Azt hiszem jó hírem van: nem kell, elég lesz letölteni az új processzorunkhoz dukáló .NET Common Language Runtime-ot és máris minden programunk kihasználja a processzor új képességeit. Nem ma, de a közeli jövőben. A Longhorn már teljes egészében a .NET Frameworkre épül (azért nem olyan gyors; semmiképp sem lassú ha tudod mi van a felszín alatt) és a Win32 API már csak kompatibilitási okokból van benne, fejlesztve nemigen lesz többet. A régi programok még elfutogatnak, egy ideig, lásd MacOS 9 -> MacOS X, de aztán bye bye x86 drótozás, welcome Managed Code. Don Box és a többi Microsoftos Software Architect már most is azt sulykolja a fejlesztők fejébe hogy álljanak át Managed Code-ra mert az a jövő. És ezzel egyet is értek, én már átálltam 2 éve. :)
Természetesen ez (jelenleg) csak a PC-k 85%-ára áll, de a Linux is ebbe az irányba mozdul el lassan, izzadnak is rendesen hogy a Mono-t összehozzák mert ha nem tudnak .NET-es programokat futtatni akkor meg lesznek lőve. Elnézést kérek a Linux mániásoktól de elég sokkal vagyok körülvéve és már mind elismerték hogy .NET über alles, szóval a többieknél is csak idő kérdése. :)
Mégegyszer elnézést hogy beleoffoltam az architektura témába.https://enginedesigns.net
-
perla
csendes tag
1. Nyilvan arrol van szo, hogy egy hasonlo teljesitmenyu risc proci kevesebb tranzisztorbol all, mint egy cisc vagy vliw stb.
USP-IV - ez 2 USP-III corebol all, az USP-III-ban a logic 11 millio tranzisztor
PA-8800 - ez ugye ket PA-8700-as corebol epul fel +cache, a core-ok 25 millio tranzisztorbol allnak
Tobbirol nem talaltam egyertelmu adatot, ha te talalsz, legyszi ird ide.
2. Nem tudom itt mire gondolsz. Szerintem nagyreszt az hatarozza meg, hogy sikerult-e egy chip, amikor a tranzisztorokat kialakitjak. Logikus modon a nagyobb meretbol nagyobb hibaszazalek adodik, raadasul egy szeletre kisebb szamu chip fer. Ezekbol az kovetkezik, hogy kisebb chipet ugyanolyan technologiaval olcsobb gyartani.
Ja, az x86 processzorok hasonloak, mint a riscek, van egy risc magjuk, meg a hulye korites. Pont a hulye korites az, amit ki kellene dobni. Amugy nem is ertem, hogy ezen miert vitatkozunk. Jozan paraszti esszel: az x86 architecture korlatozas, kereteket, szabalyokat szab. Vajon egy korlatozas nelkul vagy azzal egyutt lehet a gyorsabb procit epiteni? Nyilvan a korlatozas nelkul. Na errol van szo. Az SMT-nek meg CMP-nek nincs koze az x86 vagy nem x86 kerdeshez. -
Power
senior tag
''1. Nyilvan arrol van szo, hogy egy hasonlo teljesitmenyu risc proci kevesebb tranzisztorbol all, mint egy cisc vagy vliw stb.''
Ez mondom már mióta, hogy nem igaz!!!
''USP-IV - ez 2 USP-III corebol all''
Telejesen mindegy - 2 core, de az 1 processzor gyártási szempontból és itt erről beszéltünk.
''az USP-III-ban a logic 11 millio tranzisztor''
Az L1 szerves része a core-nak.
''PA-8800 - ez ugye ket PA-8700-as corebol epul fel +cache, a core-ok 25 millio tranzisztorbol allnak''
Mivel ezekben csak L1 van ezt simán hozzáadhatod a core-hoz, de még annélkül is baromi sok. Az Itanium2 core-ja(cache-ek nélkül) kevesebb, mint 25 millió tranziszort tartalmaz és csak 1 core van a chipen.
''Tobbirol nem talaltam egyertelmu adatot, ha te talalsz, legyszi ird ide.''
Azért nem nagyon, mert mint írtam az L1 a core része és nem is adják meg nagyon külön.
A 64 bites háborús topik indító cikkében:
[L]http://www.realworldtech.com/page.cfm?ArticleID=RWT042704221446[/L]
Itt az ábra közel méretarányos.
Itt látszik, hogy egyáltalán nem lehet azt mondani, hogy a madison nagy lenne, főleg nem a core-ja.
A Montecito-val már más a helyzet, de a core ott sem lesz olyan nagy.
Itt nem szerepel az USP-IV+, a PA-8900 vagy akár a Niagara amely szintén nem lesz pici.
Az látszik, hogy az IA-64 chipek nagyrésze az L3. Egy fejlett busszal jócskán kisebb L3 is elég lehetne.
Továbbá: az USP és PA-RISC-ekhez külső cache chipek kellenek!!!
Ugyanígy a Power-ekhez is. Az Itanium-nál belenyomták, mert a kis core miatt belefért.Power
-
kisfurko
senior tag
Azért annyit elismerhetnél már perla-nak, hogy sokkal egyszerűbb lenne a pipeline-t megcsinálni, ha nem kéne mindenféle függőségekkel szívni, hogy most ez az utasításrész melyik valódi regisztert, mikor érinti, vagy összeharácsolni az EFLAGS állapotát egy-egy utasítás után.
Tudom, hogy a mostani RISC-szerű procikban is van register renaming, de egy háromoperandusú utasításkészlet jóval kevesebb függőséget okoz. Igaz ez nem RISC/CISC kérdése. -
Power
senior tag
válasz
kisfurko
#283
üzenetére
''Azért annyit elismerhetnél már perla-nak, hogy sokkal egyszerűbb lenne a pipeline-t megcsinálni, ha nem kéne mindenféle függőségekkel szívni, hogy most ez az utasításrész melyik valódi regisztert, mikor érinti, vagy összeharácsolni az EFLAGS állapotát egy-egy utasítás után.''
A regiszter kezelés illetve a flagek a RISC procikban is jelen van, ezt register átnevezéssel jól lehet kezelni a RISC procikban is így csinálják, ez nem gond, könnyen orvosolható probléma.
''Tudom, hogy a mostani RISC-szerű procikban is van register renaming, de egy háromoperandusú utasításkészlet jóval kevesebb függőséget okoz. Igaz ez nem RISC/CISC kérdése.''
Nem a 3 operandusú okoz kevesebb függőséget, hanem a több elsődleges regiszter. A gyakorlatban azonban ugyanakkora a függőség egy P4/K8-nál, mint egy USP/Power-nél.Power
-
Power
senior tag
''Azert egy riscben egyszerubb a flag kezeles''
Aligha. Egyébként ezt kifejthetnétek bővebben konkrétan mire gondoltak. Mi egyszerűbb benne és miért?
''masik hasonlo cucc a szazmillio fele ugro utasitas.''
:F
Feltételes vezérlés átadás a RISC-nek is szerves része.
Vagy mire gondolsz?Power
-
perla
csendes tag
Ez a ketto osszefugg. Az x86 processzorok (a kompatibilitas miatt) ossze-vissza allitgatjak a flageket, es emiatt szopatjak a pipelinet (illetve a branch predictiont). De errol mar volt szo korabban. De nezd meg pl., hany orajel kell a flag allito utasitasokhoz (pl. shift, rotate).
Hulyeseg, hogy mindig riscet mondunk (mondok), amugy helyesen 'nem x86'. Hogy ne legyen felreertes, mar mondtam ugyan, szal nem arrol van szo, hogy a mostani x86 procik szarok, eppen ellenkezoleg, de sokkal faszabbak lennenek, ha nem x86-ok lennenek. Meg az itanic is jo pelda erre, az Intel szerint is szopat az x86 architectura, az itanium nem is arra van optimalizalva. -
Power
senior tag
''Ez a ketto osszefugg. Az x86 processzorok (a kompatibilitas miatt) ossze-vissza allitgatjak a flageket, es emiatt szopatjak a pipelinet (illetve a branch predictiont). De errol mar volt szo korabban. De nezd meg pl., hany orajel kell a flag allito utasitasokhoz (pl. shift, rotate).''
Nem probléma a teljesítmény szempontjából.
1 órajel kell az a használatos rotate és shift utasításokhoz.
Vannak bizonyos utasítások amit már évek óta kifejezetten ellenjavalott használni, de aki sz*patni akarja magát az használja, mindenesetre a magas szintű nyelvek compilerei nem használják. Az, hogy nem vették ki az ISA-ból az pedig érthető.
''Hulyeseg, hogy mindig riscet mondunk (mondok), amugy helyesen 'nem x86'''
Az IA-64 nem risc :)
A transmeta sem.
Sőt egyébként a mai risc-ek sem felelnek meg a klasszikus értelembevett risc definiciónak.
''Hogy ne legyen felreertes, mar mondtam ugyan, szal nem arrol van szo, hogy a mostani x86 procik szarok, eppen ellenkezoleg, de sokkal faszabbak lennenek, ha nem x86-ok lennenek''
Hidd el nem lenne sokkal jobb.
A mai risc-ek eleve 32 bitesek voltak, de ma már 64 bitesek. Nekik is meg van a maga 32/64 bites nyűgés.
A kompatibilitás sokkal nagyobb érték, mint bármi más.
''Meg az itanic is jo pelda erre, az Intel szerint is szopat az x86 architectura, az itanium nem is arra van optimalizalva.''
Az itanium teljesen más megközelítés. A risc és cisc sokkal közelebb áll egymáshoz, mint az epichez vagy a vliwhez.
Az epic-et nem az intel találta ki, már több, mint 10 éve masszírozzák, mert már akkor látszottak a risc és x86 problémai.
[Szerkesztve]Power
-
perla
csendes tag
Bocs, felreertettel. ''Helyesen 'nem x86''' alatt azt ertettem, hogy amikor eddig arra hivatkoztam, hogy a risc mennyivel jobb, stb., az azt jelentette, hogy a 'nem x86' mennyivel jobb.
Nem hiszem, sokkal jobb lenne. Eddig egyetlen jo erv nem volt a mellett, hogy az x86 miert lenne az abszolut sebessegkiraly irany (nem is az). Persze, az Intel meg az AMD mernokei fasza csavok, es mara nagyon kiraly procikat hoztak ossze. (Nagyon sok penzert, amin sokkal gyorsabb nem x86-os procit lehetett volna fejleszteni). Igen, a kompatibilitas a legnagyobb ertek, ezert is mehet a sebesseg rovasara.
Igen, Itanium teljesen mas megkozelites. Miert csinaltak igy, es miert nem x86 az is? Mert megprobaltak valami gyorsat csinalni, es ugy gondoltak (ahogy en is, de te nem), hogy azt nem x86 alapon lehet megcsinalni. -
Power
senior tag
''Bocs, felreertettel. ''Helyesen 'nem x86''' alatt azt ertettem, hogy amikor eddig arra hivatkoztam, hogy a risc mennyivel jobb, stb., az azt jelentette, hogy a 'nem x86' mennyivel jobb.
Nem hiszem, sokkal jobb lenne. Eddig egyetlen jo erv nem volt a mellett, hogy az x86 miert lenne az abszolut sebessegkiraly irany (nem is az). Persze, az Intel meg az AMD mernokei fasza csavok, es mara nagyon kiraly procikat hoztak ossze. (Nagyon sok penzert, amin sokkal gyorsabb nem x86-os procit lehetett volna fejleszteni). Igen, a kompatibilitas a legnagyobb ertek, ezert is mehet a sebesseg rovasara.''
Jelenleg a SPECint2K szerint a P4EE a leggyorsabb.
Figyelj sem az IBM-nél, a HP-nél, sem a SUN-nál sem hülyegyerekek tervezik a processzorokat. Nekik sem nagyon sikerült, ráadásul az utóbbi kettő még dual core-ral is nehezen hozza a P4 sebességét.
Nem hiszem, hogy akármilyen risc architechtúrával gyorsabb lehetne.
Ennek elvi okai vannak és nem technikai.
Az 1 threades IPC-nek elvi korlátait nem lehet átlépni a mai risc/x86-tal, a vliw/epic-kel igen, de ott meg a fordító írása bitang nehéz.
''Igen, Itanium teljesen mas megkozelites. Miert csinaltak igy, es miert nem x86 az is?''
A 80-as évek elején megjelent risc és superskalár ez a 90-es évek elején már látszottak a korlátai ezért fordultak a vliw felé. Most pedig a 2000-es évek elején ugyanez lesz a CMP. Aztán megint jön vmi.
''Mert megprobaltak valami gyorsat csinalni, es ugy gondoltak (ahogy en is, de te nem), hogy azt nem x86 alapon lehet megcsinalni.''
Pontosan, de ebből a szempontból az x86-ra ugyanígy igaz, mint a risc-re.
Én csak azt vitattom, hogy gyorsabb RISC magot lehet építeni, mint x86-ot. Lehet nagyon egyszerű RISC magot építeni, de a mai RISC-ek már egyáltalán nem azok.Power
-
perla
csendes tag
Persze, a tobbiek is okosak. De mondjuk azok mas celu processzorok, szal nem gondolnam, hogy az osszehasonlitas valamennyire is erdekes. Szal egy olyan procit, ami csak single proc uzemmodban mukodik, nem erdemes egy olyanhoz hasonlitani, ami 64 procis kornyezetben is mukodik.
Fejtsd ki legyszi, hogy milyen elvi oka van, hogy egy risc proci gyorsabb legyen, mint egy p4. Kulonosen, mert hiszen tudjuk, hogy belul riscszeru magja van, szal igy mar lehetne rogton olyan procit csinalni, ami ugyanilyen gyors, es risc, ha ennek a magjat vesszuk (igaz, az nem x86 kompatibilis). Megszorjuk meg par 3 operandusu utasitassal ill. sok regiszterrel, es maris gyorsabb (es meg az utasitasok mikroutasitasra bontasat is megsporoltuk -> rovidebb pipeline, vagyis egy pipeline stall koltsege kisebb -> meg gyorsabb). Tessek, ez egy recept a gyorsabb risc procihoz. -
Power
senior tag
''Persze, a tobbiek is okosak. De mondjuk azok mas celu processzorok, szal nem gondolnam, hogy az osszehasonlitas valamennyire is erdekes. Szal egy olyan procit, ami csak single proc uzemmodban mukodik, nem erdemes egy olyanhoz hasonlitani, ami 64 procis kornyezetben is mukodik.''
Egy olyan processzor ami sok proci környezetre terveztek nem lassabb, mint amit ugyanabból egy procis környezetre terveztek, sőt mindegyike gyorsabb.
Ugyanolyan célú processzorok pl. egy PowerPC970-es, mint egy P4 vagy egy A64. Ezek kb. mindegyike ugyanolyan gyors(mindegyik másra van kihegyezve).
''Fejtsd ki legyszi, hogy milyen elvi oka van, hogy egy risc proci gyorsabb legyen, mint egy p4. Kulonosen, mert hiszen tudjuk, hogy belul riscszeru magja van, szal igy mar lehetne rogton olyan procit csinalni, ami ugyanilyen gyors, es risc, ha ennek a magjat vesszuk (igaz, az nem x86 kompatibilis). Megszorjuk meg par 3 operandusu utasitassal ill. sok regiszterrel, es maris gyorsabb (es meg az utasitasok mikroutasitasra bontasat is megsporoltuk -> rovidebb pipeline, vagyis egy pipeline stall koltsege kisebb -> meg gyorsabb). Tessek, ez egy recept a gyorsabb risc procihoz.''
Neked ez rögeszméd, hogy ha 3 operandusos utasításaid vannak attól máris gyors lesz minden? :) Ezt honnan veszed?
1. Nincs szükség sokkal több regiszterre, threadváltásnál megfogná a rendszert.
Van egy optimális méret aminél nem érdemes többet belepakolni, túl sok tranzisztort emészt fel, az egészben és itt nem csak a több registerfile-ra gondolok.
2. A mikroutasításra bontás már az L1 cache-be töltéskor megtörténhet, úgyhogy nem kell, lassítson.
3. Az IPC-t nem tudod növelni, ha megszakadsz se egy RISC-el sem márpedig ez ami visszafog. A függőségek illetve az alapblokk hossza adott.
4. A memória késleltetéssel sem tudsz mit kezdeni.
Lehet izmozni, de szignifákns különbséget nem fogsz tudni elérni RISC-kel sem, viszont annál több munka van vele + sok extra tranzisztor.
Manapság nagyon komoly elemző munka előzi meg egy processzor tervezését. A jó fordító írása még egy RISC-re vagy x86-ra is évekig, márpedig annélkül nem ér sokat a leggyorsabb vas sem.Power
-
perla
csendes tag
Tenyleg nem lassabb? Xeon MP? Vagy akar Xeon? Ezek mind lassabbak, mint a megfelelo p4-ek. A Xeon MP meg orajelben is.
Nem tudom ertelmezni amit irtal, hogy ugyanolyan gyorsak. PPC-t nem tudom, de szerintem mind dual procira van tervezve, A64 meg multiprocira, szal nincs beloluk single-re tervezett, nem?
Ja, 3 operandusos utasitasok gyorsitjak a kodot. Latszik, hogy sose programoztal assemblyben. Tok fontos, hogy nem irodik felul egy operandus, nem kell ujra betolteni, vagy masik regiszterbe menteni, ez kezzelfoghato gyorsulast jelent. Hogy a 4 operandusu utasitasokrol mar ne is beszeljek. Pl. nem tudom hallottal-e mar arrol, hogy egy ilyen jellegu muvelet: d=a*b+c az ppc-ben 1 utasitassal vegrehajthato, es ugyanugy 1 orajel mint barmi mas. Probalj egy a*b+b*c+c*a kifejezest kiszamitani 2 es 3-4 operandusu muveletekkel, es latni fogod, hogy melyik a gyorsabb.
1. Szukseg van tobb regiszterre, megint azt tudom mondani, hogy latszik, hogy nem programoztal assemblyben. De tekintsd pl. ugy, hogy a regiszterek a 0. szintu cache, minel tobb van, annal jobb. Kulonben ennel nyilvanvalobb dolgot, hogy az x86 architecturaban keves a regiszter, nem is lehet talalni. Te ezt komolyan cafolni probalod???? Ja, taskvaltasnal trade-off van, ezert van optimalis meret, nem kell ezer regiszter. Eleg mondjuk 32.
2. Ez igaz, ilyenkor a l1 cache-be toltest lassitja.
3. Latod, hogy tudtam. 3 operandusu muvelettel es tobb regiszterrel. Illetve igazabol 'felesleges' utasitasokat sporoltam meg ezekkel. Egyebkent nyilvan nem az IPC fog vissza, az csak meri a proci egy jellemzojet, nem meghatarozza.
4. Azzal valoban nem, az olyan amilyen. Mondjuk azt azert el lehet erni, hogy ugyanannyi ido alatt tobb adatt toltodjon fel a cachekbe. Masreszt van ez a data stream cucc a ppc-kben, hogy ha folytatolagos cimrol kezdesz olvasni a memoriaban, akkor elkezdi neked a proci elore behozni a cachebe.
Nemnem. A peldam jo, egy csomo tranyot kidobtam, amikor csak a magot tartottam meg, par regiszter meg par utasitas siman kitelik belole. Es forditot csak x86-ra meg itaniumra nehez irni, riscre sokkal egyszerubb, ez is egy elonye, csak eddig errol nem volt szo, mert nem a hardverhez kapcsolodik.
Amugy eddig azt magyaraztad, hogy risckel kozelebe se jutok az x86-nak, mostmar visszakoztal, hogy szignifikans kulonbseget nem tudok osszehozni. Egyreszt ez a nem szignifikans kulonbseg szerintem akar 20-30% is lehet (ki lehet probalni G5-on csak 4-6-8 regiszter hasznalataval mennyivel lassabb kodot lehet irni, es amikor rajossz, hogy hoppa, ki kell irni a memoriaba az adatot, mert nincs tobb regiszter, akkor kiderul, hogy mennyit lassit), masreszt mivel kidobtam a procibol egy nagy reszt, valszeg magasabb orajelet is el lehetne erni, harmadreszt ez 0 uj otletet tartalmazo megoldas, szal ha meg 1-2 evet belefektet az ember a tervezesbe, nyilvan egyeb gyoritasokat is kitalal, es nem csak egy siman lemasolt procit krealna. -
kisfurko
senior tag
''A regiszter kezelés illetve a flagek a RISC procikban is jelen van, ezt register átnevezéssel jól lehet kezelni a RISC procikban is így csinálják, ez nem gond, könnyen orvosolható probléma.''
Ez igaz, de nem mindegy, hogy 8 regiszterre kell trükközni, vagy minimum 32-re. Meg az sem mindegy, hogy kétoperandusú vagy több. Mert kétoperandusúhoz több regiszter kell.
A flagekről meg csak annyit, hogy sokszor tök feleslegesek (mert részszámítás), nyugodtan lehetne szabályozni, hogy mikor kell. Egyébként nem RISC/CISC összehasonlítást kell csinálni (hiszen manapság nincs igazi CISC), én is, mint perla x86 vs. jobb.
''A gyakorlatban azonban ugyanakkora a függőség egy P4/K8-nál, mint egy USP/Power-nél.''
Ezt azért nehezen hiszem, nem véletlen, hogy a K8-ba is duplaannyi regisztert raktak.
Mikor is vitáztunk ezen régebben? :) -
kisfurko
senior tag
Teljesen egyetértek veled, szerintem sem lehet nagyobb teljesítményűt kihozni egy másik architektúrával.
DE!
Nagyon nem mindegy, hogy szegény programozónak mennyit kell szenvednie (mert nincs olyan programnyelv, ami a vektoros számításokat normálisan használná pl.)! Egyébként nem értem, hogy a C-t (vagy C++-t) miért nem egészítették ki megfelelő adattípusokkal... Persze szóljatok, ha van már ilyen...:)
''Lehet izmozni, de szignifákns különbséget nem fogsz tudni elérni RISC-kel sem, viszont annál több munka van vele + sok extra tranzisztor.''
Ez az, ami szerintem nem igaz. A P4 kifejlesztése szerintem sokkal több pénzt emésztett fel, mint egy ugyanolyan teljesítményű, de kevésbé gány processzor. Pont a szopások leküzdése miatt. Gondolom te is megnézted azt a videót, amit DCsabaS linkelt be a korábbi vitánk során, és ott elmesélte az inteles fickó, hogy bizony a P6 architektúrában volt egy olyan bibi, hogy néha bizonyos utasítások még több száz (vagy több, nem emlékszem) ciklus után sem akarták elhagyni az instruction pool-t.
Nekem csak ez a problémám. De ezt már kibeszéltük egyszer. :) -
Power
senior tag
''Tenyleg nem lassabb? Xeon MP? Vagy akar Xeon? Ezek mind lassabbak, mint a megfelelo p4-ek. A Xeon MP meg orajelben is.''
Nem a xeon-okról volt szó, hanem a RISC-ek 1 illetve több processzoros példányai között. A XeonMP pedig igeni gyorsabb azonos órajelen, mint a sima P4.
Nyílván a Xeon-oknak a megbízhatóság miatt nem hajhatják olyan magasan, de 3 GHz-es XeonMP már van.
SPECint2K peak:
Xeon - 3,2GHz - 1563
XeonMP - 3,0GHz - 1408
P4 - 3,4GHz - 1393
Ez alapján még az alacsonyabb órajel ellenére sem lassabb, sőt.
''Nem tudom ertelmezni amit irtal, hogy ugyanolyan gyorsak. PPC-t nem tudom, de szerintem mind dual procira van tervezve, A64 meg multiprocira, szal nincs beloluk single-re tervezett, nem?''
Ebből a szempontból tökmindegy.
''Ja, 3 operandusos utasitasok gyorsitjak a kodot. Latszik, hogy sose programoztal assemblyben. Tok fontos, hogy nem irodik felul egy operandus, nem kell ujra betolteni, vagy masik regiszterbe menteni, ez kezzelfoghato gyorsulast jelent.''
Te ezt honnan veszed, hogy én mit csináltam és mit nem? :))
Kis naiv. Már rég egész más hajtódik végre, mint amit te látsz az x86 opcodok alapján. Az áttöltések nem lassítanak semmit, csak plusz tranzisztor kérdése, regiszter átnevezés az egész. Semmit nem gyorsít.
''Hogy a 4 operandusu utasitasokrol mar ne is beszeljek. Pl. nem tudom hallottal-e mar arrol, hogy egy ilyen jellegu muvelet: d=a*b+c az ppc-ben 1 utasitassal vegrehajthato, es ugyanugy 1 orajel mint barmi mas. Probalj egy a*b+b*c+c*a kifejezest kiszamitani 2 es 3-4 operandusu muveletekkel, es latni fogod, hogy melyik a gyorsabb. ''
Barátom te keversz valamit! :)
Itt nem a 4 operandus miatt gyorsabb, hanem azért mert kétműveletet hajt végre a VE. A három operandusú műveletek: a = b + c, ez a klasszikus RISC.
''Szukseg van tobb regiszterre, megint azt tudom mondani, hogy latszik, hogy nem programoztal assemblyben. De tekintsd pl. ugy, hogy a regiszterek a 0. szintu cache, minel tobb van, annal jobb. Kulonben ennel nyilvanvalobb dolgot, hogy az x86 architecturaban keves a regiszter, nem is lehet talalni. Te ezt komolyan cafolni probalod???? Ja, taskvaltasnal trade-off van, ezert van optimalis meret, nem kell ezer regiszter. Eleg mondjuk 32.''
Már megint feltételezgetsz? :)
Az x86 is van elég regiszter nem csak az amit az opcode-ból látsz. Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.
A 32 nem elég, de ennyi van az x86.
Ha jól emlékszem a P4-ben 128 entry-s a regiszter file.
''cache, minel tobb van, annal jobb''
Ez sincs így csak a mesében.
''Ez igaz, ilyenkor a l1 cache-be toltest lassitja.''
Nem mert könnyen párhuzamosítható. Az L1-L2 között késleltetés pedig még így is lassú - 10-30 órajel.
''3. Latod, hogy tudtam. 3 operandusu muvelettel es tobb regiszterrel. Illetve igazabol 'felesleges' utasitasokat sporoltam meg ezekkel. Egyebkent nyilvan nem az IPC fog vissza, az csak meri a proci egy jellemzojet, nem meghatarozza''
Azt hiszem folyamatosan kevered az összetett műveleket a több operandusossággal.
''Nemnem. A peldam jo, egy csomo tranyot kidobtam, amikor csak a magot tartottam meg, par regiszter meg par utasitas siman kitelik belole. Es forditot csak x86-ra meg itaniumra nehez irni, riscre sokkal egyszerubb, ez is egy elonye, csak eddig errol nem volt szo, mert nem a hardverhez kapcsolodik.''
Abban biztos vagyok, hogy még nem írtál compilert. :)
Én sem, de sok olyan embert ismerek aki igen. Szerintük egy RISC esetén a kb. 3-4 év után lesz jó, de kb. 8-10 év után éri azt a szintet, hogy nem nagyon van mit javítani a teljesítményen, s ezt minden egyes generációnál el kell játszani.
''Amugy eddig azt magyaraztad, hogy risckel kozelebe se jutok az x86-nak, mostmar visszakoztal, hogy szignifikans kulonbseget nem tudok osszehozni. Egyreszt ez a nem szignifikans kulonbseg szerintem akar 20-30% is lehet ''
Nem visszakozok.
20-30% kizárt.
max 5%-ra gondoltam :)
''(ki lehet probalni G5-on csak 4-6-8 regiszter hasznalataval mennyivel lassabb kodot lehet irni, es amikor rajossz, hogy hoppa, ki kell irni a memoriaba az adatot, mert nincs tobb regiszter, akkor kiderul, hogy mennyit lassit), masreszt mivel kidobtam a procibol egy nagy reszt, valszeg magasabb orajelet is el lehetne erni, harmadreszt ez 0 uj otletet tartalmazo megoldas, szal ha meg 1-2 evet belefektet az ember a tervezesbe, nyilvan egyeb gyoritasokat is kitalal, es nem csak egy siman lemasolt procit krealna''
A G5 alatt a PPC970-et érted?
Ez ilyen visszafele bizonyítás? :))
Na mindegy, nem akarok semmi bántót írni.Power
-
Power
senior tag
válasz
kisfurko
#297
üzenetére
''Ez igaz, de nem mindegy, hogy 8 regiszterre kell trükközni, vagy minimum 32-re. Meg az sem mindegy, hogy kétoperandusú vagy több. Mert kétoperandusúhoz több regiszter kell. A flagekről meg csak annyit, hogy sokszor tök feleslegesek (mert részszámítás), nyugodtan lehetne szabályozni, hogy mikor kell. Egyébként nem RISC/CISC összehasonlítást kell csinálni (hiszen manapság nincs igazi CISC), én is, mint perla x86 vs. jobb.''
A 3 operandusú nem is működne kevéssel ott lenne csak nagy baj, ott már eleve ezért is több van. Az igaz, hogy a renaming regiszterből ehhez viszonyítva már nem kell annyi.
Ahhoz viszont, hogy a flageket ne állítsa új útasítás halmazok kellenek, ezeket bele lehet pakolni.
Az x86 vs. bármi. Itt egyedül a bármi, ha az risc akkor jobbat vitatom.
''Ezt azért nehezen hiszem, nem véletlen, hogy a K8-ba is duplaannyi regisztert raktak.''
Itt adatfüggőségről beszéltem, nem regiszter függőségről.Power
-
perla
csendes tag
''Egy olyan processzor ami sok proci környezetre terveztek nem lassabb, mint amit ugyanabból egy procis környezetre terveztek, sőt mindegyike gyorsabb.''
Nincs benne, hogy riscrol lenne szo, hanem az, hogy mindegyik. Nezzel mas benchmarkot is, pl. quake. Masreszt meg olyat nezz, ahol hasonlok a cache meretek. Ajanlom a p4ee-t.
Ha programoztal volna assemblyben, tudnad, hogy x86 felulirja az egyik operandust, es ha kesobb szukseged van ra, akkor extra utasitassal kell elmenteni (rosszabb esetben memoriaba). Attoltes lassit, probald ki. Ha nagyon kotni akarod az ebet a karohoz, mutass peldat, amikor nem lassit, szivesen lemerem.
Nem keverek semmit, te nem olvasod el amit irtam. Nem volt szo a miertrol, csak arrol, hogy gyorsit.
''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?
Masreszt a register renaming nem helyettesiti a tobb regisztert. X db regiszterben nem tudsz X+1 adatot tartani, errol szol az egesz. Ki kell irni membe (ami szerinted regiszterbe irasra helyettesitodik??? Vicces). Membe iras (level 1 cachebe is) lassu.
''cache, minel tobb van, annal jobb''
Ez sincs így csak a mesében.
Ez megint hulyeseg. Mutass 2 processzort, amik csak a cache mereteben ternek el egymastol, es amiben a kisebb cache van, az gyorsabb. Nagyon kivancsi vagyok.
''Azt hiszem folyamatosan kevered az összetett műveleket a több operandusossággal.''
Nem, csak te hiszed, hogy ezeket szet kell valasztani. Annyirol volt szo, hogy szetkapja az ember a legfaszabb x86 processzorat, a riscszeru magot megtartja, rak bele tobb regisztert es nehany uj utasitast (3-4 operandusut), es gyorsabb lesz a proci. Igen, van, ahol az osszetett muvelet miatt, van ahol azert, mert nem irja felul az operandust, van ahol azert, mert nem kell kiirni membe. Tok mind1, gyorsabb lesz.
Kerdezd meg az ismeroseidtol, hogy riscre vay x86-ra konnyebb compilert irni. Nyilvan riscre. Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.
''Nem visszakozok.
20-30% kizárt.
max 5%-ra gondoltam ''
Tegyel egy probat. Irjal egy akarmilyen c proggyt, forditsd le, aztan nezd meg a kodot amit kaptal. Latni fogod, hogy tele van olyan reszletekkel, amikor adat kiirodik membe, aztan visszaolvasodik. Ugye mondanom sem kell, hogy membe irni (level 1 cachebe is) jopar orajel. Szal 5% az 100 orajelenkent kevesebb, mint 1 ilyen. Szerintem tobbet fogsz talalni.
''Ez ilyen visszafele bizonyítás?''
Mit nem ertesz? Szivesen elmagyarazom.
''Na mindegy, nem akarok semmi bántót írni.''
Ne is, erveket irjal. Megjegyzem a stilusod eleg lenezo ebben a hozzaszolasban, pedig eleg sok hulyeseget irtal. Erdekes eddig meg ha nem is ertettunk egyet, de nem volt ilyen. -
kisfurko
senior tag
''Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezt lemérted? Érdekelne. Manapság nagyon sok szabályra kell figyelni. P6 óta már nem vagyok biztos abban, hogy jobbat írunk kézzel, tekintve, hogy nem publikus a belső.
Sajnos nincs intel compilerem (csak májkroszoft), szóval nem tudom kipróbálni.
''''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?''
Én el tudom képzelni, főleg, hogy a P4 már lefordított kóddal dolgozik. Simán meg lehet különböztetni fix és változó címeket.
Régen én is hasonlóan gondolkoztam...:))
Igaz Power?
[Szerkesztve] -
Power
senior tag
''Nincs benne, hogy riscrol lenne szo, hanem az, hogy mindegyik. Nezzel mas benchmarkot is, pl. quake.''
Ne gyerekeskedj!
Az IBM vagy a SUN esetleg az Intel szerver részlege szerinted a quake-re tervezi a processzorokat???
''Masreszt meg olyat nezz, ahol hasonlok a cache meretek. Ajanlom a p4ee-t.''
A P4EE egy áttokozott Xeon.
''Ha programoztal volna assemblyben, tudnad, hogy x86 felulirja az egyik operandust, es ha kesobb szukseged van ra, akkor extra utasitassal kell elmenteni (rosszabb esetben memoriaba). Attoltes lassit, probald ki. Ha nagyon kotni akarod az ebet a karohoz, mutass peldat, amikor nem lassit, szivesen lemerem''
Mire?
Te írod állandóan, hogy gyorsít. Én ezt vitattom. Írj te, hogy hol gyorsít ez?
A későbbi szükségletekre ott a renaming, az átöltés párhuzamosan megy.
Felejtsd már el ezt a kézi optimalizálást. Mind az intel, mind az Amd ellenjavalja az assembly-t. Egy 386-os vagy egy P2-es esetén használhatsz, de 2004-ben már csak magadat fogod szívatni.
''Nem keverek semmit, te nem olvasod el amit irtam. Nem volt szo a miertrol, csak arrol, hogy gyorsit.''
''Ja, 3 operandusos utasitasok gyorsitjak a kodot. Latszik, hogy sose programoztal assemblyben. Tok fontos, hogy nem irodik felul egy operandus, nem kell ujra betolteni, vagy masik regiszterbe menteni, ez kezzelfoghato gyorsulast jelent. Hogy a 4 operandusu utasitasokrol mar ne is beszeljek. Pl. nem tudom hallottal-e mar arrol, hogy egy ilyen jellegu muvelet: d=a*b+c az ppc-ben 1 utasitassal vegrehajthato, es ugyanugy 1 orajel mint barmi mas.''
Nyílvánvaló, hogy nem a 3/4 operandus gyorsít.
''Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?''
Fogalmad sincs róla. :)
''Masreszt a register renaming nem helyettesiti a tobb regisztert. X db regiszterben nem tudsz X+1 adatot tartani, errol szol az egesz. Ki kell irni membe (ami szerinted regiszterbe irasra helyettesitodik??? Vicces). Membe iras (level 1 cachebe is) lassu.''
Én nem ezt írtam. Én nem írtam egy szót se a memóriába írásról.
Nem olvasol figyelmesen vagy nem érted?
''Ez megint hulyeseg. Mutass 2 processzort, amik csak a cache mereteben ternek el egymastol, es amiben a kisebb cache van, az gyorsabb. Nagyon kivancsi vagyok.''
1. Több processzoros környezetben a kozisztencia problémák léphetnek fel és egy túlméretezett cache visszafoghatja a rendszert.
2. Gyártási problémák - túlontúl nagy cache -> rosszabb kihozatal, alacsonyabb órajel
''Nem, csak te hiszed, hogy ezeket szet kell valasztani. Annyirol volt szo, hogy szetkapja az ember a legfaszabb x86 processzorat, a riscszeru magot megtartja, rak bele tobb regisztert es nehany uj utasitast (3-4 operandusut), es gyorsabb lesz a proci. Igen, van, ahol az osszetett muvelet miatt, van ahol azert, mert nem irja felul az operandust, van ahol azert, mert nem kell kiirni membe. Tok mind1, gyorsabb lesz.''
Tudod mi az az MMX/SSE/SSE2?
''Tegyel egy probat. Irjal egy akarmilyen c proggyt, forditsd le, aztan nezd meg a kodot amit kaptal. Latni fogod, hogy tele van olyan reszletekkel, amikor adat kiirodik membe, aztan visszaolvasodik. Ugye mondanom sem kell, hogy membe irni (level 1 cachebe is) jopar orajel. Szal 5% az 100 orajelenkent kevesebb, mint 1 ilyen. Szerintem tobbet fogsz talalni.''
Micsoda???
Látod a mikro kódot? Látod a futásközbeni átrendezést?
Felejtsd már el az x86-os opcode-okat, totál más zajlik a háttérben.
''Kerdezd meg az ismeroseidtol, hogy riscre vay x86-ra konnyebb compilert irni. Nyilvan riscre. Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezen már mosolyogni sem tudok.
Te vagy 14 éves vagy vagy menthetetlen.
Szerintem itt zárjuk le.Power
-
perla
csendes tag
''Az áttöltések nem lassítanak semmit''
Te irtad. Megegyszer mondom, probald ki.
''Írj te, hogy hol gyorsít ez?''
Ok. Pl:
attoltes nelkuli kod:
mov eax,1
mov ebx,1
add ebx,eax
attoltessel kod:
mov eax,1
mov ebx,1
mov ecx,ebx
add ebx,eax
Lemerheted, lassit az attoltes. Johet a te peldad.
''A későbbi szükségletekre ott a renaming, az átöltés párhuzamosan megy.''
? A renamingnek szerintem semmi koze a keves regiszter problemahoz. Szerinted mi koze van hozza?
''Felejtsd már el ezt a kézi optimalizálást. Mind az intel, mind az Amd ellenjavalja az assembly-t. Egy 386-os vagy egy P2-es esetén használhatsz, de 2004-ben már csak magadat fogod szívatni.''
Ezt nem tudom, honnan veszed, hogy ellenjavaljak, hivatkozd le. Azt tudom, hogy en szinte minden nap irok assembly kodot, C-ben in-line assembly, foleg sse2 gyorsitas miatt, de sajnos ahhoz kell sima x86 assembly is ugye. SSE2 nelkul nyilvan nem irnek, mezei x86-ban nagyon sok munkaval tudok csak kicsivel gyorsabb kodot irni (ha erre a gondoltal, akkor az igy van), az nem eri meg, de sse2 az tokre megeri.
''Nyílvánvaló, hogy nem a 3/4 operandus gyorsít.''
Latom ezt nem veszi be az agyad. Ujra mondom, probald ki. Pl. a*b+b*c+c*a 2 operandusu muvelettel 7 utasitas, 3 operandusuval 5. Emiatt gyorsit.
''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Na, ha fogalmam sincs rola, akkor fejtsd ki. Hogy tudja vajon a proci a memoria operandusu utasitast regiszteressel helyettesiteni. Ha a forras a memoria operandusu: hulyeseg, ha az adat a memoriaban van, akkor nem lehet regiszterben. Ha az eredmeny: vajon ilyenkor beirja az adatot egy regiszterbe, egy masikba meg egy cimet, hogy hova is kellett volna irni, hiszen kulonben nem tudna, hogy hogy milyen mem hivatkozasnal kell elovenni. Es ezt igy folytatja, mig el nem fogynak a regiszterek. Es utana? Ez is hulyeseg. Cachbe irodik nyilvanvaloan, az pont erre van kitalalva. Na meselj, hogy van ez szerinted?
''Én nem ezt írtam. Én nem írtam egy szót se a memóriába írásról.
Nem olvasol figyelmesen vagy nem érted?''
Probalsz kodositeni. Arrol volt szo, hogy tobb regiszterrel gyorsabb kodot lehet irni, szerinted meg nem. De igen, mert sokszor elofordul, hogy keves regiszterbe sok adat nem fer be, valamit ki kell irni membe. Ezert lehet tobb regiszterrel gyorsabb kodot irni. Lehet, hogy te nem szoltal memoriaba irasrol, csak sajnos mas valasztasa a forditonak sincs, minthogy kiirja az adatot membe.
''1. Több processzoros környezetben a kozisztencia problémák léphetnek fel és egy túlméretezett cache visszafoghatja a rendszert.
2. Gyártási problémák - túlontúl nagy cache -> rosszabb kihozatal, alacsonyabb órajel''
Ja, ezert is raknak egyre tobb cachet a procikra. Ez full kamu. Az egesz hozzaszolasodra ez jellemzo egyebkent. De hivatkozd le. Melyik gyartonal van olyan, hogy azt mondjak, itt egy specko proci direkt kisebb cache-sel, hogy gyorsabb legyen. Nincs ilyen.
''Tudod mi az az MMX/SSE/SSE2?''
Abszolut. Tobb eve sse2-ben programozok. Az intel marketing eventeken szokott a kodjaimra hivatkozni. Mondjuk ez nem tudom, hogy jott a temaba, de mind1.
''Micsoda???
Látod a mikro kódot? Látod a futásközbeni átrendezést?
Felejtsd már el az x86-os opcode-okat, totál más zajlik a háttérben.''
Ezt nem kell ennyire misztifikalni. Egyreszt ha nagyon muszaj, akkor a mikrokodot is elo lehet banyaszni, de nem szoktam. Szepen le lehet merni a sebesseget enelkul is, tokre kimerheto, hogy az adott kodban egy ilyen memoriaba mentes es visszaolvasas mennyit lassit.
''Ezen már mosolyogni sem tudok.
Te vagy 14 éves vagy vagy menthetetlen.
Szerintem itt zárjuk le.''
? Ha jol ertem, nincs erved, inkabb fikazol. Ird be a google keresobe : ''risc vc cisc compiler'', es lasd az eredmenyt. Risc compilert egyszerubb irni. Egyforma az utasitasok hossza. Ugyanarra a feladatra nincs tobb megoldas, mint a ciscnel, nem kell gondolkozni, hogy melyiket valassza a compiler. Egyszerubb a cimzes. stb. -
perla
csendes tag
Persze, mindenki abban hisz amiben akar. De teveszmeid neked vannak. Eleg sokminden osszegyult mar az elozo hozzaszolasomban, amit te mondtal es hulyeseg. Csak sorolom:
1. Attoltesek nem lassitanak semmit
2. Intel&AMD ellenjavalja az assemblyt
3. 3/4 operandusu utasitassal nem lehet gyorsabb kodot irni, mint 2 operandusuval
4. Memoria operandusu muvelet regiszteresre helyettesitodik
5. Tobb regiszterrel se lehet gyorsabb kodot irni, mint kevesebbel
6. Ugyanaz a proci tobb cache-sel lassabb, mint kevesebbel.
7. Risc compilert nehezebb irni, mint cisc/vliw compilert.
Ezek a te teveszmeid. Nem kijavitani nincs idod, max utananezni vagy lusta, hogy hol tevedsz. Nyilvan nem tudtad egyebkent ezeket lehivatkozni, hiszen ezek hamis allitasok, csak nehez beismerni, hogy tevedtel. Sokkal egyszerubb azt mondani, hogy 'nincs idom'. -
Power
senior tag
''Persze, mindenki abban hisz amiben akar. De teveszmeid neked vannak. Eleg sokminden osszegyult mar az elozo hozzaszolasomban, amit te mondtal es hulyeseg. Csak sorolom:''
Inkább hagyjuk a személyeskedést.
''1. Attoltesek nem lassitanak semmit''
A register renaming lassít?
Ez csupán az L/S egységek számától és végrehajtandó utasításoktól függ.
Ha nálad lassít, akkor:
a.) rossz a kódod
b.) rossz processzort használsz
Elméletileg semmit nem lassít.
A hozott példádat meg nem lehet önmagában lemérni, szóval kiváncsi lennék hogy hogyan sikerülhetett.
Ciklusban pörgetve már az átlapolódástól illetve a ciklustól már egész más a környezet, szóval torz képet ad.
A mov és az add ott is mehet egyszerre, tehát ott sem lassít.
''2. Intel&AMD ellenjavalja az assemblyt''
Ez a hivatalos álláspont.
''3. 3/4 operandusu utasitassal nem lehet gyorsabb kodot irni, mint 2 operandusuval''
Te folyamatosan kevered az utasítást és műveleteket.
Te a RISC-re írtad, hogy gyorsabb, mert 3 operandusúak az utasítások, én csupán ezt cáfoltam.
''4. Memoria operandusu muvelet regiszteresre helyettesitodik''
Pontosan. Milyen mikroutasításokat ismersz amelyek memóriacímeken végez pl. aritmetikai műveleteket.
''5. Tobb regiszterrel se lehet gyorsabb kodot irni, mint kevesebbel''
??? Ezt te írod. Én ilyet nem írtam, csak annyit hogy itt sem a minnél több a legjobb.
''6. Ugyanaz a proci tobb cache-sel lassabb, mint kevesebbel.''
Ezt megint te írod. Én csak, azt írtam, hogy a több nem biztos, hogy jobb.
''7. Risc compilert nehezebb irni, mint cisc/vliw compilert.''
??? Ember te folyamatosan ferdítesz!
Én azt írtam, hogy nem könnyű RISC-re sem:
''Szerintük egy RISC esetén a kb. 3-4 év után lesz jó, de kb. 8-10 év után éri azt a szintet, hogy nem nagyon van mit javítani a teljesítményen, s ezt minden egyes generációnál el kell játszani''
Nem tudom ebből honnan veszed, hogy vliw-re, vagy cisc-re milyen?
Egyébként el vagy tévedve, ha az x86-ot cisc-nek tekinted.
''Risc compilert egyszerubb irni. Egyforma az utasitasok hossza. Ugyanarra a feladatra nincs tobb megoldas, mint a ciscnel, nem kell gondolkozni, hogy melyiket valassza a compiler. Egyszerubb a cimzes. stb. ''
Nem tudom honnan jön ide az egyforma utasításhossz vagy a többfajta címzés???
Nem a compiler működőképességében van a munka, az 1-2 hét alatt összehozható. Hanem hogy optimális kódot fordítson, na ahhoz sok-sok év kell.
x86 esetén sincs több megoldás, elégg rég óta 1 féle megoldást fordítanak adott feladatra. Tulajdonképp a RISC is emiatt fejlődött ki, ugyanis az akkori jó CISC fordítók is egyfélét fordítottak.
Egyébként a mai RISC-eknél sincs már egyforma utasításhossz.
Egyszerű címzés? pl. PA-RISC egyszerre támogatja mindkétféle endian-t.
''Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezt elküldöm az inteleseknek, ők is szórakozzanak egy kicst :)
''Ezek a te teveszmeid. Nem kijavitani nincs idod, max utananezni vagy lusta, hogy hol tevedsz.''
Figyelj vegyél kicsit vissza újoncstílusodból!
''Nyilvan nem tudtad egyebkent ezeket lehivatkozni, hiszen ezek hamis allitasok, csak nehez beismerni, hogy tevedtel.''
Mondod ezt az együgyüség magabiztosságával.
''Sokkal egyszerubb azt mondani, hogy 'nincs idom'.''
Valóban nincs sok időm, ugyanis dolgozom, értelmes emberekkel, értelmes célokért és még sok pénzt is kapok érte.
Szerinted vitatkozzam inkább veled, eredménytelenül??? :)
A június végén megyek az USA-ba és találkozom többek közt John Crawforddal(gyerünk nézd csak meg a Google-ba kicsoda az ürge), majd megemlítem neki a gondolataid.Power
-
perla
csendes tag
1. Register renaming es attoltes nem ugyanaz, de ezt mar mondtam. Masreszt az, hogy ket utasitas mehet egyszerre, az nem jelenti azt, hogy pl. a masodik nem lassit, hiszen az elso mehetne egyutt a harmadikkal is, ha nem lenne ott a masodik. Amugy minden utasitas, ami atmegy a pipe-on bir lassitani, ha lehetne helyette ott a kovetkezo.
Ha a peldam nem tetszik, nyugodtan irjal masikat, megnezhetjuk.
2. Ha ez hivatalos allaspont, akkor rakd be az url-t, ahol olvashato.
3. Cafolni nem cafoltad, csak irtad, hogy nem igaz. Ez ugye nem cafolat, hiszen nincs indoklas. En peldat is irtam, ahol latszik, hogy 7 helyett 3 utasitassal meg lehet ugyanazt oldani.
4. Ez megint kodosites. Arrol volt szo, hogy ha keves regisztered van, es kifogysz beloluk, akkor kenytelen vagy memoriaba irni az adatot. Erre irtad te, hogy memoria operandusu muvelet regiszteresre helyettesitodik. Aha, csak lesz mellette egy memoria eleres, szal igy mindenkepp lassabb, mintha regiszterekben meg lehetne oldani.
5. Akkor ebben megegyeztunk?
6. ? Akkor mit ertesz nem jobb alatt? Minthogy sebessegrol van szo, nekem csakis az jut eszembe, hogy nem gyorsabb. De mar mondtam, hivatkozd le. Akkor nem kene itt levegobe beszelni, es az idot tolteni (amibol neked olyan keves van).
7. Akkor ebben is megegyeztunk?
'Figyelj vegyél kicsit vissza újoncstílusodból!'
'Mondod ezt az együgyüség magabiztosságával.'
Es te mondod, hogy hagyjuk a szemelyeskedest. Amugy mit jelent nalad az, hogy ujoncstilus? Ez az, aki nem hiszi el a sok hulyeseget, hanem ellentmond? Ez az egyugyuseg is sima fikazas, erv nelkul, teny, hogy nem hivatkoztad le egyiket sem. Beszolasverseny nem itt van.
'Valóban nincs sok időm, ugyanis dolgozom, értelmes emberekkel, értelmes célokért és még sok pénzt is kapok érte.
Szerinted vitatkozzam inkább veled, eredménytelenül???
A június végén megyek az USA-ba és találkozom többek közt John Crawforddal(gyerünk nézd csak meg a Google-ba kicsoda az ürge), majd megemlítem neki a gondolataid.'
? Nem maradt mas, mint elovenni, hogy kinek az apukaja erosebb?? Kepzeld, en is ertelmes emberekkel, ertelmes celokert dolgozom, es sok penzt kapok erte (es nalam ez azt jelenti, hogy sebessegre optimalizalok intel/amd/mips/ppc procikon, szal a temahoz eleg sok kozom van). Nem kell velem vitatkozni feltetlenul, eleg ha beismered, ha tevedsz ;). Es az ellentmondas nem vita. A vitaban erveket is mond az ember. Amugy Inteles csokaval nem annyira jo mostanaban dicsekedni, minthogy architekturaban elegge bukasra allnak. A marketingesekkel dicsekedhetsz, az jol megy naluk. Szal uzenem a csavonak, hogy jo lenne belehuzni, mert az emberek allnak at az amd platformra, szal nagyotmondasbol eleg, kene dolgozni is.
Aktív témák
ph Az Intel leállította a Prescott utódjának szánt processzor fejlesztését.
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával
- Beszámítás! Intel Core i7 6700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Garanciális Intel Core i5-13600K
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 88.000.-