Intel forsterker utviklerstab

[int20h]

Intel forsterker utviklerstab

Intel har hentet inn flere kjente utviklere fra Elbrus MCST. Forholdet har tidligere vært noe anstrengt mellom Elbrus og Intel, som tidligere jobbet med en "Itanium-killer".

 

Les artikkelen her

[majuz]

de kjenner vel AMD puste de i nakken og må prøve og komme før de..

 

"It's some Java stuff, some compiler stuff, some graphics stuff – it's a big team"

 

så mange til det??? er nok noen 64 bits prosessorer som skal lages.

[Knick Knack]

Neste generasjon Itanium må vel ha tape out rimelig rett etter at dette teamet er blitt integrert så de rekker vel ikke å gjøre noe med den (Montecito). Det kommer imidlertid det som antadelig er en 65nm versjon av Montecito, menlig Montevale. Den kan de vel muligens få tid til å flikke litt på. Ellers er jo alltids Tukwila i det fjerne (2007). Med Intels planleggingshorisont for IPF så er det vel også på høy tid å starte opp prosjektet for etterfølgeren til Tukwila. Har også hørt at Fujitsu, de som kloner SPARC bedre enn orginalen, skal hjelpe Intel med å optimalisere Itanium for databaser. I det hele tatt er det veldig mange som er inne i dette stormannsgalskapsprosjektet. Digger det!

Endret 25. mai 2004 av Knick Knack

[Vaio]

Intel har hentet inn flere kjente utviklere fra Elbrus MCST. Forholdet har tidligere vært noe anstrengt mellom Elbrus og Intel, som tidligere jobbet med en "Itanium-killer".

 

<a href="http://hardware.no/art.php?artikkelid=7646">Les artikkelen her

Lure på om jeg kan sende en søknad for en jobb som "water boy" hos intel for disse 1000 russiske talende mennesker...

 

Minst 1\3 av må være damer da? Sexy?

[Knick Knack]

Intel Itanium 2 to Get Additional Clock-Speed, Cache

 

"Intel Itanium 2 processors with Madison 9M core are designed for powerful multiprocessor servers and will be available at 1.70GHz, 1.60GHz and 1.50GHz with 9MB, 6MB and 4MB L3 cache respectively. Intel also has plans to roll-out cut-down version of Madison 9M – code-named Fanwood – for dual-processor servers and workstation. Both Fanwood and Madison 9M will use 400MHz processor system bus and will be drop-in compatible with existing infrastructure, sources said."

 

"667MHz PSB to be introduced early next year will be the first bump for Itanium’s bus speed that is likely to give a strong increase in performance of IA64 multi-processor servers. However, even earlier Intel is expected to boost the PSB clock-rate of Itanium 2 processors designed for 2P servers: in Q4 2004 a cut-down flavour of Madison 9M, chip code-named Fanwood, will get a 533MHz Quad Pumped Bus."

 

+masse mer kramgodt intel-hype i den artikkelen

 

Så var det bare å få riktig pris på disse greiene da.

 

Det er i alle fall helt tydelig at IA-64 har begynt å rulle kjappere. Så hadde jeg vært et 26 (?) år gammelt loslitt lappverk av en ISA så hadde jeg begynnt å tenke på pensjonen litt kvikt. Embedded?!

Endret 25. mai 2004 av Knick Knack

[snorreh]

Det er i alle fall helt tydelig at IA-64 har begynt å rulle kjappere. Så hadde jeg vært et 26 (?) år gammelt loslitt lappverk av en ISA så hadde jeg begynnt å tenke på pensjonen litt kvikt. Embedded?!

x86 er et gammelt ISA ja, men med AMD64 så har faktisk AMD klart å rydde opp ganske kraftig i dette instruksjonssettet og det fremstår nå som mer robust enn på veldig lenge (siste opprydding tok Intel seg selv av med IA32). Selv om IA64 er av nyere dato, så bærer den allerede med seg en god del unyttig bagasje som f.eks. integrert støtte for IA32 og PA-RISC instruksjoner med latterlig lav ytelse. Med AMD64 så har x86 fått et realt ansiktsløft, mens IA64 på ingen måte har vist seg å være et reelt alternativ eller noen bedre ISA på noen som helst måte. Med AMD64 så har også behovet for en helt ny ISA mer eller mindre forduftet, så jeg skjønner ikke helt hva du vil frem til?

Endret 25. mai 2004 av snorreh

[sls]

Forholdet har tidligere vært noe anstrengt mellom Elbrus og Intel, som tidligere jobbet med en "Itanium-killer".

 

Hvem/hva peker "som" på? Intel eller Elbrus, eller begge? Mulig jeg er litt kverulant, men synes det er en dårlig strategi av Intel å lage en Itanium-killer...

[Knick Knack]

Det er i alle fall helt tydelig at IA-64 har begynt å rulle kjappere. Så hadde jeg vært et 26 (?) år gammelt loslitt lappverk av en ISA så hadde jeg begynnt å tenke på pensjonen litt kvikt. Embedded?!

x86 er et gammelt ISA ja, men med AMD64 så har faktisk AMD klart å rydde opp ganske kraftig i dette instruksjonssettet og det fremstår nå som mer robust enn på veldig lenge (siste opprydding tok Intel seg selv av med IA32). Selv om IA64 er av nyere dato, så bærer den allerede med seg en god del unyttig bagasje som f.eks. integrert støtte for IA32 og PA-RISC instruksjoner med latterlig lav ytelse. Med AMD64 så har x86 fått et realt ansiktsløft, mens IA64 på ingen måte har vist seg å være et reelt alternativ eller noen bedre ISA på noen som helst måte. Med AMD64 så har også behovet for en helt ny ISA mer eller mindre forduftet, så jeg skjønner ikke helt hva du vil frem til?

Hadde egentlig ikke tenkt å kommentere dette siden det nesten utelukkende er basert på faktafeil, men siden det er søndag og ellers lite å gjøre vil jeg gjerne vise til en link hvor diskusjonen fyker i vei.

 

Itanium 2-powered SGI Altix sets Records

 

Men, bare for å oppklare:

 

*IA64 har ikke støtte for noe som helst annet enn IA64!

*IPF støtter IA64 og IA32 (~3% av die, ikke 33% slik mange tror. Mulig det var rundt 33% for Itanium 1, Merced)

*PA-RISC er så vidt jeg vet ikke støttet av IPF, men de benytter nesten identiske register-register RISC instruksjoner så det er veldig greit å rekompilere PA-RISC til (native) IA64 slik de har gjort med HP-Unix.

 

At IA64 ikke har vist seg å være et bedre ISA enn x86 på noen som helst måte er ikke annet en en humoristisk kommentar. Skal en ha standup show på computex så er sikkert uhemmet prising av de tekniske fordelene med hardware emulering av register-memory CISC en slager!

Endret 6. juni 2004 av Knick Knack

[snorreh]

Hadde egentlig ikke tenkt å kommentere dette siden det nesten utelukkende er basert på faktafeil, men siden det er søndag og ellers lite å gjøre vil jeg gjerne vise til en link hvor diskusjonen fyker i vei.

 

Itanium 2-powered SGI Altix sets Records

Tja, det var ikke mye nyttig informasjon å hente i denne såkalte diskusjonen bortsett fra mye drittslenging fra Itanium-fanatikere så jeg forstår veldig godt at tråden ble stengt

 

Du er vel ikke tilfeldigvis i slekt med Duraid?

 

Men, bare for å oppklare:

*IA64 har ikke støtte for noe som helst annet enn IA64!

*IPF støtter IA64 og IA32 (~3% av die, ikke 33% slik mange tror. Mulig det var rundt 33% for Itanium 1, Merced)

*PA-RISC er så vidt jeg vet ikke støttet av IPF, men de benytter nesten identiske register-register RISC instruksjoner så det er veldig greit å rekompilere PA-RISC til (native) IA64 slik de har gjort med HP-Unix.

Tja, for å bruke en av dine favorittkilder:

http://www.extremetech.com/article2/0,1558,1155606,00.asp

 

"There's one IA-64 instruction that switches the processor to x86 mode and another (newly defined) x86 instruction, JMPE, that switches to IA-64 mode. If the programmer so wishes, interrupts can switch automatically to IA-64 mode or the machine can stay in x86 mode. In the latter case, you can reuse your x86 interrupt handlers.

 

Switching to x86 mode is a lot like booting a '386 because you have to set up memory segment descriptors, status registers, and flags. Also, x86 code likes to have its way with all the resources of the processor, either overwriting or ignoring many of Itanium's state bits and registers. It's also likely to upset your cache contents. In general, it's best to save the entire state of the processor before switching to x86 mode. It's awkward enough that you probably don't want to switch modes willy-nilly. Save it for dramatic changes, such as executing entire x86 applications.

 

