idézet:
Ezt írta Fiery:
Az Itanic lenyege az L3 cache, egyebkent meg hol lattal Te 1 processzoros 64 bites kiszolgalot?
A Deerfield teljesitmenyet pedig varjuk meg, majd meglatod, hogy falidisz lesz. Ha nem az lenne, mar regen mennenek a SPEC eredmenyek, melldongetessel...
Fiery[/quote]
Meg nem jelent termékről az Intel nem szokott túlzottan sok infot kiadni. MP means 4+ cpu. És szerintem vannak 1 utas 64 bites WS-ek.
[ 2003. október 09.: special szerkesztette a hozzászólást ]
Intel Itanium 2: egy új korszak kezdete
#301
Elküldve: 2003. 10. 09. 19:50
#302
Elküldve: 2003. 10. 09. 19:53
Elric
#303
Elküldve: 2003. 10. 09. 19:54
idézet:
Ezt írta special:
A párhuzam az adott termék fontosságában rejlik. Ha három darab XBoxot adott volna el az MS eddig, amiből egyet-egyet Ballmer öcsi és Gates vett volna meg, akkor is gőzerővel ölnék bele a pénzt. Mert ahogyan mondod, a jövő otthonaiban nem PC lesz, hanem egy szórakoztató központ. Ezért a jövőbeni piacért dúl a háború. A jövőbeni 64 bites server/ws és később desktop piacot célozza az IA-64 is.[/quote]
Ha mar ennel a parhuzamnal tartunk, nemtom, feltunt-e, hogy az Xbox eseteben sem a hatalmas innovacion van a hangsuly. Milyen proci is van benne? Milyen vinyo? Milyen videochip? Egyaltalan, milyen architekturara epul a cucc??
Az Intel arra ment ra, hogy forradalmat csinal: hany forradalom is volt sikeres az utobbi 2 evszazadban?
Az M$ ezzel szemben fogott egy bevalt HW-t, kicsit tweakelt rajta, es kidobott valamit, amiben lenyegeben semmi innovacio nincs! Az M$-nek megvan az a kepessege, hogy hasson a szoftver fejlesztokre: ide is rak nehany szazezer dolcsit, oda meg 1 milliot, es raveszi a piacot arra, hogy az egyebkent a PC-hez sokkal kozelebb allo Xboxra fejlesszen (lenyegeben kisebb befektetessel, mint mondjuk PS-re vagy GameCube-ra!), mint barmi masra (incl. PC adott esetben).
Az Intel nagyon ugyes, de az M$ me'g nala is sokkal ugyesebb...
Fiery
#304
Elküldve: 2003. 10. 09. 19:57

