Direkte fra Intels press-release ?

Det lyder som noget der kommer direkte ud af Intels press-release, helt uden fakta-check.

Itanium for alle praktiske formål 100% død udenfor computer-cluster segmentet, hvor den har det meget, meget svært, fordi den dybe pipeline næsten er umulig for kodere og compilere at holde fyldt.

Desuden er den naturligvis ikke kompatibel med noget som helst andet, kan ikke købes nogen steder og er alt for dyr hvis man alligevel prøver.

Poul-Henning

Re: Direkte fra Intels press-release ?

Itanium for alle praktiske formål 100% død udenfor computer-cluster segmentet, hvor den har det meget, meget svært, fordi den dybe pipeline næsten er umulig for kodere og compilere at holde fyldt.

Re: Re: Direkte fra Intels press-release ?

Antallet af states i pipelines betyder stort set ikke noget. Normalt kan processoren forudsé de efterfølgende indstruktioner mange states frem - hvis den er ordentligt lavet. Allerede ved fetching ind i cachen, har den mulighed for at analysere de følgende indstruktioner, jumps osv. og derved optimere i den rette jump retning. Det mest normale er jumps, ved branches mv. men skulle det vise sig flere gange at ikke være jumps, skiftes koden ud dynamisk.

Det største problem, og flaskehalsen, er normalt anvendelse af indexeret ram. Bruges ikke indexeret ram (konstant addresse), kan det direkte analyseres og forwardes. Indexerede addresser, tager ikke tid ved skrivning, hvor de kan buffres, men ved læsning kræves hele cachen/lagerets accesstid, før data kan læses ud. Det eneste CPU'en kan gøre, er at søge at flytte udregningen af index addressen så højt op som muligt, og at begynde opslaget, allerede på tidspunktet hvor index registeret er udregnet.

At udføre CPU indstruktioner med en rivende hastighed, er intet problem. Problemerne ligger alene i brugen og adgang til ram lager - og her kan man skele til, hvordan moderne compilere fungerer. I dag, skal computere ikke fungere hurtigt når koden skrives i maskinsprog - men når den gennereres af compilere, og man kan diskutere om de burde udføre et højniveau bitnært niveau mere direkte.

I forbindelse med brugen af stak, skal man også tænke på, at eliminere stak kald, samt indsætte koden direkte, da return indstruktionen er sløv. Call indstruktionen, tager dog ikke tid (0 cycles). I forbindelse med fetch af cache, indsættes indstruktioner direkte ved jump, branch, og calls.

Som nævnt, betyder antallet af states ikke noget. Et lille trick, er at folde konstruktionerne ud, således noget der tager to states, udføres på kun éen states. Der samles altså to indstruktioner, i éen. Denne process, kan gøres i mange tilfælde, og specielt nem i CPU konstruktioner. Reelt betyder det, at indstruktionerne kan opfattes både som høj hastighed, og mange states - eller lav hastighed og få states, og dette er fuldstændigt dualt. En realisering af sidste, kan give højere hastighed, hvis der anvendes en asynkron VLIW CPU, der giver besked om, hvornår resultatet foreligger. Igen, er problemet alene et spørgsmål, om indexeret ram. Alt andet, kan "forwardes".

Det værste problem ved Intels CPU'er, er deres lighed med moderne software. De fylder en masse, og yder lidt i forhold til antallet af transistorer.