Not that anyone was asking, but PA-RISC compatibility is handled offline through a software translator. IA-64 instructions don't directly support PA-RISC instructions, but they do map fairly closely (hey, RISC is RISC). The fact that x86 binaries are emulated in minute detail with enormous helpings of hardware while PA-RISC code is relegated to a translator before it has any hope of running says a lot about the relative importance of these two installed bases. It may also tell us something about the "equal" relationship between the HP and Intel engineers designing IA-64."

 

Jeg kan også legge til at Itanium var spesielt designet for å erstatte PA-RISC så smertefritt som mulig så den bruker samme buss og sokkel som PA-RISC 8700. Videre er IA64 basert på PA-RISC Wide-Word som gjør det enkelt å rekompilere kode for PA-RISC til IA64 (gjennom HP sitt Dynamo-prosjekt), samt at IA64 også har støtte for multimedia-utvidelsene PA-RISC MAX (Multimedia Acceleration eXtension), IA32 MMX og IA32 SSE (ikke SSE2/3).

 

Poenget mitt er at Itanium sitt ISA ikke er så rent som du kanskje tror, for den har med seg mer bagasje enn Intel og HP liker å gi inntrykk av. Det var også poenget til Bob Colwell, som mente at Itanium i sin nåværende versjon kanskje aldri skulle vært lansert...

 

At IA64 ikke har vist seg å være et bedre ISA enn x86 på noen som helst måte er ikke annet en en humoristisk kommentar. Skal en ha standup show på computex så er sikkert uhemmet prising av de tekniske fordelene med hardware emulering av register-memory CISC en slager!

Du må bare le av det, men det var faktisk seriøst ment.

 

Poenget mitt er at man ikke trenger noe nytt ISA nå, med AMD64 så har x86 (IA32) blitt kraftig oppgradert og behovet for IA64 har mer eller mindre forduftet. Hvis du hadde drevet med programmering så ville du visst at et ISA ikke trenger å være vakkert, men funksjonabelt. Til forskjell fra tidligere der man ofte benyttet seg av lavnivå programmering (maskinkode/assembler), så benytter man seg nå til dags hovedsaklig av høynivå programmering (strukturert som f.eks. C++/Java) der valg av ISA har fint lite å si annet enn at det må være god tilgang på kompilatorer og utviklingsverktøy. x86/IA32 er kanskje ikke så veldig vakkert, men det er veldig funksjonabelt og godt støttet i industrien. Med AMD64 så har AMD faktisk gjort en kjempejobb med å rydde opp i mye av rotet med x86/IA32 og oppgradert det tro det eller ei

 

Hovedutfordringene med tanke på best mulig ytelse er ikke lenger bare begrenset av ISA, men vesentlig mer av systemarkitekturen (buss, minne og I/O) man benytter og på dette området er det mye mer å hente vet jeg.

Endret 6. juni 2004 av snorreh

[Knick Knack]

Nei jeg aner ikke hvem Duraid er. Det er selvsagt synd at han ødelegger tråden med sine personangrep. På den andre siden forstår jeg hans frustrasjon over motpartens herlige kompinasjon av påståelighet og total kunnskapsmangel.

 

Jeg vet ikke hvordan eller om du forsto den artikkelen hos extremetech, men det er altså slik at "arve synden" til IA64 koker ned til EN instruksjon! At Itanium har implementert en IA32 modus er imidlertid en design tabbe og det er derfor Intel allerede har påbegynnt arbeidet med å rette opp dette.

 

At Itanium har SIMD instruksjoner er ikke veldig overraskende. Det er faktisk å anse som obligatorisk. Slik det ble obligatorisk med FPU i løpet av 90-tallet. Neste steg på lista over enheter som vil bli obligatorisk for å holde markedsledelse er rekonfigurerbare kretser, om du skulle lure. Også kjent som hypercomputing i dag, men å bruke en hel åker med FPGA kretser fra øverste hyle hos Xilinx er ikke akkurat billig...

 