#305
Elküldve: 2003. 10. 09. 19:57
idézet:
Ezt írta special:
Meg nem jelent termékről az Intel nem szokott túlzottan sok infot kiadni. MP means 4+ cpu. És szerintem vannak 1 utas 64 bites WS-ek.[/quote]
Mutass 1 db 1 utas, 64 bites WS-tPersze lehet venni 2 utas alaplapot Itanic2-hoz, 1 db procival, de hogy nem sokat adnak el belole, az is biztos.
A Deerfield pedig hivatalos termek, lasd itt:
[url="http://"http://www.intel.com/products/server/processors/server/itanium2/index.htm"]http://www.intel.com...nium2/index.htm[/url]
Fiery
#307
Elküldve: 2003. 10. 09. 19:59
idézet:
Ezt írta special:
Nem tudom ki mondta nekem, én itt szoktam ilyenekt olvasni.Javíts ki Elric, ha tévedek, de sok utas rendszerben nem arra jó a cache, hogy több task is elfér benne, és kevesebbet kell várni a memóriára, míg egy másik cpu legfoglalja? Mead culpa, ha baromságokat írogatok.[/quote]
Az IA-64 eseteben me'g 1 proci eseten is _letkerdes_ a nagy L3 cache, maskepp doglassu a cucc (igy se valami gyors ugye)
Mas architekturak eseteben igaz az, amit irsz: nagy altalanossagban a nagy cache foleg DP es MP rendszereknel "szukseges".
Fiery
#308
Elküldve: 2003. 10. 09. 20:02
Egyebkent egy CPUs 64-bites szerver jocskan van, (pl. a Sun-nak a nagyon sikeres t1, t100, x1, V100, V120 stb) ezek altalaban nagy eloszeretettel hasznalt web szerverek.
Elric
#309
Elküldve: 2003. 10. 09. 20:04
idézet:
Ezt írta Fiery:
Az Intel semmikepp sem fogja feladni az IA-64-et, valahova, valakinek el fog evente ajandekozni legalabb 5 ezer darabot belole, hogy egyaltalan fel tudja azt mutatni, hogy legalabb nehany matematikus/fizikus fel tudja hasznalni valamire a cuccot.[/quote]
Ahm. Es meg ezt is ravaszan csinalja (; A tanszek nyaron kapott az Inteltol ki tudja minek a kereteben X kreditet, meg egy listat kulonfele Itanium hwekkel, h azt vehetnek belole. Na, ebbol lett 8 ketutas Itanium [nem tudom most pontosan h Itanium1 vagy 2, de asszem 900MHz. hat nem a legujabb dolgok voltak a listan <;], mult honapban meg is jottek jol. Namost a tanszeken leginkabb cluster computing fejlesztesek folynak, amihez a 8 node keves, hiszen ennyin egyszeruen nem lehet skálázhatosagot vizsgalni [hja, kiegeszites, clusterekhez valo interconnect nelkul jott a 8 node, ugyhogy meg azt is kell szerezni...]. Clusteres emberek probaltak eroskodni, h a meglevo dual P3 clustert kene boviteni. Ennyi penzbol rengeteg nodeunk lehetett volna, de nem, a felajanlast csak Itanium alapu hardverre lehet forditani. Remek. A kozeljovoben megy rendeles meg 8 ketutas gepre a tanszek sajat zsebebol, persze nem ugyanolyanra, mert olyanok mar nincsenek, illetve vannak, csak eppen meglehetosen dragabbak, mint a jelenleg kaphato, azoktol nagyobb teljesitmenyu modellek. Ugyhogy jupí, lesz egy inhomogen clusterunk, bar mar hallottam olyat, h lehetseges, h a 8 ajandek is upgradelve lesz az ujak szintjere...
Szóval cselesek, adnak 16 procit, es gondolom biznak benne, h veszel hozza meg 16ot, mert azzal onmagaban ugyse tudsz mit kezdeni... Lelki szemeimmel latom, ahogy az Itanium eladasok meg szöknek az egekbe kozben... <;
#310
Elküldve: 2003. 10. 10. 08:40
idézet:
Ezt írta T2k:
Mostantol nagyon is az: az AMD64, as of today, sokkal inkabb 'sikerre van itelve' , mint az IA64. Az IA64 egyelore sehol nincs sem serverekben, sem WS-okben - es ha az AMD64 a WS-piacon elterjed (csaknem biztos vagyok benne - felteve, ha lesz belole eleg), akkor onnantol kezdve az IA64 megmarad egy szuk, zart reteg jatekszerenek. Meg server szinten is: ha a WSjeimen az fog futni, gondolod, hogy DIREKT KULON MAS architekturat fogok venni servernek?[/quote]
Hümm.
Bár korábban erről mást gondoltam, a jelenlegi információk alapján az AMD64 az IO-igényes szerverek számára az egyik - ha nem kifejezetten 'a' - legideálisabb processzor.
A WS oldalon viszont csak a 32-bites szoftverellátottság áll mellette, más nem.
Hogy ez elég lesz-e... Nem tudhatom.
Ui.: azzal itt mindenki tökéletesen egyetért, hogy ha valaki most vesz egy IA64 alapú rendszert, nem tesztcélokra, akkor az:
a.) Hülye
b.) Nagyon-nagyon pontosan tudja, hogy milyen szoftvert fog futtatni, és az min megy a legjobban - emellett fontos tényező számára a lehető legnagyobb teljesítmény, és mindez pont az említett rendszerre igaz.
Nem ezen megy a vita.
[ 2003. október 10.: Rive szerkesztette a hozzászólást ]
#311
Elküldve: 2003. 10. 10. 08:54
idézet:
Ezt írta Supposed Former Infatuation Junkie:
Rive a dolog ott kezdodik, hogy van egy problemad es annak van egy strukturaja. Ezek utan a feladat karakterisztikajahoz valasztasz implementecios nyelvet. Es ha ugy tetszik implicite, mivel az ugy (gyengen) tranzitiv, a problemahoz valasztasz szamitogep-architekturat.[/quote]
Feladat: power-app. Vagy: szerver. Válassz hozzá JAVA-t
idézet:
Ezt írta Supposed Former Infatuation Junkie:
A dolog olyanm hogy van egy problema. Ez bekerul a modellterbe es a modellter lekepzodik az implementacios terbe. Ennek a vege az assembly kod. Minnel nagyobb a szakadek a modellter elvarasai es az implementacios ter lehetosege/mukodese kozott, annal valoszinubb, hogy az implemantacio nem lesz hatekony. Ha ugy tetszik >>nyeletlen baltaval nem lehet ablakot pucolni <<, vagyis egy straming architekturara nem lehet optimalisan lekepezni egy esemenyvezerelt ugyet. A streaming architekturak batch-ek futtatasara valok.[/quote]
Aha. Jól kijelentetted, nézzük mi van mögötte.
Nézzünk egy totálisan eseményvezérelt feladatok megoldására alkalmazott nyelvet: GCC. Válasszunk hozzá egy procit: K7. Feladat: SPEC.
Egyetlen egy esetben sem sikerült 1-es IPC fölé menni. Ennek legnagyobb oka a nagy memória-késleltetés volt. Egyes esetekben az IPC 0.05 környékén mászkált.
Minden más - VE, cache, branch pred-miss - másodlagos volt ehhez képest.
Elárulom, kernel szinten a dolog még rémisztőbb, az user-kernel átmenetek és az IO miatt.
(és: egy szimpla webkiszolgáló esetén a futásidő >20% kernel-time, meglehetősen fragmentálva -> számolatlan mennyiségű task-switch, TLB-miss)
Az AMD64 ebben annyit tesz, hogy visszaállítja a ca. négy-öt évvel ezelőtti állapotot (0.8-1.3 IPC körül, azonos alkalmazásokban). Ennyit ad hozzá pillnatnyilag az x86 várható élettartamához.
Még annyit, hogy más C fordítókkal se változik a helyzet.
Azt hiszem, ennyit az esemény-vezérelt programokról, nem streaming-procin, ISA-n, bizgentyűn.
idézet:
Ezt írta Supposed Former Infatuation Junkie:
Javaslom hogy nem menjel CEO-nak sehova. A Piaci igenyek 80%-at esemenyvezerelt programok teszik ki, TTM6-os elvarassal. Tetszik/nem tetszik a keredkedelmi sw-el 80%-a java/.net/vizilobezik szeru es ezek hozzak a bevetelek 90%-at. Ha te ki akarod zarni magad errol a piacrol, am legyen, csak ne sirankozz, ha a veghen ehen maradsz.[/quote]
Ehe-ehe. Csak tudnám, mi adja az egész alá az infrastruktúrát...
idézet:
Ezt írta Supposed Former Infatuation Junkie:
Magyarra forditva: a CPU pipeline hosszanak, a beepitett cahe mem meretenek novelese helyett, modern, az igenyeket kielegito operativ tar megoldasokat kene keresni. Ennyire ecceru.[/quote]
Pistike álmodik![]()
Hadd súgjam meg: pont ez az, ami nem megy... Szimpla fizikai korlátok miatt...
Elgondolkodtál már egyszer is azon, hogy a processzorgyártók egyöntetűen mi a fenéért pumpálják az egekbe a cache mennyiségét?
Egyik se vár semmi áttörést memória-piacon, azé'...
[ 2003. október 10.: Rive szerkesztette a hozzászólást ]
#312
Elküldve: 2003. 10. 10. 08:58
idézet:
Ezt írta sz:
Ahm. Es meg ezt is ravaszan csinalja (; A tanszek nyaron kapott az Inteltol ki tudja minek a kereteben X kreditet[/quote]
De rohadék az Intel...16 proci ingyen...bezzeg az AMD, az legalább egyet sem adott, így nem is kell saját pénzből venni még hozzá! Pfff...ezt a büdös világot...
#313
Elküldve: 2003. 10. 10. 09:08
idézet:
Ezt írta Elric:
Rive, akkor kolcsonosen felreertettuk egymast. Az elerheto teljesitmeny az aktualis hardver, az ISA es az optimalizalo compiler fejlettsegenek a fuggvenye. Viszont az ISA es a hardver aktualis implementacioja kozott a leggyakrabban nincs osszefugges. Illetve amikor az elso verziot tervezik, akkor tudsz valami ilyet tenni, vagy retrofit modon benyomni egy ISA kiterjesztesbe (pl. MMX/SSE/VIS/MIX etc...). Ettol kezdve meg a compileren mulik, mit es hogyan tud hasznositani. Az IA-64 csak azert latszik jobban illeszkedni a mai hardver kovetelmenyekhez, mert ujabb, mint a 74-es x86 alap ISA. De ezen nem szabad csodalkozni. ISA kiterjesztessel ugyanazt el tudod erni. pl. Prefetchet az SSE2 hozott.[/quote]
A kiegészítések - sajnos - ez esetben nem érintették az X86 alapjait: nagyon hiányolható pl. az sw code-prefetch, az alapblokkok növelését lehetővé tevő utasításformák, a task-switch támogatás. A pillanatnyi kiegészítések csak és kizárólag speciális célú kódrészletek gyorsítását teszik lehetővé. Ez - szerintem - csak az egy task - egy gép jellegű feladatok esetén kielégítő megoldás.
idézet:
Az Intel nem veletlenul valasztotta azt a PPro-nal, hogy uops-okra all at, attol kezdve meg egy gyenge ISA-val is lehet negyon jo eredmenyeket csinalni, mint azt a mellekelt abra mutatja is...[/quote]
Pillanatnyilag az Intel a uops dekódolóinak a tehermentesítése végett be kellett, hogy vezesse a trace-cache intézményét
idézet:
Rive, erosen vitatkozom avval, hogy a jovo a hosszu pipeline-u gepeke.[/quote]
Ironikusnak szántam azt a mondatot: sajnos, úgy látszik, nem ment át![]()
idézet:
A uniprocesszoros piacon igen, mashol? Hat bizonytalan vagyok. Ha megnezed a piacot, a jovo minden esetben a sok core, sok thread per processzor rendszereke. HP, IBM, Sun, AMD, Intel. Mindenki ebbe az iranyba megy, ez meg az atbocsajtas (throughput). A szerver vilagban ha van 16 egyszeru 6-8 lepcsos, nem szuperskalar core-od es egy jo interconnected, igaz, hogy nagy chip-sd lesz, de iszonyatosan gyors. Sokkal gyorsabb, mint egy 16-utas, 40 lepcsos csoves cucc... Egyszeruen nem eri mar meg tobb ILP-t tenni a procikba... Ezt hala az egnek meg a kutatas is megerositi. [/quote]
Ezt elmagyaráznád a komplex ILP mániás népségnek is, akiknek nem fér el a fejében, hogy a memória-késleltetés dolgait illetően már nem lehet mindent a hardverre bízni?
idézet:
Minden esetre az x86-64 valoban sokkal eselyesebb a sikerre, HA az AMD jo teljesitmenyt, marketinget es ISV tamogatast tud moge tenni. Szerintem mindent meg fog tenni, de lattunk mar elszurt dolgokat, szoval erre sem vennek merget.
Elric[/quote]
Én hozzátenném azt is: és ha az AMD képes megfelelő hosszú távú terveket és kutatásokkal alátámasztott irányvonalakat felvázolni az x86 továbbvitelének hogyanját illetően.
Mert ha nem, akkor van még egy generációjuk, és becsukhatják a boltot.
#314
Elküldve: 2003. 10. 10. 09:23
#315
Elküldve: 2003. 10. 10. 14:04
idézet:
Ezt írta Rive:
Pistike álmodik![]()
Hadd súgjam meg: pont ez az, ami nem megy... Szimpla fizikai korlátok miatt...
Elgondolkodtál már egyszer is azon, hogy a processzorgyártók egyöntetűen mi a fenéért pumpálják az egekbe a cache mennyiségét?
Egyik se vár semmi áttörést memória-piacon, azé'...
[/quote]
Hadd sugjam meg neked: megy.Csak a jelenlegi processzorgyartok a memoriauzletagat a 90-esekben outsource-oltak tavolkeletre es lealltak az eziranyu fejlesztesekkel is. Ertsd alatta, ellenrdekeletek mindennemu valtozasban. Egy paradigmalis valtason alapulo, biologiai/holografikus/optikai elven mukodo tarolo felhasznalasahoz durvan at kene, hogy tervezzek a majorok a procijaikat. Ezt meg nem akarjak.
[ 2003. október 10.: Supposed Former Infatuation Junkie szerkesztette a hozzászólást ]
What do stars do? They shine.(Yvaine)
#316
Elküldve: 2003. 10. 10. 14:19
"Q: So do you think Itanium is doomed?
A: It is an architecture that's kind of inspired by the late '70s high-performance computing--in other words a pretty narrow focus, and yet trying to get applied in the '90s for a general-purpose computing environment.
Certainly there have been rumors from the beginning that Intel has sunk multiple billions of dollars into this program. On top of that, their image and self-respect--everything is at stake. So I think they will continue carrying Itanium. But...they knew the consequences of their decision. They knew they broke the binary compatibility (preventing programs written for x86 chips to run easily on Itanium chips). They knew they had to re-create an ecosystem. Probably they have such high confidence on their resourcefulness and their "macho-ness" that think they can overcome.
Sun actually tried it (breaking binary compatibility) several years back...but after we provided the compilers and ported the operating system, we looked at it on the applications side and eventually threw in the towel. We know how formidable it is to try to create a new software environment.
They created such an opportunity for AMD, which came in and did an incremental 32-bit to 64-bit extension on the foundation of the Athlon design in a relatively short time with Opteron. A huge advantage is they allow a customer to continue running their 32-bit applications.
How do you think Intel will respond?
Intel certainly recognized (the Opteron threat) a year or two ago...If you look at Prescott, if you look at some of the new (chips)--in particular some of those coming up in 2004--Intel's very quietly putting something called a 64-bit extension in. I think Intel will have to address this vulnerability created by Itanium versus Opteron. They need a better defense.
So Intel put a 64-bit extension into Prescott?
Yeah.
With 64-bit memory addressing?
With their 64-bit architecture, they will allow programs to have 64-bit addressability. I suspect there also will be 64-bit registers and 64-bit function units. But basically it's an Opteron-type of compatible design."
Fiery
[ 2003. október 10.: Fiery szerkesztette a hozzászólást ]
#317
Elküldve: 2003. 10. 10. 14:22
idézet:
Ezt írta Supposed Former Infatuation Junkie:
Hadd sugjam meg neked: megy.Csak a jelenlegi processzorgyartok a memoriauzletagat a 90-esekben outsource-oltak tavolkeletre es lealltak az eziranyu fejlesztesekkel is. Ertsd alatta, ellenrdekeletek mindennemu valtozasban. Egy paradigmalis valtason alapulo, biologiai/holografikus/optikai elven mukodo tarolo felhasznalasahoz durvan at kene, hogy tervezzek a majorok a procijaikat. Ezt meg nem akarjak.[/quote]
???
És még te jössz nekem az ufókkal...
#318
Elküldve: 2003. 10. 10. 14:50
idézet:
Ezt írta Elric:
A cache indoka [/quote]
Specialhoz hasonlóan én is többször olvastam, hogy az Intel osztott - nem dedikált - buszrendszere miatt is életbevágó a nagy cache a többprocesszoros rendszereinél (még a Xeonok kapcsán).
És úgy tudom ennek a busznak valamilyen variánsát használja az Itanium is, de tévedhetek.
#319
Elküldve: 2003. 10. 10. 15:02
idézet:
Ezt írta Michell:
Specialhoz hasonlóan én is többször olvastam, hogy az Intel osztott - nem dedikált - buszrendszere miatt is életbevágó a nagy cache a többprocesszoros rendszereinél (még a Xeonok kapcsán).
És úgy tudom ennek a busznak valamilyen variánsát használja az Itanium is, de tévedhetek.[/quote]
![]()
(egyszer már beszúrtam)
#320
Elküldve: 2003. 10. 10. 17:23
idézet:
Ezt írta Rive:
A WS oldalon viszont csak a 32-bites szoftverellátottság áll mellette, más nem.
[/quote]
Muhaha: CSAK???
Rive.... szerinted mi lehet a meghatarozo mas, ha az IA64-re NINCS SW at all (ws retegrol van szo) es tetu lassan futtatja a regi kodot, de dupla aron adjak?
Nos?
Szerited mi MAST kellene meg tudnia az Opteronnak azon kivul, hogy A) feleannyiba kerul B)barmilyen sw remekul hasit rajta??
![]()
![]()
idézet:[/quote]
Hogy ez elég lesz-e... Nem tudhatom.
Ha csak errol lenne szo, MAR MOST GYOZTEST hirdetnek. A kerdes az, LESZ-E ELEG belole ahhoz, hogy ELARASSZA a piacot vele az AMD?
idézet:[/quote]
Ui.: azzal itt mindenki tökéletesen egyetért, hogy ha valaki most vesz egy IA64 alapú rendszert, nem tesztcélokra, akkor az:
a.) Hülye
b.) Nagyon-nagyon pontosan tudja, hogy milyen szoftvert fog futtatni, és az min megy a legjobban - emellett fontos tényező számára a lehető legnagyobb teljesítmény, és mindez pont az említett rendszerre igaz.
Nem ezen megy a vita.
c.) Qrvamod vastag a penztarcaja.
DEHOGYNEM!!!! Ebbol is kozetkezik, hogy HULYESEG a ti 'sikerre van itelve' dumatok. Ezt probalom elmagyarazni en is, Elric is, SFIJ is.