Processzor architektura

Fórumok

Processzor architektura

Hozzászólások

Erdekes dolgokat mondasz Joel, de nem mindenhol tudtam kovetni az okfejtest, illetve nehany dologban nem adok neked igazat.

Az x86 korszerutlensege alatt en azt ertem, hogy bizonyos elemeiben nem felel meg a mai kor lehetosegeinek es elvarasainak. Nezz meg egy PPC 970-est (esetleg a PPC 980 specifikacioit) es ra fogsz jonni, hogy mire is gondolok! Az IBM varhatoan meg iden kepes lesz 3GHz fole vinni az orajelet, mikozben az Intel nem fog tudni 4GHz fole menni. Nem vagyok Apple-fan (sot), de ez a processzor potensebb, mint barmi, amit az Intel desktop fronton fel tud majd mutatni. Es az Isten mentse meg az Intelt attol, hogy SMT kepessegeket is bepakoljon a Nagykek (ha a pletykaknak hinni lehet, akkor lesz benne).

Az architekturat es az utasitaskeszletet gyakorlatban nemigen lehet szetvalasztani, a ketto borzaszto szoros kapcsolatban van egymassal. Eppen ez okoz problemakat az x86 haza tajan (hiaba az engeneering excellence, ha az utasitaskeszlet a szuk keresztmetszet). Elmeletileg lehet oket kulon targyalni, a papir sok mindent elbir.

A RISC elemeit en nem tartom akademiai vivmanynak. Ez persze szubjektiv kerdes. Az igazi alapokat Seymour Cray dolgozta ki es nemelyiket meg is epitette. Persze az o szamitogepei nem a commodity piacra mentek, es bizonyosan sok eredmenye titkosnak is szamitott.

A datumokat tekintve igazad van. Az elso fecskek a 80-as evek vegen jottek (azelott is voltak RISC-ek, de egyszeruen tul lassuak voltak a CISC-ekhez kepest). A 90-es evek mar a valodi sikerek korszaka volt: Power1 (~1990), Alpha (1992), MIPS R4000. Ezek az un. post-risc processzorok. Itt nalad a pont.

A forditok teren nem adok neked igazat. Szinten a memoria es szamitasi kapacitas hianya miatt az optimalizalasi technikak eleg korlatozottak voltak a 80-as evekben (masreszrol az igazan maceras reszeket meg mindig assemblyben irtak). Az igazan agressziv optimalizaciot megvalosito forditokat a masodik generacios RISC procik tamogatasara irtak.

[quote:2ab46c9f21="Pedro"][quote:2ab46c9f21="Andrei"][quote:2ab46c9f21="Pedro"]
Nekem az a véleményem, hogy kezdi az intel is belátni, hogy rossz irányba ment. Bele esett abba a csapdába, amit szerintem AMD-nél már előre láttak. Bár az is lehet, hogy ök egyszerűen nem képesek olyen tempóban növelni az órajelet, mint az Intel tette. :)
Nekem úgy tűnik, hogy kullog az AMD után. Szép csendben elkezdi megvalósítani azt, amit az AMD már eddig is megtett. Jelenleg talán csak a mobil szegmensben tart előrébb.

Nem hiszem, hogy barki latta volna elore. Az Intel kenyertoresre szerette volna vinni a dolgot a desktop piacon, es ehhez idealis fegyver lett volna a Netburst. Ha az Itanium kepes lett volna megkapaszkodni a desktop-workstation szegmensben, akkor totalis siker lett volna (mire a Netburst kifullad), es mostanaban mar csak a csodbiztosok jarnanak be az AMD-hez.

Pontosan. Az Intelnek elképzelése sem volt, hogy hogyan kellene felvenni a verseny az AMD-vel a nyers erőn kivűl. Így erőből akarta megoldani a dolgot, csak arra nem számított, hogy az AMD-nél kreatív mérnökök dolgoznak. :)
Az Intel eleinte a saját szája ize szerint ment előre. Ha nem lenne AMD, lehet, hogy még mindig nem lenne 64 bit, dual-core és HT, de még csak 2 GHz-es proci se desktop piacon.
Itt látszik, hogy mennyire fontos a verseny!
[quote:2ab46c9f21="Andrei"]
Ket ponton bukott el az elkepzeles:
- Az Itanium nem birt betorni a desktop szegmensben. Ez meg nem lett volna oruletes trauma, hiszen ott a versenyagar Netburst, vegso esetben meg a Dothan is betolhato a desktop versenybe.

Hát igen. Ezzel a procival lőtte tökön magát az Intel szerintem.
Nem az architektúrára gondolok. A problémát ott látom, hogy koránt sem lett akkora nagy durranás, mint várták. Az x86-os kód futtatása meg annyira gyatra lett, hogy nem is érdemes szót ejteni róla. :(
Ez tette be neki főleg a kaput, szerintem. Emlékszem még annak idején mekkora felhajtás volt, mikor elkezdték összehasonlítani a PowerPC-vel szerelt gépeket a Pentium I-el, ha jól emlékszem. A teszt alapja az office egyes progijai voltak, ha jól emlékszem. A PowerPC alázta a Pentiumot. Mint kiderült, mind a kettő gépen a saját magára optimalizált változata futott az officenak. Majd következett a bukta a PowerPC részéről, mikor x86-os változatát kezdte futtatni az office-nak. Lelassult egy 486-os szintjére. Itt dölt el, szeintem, hogy a PowerPC esélytelen az x86-tal szemben. Én nem is csodálkozom, hogy hasonló lett a helyzet az Itaniummal. :(
[quote:2ab46c9f21="Andrei"]
- A problema ott jott, hogy a Prescott tajekan varatlanul fogyott el a szufla a faltoro kosbol. A Northwood egyertelmu siker volt az AMD procikhoz kepest (in terms of performance), csakhat nem birtak folytatni.

Biztos? Szerintem nem. Ez a mag egyértelműen a ne gondolkodj, oldj meg mindent erőből hozzáállást tükrözik! Ebbe már más is belebukott.
Értelmes volt ezt csinálni? Csak akkor értelmes ehhez folyamodni, ha ötletem sincs értelmes dologra és egy pici időhöz akarok jutni és elég erős is vagyok hozzá! Az Intel kapott elég időt? Majd most meglátjuk, hogy mivel is jön elő ténylegesen ls mire lesz ez elég. A gondot én abban látom, hogy az Intel = MS. :( Folyamatosan nyomták ugyan azt a rossz dumát, mint amit az MS csinál! :(
"A GHz-ek számítanak!!!" Na most akkor hogy is vagyunk?? Még sem az számít?
"Nem kell desktopon 64 bit!!!" Akkor most miért is jön ki desktop procikban a 64 bites kiterjesztés??

[quote:2ab46c9f21="Andrei"]
Ennek ellenere nem ertem, hogy miert viseltetnek az emberek olyan merhetetlen ellenszenvvel a Netburst irant. Szemtelenul jol felepitett processzor volt, esszencialisan sokban hasonlitott az Alpha-hoz. No nem architekturalis szempontbol, hanem az agendat tekintve. Vettek egy (viszonylag) egyszeru design-t, mindig a legjobb gyartastechnologiat hasznalva gyartottak es eszmeletlen jo szoftveres tamogatast adtak melle (icc, mkl, ....). Es ha belegondolok, akkor hajmereszto, hogy a mikroarchitektura 1.3GHz-tol (Willamette) ~4GHz-ig (Prescott) skalazodott. Job well done. Nem szegyen, hogy nem birta tovabb.

Pont az a probléma vele, hogy nem igazán hoz be újjat. Mindent erőből akar megoldani. Ez pedig előbb utóbb akadályba fog ütközni.
Van egy olyan sanda gyanum, hogy az Intel már réges régen tudta, hogy 4GHz körül ki fog fulladni, csak el akart mindenkit altatni és figyelte az AMD-t, hogy mit is fog lépni. Mert ugye az AMD nem a GHz-eket hajszolta. Igy az Intel tud szép csendben ötleteket lopni és el tudja terelni arról a figyelmet, hogy teljesen kimerültek ötletek szempontjából, egyáltalán nem kreatívak.
Tényleg, az Intel chipek miért nem SOI technológiával készülnek?

Az a helyzet, hogy az Intel valoban elvetett ket lepest a piacon, annyi szerencsejuk van, hogy ok a meretukbol kifolyolag ezt meg tulelik (legfeljebb 1-2 veszteseges evet keresztfinansziroznak mas agazatokbol).

Volt elkepzelese az Intelnek egy sokkal okosabb procirol (Itanium), de nagyon jol ismertek fel, hogy ezen a piacon gyors ES olcso procik kellenek (itt esett ki a PPC az Alpha).

Az Intel altal elkovetett hiba nem mernoki termeszetu volt, inkabb a strategak mondtak csodot, mert mindent a Netburst-re tettek fel. Hidd el a z Inteles mernokok bizonyara elmagyaraztak a kockazatokat (extrem orajel mellett fellepo problemak), csak valaki teritett betlire jatszott.

Tenyleg jo dolog, hogy az AMD versenyben van, mert igy nem lehet ezeket a bakloveseket sorban elkovetni.

Azt azonban vaskos tevedesnek tartom, hogy az AMD kreativabb, mint az Intel. Igy hirtelen keves jelentos dolgot tudnek mondani, amit az AMD-nek koszonhetnenk.

Cserebe, ha megnezed az Itaniumot, akkor latszik, hogy telis-tele van zsenialis megoldasokkal. Piacilag nem volt sikeres az elso sorozat, de az Itanium2 mar mar komoly eredmenyeket ert el. Es akarhogy nezzuk ez az egyetlen nagygepes architektura, amelyik erdemben szembeallithato a Power5-el (PA-RISC, Alpha, MIPS lenyegeben halott, a SPARC meg lemaradt a versenyben). Az Opteronnak egyenlore meg nincs a felso szegmensben keresnivaloja. Szidni konnyu az Itaniumot, de nagyon kevesen tudjak megmondani, hogy mit kellett volna csinalnia az Intelnek. En talan a buszt dobnam ki alola, de abba is a baromarc HP kenyszeritette bele oket.

Az, hogy egy proci "erobol" akar mindent megoldani meg nem problemas. Desktopon meg kifejezetten udvozito tud lenni. Az okos, de lassu procik altalaban az elvegzett feladatokban meglevo parhuzamossagot tudjak kiaknazni, ugy hogy egy orajel-ciklus alatt tobb munkat probalnak elvegezni, mint egy brute-force CPU. Szep-szep, de mi van, ha nincs parhuzamossag? Es itt az Intel nagy meglatasa, hogy nagyon sok desktop alkalmazasban nincs kiaknazhato parhuzamossag.

Hogy szemleletes legyen a pelda: a jelenlegi technologia ismeretek szerint nincs olyan 500Mhz-es proci, ami kepes lenne felvenni a versenyt egy tapos Northwood-dal, vagy Athlon64-el.

A "nem kell desktopon 64 bit" tokeletesen helyenvalo meglatas. Mihez kellene? Word-excel-skype-opera futtatashoz? Videonezeshez? A valasz tokecceru. A 64 bites processzorok fejlettebb memoriainterfesszel, tobbmagos felepitessel es magasabb orajellel jonnek. Na ezekre van szuksege a desktop alkalmazasoknak. Ezek nem a 64 bites felepitesbol szarmazo eredmenyek. Ha ugyanezt a teljesitmenyt megkapnam 32 bites CPU-bol, akkor en egy fillerrel sem fizetnek tobbet a 64 bites valtozatert. Es meg is lehetne csinalni, csak sok embernek sikerrel toltak be a fejebe a "negy lab jo, ket lab rossz" frazist, ugyhogy arukapcsolassal nemi plusz profitert el lehet passzolni a 64 bites kiterjeszteseket.

Egyebkent meg a Netburst sikertelensege borzaszto tapasztalattal gazdagithatta az Intel-t. Semelyik masik gyartonak meg csak fogalma sincs arrol, hogy milyen problemakkal kell megbirkozni 3GHz felett.

Semelyik masik gyartonak meg csak fogalma sincs arrol, hogy milyen problemakkal kell megbirkozni 3GHz felett.
Mert? Milyenekkel? Ez olyan gagyi duma...

Andrei: ok, elfogadom

Architektura vs Instruction Set: pont a Transmeta (Ditzel) hangoztatta eloszor a post-RISC korszakot, konvergenciat CISC es RISC kozott, es nekem az az erzesem, hogy sokak meg mindig abban a vilagban elnek, ahol a ket "architektura" teljesen kulonbozo megoldasokat igenyelt/alkalmazott (gondolj csak az MKGI kozponti kozbeszerzes kategoriaira, ahol tavaly Xeon-os szervereket arultunk a RISC kategoriaban, mert nem lehetett meggyozni a kedves magukat informatikusnak hivo urakat arrol, hogy nem attol CISC valami, mert Windows-t futtat).

Compilerek: igaz, az attores ideje a 90-es evek eleje, masodik generacios RISC technologiak... regebbi C kodokban lehet latni a register keyword-ot sok helyen, ami manapsag (hala istennek) teljesen kikopott a programozok eszkoztarabol...

[quote:7515560209="SuperPityu2002"]
Én azon gondolkodtam, hogy pl. J2EE alkalmazásszerverként a RISC vagy a CISC procik teljesítenek jobban.

2 CPU-s Opteron dobozok, sok-sok memóriával. Jelen körülmények között ár/teljesítményben nincs ami megverje...

Persze amikor az ember szervert vesz nem csak a CPU teljesítményét nézi, hanem a buszrendszert, a memória gyorsaságát, diszkalrendszert, menedzsment tulajdonságokat (távolról ki/bekapcsolható, újraindítható a gép, van SNMP trap-eket küldözgető szervizproccesszor, stb). Régen ilyenekben a RISC alapú gépek egyértelműen jobbak voltak. Ma, főleg 1-2 CPU-s szerverek esetén....

[quote:66e71efb94="_Joel"]Az aszinkron cpu design megy a Sun labs keretein belul:

http://research.sun.com/projects/dashboard.php?id=6

A legfrissebb szabadalmuk most augusztus eleji: "Method and apparatus for aligning semiconductor chips using an actively driven vernier"

Ezek mar a vizbul veszik ki azokszigent... Kerem kapcsojja ki :)

[quote:9064640f86="_Joel"]
Architektura vs Instruction Set: pont a Transmeta (Ditzel) hangoztatta eloszor a post-RISC korszakot, konvergenciat CISC es RISC kozott, es nekem az az erzesem, hogy sokak meg mindig abban a vilagban elnek, ahol a ket "architektura" teljesen kulonbozo megoldasokat igenyelt/alkalmazott

A konvergencia valamilyen szinten azert mar megvalosult. Peldakent megint a PPC 970-et hoznam fel, ott ugyanis annak ellenere, hogy RISC elvrol van szo vannak olyan utasitasok, amelyek a dekodolasi fazisban ketto vagy tobb elemi utasitasra esnek szet (ez azert erosen CISC megoldasnak tunik). Persze ezt az altalad emlitett idomitott informatikusok valszeg nem tudjak, nem is lenne erdemes ezzel osszezavarni oket.
:D :D :D

Masik jo pelda az EPIC elv, amit az Itanium (IA64) valositott meg. Ott is vannak komplex konstrukciok. Az Itanium nem tul sikeres, de ez nem az elv hibaja.

Hi!

A HT pontosan micsoda? Ha van egy 3.06 GHz-es HT-s procim, akkor az olyan, mintha lenne 2db 3.06GHz-es nem HT-s, vagy 2db 1.53GHz-es, vagy 2db olyan, ami 3.06-os, csak minden pipeline-bol (integer, FPU, MMX, MMX2, stb) feleannyi, mint egyebkent? Vagy valami egesz mas?

By(t)e
TBS::Antiemes

[quote:bcc1f2494e="Andrei"] Nem veletlen, hogy az Apple sikereket er el a G5 (PPC970 post-RISC magra epul) gepeivel. Ezek a sikerek annak (is) koszonhetoek, hogy a proci lenyegesen potensebb. Mas lapra tartozik, hogy az OS maga eleg csumpi :)

pontosan melyik resze?

a mach kernel?
vagy a media api? (amihez foghato a pcken nincsen)
a grafikus felulet?
vagy a freebsd?

most hirtelen nem tudnek rosszat mondani a macosre max hogy kicsit frisebb is lehetne

[quote:9bbeef1e05="drastik"][quote:9bbeef1e05="Andrei"] Nem veletlen, hogy az Apple sikereket er el a G5 (PPC970 post-RISC magra epul) gepeivel. Ezek a sikerek annak (is) koszonhetoek, hogy a proci lenyegesen potensebb. Mas lapra tartozik, hogy az OS maga eleg csumpi :)

pontosan melyik resze?

a mach kernel?
vagy a media api? (amihez foghato a pcken nincsen)
a grafikus felulet?
vagy a freebsd?

most hirtelen nem tudnek rosszat mondani a macosre max hogy kicsit frisebb is lehetne

Hat ezekkel minddel van baj....

Mindegy ez egy kiszolas volt, ha tenyleg erdekel a dolog, akkor menjunk a flame-re ez a kerdes odavalo, ne tegyuk tonkre ezt a topicot!

[quote:2a0e0d9d53="drojid"]Meggugliztam a kérdést (csak könnyedén, nem túrtam bele mélyen)

http://www.bizjournals.com/sacramento/stories/1999/06/28/story2.html

Ezek szerint nem csak egyszer csinálták, hanem bevett gyakorlat náluk, ha jól értem a cikket, ráadásul elég komoly létszámokkal...

Tehát akár jól is emlékezhettem, bár nem biztos, hogy tényleg a PPro-PII fejlesztéséhez alkalmazta az Intel őket...

Ebben a cikkben csak arrol volt szo, hogy a HP es az Intel is vett fel mernokoket, de nem egymastol.

Volt egyebkent precedens ra, hogy az Intel atvett processzortervezoket a HP-tol (korabban a Compaq-tol), de az az Itanium project keretein belul tortent (pl. az Alpha EV-7, es a leallitott Alpha EV-8 "Arana" fejlesztoit is atpasszoltak, jelenleg az uj generacios Itaniumot reszelgetik), de ez strategiai megallapodas volt. A PentiumPRO fejlesztese lenyegesen korabban kezdodott, ugyhogy ezek a csapatok bizonyosan nem terveztek a PPRO-t, mikozben a 21x64-et tervezgettek.

[quote:d8e298a36d="szgabor"]Semelyik masik gyartonak meg csak fogalma sincs arrol, hogy milyen problemakkal kell megbirkozni 3GHz felett.
Mert? Milyenekkel? Ez olyan gagyi duma...

Szivargasi aram, lokalis melegedes, kvantumfizikai szopasok.

Ha az IBM tudna a megoldast, nem lenne meg mindig 2.7GHz-es a leggyorsabb PPC970. A tobbi gyarto meg ennel is gyengebben all.

En eloszor akkor dobbentem meg, amikor tudatosult bennem, hogy 3 Ghz-en egy orajel alatt az informacio kb 10 cm-re jut el a felvezetoben. Sot, annyire sem, mert ott nem is igaz a 3x10 a nyolcadikon meter/s fenysebesseg... Aszinkron CPU-k frontjan mintha csend lenne mostanaban.

Mondjuk ezek az igazi mernoki tudomanyok, nem a szoftver. Az egyik szobatarsam felvezetok tervezesevel foglalkozo szakiranyra ment... nem irigyeltem, amikor az eletktronmikroszkopos abrakon keresgelte a tranzisztorokat, de nekem mar az is sok volt:)

Ja, Rock: amennyire kovetem az esemenyeket, az high end-re van pozicionalva. Persze ki tudja mi es hogyan alakul az iparban addig. De Niagara mar nincs messze, tesztgepekkel tele van szorva jopar ugyfel, hogy a bejelenteskor mar legyenek referenciak, ugyhogy minden jol halad a megjelenes fele. Persze az sem egy tipikus desktop processzor lesz...

Hi,

Kivancsi lennek, hogy
1) szerintetek mi a jo es mi a rossz az x86-os architekturaban?
2) milyennek kellene lennie egy altalanos celu processzornak?
3) milyennek kellene lennie egy cel processzornak?(pl: vga)

uDv,
PEdro

3) milyennek kellene lennie egy cel processzornal?(pl: vga)

hát, sztem legyen fehérjéből :lol:

[quote:9d4ac5b791="belabacsi"]Igazából mire is vagy kíváncsi? Vagy írjuk meg helyetted a szakdogádat?

Hmm. Nem erre gondoltam. Mar csak azert sem, mert meg van a diplomam.
Egyszeruen csak erdekel, hogy itt a hup olvasoi kozott vannak-e olyanok, akik ertenek a temahoz es ill. erdekli oket a tema. Igy lenne lehetoseg egymastol tanulni, megismeri, hogy ki foglalkozik ilyen temaval. Ennyi.
Egyebkent pedig melyebb architekturalis kerdesek erdekelnenek.

[quote:69668e6e00="Pedro"]Hi,

Kivancsi lennek, hogy
1) szerintetek mi a jo es mi a rossz az x86-os architekturaban?
2) milyennek kellene lennie egy altalanos celu processzornak?
3) milyennek kellene lennie egy cel processzornak?(pl: vga)

uDv,
PEdro

1. az x86 architektúrában az a jó, hogy sok van belőle és elég
jól megtanultam már. Az a roszz benne, hogy van jobb.

2. egy általános célú processzor tetszőleges inputból pont olyan
outputot állít elő, amilyet szeretnék, vagy jobbat.

3. egy cél processzor hamarabb végez egy feladattal, mint ahogy
a request kimegy rá.

(-::

[quote:fceb36a68a="meditor"][quote:fceb36a68a="Pedro"]Hi,

Kivancsi lennek, hogy
1) szerintetek mi a jo es mi a rossz az x86-os architekturaban?
2) milyennek kellene lennie egy altalanos celu processzornak?
3) milyennek kellene lennie egy cel processzornak?(pl: vga)

uDv,
PEdro

1. az x86 architektúrában az a jó, hogy sok van belőle és elég
jól megtanultam már. Az a roszz benne, hogy van jobb.

2. egy általános célú processzor tetszőleges inputból pont olyan
outputot állít elő, amilyet szeretnék, vagy jobbat.

3. egy cél processzor hamarabb végez egy feladattal, mint ahogy
a request kimegy rá.

(-::

Bocs, de nem erre gondoltam.
1) Pontosan mi a rossz bene? Nem arra a valaszra lennek kivancsi, hogy az egesz sz*r. Pontosan mi? Ha van jobb, akkor melyik? Miben jobb?
2) Olyan otletekre lennek kivancsi, hogy egy proci architekturanak hogy kellene kineznie. Mit tartalmazzon, meg ilyenek.
3) az elobbi csak cel procira. Az egyszeruseg kedveert legyen grafikus proci
Ilyenekre gondoltam es ha kerhetnem, akkor ne legyen flame! Ok?

Haat ez sem ilyen egyszeru. Eloszor is fontos felismerni, hogy NINCS olyan processzor architektura, ami minden celra korszeru es hatekony.

Ugy tunik, hogy desktop fronton a kovetkezo dolgok tesznek sikeresse egy procit:

- Nagy orajel
- jo IA32 kompatibilitas
- SIMD kiterjesztesek (SSE2 v. AlitVec vagy ilyesmi)
- integralt memoriavezerlo

Szerveren kicsit mas kell.

Az altalad felsorolt technologiak kozvetlenul nincsenek hatassal erre, igy elvileg barmelyik alkalmazhato, de ha jobban megnezzuk, akkor van egy-ketto, ami kiesik.

EPIC: Ez egy kemeny dio. Egy hagyomanyos RISC gyarto sok eves munkaval tudja elerni, hogy versenykepes EPIC procit keszitsen. Nem is igen probalkoznak vele (kiveve Intel, Transmeta), es a piacra dobott megvalositasok nem taroltak nagyot. Ettol fuggetlenul nagyon jo kis technologia ez. Elsosorban szerverekbe valo, vagy nagyon alacsony orajelu "szeles" procikba, mert sok vegrehajtoegyseg kell hozza.

Predikatumok: szerintem lassan becsorognak majd az alacsony szegmensekbe is (asszem egyenlore Itanium, meg a tobbi nagyagyu hasznalja). Szerintem tokegyszeru dolog, a nalam hozzaertobbek viszont azt mondjak, hogy nem trivialis sziliciumba faragni.

Elagazasbecsles: manapsag van minden prociban, must-have egy szuperskalar pipeline prociban, maskulonben nehez lenne kihasznalni a CPU-t.

Pipeline hossz: Ez elsosorban az alkalmazasoktol fugg egy hosszu pipeline jo dolog mert konnyebb novelni az orajelet, viszont a rossz elagazasbecslesek miatti pipeline stall nagyon visszaveti a proci teljesitmenyet. Osszehasonlitaskeppen az IBM Power5 16 lepcsos futoszalaggal dolgozik, a Prescott 31 lepcsossel. Ha nem jonnek kozbe egyeb gyartasi problemak, akkor a Prescott ma 4GHz felett lenne. Ha sok elagazas van a programokban, akkor nem jo nyujtani a pipeline-t.

Hyperthreading: szerver es desktop egyarant kepes profitalni, szerintem egy-ket even belul mindenhol lesz.

A magok szama desktop eseten legfeljebb ketto, szerver eseten akar nyolc is ertelmes lehet.

64 bit ugy nez ki szerveren desktopon manapsag mar egyarant jol jon, a hatranyok annyira mar nem jelentosek.

Fuggosegkezeles? Az mi? :)

Regiszterek: Hat egy otvenes (altalanos celu) kornyeken szerintem mar senki sem panaszkodna. Lehet, hogy tobb is jo lenne. Nemt'om

Cache: ofkorsz kulon i es d L1 cache. Meretre meg mondjuk 16-64kbyte L1. 1mega L2 desktopon. Szerverek eseten 32-96kbyte L1/ 2-4Mbyte L2/6-9Mbyte L3, de itt hatar a csillagos eg (lasd Power5 32megas L3-al).

SIMD: SSE2 v. Altivec izles szerint. Sokak szerint az Altivec jobb, a gyakorlat azt mutatja, hogy az SSE2 sem kevesbe potens csak tobb legacy dolgot hordoz, igy kicsit kacifantosabb design. Teljes processzort vektorizalt mukodesre epiteni mar nem szokas, csak egy ket specialis feladat kivanja meg (es ezt a tendenciat tovabb erositette a GPU-k megjlenese).

MISD, MIMD: Ezek mar inkabb a szamitogepek architekturajaval kapcsolatos dolgok a CPU kevesse szamit. Mondjuk szervereknel nem art, ha egy CPU tamogatja a multiprocesszoros mukodest (SMP aware). Az MISD meg kihalt, nyugodjek is bekeben, nem volt sok teteje.

[quote:533b48063b="antiemes"]Hi!

A HT pontosan micsoda? Ha van egy 3.06 GHz-es HT-s procim, akkor az olyan, mintha lenne 2db 3.06GHz-es nem HT-s, vagy 2db 1.53GHz-es, vagy 2db olyan, ami 3.06-os, csak minden pipeline-bol (integer, FPU, MMX, MMX2, stb) feleannyi, mint egyebkent? Vagy valami egesz mas?

By(t)e
TBS::Antiemes

Nem vagyok teljesen kompetens HT ugyben, de megprobalom korbeirni, aztan legfeljebb majd kijavitnak.

A problema ott kezdodik, hogy egy modern processzorban nagyon sok szufla van meg tartalekban. Arrol van szo, ugyanis, hogy sok vegrehajtoegyseg van, ami a vegrehajtas soran nem tud semmit sem csinalni, mert egy processz vegrehajtasakor nincs eleg parhuzamossag.

Ebbol mar egyenesen kovetkezik a megoldas: legyen ket aktiv vegrehajtasi szal a processzoron belul. Ez azert jo, mert a cel erdekeben csak keves reszt kell a prociban "megketszerezni". Kell hozza nemi OS support, meg nem art, ha a prociba kicsit tobb L2 kerul, de alapjaban veve eleg jo es egyszeru otlet.

Az, hogy a HT mennyi nyereseget hoz, az nehezen mondhato meg precizen. Ha van egy alkalmazasod, ami teljesen kepes a vegrehajtoegysegeket kihasznalni, akkor mar nincs ertelme masik szalat inditani (elofordulhat, hogy kis teljesitmenycsokkenessel is jar cache trashingbol kifolyolag). Ellenkezo eset, amikor az egyik szalon foleg lebegopontos muveletek zajlanak, a masik szalon meg leginkabb integer muveletek. Ilyenkor eleg szep teljesitmenynovekedest lehet tapasztalni, mondjuk azert nem "duplazodik" meg (szerintem 30-50% tobblet mar nagyon jo eredmeny).

Igazából mire is vagy kíváncsi? Vagy írjuk meg helyetted a szakdogádat?

[quote:68bde6547d="oscar"]http://www.digit-life.com/articles/pentium4xeonhyperthreading/

A teljesítménynövekmény mérete erősen függ a feladattól.
Jobb a rendes SMP csak drágább :)

Monnyuk ez evidens, mert az SMP eseteben nem csak a regiszterek, hanem egyeb dolgok is duplazva vannak. Nevezhetjuk a HT-t a szegeny ember SMP-jenek is. Ertsd ennel olcsobban mar valszeg nem lehet megoldani :wink:

Leteznek mar ilyen megoldasok komolyabb procikban is Niagara, PPC980, Power5, csak ott lehet, hogy kicsit szofisztikaltabbak (es dragabbak).

[quote:d696ba91dc="Andrei"]Ebben a cikkben csak arrol volt szo, hogy a HP es az Intel is vett fel mernokoket, de nem egymastol.

:oops: :oops: Upsz, tényleg :) Én az Itaniumos projectről nem tudtam tegnapig, csak megnyitottam egy halom olyan oldalt, ahol arról volt szó, hogy az Intel HP mérnököket vett át, aztán sikerült egy nem olyan cikket belinkelnem :oops: Na mindegy, én úgy tudom, hogy vett át, de talán ez nem olyan izgalmas kérdés a topic fő témájához képest :)

Na skacok ugy tunik, hogy az IDF-en megmondtak az Intelek a tutit, fooldalon kint van a hir.

Mivel 50+ hozzaszolast generalt a hir, gondoltam itt is feldobom hatha tartalmasabban is meg lehet dumalni az esemenyeket.

Az en velemenyem, hogy az Intel most eppen semmi mellbevagoval nem allt elo, sokkal inkabb azt latjuk, hogy megprobalja osszeterelni a szetfutott lovakat es a jelenleg futo processzorcsaladokbol probal osszekalapalni valamit, amit az AMD desktop megoldasai ellen piacra dobhat.

Üdv!
Szerintem az x86 architekturánál jobb pl a PowerPC vagy egy falyta fejlfogásban az Amiga... :-)
Legalábbis abból amit eddig a hardver tanárom magyarázott, ez derül ki... :-)
ha most hülyeséget mondtam az Amigáról akkor sorry... csak engem meggyőzött a 40Mhz-en realtime-ba nyomott video amit kb 2 éve láttam...

[quote:170f14320f="Andrei"]
Mindegy ez egy kiszolas volt, ha tenyleg erdekel a dolog, akkor menjunk a flame-re ez a kerdes odavalo, ne tegyuk tonkre ezt a topicot!

pusztan erdeklodes szintjen kerdeztem.
szeretem a macet ha neha ele kerulok
nah telleg bocs az offert

[quote:1728116d59="Andrei"]A fuggosegnel azt nem ertettem, hogy minek a fuggosegerol beszelunk? Bevallom ez meg most sem vilagos :roll:

Itt adatfüggésre gondoltam.
Pl:(utasítások)
1) olvassed be az x. memóriacímről az adatot
2) ird ki az x. memóriacímre az adatot
Ezt ugy normál esetben elég nehéz lenne párhuzamosítani, mert előfordulhat, hogy az írás történik meg előbb, és ebben az esetben az 1) utasítás hibás adatot fog olvasni.
[quote:1728116d59="Andrei"]
Elagazasbecslest passzolom, mert nem ismerem reszleteiben a kulonbozo megkozeliteseket, az viszont biztos, hogy nagyon fontos a jo elagazasbecsles, mert az elrontott becslesek agyoncsapjak a modern procik teljesitmenyet.

Hát igen, ez eléggé összetett dolog. Kérdés, hogy melyik a legjobb megközelítés. Mondjuk szerintem a dinamikus, történeten alapuló megoldás lehet a jobb megoldás. Ugy értem, hogy figyelembe veszi, hogy az elágazásoknak a múltban mi volt az eredménye.

[quote:1728116d59="Andrei"]
A regiszterek latszhatnak a felhasznalo fele. A forditoprogram majd szepen kihasznalja oket. A SPARC fele register window cuccok nekem nem szimpatikusak...

Persze jó dolog, ha sok regiszter van. Én olyan megközelítésre gondoltam, hogy van rengeted regiszter a procin belül, ami nem látszik. Így könnyebben fel lehetne oldani az álfüggöségeket.

[quote:1728116d59="Andrei"]
Az SISD, SIMD, MISD, MIMD felosztas (bocsuletes neve: Flynn's taxonomy) nem CPU architekturakra vonatkozik, hanem mindenfele parhuzamos rendszerre (akar meg a MacDonald's DriveIn(r)(tm) kiszolgalasra is).

Igen, ez igaz ezekre is, de alapvetően rá lehet húzni a procikra is. Pl. olyan utasítás lehet egy prociban, ami több adaton is ugyan azt a műveletet végzi el.

[quote:a8a1eec063="RasTasi"]Üdv!
Szerintem az x86 architekturánál jobb pl a PowerPC vagy egy falyta fejlfogásban az Amiga... :-)
Legalábbis abból amit eddig a hardver tanárom magyarázott, ez derül ki... :-)

Na, hogy valami konkrét dolog is legyen:

Szerintem a 68000-esek interruptkezelése jobb.

Csináltunk egyszer egy oprendszert 68070-esre. Egy mérőcájgban
volt benne. Nagyon jó volt vele dolgozni. Szerettem a
regiszterkészletét is, a cimzési módjai is változatosabbak és
logikusabbak voltak, mint az akkoriban használt 386/486-os
inteleké.

[quote:1c435499a5="Andrei"]Na skacok ugy tunik, hogy az IDF-en megmondtak az Intelek a tutit, fooldalon kint van a hir.

Mivel 50+ hozzaszolast generalt a hir, gondoltam itt is feldobom hatha tartalmasabban is meg lehet dumalni az esemenyeket.

Az en velemenyem, hogy az Intel most eppen semmi mellbevagoval nem allt elo, sokkal inkabb azt latjuk, hogy megprobalja osszeterelni a szetfutott lovakat es a jelenleg futo processzorcsaladokbol probal osszekalapalni valamit, amit az AMD desktop megoldasai ellen piacra dobhat.

Nekem az a véleményem, hogy kezdi az intel is belátni, hogy rossz irányba ment. Bele esett abba a csapdába, amit szerintem AMD-nél már előre láttak. Bár az is lehet, hogy ök egyszerűen nem képesek olyen tempóban növelni az órajelet, mint az Intel tette. :)
Nekem úgy tűnik, hogy kullog az AMD után. Szép csendben elkezdi megvalósítani azt, amit az AMD már eddig is megtett. Jelenleg talán csak a mobil szegmensben tart előrébb.

Ez a Watt-os dolog pedig erdekes. A Niagaranak pont az az egyik igerete, hogy joval kisebb teljesitmenyfelvetellel fog joval nagyobb teljesitmenyt nyujtani tobbszalu, integer-heavy alkalmazasok ala - persze egy teljesen mas megkozelitessel... Amit eddig lattam belole: mind arat, mind teljesitmenyet tekintve versenykepes lehet a low-end szerverpiacon.

[quote:4758617499="Andrei"]Haat ez sem ilyen egyszeru. Eloszor is fontos felismerni, hogy NINCS olyan processzor architektura, ami minden celra korszeru es hatekony.

Hat igen, ez vilagos. En sem arra gondoltam, hogy egy prociban mindent.
Arra gondoltam, hogy a kulonbozo celra keszitett proci milyen legyen?
(altalanos, vga, stb....)
[quote:4758617499="Andrei"]
Ugy tunik, hogy desktop fronton a kovetkezo dolgok tesznek sikeresse egy procit:

- Nagy orajel
- jo IA32 kompatibilitas
- SIMD kiterjesztesek (SSE2 v. AlitVec vagy ilyesmi)
- integralt memoriavezerlo

Szerveren kicsit mas kell.

Az altalad felsorolt technologiak kozvetlenul nincsenek hatassal erre, igy elvileg barmelyik alkalmazhato, de ha jobban megnezzuk, akkor van egy-ketto, ami kiesik.

EPIC: Ez egy kemeny dio. Egy hagyomanyos RISC gyarto sok eves munkaval tudja elerni, hogy versenykepes EPIC procit keszitsen. Nem is igen probalkoznak vele (kiveve Intel, Transmeta), es a piacra dobott megvalositasok nem taroltak nagyot. Ettol fuggetlenul nagyon jo kis technologia ez. Elsosorban szerverekbe valo, vagy nagyon alacsony orajelu "szeles" procikba, mert sok vegrehajtoegyseg kell hozza.

Predikatumok: szerintem lassan becsorognak majd az alacsony szegmensekbe is (asszem egyenlore Itanium, meg a tobbi nagyagyu hasznalja). Szerintem tokegyszeru dolog, a nalam hozzaertobbek viszont azt mondjak, hogy nem trivialis sziliciumba faragni.

Elagazasbecsles: manapsag van minden prociban, must-have egy szuperskalar pipeline prociban, maskulonben nehez lenne kihasznalni a CPU-t.

Ez ok, hogy kell, de szerinted milyen kell?

[quote:4758617499="Andrei"]
Pipeline hossz: Ez elsosorban az alkalmazasoktol fugg egy hosszu pipeline jo dolog mert konnyebb novelni az orajelet, viszont a rossz elagazasbecslesek miatti pipeline stall nagyon visszaveti a proci teljesitmenyet. Osszehasonlitaskeppen az IBM Power5 16 lepcsos futoszalaggal dolgozik, a Prescott 31 lepcsossel. Ha nem jonnek kozbe egyeb gyartasi problemak, akkor a Prescott ma 4GHz felett lenne. Ha sok elagazas van a programokban, akkor nem jo nyujtani a pipeline-t.

Hyperthreading: szerver es desktop egyarant kepes profitalni, szerintem egy-ket even belul mindenhol lesz.

A magok szama desktop eseten legfeljebb ketto, szerver eseten akar nyolc is ertelmes lehet.

64 bit ugy nez ki szerveren desktopon manapsag mar egyarant jol jon, a hatranyok annyira mar nem jelentosek.

Fuggosegkezeles? Az mi? :)

4 fajta fugges van:
RAR Read After Read ez nem problema
RAW Read After Write ez valodi fugges, ezzel elvileg nem lehet mit kezdeni. :(
WAR Write After Read alfugges
WAW Write After Write alfugges
Ez utobbi kettot hogyan kuszobolned ki?

[quote:4758617499="Andrei"]
Regiszterek: Hat egy otvenes (altalanos celu) kornyeken szerintem mar senki sem panaszkodna. Lehet, hogy tobb is jo lenne. Nemt'om

Szerinted mindnek latszania kellene a felhasznalok fele v. sem?

[quote:4758617499="Andrei"]
Cache: ofkorsz kulon i es d L1 cache. Meretre meg mondjuk 16-64kbyte L1. 1mega L2 desktopon. Szerverek eseten 32-96kbyte L1/ 2-4Mbyte L2/6-9Mbyte L3, de itt hatar a csillagos eg (lasd Power5 32megas L3-al).

SIMD: SSE2 v. Altivec izles szerint. Sokak szerint az Altivec jobb, a gyakorlat azt mutatja, hogy az SSE2 sem kevesbe potens csak tobb legacy dolgot hordoz, igy kicsit kacifantosabb design. Teljes processzort vektorizalt mukodesre epiteni mar nem szokas, csak egy ket specialis feladat kivanja meg (es ezt a tendenciat tovabb erositette a GPU-k megjlenese).

MISD, MIMD: Ezek mar inkabb a szamitogepek architekturajaval kapcsolatos dolgok a CPU kevesse szamit. Mondjuk szervereknel nem art, ha egy CPU tamogatja a multiprocesszoros mukodest (SMP aware). Az MISD meg kihalt, nyugodjek is bekeben, nem volt sok teteje.

hmmm.
MISD : Multiple Instruction Single Data
MIMD: Multiple Instruction Multiple Data
En ezekre gondoltam. Ez szerintem nem szamitogep archi, hanem CPU vagy nem?

[quote:eb6b684708="_Joel"]Ez a Watt-os dolog pedig erdekes. A Niagaranak pont az az egyik igerete, hogy joval kisebb teljesitmenyfelvetellel fog joval nagyobb teljesitmenyt nyujtani tobbszalu, integer-heavy alkalmazasok ala - persze egy teljesen mas megkozelitessel... Amit eddig lattam belole: mind arat, mind teljesitmenyet tekintve versenykepes lehet a low-end szerverpiacon.

Ez igaz lesz a Rock eseten is?

[quote:4678ef343d="RasTasi"]Üdv!
Szerintem az x86 architekturánál jobb pl a PowerPC vagy egy falyta fejlfogásban az Amiga... :-)
Legalábbis abból amit eddig a hardver tanárom magyarázott, ez derül ki... :-)
ha most hülyeséget mondtam az Amigáról akkor sorry... csak engem meggyőzött a 40Mhz-en realtime-ba nyomott video amit kb 2 éve láttam...

Nekem volt Amigám és csakk a kis meghajtó halála meg pár nyűg miat cseréltem le.
A 14 MHz kb anyit ért bene mint a p1ben 266 MHz felhasználói tapasztalat.

[quote:ac494aa0f6="Pedro"][quote:ac494aa0f6="Andrei"]Na skacok ugy tunik, hogy az IDF-en megmondtak az Intelek a tutit, fooldalon kint van a hir.

Mivel 50+ hozzaszolast generalt a hir, gondoltam itt is feldobom hatha tartalmasabban is meg lehet dumalni az esemenyeket.

Az en velemenyem, hogy az Intel most eppen semmi mellbevagoval nem allt elo, sokkal inkabb azt latjuk, hogy megprobalja osszeterelni a szetfutott lovakat es a jelenleg futo processzorcsaladokbol probal osszekalapalni valamit, amit az AMD desktop megoldasai ellen piacra dobhat.

Nekem az a véleményem, hogy kezdi az intel is belátni, hogy rossz irányba ment. Bele esett abba a csapdába, amit szerintem AMD-nél már előre láttak. Bár az is lehet, hogy ök egyszerűen nem képesek olyen tempóban növelni az órajelet, mint az Intel tette. :)
Nekem úgy tűnik, hogy kullog az AMD után. Szép csendben elkezdi megvalósítani azt, amit az AMD már eddig is megtett. Jelenleg talán csak a mobil szegmensben tart előrébb.

Nem hiszem, hogy barki latta volna elore. Az Intel kenyertoresre szerette volna vinni a dolgot a desktop piacon, es ehhez idealis fegyver lett volna a Netburst. Ha az Itanium kepes lett volna megkapaszkodni a desktop-workstation szegmensben, akkor totalis siker lett volna (mire a Netburst kifullad), es mostanaban mar csak a csodbiztosok jarnanak be az AMD-hez.

