R
krümelkacker schrieb:
rapso schrieb:
krümelkacker schrieb:
rapso schrieb:
ach ja, instruction decoding ist kein bottleneck, das war es nicht vor 30jahren als eine cpu 30k transistoren hatte und jetzt mit 2Mrd ist das decoding noch irrelevanter. intel schaltet den decoder sogar ganz ab wenn man in kleinen loops ist udn nutzt pre-decoded ops um die pipeline laenge zu reduzieren.
Ich glaube, da hast du nicht ganz aufgepasst.
das stimmt, doch scho ein langer talk.
Die Jungs wollen Loops beschleunigen. Und dafür wäre es extrem praktisch, viele Instruktionen gleichzeitig dekodieren zu können. Vor 30 Jahren haben CPUs wahrscheinlich nicht 33 Befehle parallel dekodieren wollen sondern immer nur einen. Und selbst heute schafft Intel angeblich nur 4 pro Taktzyklus.
das liegt nicht am koennen, sondern wollen.
Behauptest du mal so.
und hatte erklaert weshalb. ich sehe da jetzt kein gegenargument.
rapso schrieb:
wenn du nur 4 pro takt verarbeiten kannst, weil du 4 einheiten hast, bringt es nichts 5 zu dekodieren.
Das ist klar. Nur kannst du bei dem Design wahrscheinlich schlecht mehr Einheiten einbauen, ohne das Instruction Encoding für eine leichteres, paralleles Decoding zu verändern.
aber arm koennte es und dennoch hat arm, trotz linearer decoding complexitaet in relation zur menge der decodierten instructions/cycle es nicht gemacht. stattdessen investieren sie in jeder generation transistoren um die effizienz zu steigern in richtung der einheitenauslastung.
Die Motivation, mehrere Befehle dekodieren (und natürlich verarbeiten) zu können, wenn ich das vom Vortrag richtig in Erinnerung habe, kommt daher, dass das bei Loops richtig was bringen soll.
nur bei vorhersagbaren loops ohne branches. itanium, der sogar spekulativ mehrere branches gleichzeitig abarbeitet, kann dennoch die effiziens von x86/x64 nicht halten, weshalb keiner mehr drauf setzt. dabei war das das 1st class prestige projekt von intel. da kann man nicht behaupten man haette irgendwas halbherzig gemacht.
rapso schrieb:
das ist nur bedingt so. wenn du schnell decoden willst, kannst du ein RISC encoding verwenden z.b. arm, wo jeder befehl exakt 32bit hat und du somit mit linearem aufwand mehr decoden kannst. aber auch arm decoded nicht mehr als sie einheiten haben.
Ist halt ein Trade-Off. ARM Thumb2 ist beispielsweise wieder ein Mix aus 32- und 16-Bit-Befehlen, weil man sich so Performance und kompakten Code verspricht. Das ist aber nicht für ILP ausgelegt.
Das Thumb effizienter ist, ist etwas komplexer zu erklaeren.
wenn du ARM auf unterseter eben (ohne OS) programmierst, dann legst du Thumb code im ram ab und ARM code im scratch memory. ram ist dann meist mit 16bit angebunden, waehrend das scratch pad (z.b. 32kb "IWRam") mit 32bit. bevor du dann etwas ausfuehrst mit ARM, kopierst du dir den code ins scratch pad, machst du das nicht, braucht jede instruktion aus dem main memory im ARM mode 2 cycles.
ARM ist also eigentlich maechtiger und schneller, da viele instruktionen mehr als nur eine sache machen (z.b. zusaetzlich shift, conditional checks, increment/decrement). aber compiler das nicht so gut ausnutzen. hand geschriebener assembler kann hingegen sehr sehr gut sein, nicht erreichbar mit Thumb.(sogar hand getunter c code, aber da bluten dir die augen).
das ist bei aktuellen handy cpus auch so, zwar ist da ram mit 32bit angebunden, aber die cpus koennen meist 2 instructions dekodieren pro cycle. hast also 2 thumb oder 1 ARM. wenn du hand optimierten code hast und dieser in L1i passt, bist du mit ARM schneller. compiler generierter code aus vanilla source, ist mit thumb schneller (laut ein paar presentationen von ARM selbst).
ARM ist besser hand optimiert oder wenn die bandbreite genau soviel op codes zulaesst wie beim Thumb.
Thumb is besser als ARM wenn compiler generiert.
Thumb widerlegt also quasi deine behauptung. einzelne stupide ops enden beim compilierten code effizienter als wenn der compiler 'smart' sein muss und selbst die triviale ARM ISA ausnutzen soll.
Ich kaufe OOTBC es ab, dass
[list]
[*] ihr Instruction Encoding sowohl zu kompaktem als auch flott dekodierbarem Code führt
bestreite ich nicht, da dasselbe fuer MIPS, ARM, PowerPC auch zutrifft. linearer aufwand fuers dekodieren.
aber man sieht anhand von in-order vs OoO cores, dass OoO mehr leisten. in-order sind effizienter wenn sie trivial arbeiten z.b. ARM mit 3 cycle latenz/instruction und 1instruction/cycle throughput. aber es wird ineffizient wenn du viele instruction/cycle haben willst. mehr als 2 instruction/cycle in-order macht deswegen AFAIK niemand.
(lustig finde ich, dass viele ARM als beispiel fuer effizientes RISC angeben und arm dann Thumb entwickelt was wie Cisc auf op ebene arbeitet und eigentlich total ineffizient sein sollte fuers decodieren :D)