1. Foren
  2. Kommentare
  3. Wissenschaft
  4. Alle Kommentare zum Artikel
  5. › CPU-Architektur: Startup will…

Lahme Gurke

Helft uns, die neuen Foren besser zu machen! Unsere kleine Umfrage dauert nur wenige Sekunden!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Lahme Gurke

    Autor: Tom01 26.05.14 - 14:15

    Das wird doch wieder so eine lahme Gurke.

  2. Re: Lahme Gurke

    Autor: Anonymer Nutzer 26.05.14 - 14:57

    Tom01 schrieb:
    --------------------------------------------------------------------------------
    > Das wird doch wieder so eine lahme Gurke.

    Warum glaubst du das denn? Man wäre heute um einiges weiter und schneller unterwegs, hätten die Verbraucher und Hersteller auf RISC Prozessoren gesetzt. Aber nein es war schwer zu erklären warum ein 400 Mhz RISC CPU genauso schnell war wie ein 700 MHz Pentium III. Das hat der Verbraucher in den 90er nicht verstanden und Microsoft leider auch nicht :( Für Apple war das CPU Geschäft nicht rentabel genug und so starb auch die letzte gute Prozessorfamielie. Bleibt alsonur noch die Hoffnung auf ARM CPUs



    1 mal bearbeitet, zuletzt am 26.05.14 15:00 durch noquarter.

  3. Re: Lahme Gurke

    Autor: QDOS 26.05.14 - 15:00

    noquarter schrieb:
    --------------------------------------------------------------------------------
    > Man wäre heute um einiges weiter und schneller unterwegs, hätten die Verbraucher und Hersteller auf RISC Prozessoren gesetzt.
    Gibt's auch irgendwelche Beweise für die Behauptung, dass RISC schneller wäre als der CISC-RISC-Hybrid von Intel?

  4. Re: Lahme Gurke

    Autor: Schattenwerk 26.05.14 - 15:02

    Naja, intern ist ja jede aktuelle x86-CPU im inneren ein RISC

  5. Re: Lahme Gurke

    Autor: Neutrinoseuche 26.05.14 - 15:05

    Nunja, durch variable Register (per Software) wäre es so das die CPU bei kleineren Befehlen schneller ist als eine CPU mit festen Registern, aber bei langen Befehlen wohl langsamer. Es sei denn das hat keinen Einfluss auf die Verarbeitungsgeschwindigkeit. Dann wäre dieser "Vorteil" nutzlos und höchstens was den Energieverbrauch betrifft relevant.

    Dazu kommt das die Software selbst auch noch Rechenzeit brauchen wird. Die "Verlustleistung" wird hier wohl höher sein als bei bisherigen CPUs. Man müsste ein fertiges Produkt haben um das genau messen zu können.

    Ein Problem wird sich allerdings stellen. Die CPU müsste je nach Einsatzzweck kompatibel zu dem Befehlsatz einer CPU sein für dessen Markbrereich sie gedacht ist wie etwa x86. Wenn sie einen gänzlich neuen Befehlsatz nutzt, wird sie es schwer haben im Markt Akzeptanz zu finden.

  6. Re: Lahme Gurke

    Autor: Schattenwerk 26.05.14 - 15:06

    Nur schwer, weil hier Äpfel mit Birnen verglichen werden.

    Die Performance einer CPU hängt halt nicht nur vom Befehlssatz ab sondern von vielen anderen Faktoren

  7. Re: Lahme Gurke

    Autor: QDOS 26.05.14 - 15:14

    Schattenwerk schrieb:
    --------------------------------------------------------------------------------
    > Nur schwer, weil hier Äpfel mit Birnen verglichen werden.
    In dem Bereich hat sich also seit dem "RISC-CISC-Krieg" nichts geändert :D

    > Die Performance einer CPU hängt halt nicht nur vom Befehlssatz ab sondern
    > von vielen anderen Faktoren
    Ja, z.B. von effizienter Ressourcennutzung (Cache, Vektoreinheiten,…)

  8. Re: Lahme Gurke

    Autor: tunnelblick 26.05.14 - 15:21

    mir gefällt deine ausgefeilte und ausführliche argumentation!

  9. Re: Lahme Gurke

    Autor: pythoneer 26.05.14 - 16:16

    Bestechende Beweisführung – du hast noch das q.e.d. vergessen.

  10. Re: Lahme Gurke

    Autor: DER GORF 26.05.14 - 16:25

    tunnelblick schrieb:
    --------------------------------------------------------------------------------
    > mir gefällt deine ausgefeilte und ausführliche argumentation!

    Aber sowas von! :D

    - Es gibt nichts das eine million Chinesen nicht billiger tun könnten.

    - Alle Verdächtigen sind schuldig, sonst wären sie ja keine Verdächtigen.

  11. Re: Lahme Gurke

    Autor: pfanne 26.05.14 - 16:34

    Neutrinoseuche schrieb:
    --------------------------------------------------------------------------------
    > Nunja, durch variable Register (per Software) wäre es so das die CPU bei
    > kleineren Befehlen schneller ist als eine CPU mit festen Registern, aber
    > bei langen Befehlen wohl langsamer. Es sei denn das hat keinen Einfluss auf
    > die Verarbeitungsgeschwindigkeit. Dann wäre dieser "Vorteil" nutzlos und
    > höchstens was den Energieverbrauch betrifft relevant.
    >
    > Dazu kommt das die Software selbst auch noch Rechenzeit brauchen wird. Die
    > "Verlustleistung" wird hier wohl höher sein als bei bisherigen CPUs. Man
    > müsste ein fertiges Produkt haben um das genau messen zu können.
    >
    > Ein Problem wird sich allerdings stellen. Die CPU müsste je nach
    > Einsatzzweck kompatibel zu dem Befehlsatz einer CPU sein für dessen
    > Markbrereich sie gedacht ist wie etwa x86. Wenn sie einen gänzlich neuen
    > Befehlsatz nutzt, wird sie es schwer haben im Markt Akzeptanz zu finden.

    Die register sind in sofern "variabel groß", dass pro register einfach gemerkt wird wie groß die daten sind die dort herein geschoben wurden und dem entsprechend die passende recheneinheit ausgewählt wird.
    Heißt also, wenn ich in die belt slots b1 und b2 8bit zahlen reingeschoben habe, dann "merkt" sich die cpu das und wenn ich dann später sage "add b1 b2" dann wird automatisch der 8bit adder und nicht der 64bit adder benutzt, was natürlich energie effizienter ist.
    Der Befehlssatz der cpu ist in keinster weise mit x86 kompatibel und wird es auch nie versuchen zu sein.
    Bei der Entwicklung wurde bewusst auf jegliche kompabilität verzichtet um nicht an altlasten gebunden zu sein.

  12. Re: Lahme Gurke

    Autor: floziii 26.05.14 - 16:38

    Wer erinnert sich noch? :)

    https://www.youtube.com/watch?v=w9VWRB07yqc

  13. Re: Lahme Gurke

    Autor: QDOS 26.05.14 - 19:38

    pfanne schrieb:
    --------------------------------------------------------------------------------
    > Heißt also, wenn ich in die belt slots b1 und b2 8bit zahlen reingeschoben
    > habe, dann "merkt" sich die cpu das und wenn ich dann später sage "add b1
    > b2" dann wird automatisch der 8bit adder und nicht der 64bit adder benutzt,
    > was natürlich energie effizienter ist.
    Außer du verwendest C, den da werden beide laut Standard auf INT gecastet (usual arithmetic conversion) und ein Programm welches sich darauf verlässt hat auf einmal massive Probleme…
    zB:

    unsigned char a = 1;
    unsigned char b = 255;

    //decltype(a + b) liefert int!
    auto c = a + b;//c == 256 (INT)

  14. Re: Lahme Gurke

    Autor: QDOS 26.05.14 - 19:42

    floziii schrieb:
    --------------------------------------------------------------------------------
    > Wer erinnert sich noch? :)
    >
    > www.youtube.com
    Ohne jetzt den P4 in Schutz zu nehmen - denke jeder wird mir zustimmen dass das eine Sackgasse war - was war der Benchmark? (und vor allem: war er objektiv^^)

  15. Re: Lahme Gurke

    Autor: pfanne 26.05.14 - 20:41

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > pfanne schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Heißt also, wenn ich in die belt slots b1 und b2 8bit zahlen
    > reingeschoben
    > > habe, dann "merkt" sich die cpu das und wenn ich dann später sage "add
    > b1
    > > b2" dann wird automatisch der 8bit adder und nicht der 64bit adder
    > benutzt,
    > > was natürlich energie effizienter ist.
    > Außer du verwendest C, den da werden beide laut Standard auf INT gecastet
    > (usual arithmetic conversion) und ein Programm welches sich darauf verlässt
    > hat auf einmal massive Probleme…
    > zB:
    >
    > unsigned char a = 1;
    > unsigned char b = 255;
    >
    > //decltype(a + b) liefert int!
    > auto c = a + b;//c == 256 (INT)

    was auf der mill cpu interessanterweise kein problem ist, da es ein add gibt, dass bei überlauf automatisch ein größeres ergebnis ausgibt.
    Das problem, dass du hier aber schilderst ist eigentlich keins, da es sowieso compiler sache ist wie und ob daten gecastet werden.

  16. Re: Lahme Gurke

    Autor: QDOS 26.05.14 - 21:46

    pfanne schrieb:
    --------------------------------------------------------------------------------
    > sowieso compiler sache ist wie und ob daten gecastet werden.
    Also ist es in der Realität dann doch nichts mit? »wenn ich dann später sage "add b1 b2" dann wird automatisch der 8bit adder und nicht der 64bit adder benutzt«

  17. Re: Lahme Gurke

    Autor: pfanne 26.05.14 - 22:41

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > pfanne schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > sowieso compiler sache ist wie und ob daten gecastet werden.
    > Also ist es in der Realität dann doch nichts mit? »wenn ich dann später
    > sage "add b1 b2" dann wird automatisch der 8bit adder und nicht der 64bit
    > adder benutzt«

    wenn du das ergebnis wieder in einer 8bit variable unterbringst wird der compiler clever genug sein vorher nicht alles auf integer hochzucasten.
    und "add b1 b2" war eher ein beispiel für pseudo assembler code.
    wenn ich in c
    uchar a,b,c;
    a = 1;
    b = 2;
    c = a+b;
    schreibe, dann will ich doch hoffen, dass der compiler clever genug ist nicht zwischen durch alles auf integer hochzucasten und das ergebnis dann wieder auf char zu casten.



    1 mal bearbeitet, zuletzt am 26.05.14 22:44 durch pfanne.

  18. Re: Lahme Gurke

    Autor: QDOS 26.05.14 - 22:52

    pfanne schrieb:
    --------------------------------------------------------------------------------
    > wenn du das ergebnis wieder in einer 8bit variable unterbringt wird der
    > compiler clever genug sein vorher nicht alles auf integer hochzucasten.
    Da hat er gar keine Wahl! Diese Konvertierung ist vom Standard explizit vorgegeben! Da das Rechnen in »char« weiters zu einer anderen Semantik (vor allem dann bei signed char -> Overflow bei signed == UNDEFINED BEHAVIOUR) führt, darf die »AS IF«-Regel hier (IMHO) auch nicht angewendet werden!
    Von der Problematik, dass eine Addition von 2 8bit-Werten, 9bit-Werte erzeugen kann und damit im Speicher mindestens 16bit brauchen würde…

    > schreibe, dann will ich doch hoffen, dass der compiler clever genug ist
    > nicht zwischen durch alles auf integer hochzucasten und das ergebnis dann
    > wieder auf char zu casten.
    Machen alle aktuellen CPUs, da es keinen Sinn macht die Register halb/viertel/achtel voll zu laden, wenn man skalar darauf operiert…



    1 mal bearbeitet, zuletzt am 26.05.14 22:55 durch QDOS.

  19. Re: Lahme Gurke

    Autor: pfanne 26.05.14 - 23:26

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > pfanne schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > wenn du das ergebnis wieder in einer 8bit variable unterbringt wird der
    > > compiler clever genug sein vorher nicht alles auf integer hochzucasten.
    > Da hat er gar keine Wahl! Diese Konvertierung ist vom Standard explizit
    > vorgegeben! Da das Rechnen in »char« weiters zu einer anderen Semantik (vor
    > allem dann bei signed char -> Overflow bei signed == UNDEFINED BEHAVIOUR)
    > führt, darf die »AS IF«-Regel hier (IMHO) auch nicht angewendet werden!
    > Von der Problematik, dass eine Addition von 2 8bit-Werten, 9bit-Werte
    > erzeugen kann und damit im Speicher mindestens 16bit brauchen würde…
    Da muss ich dir recht geben. Bin davon ausgegangen, das der cast zurück anders funktioniert.
    > > schreibe, dann will ich doch hoffen, dass der compiler clever genug ist
    > > nicht zwischen durch alles auf integer hochzucasten und das ergebnis
    > dann
    > > wieder auf char zu casten.
    > Machen alle aktuellen CPUs, da es keinen Sinn macht die Register
    > halb/viertel/achtel voll zu laden, wenn man skalar darauf operiert…
    Es kann schon seine Vorteile haben, mit uchars zu rechnen besonders im bereich von Farbwerten, wo 8bit pro Kanal Gang und Gäbe sind.
    Das interessante an der Mill CPU ist, dass es viele addbefehle mit verschiedenen Überlaufverhalten gibt. So gibt es z.B. ein saturated add, dass bei Überlauf den maximalwert des Registers annimmt, so wäre 255+1 dann immer noch 255, was im Bereich von Farbwerten Praktisch.

    Ich muss aber zu dem ganzen sagen, dass die variable größe der Register eher der minimierung der Instructioncodes dient als irgendwelcher Energieeffizienz.
    Wenn die CPU nämlich weiß, wie groß die Daten sind, dann muss in der Instruktion nicht kodiert um welche version es sich nun handelt, was den Instruktionsraum um faktor um ein vielfaches verkleinert, da Register nicht nur 8/16/32/64 bit Daten enthalten können, sondern auch Vektoren von Daten ähnlich zu SSE.
    Was der Golem Artikel vielleicht ein wenig falsch darstellt ist, dass die Energieersparnis nicht etwa durch Variable größe der Register erziehlt wird sondern durch das auslassen von out of order execution. Durch das Design der CPU soll nämlich das Scheduling der Befehle schon zur Compiletime möglich sein.

    Bezüglich der Registergröße und wozu das ganze dient kann ich diesen Talk von einem der Mill CPU designer empfehlen. Ich weiß, dass er relativ lang ist, aber falls weiteres Interesse besteht, kann ich den wärmstens empfehlen.

    http://millcomputing.com/topic/metadata/

  20. Re: Lahme Gurke

    Autor: nie (Golem.de) 27.05.14 - 00:55

    Ein Marketing-Klassiker. Das war 2001, und vier Jahre später wechselte Apple zu x86, weil IBM et al mit dem PowerPC nicht mehr so wirklich konkurrenzfähig waren. Das hatte Konsequenzen, und hier sind nur die dort zitierten Absatzzahlen gemeint:

    https://www.golem.de/0506/38471.html

    Der "Megahertz Myth" (obwohl im Kern korrekt, weil der Takt nur innerhalb der selben Architektur etwas aussagt) ist übrigens eine sehr viel frühere Erfindung von Apple selbst:

    http://en.wikipedia.org/wiki/Megahertz_myth

    Nico Ernst
    Redaktion Golem.de

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Lödige Industries GmbH, Warburg
  2. Helios IT Service GmbH, Berlin-Buch
  3. Bayerische Versorgungskammer, München
  4. AbbVie Deutschland GmbH & Co. KG, Ludwigshafen am Rhein

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme