Knick Knack

Frekvensøkninger nesten alltid den beste måten å øke ytelsen på til en hvilken som helst komponent i datamaskinen.

Athlon64 CPU'er er vel et bevis på det motsatte...

Nei de er et bevis på det samme. Dobling av frekvensen er f.eks mye mer effektivt enn å bruke to stk kjerner.

Vær klar over at jeg nå snakker om å øke frekvensen til et gitt design uten å endre det. Altså den beste måten å øke ytelsen til en A64 prosessor er å øke frekvensen. Den beste måten å øke ytelsen til en link (det være seg FSB, HTT eller PCIe) er å øke frekvensen. Problemet er at dette er så effektiv måte å øke ytelsen på at en gjerne balanserer på kanten av hva som er mulig. For PCIe var det tydeligvis ikke tilfellet.

Alternativet til å øke frekvensen på en link er å øke bredden. Om du skal oppgradere en gitt link kan du altså f.eks:

1) Doble bredden. Det gir dobbel båndbredde

2) Doble frekvensen. Det gir dobbel båndbredde og halvert forsinkelse

3) Doble begge deler, om mulig. Det gir 4x båndbredde og halvert forsinkelse.

geddit?

Jøss, finnes det forbruker-hovedkort med 32 baner i dag?

E7525 har 24 på NB og mulighet for noen på SB. Om det er et forbruker chipset er vel kanskje litt på kanten. Du må ha Xeon CPU, DDR2 og HK til ca 3000. Ekstrem entusiast kanskje..

Ellers kommer det et Xeon chipset (Blackford) med FB-DIMM, 32x PCIe og dual FSB i 2005. Det blir antagelig det råeste og dyreste chipsettet du får kjøpt i 2005 til x86 workstation. Bare så synd at det ikke ser ut til å komme noen gode Xeon prosessorer i 2005.

For Opteron er det vel ute et hovedkort fra Iwill (DK8ES) med to nforce4 chipset hver med 16x PCIe. De kortene ligger vel på 5000.

kommer an på hvordan man oppfatter diskusjonen

Er det så mange måter å oppfatte "et slag i ansiktet for Intel" på? De er sikkert veldig lei seg for å få full kontroll over CPU utviklingen og på kjøpet et svært kompetent ingeniørteam på 100-300 mann.

HP har jo også sagt at de vil satse med 3 milliarder dollar på videreutvikling så det blir litt vanskelig å tolke denne hendelsen som at "HP trekker seg". Det er en vri nesten bare hw.no og INQ klarer å få til. HP trekker seg ikke fra noe IA64 utvikling som helst. De øker faktisk innsatsen! Det de gjør er å overlate utviklingen av CPU til Intel. Det er imidlertid sluttproduktet som er viktig for å lykkes og her kommer HP sterkere inn enn før.

Nå er vel INQ fortsatt et hakk vassere enn hw.no på denne fornten. Vi får se om hw.no klarer å lage mer FUD enn dette: http://www.theinquirer.net/?article=20255

Dette er helt klart fremtiden for alle skjermkort. Både for budsjett og high-end kort. High-end kort som 3DLabs VP10 har også brukt lignende funksjonalitet. Det er egentlig bare snakk om en oppgradering av minnehierarkiet til skjermkortet. En får det til å ligne mer på det hierarkiet som CPU har brukt siden midten av 90-tallet. Minnet lokalt på kortet blir brukt som en cache til å lagre akkurat det en har bruk for til en hver tid, mens systemminnet lagrer hele arbeidssettet. Forskjelen på CPU og GPU er at CPU er langt mer avhengig av lav forsinkelse på cache og må derfor ha on-die SRAM cache som er dyrt å produsere og har lav lagringstetthet i forhold til off-die DRAM cache som skjermkortene bruker. Skjermkortene er typisk ikke veldig avhengige av lav forsinkelse (relativt sett i forhold til CPU) men er veldig avhengig av å ha stor cache med høy båndbredde.

Det som er litt synd med dagens systemer er at PCIe svitsjene i chipsettene ikke klarer å levere like mye båndbredde som linken kan levere. F.eks kan i915 chipsettet i følge Anandtech bare levere 1GB/s fra GPU til NB og 3GB/s fra NB til GPU, mens selve linken er god for 4GB/s i hver retning.

Fremtidige systemer med dual chanel DDR2-800 og fullt implementert PCIe svitsj i NB vil antagelig levere svårt gode arbeidsforhold for high-end skjermkort med denne typen teknologi, også i SLI.

Svært gode nyheter for videreutviklingen av "Itanic" dette! HP dytter inn nye 3 milliarder dollar i utvikling av chipset, servere og software for IA64 platformen. Dette vil også medføre at Intel står feiere til å sammarbeide med HP's konkurrenter om å utvikle IA64 platformen videre.

http://www.internetnews.com/ent-news/article.php/3448641

Dette har vi så absolutt bruk for. Dette medfører at en dobler overføringshastigheten per linje noe som grunnet PCIe sin fleksibilitet kan utnyttes enten ved at en halverer antall linjer og dermed får billigere og mindre hovedkort eller ved at en får dobbel hastighet (duh! ). F.eks et SLI oppsett med dual 8xPCIe Gen. 2 vil ha samme båndbredde som et dual 16x PCIe (Gen. 1).

Gen 2 vil også ha halve forsinkelsen av dagens versjon. Frekvensøkninger nesten alltid den beste måten å øke ytelsen på til en hvilken som helst komponent i datamaskinen.

ctrl-alt-del funker i alle fall mye bedre i 2k og 2k er mye mer stabilt den xp litt forskjell

Det er ikke min erfaring at XP er mindre stabilt en 2k.

Så vidt jeg vet så er også Win XP egentlig bare Win 2k med "glasur". Altså egentlig samme OS, men med litt ekstra. Det er kanskje noen ekstra bugs som følger med den ekstra funksjonaliteten og "brukervennligheten".

Den største forskjellen på XP og 2k er nok brukeren og de programmene oftest som installeres. Spill er ikke kjent for å være debugget til den store gullmedalje...

Win XP 64 bit edition for x86 prosessorer er ikke laget fra noe scratch som helst. Det er en "twak, tune and recompile". Ferdig med det. Samme gjelder for så vidt for alle andre 32 og 64 bit versjoner av Win XP. Alt bygger på samme koden. "Bare" nye driverne og noe kernel endringer som skal til. Å porte software fra 32 bit til 64 bit er veldig enkelt om en ikke har rotet seg bort i spesielle 32bit antagelser, noe de aller fleste sørger for å unngå. OS er likevel noe av det vanskeligste å porte da kernel må ha en del kunnskap om de prosessorene den skal jobbe på for å kunne fungere effektivt og levere all funksjonaliteten som prosessoren gir mulighet for.

:!: priceless.

Et alternativ er jo å jobbe et par timer og kjøpe seg en "godis bag". Men det er vel primært for oss som er blitt litt skadd av å ha brukt for mye tid i den virkelige verdenen.

snorreh: enkelte av de testene du refererer til er ikke basert på DP Xeon 3.6GHz.

Du er med andre ord litt utenfor blinken. Dette er Dell sin representasjon av DP Xeon 3.6GHz. Da må en nesten vise til tester gjort med den prosessoren. Ellers kunne de like gjerne diktet opp tall.

Det nærmeste du kan komme en sammenligning i TPC-C er dette:

2-way Xeon DP 3.6GHz: 68k TpmC 1.80 US $ Price/tpmC

4-way Opteron 250: 123k TpmC 2.94 US $ Price/tpmC

http://www.tpc.org/tpcc/results/tpcc_resul...sp?id=104110101

http://www.tpc.org/tpcc/results/tpcc_resul...sp?id=104120801

"We've run out of acronyms and started to reuse them,"

Noen som vet hvem denne Nathan Brookwood er? Han ser ut til å dukke opp i alle artikler jeg leser.

http://www.insight64.com/

In 1998 Nathan founded Insight 64, where he works with clients who value his unique blend of marketing and technology skills. Although best known for his knowledge of the semiconductor market, he also works in closely allied system markets where improved semiconductor technology plays a key role.

hva blir så mye bedre med SSE3 engentlig?

Relativt lite. det er en liten utvidelse av instruksjonssettet som blandt annet gjør det enklere å styre tråder på prosessorer som støtter SMT. Det er også noen kjekke triks der for konvertering mellom flyttall og heltall samt noe skalarprodukt greier om jeg ikke husker helt feil.

Kort sagt er det de instruksjonene som manglet i SSE1 og SSE2, men markedsføres det skal det!

Betyr ca nix og nada for sluttbruker. De som lager skreddersydde multimediabibliotek kommer til å like SSE3 og det samme gjelder de som lager kompilatorer. SSE3 gjør nemlig hele SIMD pakken av instruksjoner mer komplett og enklere å lage kompilatoroptimaliseringer for.

Så helt til slutt kan en kanskje konkludere med at SSE3 vil gjøre SSE2 kompatible programmer mer vanlige, da de blir lettere å lage.

Det eneste jeg ikke helt fatter er SSOI, er jo bedre enn SOI. Og dette er noe annet igjen? Fælt så mange ting de skal ha for akkurat det samme. Hva er forkortelsen for denne tingen?

nå har jeg ikke kværna gjennom denne tråden ennå, men hva er SSOI? Mener du SS-SOI? Som i Strained Silicon (SS) og SOI kombinert? Det er jo det de leverer nå, snart.

En må forøvrig ikke se seg blind på alle forkortelsene. At en prosess benytter SS sier ikke noe om hvor bra denne SS teknologien er implementert.

Jeg har nå studert disse Dell-plansjene litt mer i detalj for å undersøke om det er noe hold i dem eller ikke.

 

<klippe-klipp>

 

Konklusjon:

Utifra dette så er det vanskelig å konkludere med noe annet enn å si at dette er direkte villedende markedsføring fra Dell, siden det bare er noen ytterst få av tallene som faktisk stemmer og de øvrige er enten feilaktige eller direkte missvisende

Det er et imponerende stykke research du har gjort der snorreh.

 

Ikke bare er grafene presantert med alle visuelle teknikker for å få de til å vrike så store som mulig, men de har til og med kuttet ut en rekke benchmarks som viser det motsatte (LS-DYNA, BLAST, BLAT, HMMER og STREAM) og atpåtil ganget med en liten "dell-faktor" for å få resultatene ennå litt mer imponerende.

 

Hadde vært fint om du kunne sette opp et skikkelig stolpediagram med 0 som grunnlinje, ingen forkorting av noen akser og kanskje med Opteron 250 som 100%. Så kunne vi sett bedre hvilke bencharks som yter dårligere og bedre med en visuelt bedre skala enn det dell har bruk.

Jeg må si meg svært enig i dette bortsett fra at jeg seriøst begynner å miste respekt for din vurderingsevne av grafer... Grafen HAR 0 som grunnlinje. I tillegg er dette en av de mest benyttede, lettfattelige og presise teknikkene for å vise forskjellen mellom TO enheter. Det være seg bildekk eller prosessorer. hjelp! noen skaff oss en ingeniør!

Vel hipp hurra for de nye inovatørene! AMD og IBM har endelig oppfunnet det samme kruttet som Intel har brukt i lengre tid, nemlig "dual strain". Dette vil nok medføre at de tar knekken på de problemene de hadde med å skalere frekvensen på sin 90nm prosess.

Det er også et delvis bevis på at SOI ikke egentlig var verdt insatsen. Noe nokså mange har påstått. Undertegnede inkludert.

Skal likevel bli spennende å se hvor bra dette blir. Teknisk sett er SOI tross alt ca 10% - 20% bedre enn bulk, selv om det vel er mer utgifter (yield tap, utvikling og ekstra produksjons kostnader) enn fordelene retferdiggjør.

