KlaasKersting schrieb:
Die meisten Reviewer testen die Leistung mit dem Höchstleistungsprofil am Strom, aber die Laufzeit unter ausgeglichen oder gar Energiesparen, logischerweise nicht am Strom.
Wie will man das auch anders machen? Es ist relativ sinnlos, die Laufzeit bei Vollast zu testen, weil das in der Praxis irrelevant ist. Unter Dauervollast wird auch ein MacBook Pro nur 2-3 Stunden (oder gar weniger) Laufzeit schaffen. Worüber man sich streiten kann ist, ob die Laufzeittests wirklich immer mit niedriger Helligkeit gemacht werden müssen. Das ist ähnlich realistisch wie Verbrauchstests von Autos mit ausgeschalteter Klimaanlage/Heizung.
DevPandi schrieb:
Bei RISC versucht man sich auf elementare Operatoren zu beschränken, während man bei CISC auf Grund der Lesbarkeit halt auch komplexere Operatoren zulässt.
Wenn Du mit "Lesbarkeit" "Komfort bei der Programmierung in Assembler" meinst, dann stimmt das. In den 70/80ern wurde tatsächlich noch viel Assembler programmiert, und da war der Komfort der ISA tatsächlich ein Argument. Ich erinnere mich noch gut daran, wie die Atari und Amiga Fans den im Vergleich zum 8086 komfortablen Befehlssatz des 68000 hervorgehoben haben. Natürlich haben sie dann trotzdem meist in Basic programmiert
Ein anderer Grund war durchaus auch Codegröße. Damals war Speicher noch knapp und teuer. Deswegen hatte man auch Zwei-Address oder sogar Ein-Address (Akkumulator) Befehle, das sparte Instruction Bits.
Der dritte Grund war das Fehlen leistungsfähiger EDA Tools, das machte den Control Path schwierig zu entwickeln und zu debuggen. Mit Microcode konnte man ein Teil des CPU Designs in Software verlagern, den Microcode konnte man einfach im Simulator debuggen.
Manche Prozessoren wie der Z8000 oder die NS32 Serie hatte vermutlich auch deswegen mit vielen Bugs zu kämpfen, weil man die Design Methoden aus der 8 Bit Zeit auf komplexe 16 und 32 Bit CPUs anwenden wollte.
Eigentlich wäre es richtiger zu sagen, das die ersten RISC CPUs nicht wegen, sondern trotz des reduzierten Befehlssatzes und der fixen Befehlslänge schnell waren.
Man konnte die Chip Fläche, die man sonst für das Microcode ROM und komplexe Befehlsdecoder verwenden musste, für sinnvollere Dinge wie ein großes Register File, Barrel Shifter, usw. einsetzen.
Obendrein waren die CPUs viel einfacher zu designen. Man darf nicht vergessen, das das Team, dass den ARM1 entworfen hat, eigentlich total unerfahren im Prozessordesign war.
DevPandi schrieb:
Leider hält sich auch bis heute - selbst bei Menschen die es theoretisch besser wissen müssten - die Mär, dass RISC sich nur für effiziente und langsame "CPUs" eigenet, während CISC (wegen dem Wort "Complex") ineffizienter wäre, dafür aber deutlich schneller. Oft ist das sogar die Begründung dafür.
Als Seiteneffekt war ARM sehr klein und sparsam, und hat dann, nach zunächst mangelnden Erfolg im Desktop Bereich seinen Sweet Spot in Mobilgeräten gefunden. Daher haftet ARM immer noch der historische Ruf an, zwar sparsam, aber verhältnismäßig langsam zu sein.
Grundsätzlich waren die ersten RISC CPUs massiv schneller als vergleichbare CISC Designs aus der gleichen Zeit (z.B. Motorola 6800xx vs. SPARC/MIPS/PA-RISC/PowerPC). Deswegen sind damals ja die Workstation Hersteller und Apple sehr schnell von Motorola auf die genannten RISC Architekturen gewechselt.
Intel hat dann aber in Folge einfach durch die Unsummen an Geld, dass sie durch die großen Stückzahlen im PC Bereich verdient haben, alle anderen Architekturen überholt.
Apple hat nun bewiesen, dass es grundsätzlich anders geht, und ich denke auch die Snapdragons sind jetzt durchaus nicht schlecht. Ich würde jetzt erst mal abwarten, anscheinend sind sowohl die Geräte, die Software und nun auch die ersten Tests mit der heißen Nadel gestrickt. Ist natürlich schade, dass es scheinbar so "verkackt" wurde, damit wird viel Vertrauen zerstört.
DevPandi schrieb:
Weil bei der ISA (allgemein) hat Apple durchaus einen Punkt, wobei es halt darauf an kommt, was genau gemeint ist.
Soweit ich weiß, unterstützt Apple Silicon nur die 64Bit ARMv8/9 ISA, ARMv7 mit seinen ganzen etwas vermurkst historischen Erweiterungen wurde entfernt. Das kann schon etwas Energie und Chipfläche im Frontend sparen und außerdem erleichtert es die Verifikation, sodass man schneller neue Generationen entwickeln kann.