Ket ponton bukott el az elkepzeles:
- Az Itanium nem birt betorni a desktop szegmensben. Ez meg nem lett volna oruletes trauma, hiszen ott a versenyagar Netburst, vegso esetben meg a Dothan is betolhato a desktop versenybe.
- A problema ott jott, hogy a Prescott tajekan varatlanul fogyott el a szufla a faltoro kosbol. A Northwood egyertelmu siker volt az AMD procikhoz kepest (in terms of performance), csakhat nem birtak folytatni.

Ennek ellenere nem ertem, hogy miert viseltetnek az emberek olyan merhetetlen ellenszenvvel a Netburst irant. Szemtelenul jol felepitett processzor volt, esszencialisan sokban hasonlitott az Alpha-hoz. No nem architekturalis szempontbol, hanem az agendat tekintve. Vettek egy (viszonylag) egyszeru design-t, mindig a legjobb gyartastechnologiat hasznalva gyartottak es eszmeletlen jo szoftveres tamogatast adtak melle (icc, mkl, ....). Es ha belegondolok, akkor hajmereszto, hogy a mikroarchitektura 1.3GHz-tol (Willamette) ~4GHz-ig (Prescott) skalazodott. Job well done. Nem szegyen, hogy nem birta tovabb.

Asszem errol a harom kerdesrol vastag konyveket megtoltottek mar.

Az x86-os architekturaban semmi sem "jo". Cirka 25 eve hasznaljuk, eleg korszerutlenne valt mostanra.

Eloszor is az x86 architektura igazi boveru CISC megvalositas. Amikor fejlesztettek, akkor ez volt a hatekonyabb:

-mert a memoria draga volt, es a CISC procik kevesebb utasitassal voltak kepesek adott feladat vegrehajtasara.

-mert a forditoprogramok pedig nem tudtak jol optimalizalni, ezert az assembly programozasnak sokkal nagyobb jelentosege volt, mint manapsag. A RISC assembly eleg maceras dolog.

-keves regiszteruk volt, ami nyilvanvaloan olcsobb volt, es a memoria sem volt tul lassu a procihoz kepest, ezert nem jelentett komoly problemat a memoria es a regiszter az adatok mozgatasa.

Aztan a 90-es evekre ezek a problemak megszuntek, es mas kihivasok jelentek meg:

- a forditoprogramok potencialisan hatalmasat fejlodtek, viszont nyilvanvalova valt, hogy csak RISC architekturakon kepesek a legjobb optimalizaciora.

- a memoria hirtelen olcso lett, viszont a sebessege nem volt kepes tartani a proci tempojat. Ez az x86 szempontjabol azert volt rossz, mert tele volt olyan utasitasokkal, amiknek az egyik operandusa valamilyen memoria tartalom volt. Legtobb RISC architekturaban osszesen KETTO utasitas van, ami memoriatartalommal operal LOAD illetve STORE.

- a piaci verseny azt diktalta, hogy a procik orajelet az egekbe emeljek, igy gyorsitva a vegrehajtast. Ez tovabbi gondokat okozott, mert a memoria meg lasabb lett a procihoz viszonyitva. Az x86 regiszterek sajnos kevesnek bizonyultak, ahhoz, hogy jol lehessen optimalizalni a kodot.

- a nagy orajel eleresehez olyan processzorok kelletek, amik egyszeru reszegysegekbol alltak, mert igy lehetett az orajelet a legjobban novelni. Az x86 valtozo utasitashosszal, algoritmikusan nehezen dekodolhato operandusokkal szinten nem volt egy telitalalat.

Ezert volt az, hogy az elso DEC Alpha proci 200MHz korul debutalt (marha egszeru, viszonylag tiszta RISC implementacio), amikor a Pentium 66MHz kornyeken jart, es ezt a kulonbseget tudta is tartani, amig a Digitalt fel nem vasaroltak (innentol az Alpha mar inkabb csak vergodott, az uj tulajdonosok sosem alltak mogotte igazan).

Az utobbi evekben meg volt egy nagy dobasa az x86-nak, amikor az Intel a NetBurst (Pentium4) design segitsegevel probalta meg az orajelet feljebb nyomni. Eleg szep sikereik voltak, de ugy tunik, hogy a 4GHz kornyeken vegleg elfogyott a nafta, es zsakutcaba jutottak. Vissza kellett lepniuk a Pentium III mag tovabbfejlesztesehez, ez az amit Banias es Dothan kodneven emlegetnek (egyenlore laptopokban divatosak, de ha minden igaz az asztali procik is hasonlo designra epulnek).

A piac azonban azt diktalja, hogy a regi programok lehetoleg fussanak az uj gepeken, ezert most megtortent egy kis rancfelvarras a 64 bites kiterjesztesek bevezetesevel. Ez meg nehany evig jo lesz, de erzesem szerint nem vegleges megoldas. Nem veletlen, hogy az Apple sikereket er el a G5 (PPC970 post-RISC magra epul) gepeivel. Ezek a sikerek annak (is) koszonhetoek, hogy a proci lenyegesen potensebb. Mas lapra tartozik, hogy az OS maga eleg csumpi :)

[quote:3330ec7400="Andrei"]A RISC assembly eleg maceras dolog.

De élvezetes :)

[quote:3330ec7400="Andrei"] -keves regiszteruk volt

Egy kiegészítés, hogy szemléletesebb legyen: egy Pentiumnak (mostanában nem programoztam assemblyben x86-ot, lehet, h mostanában néhánnyal több van) kb tizenvalamennyi olyan regisztere volt, amit a programozó elérhetett. Ehhez képest egy kis csopfadt RISC magos Microchip mikrokontrollernek (ezek azok az eszközök, amikben a cpu köré egy halom perifériát is betokoztak, io, timerek, stb) több, mint ezerötszáz piszok gyors regisztere van.

[quote:3330ec7400="Andrei"]- a nagy orajel eleresehez olyan processzorok kelletek, amik egyszeru reszegysegekbol alltak, mert igy lehetett az orajelet a legjobban novelni. Az x86 valtozo utasitashosszal, algoritmikusan nehezen dekodolhato operandusokkal szinten nem volt egy telitalalat.

Az Intel a P2 előtt vett magához egy halom HP fejlesztőt. Amennyire én tudom, a P2-kben (vagy legalábbis egy részükben) a HP RISC-jén alapuló mag köré építettek egy hardveres CISC interpretert, tehát "értette" az x86 utasításokat, mégis, RISC mag hajtotta végre azokat. Ha jól tudom, azóta van az Intel CPU-kban feltölthető mikrokód.

[quote:3330ec7400="Andrei"]A piac azonban azt diktalja, hogy a regi programok lehetoleg fussanak az uj gepeken, ezert most megtortent egy kis rancfelvarras a 64 bites kiterjesztesek bevezetesevel.

Gyanítom, hogy működőképes megoldás lehetne, ha kidobnák a régi szutykokat, készítenének egy új architektúrát, cseppet sem foglalkozva azzal, hogy nem lesz a mostanival kompatibilis, és az átmeneti időszakban valami szoftveres emulációval futtatni azokat a programokat, amikhez ragaszkodnak a juzerek... Vagy nem... :) De ha a macek a virtualpcvel használható sebességgel futtatnak x86 programokat, akkor talán megoldható lenne ez is.

[quote:ff612d037d="drojid"]...
Gyanítom, hogy működőképes megoldás lehetne, ha kidobnák a régi szutykokat, készítenének egy új architektúrát, cseppet sem foglalkozva azzal, hogy nem lesz a mostanival kompatibilis, és az átmeneti időszakban valami szoftveres emulációval futtatni azokat a programokat, amikhez ragaszkodnak a juzerek... Vagy nem... :) De ha a macek a virtualpcvel használható sebességgel futtatnak x86 programokat, akkor talán megoldható lenne ez is.

Ezt próbálta meg az Intel előadni az Itaniummal, nézd meg, hogy hol van most! :D Az Opteron terjed, mint a futótűz, az Itanium mögül meg szépen lassan lépnek ki az eddigi támogatók: HP, MS, hogy példákat mondjak. Persze nem teljesen, hiszen "a high-end szervertermékekben továbbra is támogatni fogjuk", éppen csak munkaállomásokat és low-end/midrange szervereket nem akarnak rá építeni, ill. oprendszert kihozni.

Az Intelnél valószínűleg úgy gondolták, hogy előadhatják ugyanazt, ami a DEC-nek a VAX->Alpha váltásnál sikerült: kidobni a régi architektúrát és csinálni egy gyökeresen újat. Eddig úgy tűnik, hogy nem jött össze, de a mélyebben fekvő okait nem tudom, nem vagyok übermájer elemző. :)