Legg litt godvilje til så skjønner du hva jeg mener: Det visuelle intrykket fra høye grafer står ikke i stil til de små tallene det er snakk om. Gode grafer bør ha 0 som basis på en ytelseskala (ikke %vis forskjell-skala) og ingen klipping av aksene.

 

Joda, HPC-kunder skjønner nok både resultatene og intensjonen bak grafene men det betyr likevel ikke at det visuelle førsteintrykket er noe "sannere" enn jenter som går med høye hæler eller klær med loddrette striper for å se høyere og tynnere ut.

jeg tenkte meg faktisk om to ganger før jeg valgte å forsvare den dell reklamen...

tror faktisk det er nødvendig å legge "godviljen" til for å se den som missvisende slik du og snorreh beskreiver. dvs dere har ikke beskrevet det i det heletatt. Alt jeg ser er anklagelser uten begrunnelse...

tror dere er ute å sykler litt med denne.

å vise speedup i prosent er svært vanlig fordi gir et veldig nøyaktig bilde av forholdet mellom to prosessorer. noen av de beste artiklene på anand og xbit bruker akkurat dette til å oppsumere om jeg ikke husker feil. bl.a. blitt brukt til å sammenligne nw og prescott.

Historien gjentar seg nok en gang:

 

Dell sells AMD Opterons through back door

 

Sjekk skalaen på de grafene, samt utvalget av benchmarks - ikke engang THG kunne gjort det bedre