ISA har tidligere vist seg å ikke spille veldig stor rolle, med noen unntak. f.eks SPARC sitt register system som er et design helvette for hardware designere og nesten ingen fordel for software ingeniører. Videre kan en nevne kompleksiteten til CISC som har gjort at alle CISC baserte ISA untatt x86 har måttet bite i gresset. Som en digresjon; på 9. steget i K8 pipelinen har en ALU & AGU operation scheduling. På neste syklus begynner nyttearbeidet. En likt klokket Itanium 2 ville hatt ferdig resultatet for en syklus siden selv om de har ca samme lengde på den delen som utfører selve nyttearbeidet.

 

Den største grunnen til t IA64 faktisk vil utgjøre en forskjell er at en har forutsett at forsinkelsen mellom CPU og minne relativt sett i forhold til CPU hastighet vil øke i fremtiden. Antagelig i all fremtid. At en også vil ha behov for økende mengder RAM i fremtiden er med på å forsterke denne utviklingen. IA64 er det eneste ISA'et som tar hensyn til denne problemstillingen. Videre tillater EPIC langt større grad av parallellitet enn hva som er teoretisk mulig å oppnå med x86, noe som gjør at økt ytelse i fremtiden ikke nødvendigvis må komme fra økt klokkefrekvens slik det må for x86 og andre rene RISC/CISC systemer.

 

Jeg finner det noe merkelig at du visste at jeg ikke hadde programmert. Selv trodde jeg dette var en del av telematikk utdanningen. Selv teleteknikk har det. Jeg er også nysgjerrig hva jeg gjorde galt da jeg satte mine ben i en Parcal kompilator sommeren for nokså nøyaktig 9 år siden. Programmering var det altså ikke. x86 assembler, VB, C++ (ja ++ delen også), Verilog og VHDL er vist ikke relatert heller.

 

Siden jeg ikke aner hva dette dreier seg om er det merkelig at jeg har så sterk følelse av å vite at en ikke koder mot ISA i rundt rekna 100% av tilfellene og at det faktisk er slik i dag at en designer ISA for at kompilatorene skal ha mest mulig spillerom for å optimalisere. Intel fraråder faktisk assembler koding for IA64. Så stygt er det!

Endret 7. juni 2004 av Knick Knack

[snorreh]

Jeg vet ikke hvordan eller om du forsto den artikkelen hos extremetech, men det er altså slik at "arve synden" til IA64 koker ned til EN instruksjon! At Itanium har implementert en IA32 modus er imidlertid en design tabbe og det er derfor Intel allerede har påbegynnt arbeidet med å rette opp dette.

Det er nok mer rusk i designet av IA64 enn den ene instruksjonen kan jeg forsikre deg om, og den bærer allerede på mye unyttig funksjonalitet som man vanskelig kan fjerne uten å måtte redesigne hele ISA'et. Det vil isåfall bety inkompatible Itanium-prosessorer og det er heller tvilsomt at noe slikt vil skje med det aller første, siden Itanium allerede er hardt nok presset som den er.

 

Som en digresjon; på 9. steget i K8 pipelinen har en ALU & AGU operation scheduling. På neste syklus begynner nyttearbeidet. En likt klokket Itanium 2 ville hatt ferdig resultatet for en syklus siden selv om de har ca samme lengde på den delen som utfører selve nyttearbeidet.

Ja, det stemmer for Opteron "SledgeHammer" men det betyr ikke at det kommer til å være slik for evig og alltid som du prøver å gi inntrykk av. Det har kanskje slått deg at også AMD kan optimalisere K8-kjernen ytterligere i fremtidige revisjoner? AMDs Kevin McGrath har forøvrig uttalt at det vil komme optimaliseringer og forbedringer av K8-kjernen ca. hver 6 måned. Bl.a. følgende nye funksjoner vil snart komme i nye revisjoner, ref. dette:

• 
   
  
• Power reductions
   
  
• Speed improvements
   
  
• Lower power in Halt Stopclock states
   
  
• SSE3 (Prescott New Instructions)
   
  
• Enhanced data prefetch
   
  
• Negative stride, improved page crossing
   
  
• On-Die Thermal Throttling
   
  
• Additional write combining buffers
   
  
• Convert LEA -> ADD
   
  
• DRAM Controller improvements
   
  
• DDR400 managing open pages 2T
   
  

 

Problemstillingen du skisserer vil snart bli utbedret ifølge Kevin McGrath:

http://stanford-online.stanford.edu/course...7-ee380-100.asx

 