Azer' nem allnak olyan jol regiszterek teren a RISC procik sem. Mondjuk az Itaniumnak (ami nem is igazi RISC, hanem EPIC CPU) lehet 200 regisztere (de ebben mar a lebegopottyos regek is benne vannak). A drojid altal emlegetett Microchip kontroller nem altalanos celu processzor, igy nem igazan erdemes osszevetni azokkal. A Pentiumban is az orajelen mukodtek a regiszterek, igy a Microchip nem lehetett gyorsabb ezen a teren.

Ugy tunik, hogy manapsag a kompatibilitas a siker kulcsa, es egyenlore nem elegseges az emulacio (virtualpc, vmware, stb.). Ugyhogy az x86 elkotyavetyelese nem lenne hasznos lepes az Intel reszerol. Probaltak ok ezt (lasd korabbi hozzaszolas az Itaniumrol), de csunyan belebuktak. Az eredeti tervek szerint mostanaban mar a desktop piacon az Itanium architektura mindenfele valtozatainak kellene randalirozniuk. Ezzel szemben ugy tunik, hogy jo, ha a high-end szegmensben meg tud kapaszkodni.

A RISC mag kore epitett x86 interpretert eloszor a Pentium PRO sorozatban lathattuk, nem a P2-ben. A P2 mar egy olyan Pentium PRO volt, ami gyorsabb 16 bites vegrehajtast (merugye az MS nem kapkodta el a 32 bitre valtast sem) es lassabb L2 cache-t kapott. Arrol hol olvastatok, hogy a HP mernokei asszisztaltak a fejlesztesben? Szerintem ez urban legend.

A megoldas egyebkent a maga modjan brillians volt a Pentium PRO-ban. A dekodolt utasitasokat felbontotta uops-okra (mikroutasitasokra), elhelyezte oket egy atmeneti taroloban (Reservation Station). Az RS-ben eleg sok kunsztot el lehetett vegezni (out-of-order execution, branch prediction, superscalar execution, speculative execution), tenyleg minden ment, amit akkoriban egy tapos RISC proci tudott, es mindezt a RISC-ek aranak toredekeert. Gyanitom a vegen mar az dekodolas-RS fazis volt az a resz, amit nem lehetett egyszerunek es gyorsnak megtartani, es ez korlatozta veglegesen a Pentium 4 teljesitmenyet. Innentol kezdve az Intel kinsoan odafigyelt, hogy gyartastechnologiaban a tobbiek elott jarjon es ez mar lehetove tette, hogy viszonylag potens CPU-kat fyartson, amik nagyon nagy orajelen is uzemeltek.

Előrebocsájtom: smmilyen fajta arch-t nem áll szándékomban bántani.

De a PIC az nagyon nagy cucc!!!

[quote:8484e91c1a="_Joel"]En eloszor akkor dobbentem meg, amikor tudatosult bennem, hogy 3 Ghz-en egy orajel alatt az informacio kb 10 cm-re jut el a felvezetoben. Sot, annyire sem, mert ott nem is igaz a 3x10 a nyolcadikon meter/s fenysebesseg... Aszinkron CPU-k frontjan mintha csend lenne mostanaban.

Mondjuk ezek az igazi mernoki tudomanyok, nem a szoftver. Az egyik szobatarsam felvezetok tervezesevel foglalkozo szakiranyra ment... nem irigyeltem, amikor az eletktronmikroszkopos abrakon keresgelte a tranzisztorokat, de nekem mar az is sok volt:)

Ja, Rock: amennyire kovetem az esemenyeket, az high end-re van pozicionalva. Persze ki tudja mi es hogyan alakul az iparban addig. De Niagara mar nincs messze, tesztgepekkel tele van szorva jopar ugyfel, hogy a bejelenteskor mar legyenek referenciak, ugyhogy minden jol halad a megjelenes fele. Persze az sem egy tipikus desktop processzor lesz...

Pedig eppen a a Sun-nak voltak aszinkron proci tervei. Meg valami "clockless computing" otletrol is hallottam feloluk, de reszletek nem voltak.

Az a baj a Niagara-Rock parossal, hogy a ketto csak egyutt tudja majd lefedni a szerverpiacot. Tehat webszerver, db szerver -> Niagara, HPTC->Rock.... Engem inkabb a Rock erdekel majd, de ketsegtelenul a Niagara is taposnak tunik.

[quote:6e4cbd891b="Andrei"]A drojid altal emlegetett Microchip kontroller nem altalanos celu processzor, igy nem igazan erdemes osszevetni azokkal.

Persze, csak szemléltető példaként jutott az eszembe, a kedvenc kisvacak Texas MCU-m most olyan 150MHz körül ketyeg, tehát emaitt sem lehet összevetni őket...

A HP fejlesztők alkalmazását nem tudom, hol olvastam, persze, lehet urban legend is, csak nekem úgy rémlik, elég nagy hír volt akkoriban. (1997?)

Meggugliztam a kérdést (csak könnyedén, nem túrtam bele mélyen)

http://www.bizjournals.com/sacramento/stories/1999/06/28/story2.html

Ezek szerint nem csak egyszer csinálták, hanem bevett gyakorlat náluk, ha jól értem a cikket, ráadásul elég komoly létszámokkal...

Tehát akár jól is emlékezhettem, bár nem biztos, hogy tényleg a PPro-PII fejlesztéséhez alkalmazta az Intel őket...

[quote:15223d86da="Andrei"][quote:15223d86da="Pedro"]
Nekem az a véleményem, hogy kezdi az intel is belátni, hogy rossz irányba ment. Bele esett abba a csapdába, amit szerintem AMD-nél már előre láttak. Bár az is lehet, hogy ök egyszerűen nem képesek olyen tempóban növelni az órajelet, mint az Intel tette. :)
Nekem úgy tűnik, hogy kullog az AMD után. Szép csendben elkezdi megvalósítani azt, amit az AMD már eddig is megtett. Jelenleg talán csak a mobil szegmensben tart előrébb.

Nem hiszem, hogy barki latta volna elore. Az Intel kenyertoresre szerette volna vinni a dolgot a desktop piacon, es ehhez idealis fegyver lett volna a Netburst. Ha az Itanium kepes lett volna megkapaszkodni a desktop-workstation szegmensben, akkor totalis siker lett volna (mire a Netburst kifullad), es mostanaban mar csak a csodbiztosok jarnanak be az AMD-hez.

Pontosan. Az Intelnek elképzelése sem volt, hogy hogyan kellene felvenni a verseny az AMD-vel a nyers erőn kivűl. Így erőből akarta megoldani a dolgot, csak arra nem számított, hogy az AMD-nél kreatív mérnökök dolgoznak. :)
Az Intel eleinte a saját szája ize szerint ment előre. Ha nem lenne AMD, lehet, hogy még mindig nem lenne 64 bit, dual-core és HT, de még csak 2 GHz-es proci se desktop piacon.
Itt látszik, hogy mennyire fontos a verseny!
[quote:15223d86da="Andrei"]
Ket ponton bukott el az elkepzeles:
- Az Itanium nem birt betorni a desktop szegmensben. Ez meg nem lett volna oruletes trauma, hiszen ott a versenyagar Netburst, vegso esetben meg a Dothan is betolhato a desktop versenybe.