Jepp, utvalget av tester er tragisk ensidig og bruken av relative grafer (%-vis forskjell) gir lett et feil visuelt intrykk av hvor små forskjeller det er snakk om. F.eks får man et visuelt bilde av at den høyeste grafen (se link) snakk om ~10x høyere ytelse på Xeon, noe som slett ikke er sant. Det reelle tallet er 1,58x høyere ytelse. Greit nok at tallene står der i små skrift, men hjernen oppfatter det visuelle intrykket (høyden på grafene) lettere enn en rekke tall. Hovedintrykket av ytelsenivået blir dermed helt feil. (unntak: de som klarer å gjennomskue "synsbedraget" eller de som setter opp grafene på egenhånd slik at det visuelle intrykket samsvarer med det faktiske tallmaterialet.

Hva er det du preker om? ~10x høyere ytelse? synsbedrag? mulig jeg undervurderer Jonny fra Stovner litt, men hvordan i huleste kan man ha slik fantasi? For ikke å snakke om HPC kundene til Dell....

Dette er definitivt ikke mitt fagområde, så unnskyld et banalt spørsmål. Jeg trodde årsaken til at man fokuserer på flere kjerner nå er at man ikke klarer å skalere effektivt på den enkelte. (Ingen 4Gig Pentium.) I så fall er vel ditt hjertesukk rimelig akademisk?

Yes godt observert! Det er svært vanskelig å øke ytelsen på mange av dagens prosessorkjerner. Det er ett unntak, men jeg er redd det blir leven om jeg nevner det her la oss si at det begynner på "itan" og slutter på "ium"..

Det er også noen kjente triks (cache, ODMC, prefetch, SIMD) som kan gjøres for å øke ytelsen per kjerne for andre cpu-typer og det er noen mindre kjente (f.eks PARROT).

Det er også noen kjente triks som ikke lar seg gjøre med det første. Bredden på en x86 CPU vil f.eks ikke bli mer enn 3. Dvs. issue width på 3 eller altså at maksimalt 3 instruksjoner kan legges inn i pipelinen på samme klokkeslag. Både Dothan Prescott og k8 har dette... skulle en kanskje ikke tro. Årsaken til forskjellen i ytelse/frekvens skyldes flere ting. bl.a. har Dothan og k8 mulighet for flere kombinasjoner av instruksjoner og de bruker mer tid på å lete etter mulige kombinasjoner. I tillegg har jo k8 som kjent integrert minnekontroller (ODMC) som gjør at CPU vil bruke mindre tid på å vente på data fra minnet som prefetch ikke klarte å snappe opp på forhånd. Breanch prediction er også inne i bildet og favoriserer Dothan og k8 fremfor Prescott.

Det antas nærmest som galskap å gå til issue width på 4 med x86 på dagens CMOS prosesser. Kanskje aktuelt på 45nm. Issue width på 5 er helt utelukket med dagens teknologi. PARROT kan kanskje gjøre noe med dette i fremtiden. 2'er versjonen av den CPUen jeg ikke nevnte navnet på lengre oppe har en issue width på 11. Hvorfor? Fordi kompilatoren tar seg av å finne ut hvilke instruksjoner en kan kjøre sammtidig. Dette er svært tungt arbeid, men siden det gjøres ved kompilering så har en ikke noen viktig tidsfrist å forholde seg til. Dvs. det er greit at det tar 10min ekstra å kompilere koden. Det som ikke hadde vært greit er å måtte gjøre samme jobben hver gang koden ble kjøret.

Det er altså ikke problem å bygge en CPU som teoretisk kan ta 10-20 instruksjoner per klokkesyklus, du får bare ikke til å lage en rask nok krets som finner ut hvilke instruksjoner en kan kjøre samtidig.

OT: Det er forøvrig ikke tilfeldig at folk som Linus Thorvalds (og meg, uten sammenligning forøvrig) tror ARM vil ta over for x86 i konsumer markedet fremtiden. Den innebygde overheaden i x86 og mangelen på load-store arkitektur medfører at effektforbruk går unødvendig opp og ytelsen går unødvendig ned. (Jeg og Linus er imidlertid svært uenige om hva som vil skje med servere )

er det noe som ikke er digg så er det at det hypes for fult på multicore mens ytelsen til de individuelle kjernene ser ut til å stagnere. Det er kjedelig. De fleste vil ha innsett det innen 2008.

Mulig det er servere du tenker på, ellers går du imot deg selv med tanke på ytelsen til de individuelle kjernene.

I tråden IBM selger PC-divisjonen mener du at det ikke vil være behov for noe særlig kraftigere prosessorer til vanlig bruk. Eller har jeg gått glipp av noe ?.

mhm bruksområde. Multi core er nesten utelukkende brukbart i servere. Slik det ser ut nå så ligger det an til en dobling av antall kjernen hver 18mnd. som en slags "Moores lov". Det vil gi langt kraftigere diminishing returns enn frekvens racet vi nettopp tok en _pause_ i fra.

Det hele koker ned til en throughput vs. responstime diskusjon og jeg vet ikke om det er mange her som henger med på en slik diskusjon. Kanskje jeg tar feil. Det som ser ut til å være mannen i gatas oppfatning er at throughput ytelse = reell ytelse. Det er bare riktig hvis du kan vente i en evighet på din uber 8 core throughput, satt litt på spissen. At responstid er viktig er noe de fleste ikke forstår det er derfor alle hw sider tester throughput på spill (avg FPS) mens dette egentlig bare er en dårlig tilnærming til det egentlige problemet, nemlig responstid eller lengste tid mellom to frames. En hvilken som helst spiller kan nok etter å ha prøvd et system med 500 avg FPS og lagg (f.eks ned i 10 FPS i 0.3 sekunder for så opp igjen til 500 FPS resten av det "måle sekundet" hvilket gir 353 FPS) hver gang det skjer et eller annet "spesielt", skrive under på at det hadde vært bedre med en system med 70 FPS avg. som _aldri_ gikk over 0.03 sekunder responstid = 33 FPS. Det er hele throughput vs. responsetime debatten komprimert og anvendt på ett spesifikt eksempel. Et annet (og motsatt eksempel) er FB-DIMM. Hvorfor er denne teknologien geniforklart selv med en responstid høyere enn DDR2? Tenk litt på det... Dette er ikke trivielle spørsmål og om en ikke fatter bæra av det så tror jeg ikke en skal bruke for mye tid på å sette seg inn i hvorfor multicore er en spesiell teknologi som ikke egner seg til hva som helst. En får heller ta alt hypet med en klype salt inntil videre håpe på høyere frekvenser, og vente på dual core. De kommer til å gjøre det jevnt over bra. Quad core? Glem det. Kun egnet til server i mange år ennå. Kompilatorene må opp på et intelligensnivå som overgår EPIC kompilatorer med god margin før dette blir interessant for desktop.

snorreh: Det er liten sannsynlighet for at pipa mi endrer lyd nevneverdig de neste 3 årene. Jeg vet hva slags forbedringer jeg vil ha og hvorfor jeg vil ha de. Da tenker jeg ikke på ISA spesifikke detaljer. Videre har jeg rimelig grei oversikt over hva de forskjellige produsentene jobber med i dette tidsperspektivet og regner ikke med store overraskelser. 3 år høres kanskje mye ut, men det er engang slik at de prinsippene de ikke har begynt å jobbe etter nå, vil ikke kunne leveres før om 3-4 år. Den eneste dimensjonen det knytter seg nevneverdig usikkerhet til er klokkefrekvens. IPC*tråd/kjerne er veldig forutsigbart. Effektforbruk og areal er rimelig oversiktlig.

Høy på pæra? Egentlig ikke. Dette er fagfeltet mitt. Regn med at jeg kan like mye om dette som dere kan om deres fagfelt (for de av dere som har kommet så langt at dere har et ).

Åtte kjerner digg!

Faktisk fundamentalt uenig i at det er noe digg som helst. Det er ikke et "angrep" motAMD det gjelder samtlige CPU produsenter. er det noe som ikke er digg så er det at det hypes for fult på multicore mens ytelsen til de individuelle kjernene ser ut til å stagnere. Det er kjedelig. De fleste vil ha innsett det innen 2008.

såså ikke yppen nå. hw folk lar seg aldri pille ved nesen av sw folk

Nja ble ikke helt klok på de linkene. Var mer ute etter hvordan IA64 angriper problemet enn hva problemet går ut på. Tror kanskje det bl.a. er relatert til ALAT.

PA-RISC Wide-Word ble faktisk brukt som basis for IA64:

Jeg vet. Fant en gang en lang liste over hvor de hadde hentet de fleste ideene fra. Det er nesten ingenting nytt i Itanium. Nesten alt er hentet fra andre testprosjekter eller kommersielle produkter. Det er komposisjonen som er ny og det er det som er så genialt.

Og som nevnt på første side i dokumentet du linket til:

It addresses several fundamental performance bottlenecks in modern computers, such as memory latency, memory address disambiguation, and control flow dependencies.

Første og siste punkt har jeg god kontroll på hvordan fungerer og hvordan det er implementert. "Memory address disambiguation" er fortsatt noe diffust. Finner vel ut av det snart...

Ellers så ser blekka ut til å ha glemt ILP veggen, men den var vel ikke så tydelig på den tiden den ble lagd.

btw takk for linken nedenfor. Til alt overmål så tror jeg faktisk jeg manglet den.. hvilket er ganske godt gjort..

Det tviler jeg sterkt på siden IA32 (inkl. MMX & SSE) og PA-RISC MAX er en integrert del av IA64, noe som isåfall vil bety at Montecito ikke er en IA64-prosessor. Det er nok derfor svært lite sannsynlig at "IA32 Decode, Control Unit" som du snakker om mangler, for isåfall ville Montecito representere en ny arkitektur bare basert på Itanium, så det er heller mer sannsynlig at den er krympet ned eller integrert med en annen kontrollenhet på kjernen. IA64 må nok belage seg på å drasse med seg litt unødvendig bagasje som de fleste andre arkitekturer i dag...

Spenstig påstand. Gi gjerne noe dokumentasjon på dette.

Det er vanskelig å finne god og oppdatert informasjon om Itanium etter at cpus.hp.com plutselig forsvant, men det står litt om det i dette PDF-dokumentet:

 

Itanium Processor Microarchitecuture

Another key feature of the Itanium processor is its full support of the IA-32 instruction set in hardware (see Figure A). This includes support for running a mix of IA-32 applications and IA-64 applications on an IA-64 operating system, as well as IA-32 applications on an IA-32 operating system, in both uniprocessor and multiprocessor configurations. The IA-32 engine makes use of the EPIC machine’s registers, caches, and execution resources. To deliver high performance on legacy binaries, the IA-32 engine dynamically schedules instructions.1,2 The IA-64 Seamless Architecture is defined to enable running IA-32 system functions in native IA-64 mode, thus delivering native performance levels on the system functionality.

Det var akkurat det jeg tenkte meg. Du må nesten bestemme deg for om du skal tro på din egen versjon eller den du fant frem. De er i allefall diamentralt forskjellige.

Din versjon: IA64 = IA32 + "Itanium" + PA-RISC

Korrekt versjon: Merced/Mckinley/Madison = IA64 + IA32

Montecito er _antagelig_ bare IA64. Enten det eller så er IA32 kjernen krymped merkbart. Det er ingen som finner den...

PA-RISC har aldri vært integrert på noe Itanium CPU såvidt meg bekjent.

En dag uten Itanium nyheter er en dårlig dag...  I dag er en bra dag!

En dag uten Itanium nyheter er en god dag, og i dag er det søndag

Dvs. at ytelsesforskjellene mellom Athlon 64 3400+ 2.2GHz (1MB) og Itanium2 1.5GHz (4MB) med IA32EL på denne testen blir som følger:

 

LU: 268% raskere

FFT: 237% raskere

ODE: 500% raskere

Sparse: 364% raskere

 

Det må med andre ord et mirakel til for a Itanium ved hjelp av IA32EL skal kunne klare å yte i nærheten av like bra som som AMD64-prosessorer på x86-kode

Synes det ser bra ut jeg, gitt at IA32EL er på et svært tidlig stadium og at integer ytelsen (hvilket er svært viktig for emulatorer) er dårlig på dagens Itanium prosessorer i forhold til hva en kan forvente av neste generasjon. Dette er tross alt snakk om emulering. De viktigste programmene vil uansett bli portet til IA64, Java eller .net.

btw du har en litt snedig prosentregning. Med din regnemetode får jeg at en Itanium 2 som bruker noe tid på ett eller annet er 100% raskere enn en A64 som gjør akkurat det samme på like lang tid... eller visa versa. Det er mildt sagt interessante tall...

Slik ser det egentlig ut: (A64 2.2GHz 1MB vs. I2 1.5GHz 4MB x86 software emulering)

LU: 168% raskere

FFT: 137% raskere

ODE: 400% raskere

Sparse: 286% raskere

Det tviler jeg sterkt på siden IA32 (inkl. MMX & SSE) og PA-RISC MAX er en integrert del av IA64, noe som isåfall vil bety at Montecito ikke er en IA64-prosessor. Det er nok derfor svært lite sannsynlig at "IA32 Decode, Control Unit" som du snakker om mangler, for isåfall ville Montecito representere en ny arkitektur bare basert på Itanium, så det er heller mer sannsynlig at den er krympet ned eller integrert med en annen kontrollenhet på kjernen. IA64 må nok belage seg på å drasse med seg litt unødvendig bagasje som de fleste andre arkitekturer i dag...

Noterte meg at HP skal trekke seg fra CPU bransjen jeg også. Det lover i det minste bra for videreutviklingen av Itanium chipset og prosessorer siden det ser ut til at Intel kjøper opp hele virksomheten. HPs mx2 modul er av svært høy kvalitet skrives det, og HPs chipset for Itanium er det beste for 2-way og 4-way servere.

Når det gjelder fremtiden til Alpha og PA-RISC så regner jeg med at den er forseglet for lengst og det er også sannsynlig at de siste Alpha og PA-RISC prosessorene ble produsert tidligere i år. Det tok neppe lang tid å produsere et lager som skal holde ut support tiden til 2011. Altså ingen forskjell for deres fremtid.