"One of the interesting things we just added that is coming out in one of the next revisions. Remember that I was saying that AGU's are used to calculate the effective address for the load store unit? That is a x86 instruction that take the effective address and drop it in the register and that took 2 cycles because we had to feed it from the AGU back up to the ALU to get it into the register. It turns out that more and more compilers are using that instruction as a cheap three input ADD or probably as a three operand ADD so that it dosen't destroy one of the sources. And so what we do is that we went back up into the decoders that you saw and we took a look at the LEA instruction and if it is not one of the three operand forms we transmogrified it from an LEA to an ADD which is a single cycle latency. This is again one of the things that the performance team come and tell us."

 

 

Videre kan en nevne kompleksiteten til CISC som har gjort at alle CISC baserte ISA untatt x86 har måttet bite i gresset.

 

Den største grunnen til at IA64 faktisk vil utgjøre en forskjell er at en har forutsett at forsinkelsen mellom CPU og minne relativt sett i forhold til CPU hastighet vil øke i fremtiden. Antagelig i all fremtid. At en også vil ha behov for økende mengder RAM i fremtiden er med på å forsterke denne utviklingen. IA64 er det eneste ISA'et som tar hensyn til denne problemstillingen. Videre tillater EPIC langt større grad av parallellitet enn hva som er teoretisk mulig å oppnå med x86, noe som gjør at økt ytelse i fremtiden ikke nødvendigvis må komme fra økt klokkefrekvens slik det må for x86 og andre rene RISC/CISC systemer.

Greit nok det, men ingen kan spå for sikkert hva fremtiden vil bringe mhp. valg av systemarkitektur. Det finnes svært få rene RISC/CISC systemer lenger, de aller fleste benytter idag såkalte Superskalare prosessorer (bl.a. P4, K8 og G5). Selv har jeg mer tro på flere eksekveringsenheter (ALU/FPU/SIMD) på disse prosessorene siden det automatisk gir parallelisering, dernest ser jeg frem til flere kjerner i prosessoren. AMD har som kjent satset mye på å ha mange eksekveringsenheter på sine prosessorer, og de skal også komme med flerkjerne-CPU omtrent samtidig med Intel neste år.

 

Hovedproblemet med IA64 iforhold til AMD64 er *PRISEN* på Itanium-systemer iforhold til ytelsen man får igjen. Dessuten er tilgangen på kompilatorer og utviklingsverktøy fortsatt ikke særlig god selv om IA64 har hatt flere års forsprang på AMD64. Intel har lenge prøvd å gjøre Itanium til en industristandard, men har heldigvis ikke lykkes med det. Industrien har valgt x86, og med AMD64 så har dette ISA'et helt klart fått en ny sommer til Intels store ergelse

 

Jeg finner det noe merkelig at du visste at jeg ikke hadde programmert. Selv trodde jeg dette var en del av telematikk utdanningen. Selv teleteknikk har det. Jeg er også nysgjerrig hva jeg gjorde galt da jeg satte mine ben i en Parcal kompilator sommeren for nokså nøyaktig 9 år siden. Programmering var det altså ikke. x86 assembler, VB, C++ (ja ++ delen også), Verilog og VHDL er vist ikke relatert heller.

 

Siden jeg ikke aner hva dette dreier seg om er det merkelig at jeg har så sterk følelse av å vite at  en ikke koder mot ISA i rundt rekna 100% av tilfellene og at det faktisk er slik i dag at en designer ISA for at kompilatorene skal ha mest mulig spillerom for å optimalisere. Intel fraråder faktisk assembler koding for IA64. Så stygt er det!

Fint at du faktisk har programert litt, men det virket ikke slik når du så hardnakket påstod at IA64 var et så rent ISA og at x86 var nærmest ubrukelig i lengden

 

Det er ikke ISA'et, men pris/ytelse som til syvende og sist avgjør fremtiden til en prosessor-familie - noe sjebnen til DEC Alpha så klart demonstrerte. Den gang var det også x86 med Pentium Pro som skapte problemer for Alpha, og slik jeg ser det så gjorde Intel seg selv en bjørnetjeneste da de lanserte P4 omtrent samtidig med Itanium som gav x86 ytterlig støtte. Jeg vet ikke om det var bevist av Intel å gjøre Xeon MP så mye dårligere enn P4 for å gjøre det lettere for Itanium å vinne terreng, men det er jo litt rart å tenke på når vi nå vet at Opteron og AMD64 bare iløpet av 1 år har tatt hele verden med storm uten særlig motstand

Endret 8. juni 2004 av snorreh

[Knick Knack]