Hát igen. Ezzel a procival lőtte tökön magát az Intel szerintem.
Nem az architektúrára gondolok. A problémát ott látom, hogy koránt sem lett akkora nagy durranás, mint várták. Az x86-os kód futtatása meg annyira gyatra lett, hogy nem is érdemes szót ejteni róla. :(
Ez tette be neki főleg a kaput, szerintem. Emlékszem még annak idején mekkora felhajtás volt, mikor elkezdték összehasonlítani a PowerPC-vel szerelt gépeket a Pentium I-el, ha jól emlékszem. A teszt alapja az office egyes progijai voltak, ha jól emlékszem. A PowerPC alázta a Pentiumot. Mint kiderült, mind a kettő gépen a saját magára optimalizált változata futott az officenak. Majd következett a bukta a PowerPC részéről, mikor x86-os változatát kezdte futtatni az office-nak. Lelassult egy 486-os szintjére. Itt dölt el, szeintem, hogy a PowerPC esélytelen az x86-tal szemben. Én nem is csodálkozom, hogy hasonló lett a helyzet az Itaniummal. :(
[quote:15223d86da="Andrei"]
- A problema ott jott, hogy a Prescott tajekan varatlanul fogyott el a szufla a faltoro kosbol. A Northwood egyertelmu siker volt az AMD procikhoz kepest (in terms of performance), csakhat nem birtak folytatni.

Biztos? Szerintem nem. Ez a mag egyértelműen a ne gondolkodj, oldj meg mindent erőből hozzáállást tükrözik! Ebbe már más is belebukott.
Értelmes volt ezt csinálni? Csak akkor értelmes ehhez folyamodni, ha ötletem sincs értelmes dologra és egy pici időhöz akarok jutni és elég erős is vagyok hozzá! Az Intel kapott elég időt? Majd most meglátjuk, hogy mivel is jön elő ténylegesen ls mire lesz ez elég. A gondot én abban látom, hogy az Intel = MS. :( Folyamatosan nyomták ugyan azt a rossz dumát, mint amit az MS csinál! :(
"A GHz-ek számítanak!!!" Na most akkor hogy is vagyunk?? Még sem az számít?
"Nem kell desktopon 64 bit!!!" Akkor most miért is jön ki desktop procikban a 64 bites kiterjesztés??

[quote:15223d86da="Andrei"]
Ennek ellenere nem ertem, hogy miert viseltetnek az emberek olyan merhetetlen ellenszenvvel a Netburst irant. Szemtelenul jol felepitett processzor volt, esszencialisan sokban hasonlitott az Alpha-hoz. No nem architekturalis szempontbol, hanem az agendat tekintve. Vettek egy (viszonylag) egyszeru design-t, mindig a legjobb gyartastechnologiat hasznalva gyartottak es eszmeletlen jo szoftveres tamogatast adtak melle (icc, mkl, ....). Es ha belegondolok, akkor hajmereszto, hogy a mikroarchitektura 1.3GHz-tol (Willamette) ~4GHz-ig (Prescott) skalazodott. Job well done. Nem szegyen, hogy nem birta tovabb.

Pont az a probléma vele, hogy nem igazán hoz be újjat. Mindent erőből akar megoldani. Ez pedig előbb utóbb akadályba fog ütközni.
Van egy olyan sanda gyanum, hogy az Intel már réges régen tudta, hogy 4GHz körül ki fog fulladni, csak el akart mindenkit altatni és figyelte az AMD-t, hogy mit is fog lépni. Mert ugye az AMD nem a GHz-eket hajszolta. Igy az Intel tud szép csendben ötleteket lopni és el tudja terelni arról a figyelmet, hogy teljesen kimerültek ötletek szempontjából, egyáltalán nem kreatívak.
Tényleg, az Intel chipek miért nem SOI technológiával készülnek?

Az aszinkron cpu design megy a Sun labs keretein belul:

http://research.sun.com/projects/dashboard.php?id=6

A legfrissebb szabadalmuk most augusztus eleji: "Method and apparatus for aligning semiconductor chips using an actively driven vernier"

[quote:7c0e36548e="Andrei"]
Az x86-os architekturaban semmi sem "jo". Cirka 25 eve hasznaljuk, eleg korszerutlenne valt mostanra.

Definiald, hogy korszerutlen. Szerintem a sikeres CPU tervezesi otletek szinte kivetel nelkul megjelentek az x86 processzorok ujabb es ujabb peldanyaiban. Az utasitaskeszlet egy nagy rakas tragya, de ezt ne mossuk ossze az architekturaval.

[quote:7c0e36548e="Andrei"]Eloszor is az x86 architektura igazi boveru CISC megvalositas. Amikor fejlesztettek, akkor ez volt a hatekonyabb:

Az x86 utasításkészlete valóban CISC. Pentium Pro óta viszont a megvalósítás inkább RISC, a CISC utasítások pedig nagyrészt mikrokódoltak. A hatékonyságot nem értem miért hozod fel: a CISC kialakulása evolúció volt, a RISC megjelenése pedig revolúció: egy új ötlet először akadémiai, majd ipari kipróbálása.

[quote:7c0e36548e="Andrei"] -mert a memoria draga volt, es a CISC procik kevesebb utasitassal voltak kepesek adott feladat vegrehajtasara.

Ez igaz. Ez egyik oka lehetett a CISC kialakulásának. De nem volt olyan, hogy valaki az egyik, vagy a másik irányba fejleszthetett volna, és inkább a CISC-et választotta. A RISC új utasításkészletet jelent, vagyis teljes inkompatibilitást a korábbi programokkal. Ezt a 60-as, 70-es években még gond nélkül meg lehetett lépni. A 80-as években is csináltál még páran. A 90-es években szinte lehetetlen vállalkozás volt (legalábbis így utólag az Itanic-ot látva)

[quote:7c0e36548e="Andrei"] -mert a forditoprogramok pedig nem tudtak jol optimalizalni, ezert az assembly programozasnak sokkal nagyobb jelentosege volt, mint manapsag. A RISC assembly eleg maceras dolog.

RISC-en sokkal fontosabb szerepe van a memory alignment-nek, mivel a Reduced Instruction Set nem csak kevesebb utasítást, de kevesebb féle címzési módot is takar. A RISC architektúrának valóban jobban teljesítő fordítókra van szüksége, de azért a 60-as évek közepére a fordítási technológiák nagyrészt teljesen kialakultak, és az optimalizálási ötleteknek is elég szép tárházát felmutatták a 80-as években.

-keves regiszteruk volt, ami nyilvanvaloan olcsobb volt, es a memoria sem volt tul lassu a procihoz kepest, ezert nem jelentett komoly problemat a memoria es a regiszter az adatok mozgatasa.

Ezt nem kell magyarázni. Kevés regiszterük volt. Pont. A RISC-nél követelmény a sok regiszter pont amiatt amit irtal: a vallásosan RISC processzorok a memóriát csak két utasítással használhatták: load és store. Minden más műveletet regiszteren kellett végezniük.

Aztan a 90-es evekre ezek a problemak megszuntek, es mas kihivasok jelentek meg:

Mar a 80-as evek kozepen nem voltak problemak a RISC architektura elott. Egyszeruen csak eltelt egy kis ido, mire a Stanford es UCLA egyetemen a 70-es evek vegen valakinek kipattant az otlet a fejebol, es megepitette. Ahhoz kepest nem is rossz, hogy milyen gyorsan megjelent a kereskedelemben a technologia (1985: MIPS R2000, 1987: Sparc)...

Kozben atgondoltam, es az a bajom a hozzaszolasoddal, hogy osszemostad az utasitaskeszlet es az architektura fogalmat...:)

[quote:a7c1a1e9e3="_Joel"]az a bajom a hozzaszolasoddal, hogy osszemostad az utasitaskeszlet es az architektura fogalmat...:)

De hát az egész a csökkentett vagy komplex utasításkészletről szól, hogyan lehetne külön tárgyalni? Azért ilyen az utasításkészlete, mert olyan az architektúrája (vagy fordítva :) ) Vagy mit értesz architektúrán?

Lehet, hogy én is összemosom? 8O

Sziasztok!

Nagyon tetszik ez a téma.
Én azon gondolkodtam, hogy pl. J2EE alkalmazásszerverként a RISC vagy a CISC procik teljesítenek jobban. Összehasonlító oldalakat nem találtam, de lehet, hogy nincs is sok értelme. Pl. a fajlagos teljesítményre sincs igazán bevett mérték, így nehéz összehasonlítani pl. egy G4-et egy Athlon XP-vel.
Ha esetleg valaki látott érdekes irományt, ami összehasonlítja, hogy melyik architektúra miben teljesít jobban, írja meg a doksi címét!
Gugliban nem sokat találni.

Üdv, I.

Publikus benchmarkok:

http://www.spec.org/benchmarks.html#java

Koszonom mindenkinek az eddigi konstruktiv hozzaszolast. Most arra szeretnelek megkerni benneteket, hogy menjunk "beljebb".
Egy mai, korszeru processzornak mit kellene tartalmaznia?
Legyen olyan mint az EPIC?
Legyen predikatum alapu?
Vagy valami masmilyen elagazasbecsles?
Pipeline? hany lepcsosnek lenne ertelme?
Hany magos legyen?
Hyperthreading ertelmes?
Hany bites legyen?
Fuggosegkezeles?
Cache meret? Kulon utasitas es adat cache?
vedelmi mechanizmusok?
szegmentalas, lapozas? esetleg ezek egyutt?
regiszterszam?
SIMD? MISD? MIMD?

Mi a velemenyetek?

Pedro

A fuggosegnel azt nem ertettem, hogy minek a fuggosegerol beszelunk? Bevallom ez meg most sem vilagos :roll:

Elagazasbecslest passzolom, mert nem ismerem reszleteiben a kulonbozo megkozeliteseket, az viszont biztos, hogy nagyon fontos a jo elagazasbecsles, mert az elrontott becslesek agyoncsapjak a modern procik teljesitmenyet.

A regiszterek latszhatnak a felhasznalo fele. A forditoprogram majd szepen kihasznalja oket. A SPARC fele register window cuccok nekem nem szimpatikusak...

Az SISD, SIMD, MISD, MIMD felosztas (bocsuletes neve: Flynn's taxonomy) nem CPU architekturakra vonatkozik, hanem mindenfele parhuzamos rendszerre (akar meg a MacDonald's DriveIn(r)(tm) kiszolgalasra is).