?
Fast2_unreg schrieb:
wird ernsthaft noch ein Gleitkomma-Koprozessor eingebaut?
jup, FPU bei x86 und VFPU bei ARM, obwohl es SSE/AVX/NEON gibt. wobei das bei intel und amd wohl von den selben einheiten berechnet wird, lediglich die register sind wohl overhead.
Ich fand das Konzept mit VLIW eigentlich ziemlich gut, ich weiß gar nicht, wieso das nicht so gut ankam. Compiler muss man einmal umschreiben. Alle Programme, die dann damit für die neue Plattform übersetzt werden, profitieren automatisch von der theoretisch besseren Leistung (wenn der Prozessor nicht mehr so viel selbst tun muss, müsste das doch eigentlich grundsätzlich in bessere Laufzeiteigenschaften münden)
wo soll ich da nur anfangen
weil VLIW extrem komplex zu compilieren ist. von GPUs her sehe ich, dass eine grosse auslastung der einheiten nie moeglich ist. wenn viel code da ist (und ich meine VIEL), dann kann man den compiler eine stunde beschaeftigen wenn man will, dann hat er etwas was so ca 99% des mit diesem code moeglichen macht und lastet dann vielleicht 60%-80% aus. Dabei muss man als mensch wirklich viel zeit investieren, du kannst dir eine woche den kopf zerbrechen und im vormals vermeintlich perfekten code dann doch noch ein cycle sparen, dabei hast du dann die ganze funktion total ummutiert (weil es so tiefgreifende dependencies gibt). und ich spreche von dingen mit vielleicht 32instruktionen. ein cycle sparen kann bedeuten, dass du viel mehr instruktionen verbaust. ich habe mal eine, port beigebracht mittels maskieren und loads eine 'OR' instruktion zu emulieren, im static code analyser war es dann 8cycles schneller(weil 8x unrolled, danach war ich out of registers), im echten leben war es dann langsammer, weil ich alle VLIW ports ausnutzte, dadurch soviel memory bandbreite zog, dass es nicht mehr fuer den OR-trick reichte (das war eine architektur die automatisch "NOPs" einbaute falls eine instruktion kam die die cpu auf diesem port nicht konnte und dadurch viel bandbreite sparte).
du hast sehr viele limits zu beachten:
-nicht alle einheiten koennen alles, aber viele instruktionen sind mehrfach vorhanden bzw koennen substituiert werden, z.b. koennte eine einheit shiften, eine addieren, eine multiplizieren und du hast 3 wege um "a*=2;" zu machen. eventuell brauchst du (z.b. bei mul) ein temporaeres register mit einer 2. vielleicht ist irgendwo im VLIW eine instruction frei um das zu laden, oder du hast andere instructions frei um die 2 zu erstellen, oder du behaelst, weil du ja sehr viele register wegen VLIW hast, einfach irgendwoe immer eine '2', weil man sie oefter braucht? und das nur wegen einer instruktion!
-du hast eine limitierte bandbreite im chip, wenn du z.b. ein "a=b*c+d;" als instruktion hast, brauchst du 4 verschiedene register, eventuel hast du bei dem VLIW4 ein limit von insgesaamt 8registern, falls die anderen instruktionen schon viele register brauchen, musst du destruktiv "d=b*c+d" sein und d dann, wie im vorherigen punkt, eventuell anders fuer nachfolgende befehle besorgen. oder du schedulest diesen befehl jetzt so, dass er der letzte ist der d braucht, natuerlich kannst du die 3 anderen die damit gepaart waren nicht mit umsortieren, wobei du dann ja wiederrum in einen ganz anderen instruction slot kommst mit ganz neuen limitierungen.
-obwohl VLIW4 4unabhaengige instructions erstellen kann, kann es sein dass manche sich die einheiten teilen, z.b. ist eine division und wurzel funktion auf aenliche operationen angewiesen, aber durchaus mal auf anderen ports implementiert.
weiter siehst du bei einer statischen analyse von programmen, das meistens eine quelle existiert z.b. bei
for(int a=0;Error>0.1;a++)
{
float x=a*a+a..;
}
am anfang des loops ist also meist nur eine instruction nach der anderen am abarbeiten, oft mit dependancies und da VLIWs dazu neigen sehr tiefe pipelines zu haben (jedenfalls die die ich kenne), vergehen da ein paar duzent cycles.
danach ist es oft so dass am ende aus den berechnungen wieder eine reduction stattfindet, bei der viele daten zu wenigen zusammengesetzt werden, z.b.
for(int a=0;Error>0.1;a++)
{
float x=a*a+a..;
.
.
.
Error = sqrtf(fabsf(y-x));
}
auch dabei wird VLIW sehr ineffizient.
der code-flow bricht die optimierungspotentialle, das schlimme ist, dass du wegen VLIW viele register brauchst und an branch stellen ist es selten effizient wie man die verwalten kann.
vom chip her: der decoder ist ein winziger teil, die execution units ziehen 90% vom die und 40% davon hast du quasi umsonst rumliegen. deswegen wurden GPUs auf skalar umgestellt, mit der G80 von NVidia und dem GCN von AMD.
(Intel hat noch VLIW soweit ich weis, mit 128bit pro instruction.)
Leider denke auch ich, dass Intel im Moment keine echte Konkurrenz hat und hoffe, dass sie die Preise zumindest nicht zu übertrieben hoch setzen, denn es hält sie ja eigentlich wenig davon ab (ich brauch dann schätzungsweise im nächsten Monat einen Prozessor und die Preise bewegen sich sogar bei Sandy-Bridge schon wieder nach oben: http://geizhals.at/de/?phist=580328, http://geizhals.at/de/?phist=731595)
So ohne Konkurrenz ist das schon blöd (für den Verbraucher).
ich glaube die preise bleiben relativ gleich ueber die jahre, hab damals meinen quadcore Q9450 fuer ca 300euro gekauft, jetzt bekommst du den besten auch fuer diesen preis. haette intel konkurenz, waeren wir sicher so wie frueher nicht weit von den XEONs entfernt (also 10core) und was mainstream von server unterscheiden wuerde, waere nur die multi socket untersteutzung.