Det er nok mer rusk i designet av IA64 enn den ene instruksjonen kan jeg forsikre deg om, og den bærer allerede på mye unyttig funksjonalitet som man vanskelig kan fjerne uten å måtte redesigne hele ISA'et.

*Venter på å bli forsikret om akkurat det*

Listeform er helt greit.

 

Ingen av de punktene du nevnte har noe som helst med den komplekse dekodingen av x86, inkludert "Convert LEA -> ADD". Det den gjør er å videre legge til kompleksitet samt at den detekterer når LEA blir "missbrukt" som ADD slik at en kan gjøre en vanlig ADD og unngå den ekstra forsinkelsen på en syklus. Grunnen til dette "missbruket" er at en ønsker å ta vare på begge input variablene i tillegg til resultatet. Dette får en vanligvis ikke til i x86 siden det er et register-memory ISA. I mer moderne ISA, slik brukt i Alpha, PowerPC, SuperH, SPARC og IA64, har en den tidligere omtalte register-register ISA strukturen som mulig gjør dette for alle typer ALU opperasjoner uten behov for "juks".

 

Selv har jeg mer tro på flere eksekveringsenheter (ALU/FPU/SIMD) på disse prosessorene siden det automatisk gir parallelisering

 

Dette er desverre feil. Du må også ha muligheten til å detektere parallellitet i koden for å vite hvilke instruksjoner som kan eksekveres i parallell. Ellers kan en risikere å eksekvere instruksjoner som er avhengig av hverandre sammtidig, noe som vil medføre feil i eksekverigen. Vel.. det er altids unntak. Har jeg noen gang nevnt IA64?

 

Nå er det selvsagt slik at en kan bygge kretser som detekterer denne parallelliteten, de er forøvrig allerede på plass i alle moderne CPU'er med OoO, men tar også opp noen sykluser i starten av pipen. Unntaket er igjen IA64 hvor dette ikke gjøres ved runtime, men ved compiletime. (denne parallelliteten blir også funnet av x86 kompilatorer, men siden de ikke har noen måte å kommunisere dette på til CPU så blir informasjonen glemt og kompilatoren stabler instruksjonene i den rekkefølgen CPU enklest vil kunne gjennvinne parallelliteten. Dette er forståelig nok svært ineffektivt.

 

Ellers fant jeg noen slider av en normann som er ekspert på IA64. Kanskje du kan kontakte han for å få hjelp med de java kodene du ikke fikk noe fart på i SGI maskina. (må bare lete frem linkene først..)

 

Edit: sikkert masse trykleif her. bruker for tiden TV som skjerm... LCD'en tok kvelden.

 

Link: http://sverre.home.cern.ch/sverre/SJ.html

Endret 9. juni 2004 av Knick Knack

[snorreh]

Knick Knack: Ja, jeg kjenner til Sverre Jarp. De store ytelsesproblemene jeg opplevde med den SGI Altix Itanium2-boksen kan nok ikke bortforklares med dårlige kompilatorer alene for det stemmer nok ikke. Koden ble forøvrig sendt til kompilatorfolkene hos BEA for videre testing, men jeg har ennå til gode å høre noe fra dem med tanke på bedre ytelse. EPIC er derfor slik jeg ser det best på papiret, men langt ifra like imponerende i praksis selv med de siste og beste kompilatorene tilgjengelig. Så inntil videre kjører jeg heller koden på Opteron som gir meg MYE bedre ytelse uten en masse unødvendig og tidkrevende tweaking

Endret 15. juni 2004 av snorreh

[Knick Knack]

Du får gi lyd fra deg om du finner ut hva det var. Jeg skulle likt å vite det.

[snorreh]

Du får gi lyd fra deg om du finner ut hva det var. Jeg skulle likt å vite det.

Her har du det svart på hvitt:

 

http://www.computerweekly.com/articles/art...Search=&nPage=1

Richard Draycott, worldwide director for enterprise servers at Intel, admitted the performance of Java on Itanium was only now “competitive” to Xeon.

 

Bola Rotiba, senior analyst at Ovum, said, “Do not move to Itanium for your application server until the just-in-time compilers are ready.” She said users should look carefully at which applications they plan to deploy on Itanium II as some contain Java, which may not be able to run optimally.

 

"Before you buy 64-bit Intel, understand your system fully. Check where you have Java running," she said. Rotiba said certain applications such as SAP now offer Java interfaces, which could be affected by moving the application onto Itanium. But this problem is not limited to Java. Rotiba said the just-in-time technology used in Microsoft's .net architecture would also run inefficiently on Itanium-based systems.

 

