Jag ser att flera gånger så har det dragits upp frågor om Microsofts, Nintendo och Sony tv-spels processorer, man måste ha klart för sig att dessa processorer är mer eller mindre färdigutvecklade idag; ett TV spel upgraderas inte på samma sätt som en dator gör.
Det kommer förmodligen sitta exakt samma processor i dom PS3:or som släpps 2006 som dom PS3:or som släpps 2010.
Därför måste man vara väldigt förutseende när man gör konsol hårdvara; teknologin måste hålla länge; och framåt slutet så börjar den hårdvaran vara ganska sliten, en PS2 idag är inte speciellt märkvärdig ijämförelse med en modern PC; det var den däremot 1999/2000 när den släpptes.
Men detta är bara en del, anta någon säger varför gör inte dator tillverkare likadant ?
Om nu the cell är så otroligt kraftig som officiella siffror säger ? (256GFlops för cell processorn jämfört med ca 7-8 GFlops för en modern G5)
Problemet med dator processorer är som alltid baklängeskompabilitet, cell kan visserligen köra äldre program; men då är det för det första bara PowerPC delen som kan utnyttjas den är väldigt svag i cell processorn, den är avsedd som kontroller för DSP delarna av processorn snarare än "huvudprocessor", det andra är att PowerPC delen är väldigt strippad och saknar vissa optimeringar som alla "konsument" PowerPCs har, en G5 kan köra program skrivna för G4:an mycket bra, dock inte lika effektivt som G4:an själv, Cell skulle köra dessa väldigt väldigt dåligt för den kan inte reorganisera instruktioner för att fylla pipelinen överhuvudtaget, hastigheten idagens processorer får man ut genom att parallelt bearbeta flera instruktioner, det är där pipelining kommer in i bilden.
Som exempel (väldigt förenklat)
[Instruktionskö]->[Instruktionsavkodning och Bearbetningssteg]
Denna processor tar en instruktion ur instruktionskön, avkodar denna och repeterar sedan processen. Denna processor kan bara behandla en instruktion åt gången, idag är det väldigt få processorer som gör på detta sätt, undantag vissa lågpris "dator på ett chip" processorer (fast även dom kan ha en mer modern metod, AVR processorerna har pipelining har jag för mig.)
en modern processor ser ut mer så här
[Flyttalssteg]
[Instruktionskö]->[Instruktionsväljare] ->[Instruktionsavkodare] <- [Heltalsteg] -> [Kompletteringssteg]
[Vektorsteg]
Denna processor försöker plocka alla flyttals instruktioner den kan från instruktionskön och skicka dessa till fylttalssteget, samtidigt som den försöker hålla heltalssteget igång, och även vektorsteget på dom processorer som hanterar detta. Detta gör att såvida inte instruktionerna är direkt relaterade tillvarandra, alltså måste operera på resultatet av föregående instruktion kan processorn bearbeta flera instruktioner samtidigt, så en heltals instruktion och en flyttalsinstruktion kan tekniskt behandlas samtidigt, på detta sätt får man 200% bättre prestanda helt automatiskt om man skriver programmen på ett relativt smart sätt.
Men även om det inte är helt perfekt skrivet kan processorn tillvissdel optimera underkör tid genom att plocka ur instruktionskön, detta kan inte cell göra på samma sätt, den förväntar sig helt enkelt (som ex.) en heltals instruktion följt av 2 flyttalsinstruktioner helatiden om den inte får det går tex flyttalssteget tom och det är inte svårt att se att om man bara kan hålla ett av stegen aktiva helatiden så blir alltså prestandan endast 33% av en processor som skulle klara detta.
Så säg nu att cell som förnärvarande är klockad 3ghz har jag för mig, skulle vara direkt jämförbar med en G4 hårdvarumässigt, det innebär alltså ett program som inte är perfekt skrivet för cell säg den lyckas hålla 2 steg aktiva hela tiden, skulle endast gå med 66% av hastigheten, vilket om processorerna vore direkt likvärdiga skulle motsvara prestandan av en ca 2.1ghz G4, alltså har man "tappat" 1ghz (nu går det inte räkna exakt så här, men det är väldigt förenklat för att själva grund anledningen ska vara klar
Sedan har cell även en del andra optimeringar som är borttagna (efter som den inte behöver köra "legacy" powerpc kod, finns det ingen anledning att ha kvar dom iallafall) vilket skulle dra ner prestandan yttligare. jag har dock inte sett några exakta data på den här processorn än så hur mycket teoretiskt går inte svara på än, men jag skulle gissa på att hastigheten skulle ligga runt 50-60% av PowerPC delen på cell.
Men som sagt cell handlar mest om DSPerna och dessa kräver special skriven kod, och kan där med inte användas av äldre program iallafall.
(Det är liknande med Playstation 2 faktiskt, den har en MIPS r5900 som kontroller, sedan två vektor enheter; MIPSen själv är föga imponerande, däremot vektor enheterna är riktigt imponerande, även idag. på många saker slår dom lätt altivec och ändå är PS2:ans processor betydligt lägre klockad än dagens PowerPC, men som vi vet prestanda och klockfrekvens är inte direkt relaterade)
Detta är alltså varför PS3, XBox 360 eller Revolution processorerna inte är aktuella eller intressanta för en framtida mac.
----
Sedan håller jag helt med om att det är imponerande hur många runt om på diverse forum skrev med stora bokstäver att man är dum ihuvudet om man tror på rykten att apple skulle gå Intel,
sedan några dagar efter var det hur självklart som helst; och dom som tror på powerpc:n behöver mentalvård.
Att sedan Intel macen är snabbare på många delar är inte alls så konstig, macos x ÄR inte på något sätt PowerPC vänligt på lågnivå idag. däremot är det väldigt mycket optimeringar på högre nivå; speciellt grafiksystemet är riktigt väl optimerat isynnerhet efter Tiger.
Men på systemnivå är det rent av ett under att det går så bra som det gör ändå, "MacOS X är 100% PowerPC nativt" är inte alls sant, som exempel så bygger hela ABI:t på pc relativ addressering vilket PowerPC:n inte hanterar (precis som många andra RISC processorer, så har man ett begränsat antal addresseringsmöjligheter, vilketförövrigt är en av anledningarna till att det just är en RISC processor).
Så man är helt enkelt tvungen att simulera PC relativ addressering, och detta är naturligtvis inte gratis, man får alltså låtsas man hoppar till en funktion sedan kollar man på länk registret för att få aktuell PC, detta skrivs i PowerPC Assembler (tex)
bl func; // bl *+4
func: mflr r3; // mflr r3
det ser inte så kostsamt ut när man bara ser två instruktioner så här, men processorn var aldrig byggd för att uppdatera länkregistret sedan direkt kopiera innehållet till ett annat register, därför orsakar detta ett stall vilket iprincip gör att kombinationen motsvarar ca 3-5 instruktioner beroende på processor.
Det låter igen inte alls så märkvärdigt, men man bör tänka på att detta händer varje gång en funktionanropas, man addresserar en global variabel osv. den som programmerat vet nog att det ganska snabbt summeras till en större summa.
Det går inte säga något exakt värde efter som det beror lite på program till program, men straffet av detta gör att genomsnitts mach-o programmet är ca 15-30% långsammare än exakt samma program i CFM/Pef (vilket var ett filformat gjort specifikt för PowerPC:n)
x86:an däremot (förövrigt är det inte alls konstigt att Mach-O är pc relativt NeXT Step kördes först på 68k processorer (även dom CISC, vilka hade pc relativ addressering); senare även på x86 och samma sak där.
Därmed får Intel MacOS X automatiskt en viss prestanda boost bara av för det här problemet försvinner, och visst är det positivt.
Och bara för att dra en parallel det konstiga var att apple valde att göra detta; och inte skriva om Mach-O ABIt för PowerPC:n vilket visserligen skulle kräva en hel del jobb, men samtidigt skulle systemet tjäna oerhört på det ihelhet. Men istället så valde man att ignorera problemet senare även försöka lösa det genom att lägga till -mdynamic-no-pic till gcc, vilket löser det tillviss del men endast för applikationer, inte för bundles eller frameworks vilka tyvärr alla program i större eller mindre utsträckning; men tillbaka till ämnet: det intressant är att när Motorola släppte sin 68060 (efter följaren till 68040) så valde apple att inte gå på den processorn just av den anledningen den saknade post update instruktioner (har jag för mig), vilka många program utnyttjade väldigt flitigt.
Men som sagt när det var tal om OS X valde man ignorera problemet och "emulera" den saknande funktionaliteten på bekostnad av prestanda. det är lite märkligt tycker jag...
Men samtidigt som sagt swichen är knappast något Apple kom på i våras. Jag läste förövrigt för ett tagsedan en artikel från en föredetta apple anställd som berättade om deras MacOS 7 för Intel projekt, så Apple har nog funderat på detta länge. men samtidigt så känns det som sagt att man slog undan benen på sig själv hela tiden genom att smutskasta x86an.