Her concerns are reflected in the latest SpecjAppServer2002 Java benchmarks, in which Bea Weblogic Server 7.0 running on a two-processor HP rx5670 Itanium II server gave a total operations per second (Top) benchmark result of 408.02 at a cost of $1,075.17 (£643) per Top on HP-UX.

 

In comparison, the four-processor Xeon-powered IBM eServer xSeries x360 running Websphere 5.01 on Windows 2000 Advanced server delivered 448 Tops at a cost of $647.52 per Top.

 

Kieran Mockford, architectural software engineer at Microsoft, said a 64-bit just-in-time compiler was being developed for the next release of Visual Studio .net, but did give the release date. He claimed the approach Microsoft is taking would allow applications to run on any of the supported 32-bit and 64-bit systems without modification.

 

The problem with Java on Itanium

 

One problem with running Java on Itanium is the complexity of Intel's Epic 64-bit architecture. Epic expects a program's instructions to be ordered in a way that allows the chip to run several instructions at the same time. When a C or C++ application is converted to an executable program, a compiler converts the source code into machine instructions and optimises the performance for Epic.

 

Unfortunately, the Epic architecture does not lend itself well to just-in-time compilers used for Java because these generate a continuous stream of instructions.

[Knick Knack]

Er ikke dette problemet løst per i dag? Ser artikkelen er fra 2003.

 

Her er en som kun er 11 måneder eldre enn den du linket til.. utviklingen går raskt: How Hardware Features in the Intel Itanium 2 Support .NET and Java

Conclusion

Hardware features that are inherent to the Itanium 2 microarchitecture benefit applications in general, and the managed code in.NET and Java applications in particular. (...)

Det er ikke rart det var problemer med JIT for IPF i begynnelsen. Begge deler bygger på komplisert teknologi og ofte er det stor ytelsesforskjell på implementasjoner med små endringer i slike sammenhenger.

[snorreh]

Nei, ingen Itanium-løsninger kommer i nærheten av Sun Fire V20z med dual Opteron 250 som kjører BEA WebLogic Server 8.1 SP2 med 1,363.88 TOPS (Total Operations Per Second) i resultat til en kostnad på bare 82.74 US$/TOPS:

http://www.spec.org/jAppServer2002/results...0817-00028.html

Endret 4. november 2004 av snorreh

[Knick Knack]

Nei, ingen Itanium-løsninger kommer i nærheten av Sun Fire V20z med dual Opteron 250 som kjører BEA WebLogic Server 8.1 SP2 med 1,363.88 TOPS (Total Operations Per Second) i resultat til en kostnad på bare 82.74 US$/TOPS:

http://www.spec.org/jAppServer2002/results...0817-00028.html

Er SPEC blitt stuerent igjen?

[snorreh]

Nei, men for generell Java-ytelse i BEA på forskjellige plattformer så er SpecjAppServer2002 en grei indikator. Mine egne tester viser akkurat samme trenden, Itanium yter dårlig på Java.

[Knick Knack]

Nei, men for generell Java-ytelse i BEA på forskjellige plattformer så er SpecjAppServer2002 en grei indikator.  Mine egne tester viser akkurat samme trenden, Itanium yter dårlig på Java.

Hvilken trend sa du?

http://www.spec.org/jAppServer2002/results...0914-00030.html

 

Den gamle Itanium 2 1.5GHz prosessoren knuser Opteron 250 med ca 15% her. (Merk det er 1+1 4-way IPF, mot 2 2-way + 1 4-way i det Opteron systemet du linket til.) De nye Itanium 2 prosessorene på 1.6GHz vil jo knuse Opteron 250 noe helt forferdelig. I tillegg har prisen på IPF gått ned i dag. 1.6GHz med 9MB cache har samme pris som den forrige 1.5GHz/6MB prosessoren hadde. Og den nye 1.6GHz/6MB versjonen er mindre enn halvparten så dyr som 9MB versjonen. DP versjonene ligger omtrent på halvparten av dette igjen.

 

Trender er viktige, men denne har snudd! Du må opp hypotetiske Opteron 256 (3GHz eventuelt masse ekstra cache) for å komme ca likt med Itanium 2 1.6GHz 9MB.

Endret 8. november 2004 av Knick Knack