Test Apple vs. AMD & Intel im Test: Der M4 Pro im Vergleich zu Ryzen 9000 und Core Ultra 200S

Und wieso sind macs und apple in spielen und realen Anwendungen dann so weit hinten? Richtig weil sie keine befehle können und nicht Universal sind wie Prozessoren von amd und intel die gefühlt jedes Programm dieser welt laufen lassen können bei relativ guter performance während die m reihe von apple schon alleine viele befehle einfach von grund auf nicht beherrscht. Also schon mal so aus Prinzip ist es so: wenn weniger schaltkreise, dann weniger stromverbrauch auch.
 
Nolag schrieb:
Der CCD des 9800X3D besitzt 8,3 Milliarden Transistoren + V-Cache. Dazu kommt noch der IOD mit 3,4 Milliarden Transistoren. Bei der Desktop CPU fehlt die größere GPU und die NPU. Eine AMD APU mit 8 Cores hat auch zwischen 25 und 34 Milliarden Transistoren.

Eine AMD APU wie Strix Point besitzt sogar 34 Milliarden Transistoren. Die ist dann also noch "aufgeblasener"?
Strix Point hat eine NPU und dazu eine GPU auf AddIn-Niveau. Apple hat NULL NPU-Transistoren und wenn Du die GPU vergleiche magst muss der M4 Max herhalten, nicht der Pro.
Apple spendiert den CPU-Cores deutlich mehr Transistoren als die Mitbewerber - das ist eine Designentscheidung bei Apple welche für bestimmte Dinge gut ist. Für andere ist es egal, da treibt es nur den Preis. Manchmal ist die M4-Reihe dadurch eben sehr gut, manchmal nicht. Muss man auf den Anwendungsfall hin betrachten.
Ergänzung ()

Haggis schrieb:
Im Übrigen hat der M4pro auch nicht "14 vollwertige Kerne" sondern 10 P-Cores und 4 E-Cores.
Ist das jetzt ein Kompliment für Apple dass sie sich dazu entschieden haben ihren Kunden halbe CPU-Kerne als "echte" CPU-Kerne zu verkaufen?
Ich meine, E-Cores sind nun mal exakt das: es wird Material gespart und gerade weil nicht jede Software auf beliebig viele threads aufgeteilt werden kann wäre es evtl besser gewesen man würde mit den Transistoren der 4 E-Cores lieber zwei P-Cores bauen. Ist dann halt nur ein 12-Kerner.
Stromsparender sind E-Cores auch nicht weil man große Kerne auch niedrig takten oder schneller in den deep sleep schicken kann wenn sie mit ihrer Arbeit fertig sind. Dass das geht zeigt ARM im Android-Lager, da fliegen die E-Cores ja gerade aus den flagship-SoCs raus. Und anders herum hat Intel jetzt E-Cores die sich von der Leistung her wunderbar mit den P-Cores der M2-M3-Generation messen können.
Insofern... sind Namen wie "E-Cores" halt nur Namen. Schubladen. Und als solche nicht aussagekräftig für "Effizienz". Es sind halt universell einfach kleinere Kerne welche weniger Transistoren bekommen und dennoch einen vollwertigen thread abarbeiten sollen. Dann eben mit weniger Leistung.
 
Zuletzt bearbeitet:
Glendon schrieb:
Kann man so sehen. Aber man kann es auch anders sehen. Es war eine Entscheidung des Herstellers, die CPU so zu begrenzen. Wenn man einen FIAT Panda gegen einen F1 Wagen im Beschleuningunstest antreten lässt, würde wohl auch niemand argumentieren, dass der F1 Wagen eigentlich schneller ist, aber der Panda ja im Vergleich weniger verbraucht und deshalb (in der Beschleunigung) nicht der eindeutige Verlierer sei.
Nur ist das hier nicht ein Fiat Panda. Sonder ein Porsch 911. Und der schlägt den F1 in allen Bereichen außer bei der “Spitzengeschwindigkeit”.

Die braucht niemand. Gerade Compiler und Spiele brauchen was? Den permanenten Basistakt. Und niedrigen Energieverbrauch. Das MacBook Air ist das Brot und Buttermodell von Apple. Passiv gekühlt, somit leise und langlebig und mit langer Akkulaufzeit.

Die Spitzenleistung ist der Grund warum Intel in bedrohliche Lage geraten ist. Die haben doch 30 Jahre lang Geld gemacht, weil man sich in der Presse dafür das Lob holen kann. Damit man das Zeug darunter verkaufen kann! Die paar High-End CPUs sind eigentlich unwichtig, ausser für die Reputation und somit Umsatz/Gewinn.

Intel hat in den 90ern beschlossen, dass es “in Ordnung” ist eine schlechte Energieeffizienz zu haben und Lüfter verbaut. Ist es nicht. War es nie.

AMD ist bei Designs, dreimal (Thunderbird, Athlon 64 und Zen) an Intel vorbei gezogen. TSMC bei der Fertigung. Allein schon ein ein kompletter Wandel. Apple hat aus ARM eine leistungsfähiges Design gemacht. Wieder mit TSMC. Fehlt nur noch RISC-V. Würde mir wünschen, das Qualcomm lernt. RISC-V adaptiert und mit Linux anfreundet. Da könnte Qualcomm abräumen. Der Microsoft-Deal war ein Debakel, weil man unbedingt den großen Markt habe wollte, statt kleiner Brötchen mit Linux und ARM zu backen und dann zu wachsen. Die Atheroschips sind unter Linux weiterhin der Goldstandard. Und wenn Qualcomm das nicht auf die Reihe bekommt, AMD wird nicht zögern?

PS: So toll die CPUs von Apple sind. Mit einem ThinkPad (AMD), bekommt man hervorragende Tastaturen, offizielle Linuxzertifizierung, Magnesium statt Aluminium, und kann die nativen Ports von Counter-Strike und Steam ausführen. Das größte Problem der M-Prozessoren sind die Macs, mit schlechter Tastatur und macOS.
 
Zuletzt bearbeitet:
Cool Master schrieb:
Richtig und genau das sagte ich im ursprünglichen Beitrag ja mit:

ARM = Skalpell
x86 = Schweizertaschenmesser

x86 hat viel mehr Erweiterungen und ist daher eben das Schweizertaschenmesser das alles kann wohingegen ARM eben auf die Anwendung zugeschnitten ist.

Nein, das sagst Du eben nicht. Du wirfst Begriffe wie CISC, RISC, Instruction Set-Erweiterungen usw. in einen Fleischwolf und ziehst daraus falsche Schlüsse.

CISC kann mehrere mit einem Befehl mehrere Dinge erledigen. Einfaches Beispiel: die Werte zweier Speicher-Adressen multiplizieren und das Ergebnis in eine weitere Adresse schreiben. Das ist schneller, weil es innerhalb eines Cycles passieren kann, aber es hat seinen Preis: mehr Transistoren, mehr Energie bzw. Abwärme.

In der Praxis hat sich rausgestellt, das ein sehr umfangreiches Instruction Set wie x86 viel zu viele Befehle hat, die nur sehr selten oder auch gar nicht genutzt werden. Daher kam den in den 80ern die Idee zu RISC auf. Ein reduziertes Instruction Set, jeder Befehl tut nur eines. Damit verlagert man die Komplexität in den Compiler, also aus der Hardware in Software und kann so auch besser optimieren.

Seit den 90ern ist aber CISC bei x86 nur noch eine Fassade. Die eigentliche CPU arbeitet ganz anders, eben Superscalar mit Pipelines, also teils paralleler und spekulativer Ausführung bzw. sogar Ausführung der Befehle entgegen ihrer Reihenfolge. Dabei nimmt die CPU Befehle an und zerlegt alles in sog. Micro Ops, die dann optimiert ausgeführt werden können. Einiges kann parallel laufen, weil es voneinander unäbhängig ist, bei anderen wird quasi geraten und schon mal ausgeführt, teilweise wird auch die eigentliche Reihenfolge geändert, weil es effizienter ist.

Das alles hat erstmal überhaupt nichts mit Erweiterungen des Instruction Sets zu tun und auch nicht, ob eine CPU nun General Purpose ist oder nicht. General Purpose sagt nur, dass eine CPU grundsätzlich alles berechnen kann und das trifft auf x86 wie ARM zu. Beide können problemlos ein OS ausführen. Mit den Erweiterungen können bestimmte schneller erledigt werden, wie z.B. Vektor-Berechnungen mit AVX, weil die zusätzlichen Befehle den Zugriff auf spezialisierte Teile der CPU ermöglichen, die Vektoren schneller berechnen können, als die normalen Rechenwerke.

Daher greift auch Dein Vergleich mit den Messern funktioniert nicht, weil es mit CISC und der RISC nichts zu tun hat bzw. genauso wenig x86 vs. ARM: man kann problemlos ein CISC Instruction Set entwerfen, das nur Videos encoden kann. Oder versuch mal im Umkehrschluss ein OS auf einer NPU auszuführen.

Der aktuelle Unterschied zwischen CISC und RISC: bei RISC sind normalerweise keine Micro Ops im Spiel (es gibt Ausnahmen), weil die Befehle eine 1:1-Beziehung haben, also ein Befehl ist i.d.R. auch innerhalb der CPU nur ein Befehl. Dennoch gibt's genauso optimierte Execution Pipelines mit den og. Techniken wie Speculative Execution.

Was mit den einzelnen Instructions gemacht wird, ist dabei völlig wurscht. ARM hat diverse Basis-Befehle, die allen ARM-CPUs mit der entsprechenden Spezifikation unterstützen. Darüber hinaus kann man den Befehlssatz auch einfach erweitern, wie's z.B. Apple für Video Encoding etc. gemacht hat, aber das ist kein Grund, ARM abzusprechen, dass es General Purpose-CPUs wären. Es gibt ein paar sehr reduzierte und spezialisierte ARM-Versionen, aber das hat nichts mit den ARM-CPUs zu tun, die in Smartphones und Rechnern verbaut werden. Dabei spielt es auch keine Rolle, ob die CPU nun von Qualcomm, Apple, Samsung oder Ampere stammt. Die Dinger können die essenziellen Dinge und eben noch mehr, wie Video Encoding, AI-Beschleunigung usw. -- genauso wie ihre x86-Konkurrenz.

btw: PowerPC/POWER, SPARC etc. sind auch alles RISC ISAs.
Ergänzung ()

ComputerJunge schrieb:
Gibt es eigentlich einigermaßen aktuelle Zahlen, was bei x86/64 das reine Decoding von der ISA auf die µOps an Performance kostet? Wäre - im Vergleich zu ARM - 1-2% eine realistische Größenordnung?

Ich hab keine aktuelle Zahlen, aber so vor gut zehn Jahren, hieß es mal, dass der Overhead durchaus um die 10% betragen kann. Die Decoder müssen ja x86-Befehle mit variabler Länge verarbeiten und das ist wohl nicht ohne. Allerdings hat sich in den letzten Jahren viel getan, also könnte ich mir vorstellen, dass die modernen Decoder deutlich effizienter arbeiten und der Overhead entsprechend sinkt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Scie, ErichH., piccolo85 und 4 andere
Wenn man hier so die Beiträge ließt, erkennt man gleich wer etwas über CPU Architekturen gelernt hat und wer nicht. Gaming-Kids die nur x86 kennen, kann man schonmal ignorieren.
Egal zu welcher Zeit: x86 CPUs waren schon immer langsamer als die jeweils vergleichbaren Power-PC, Sun Sparc oder andere RISC, MISC Architekturen.

Der einzige Grund warum sich x86 so stark verbreitet hat ist: Es war billig, Entwicklerfreundlich und somit gut als "zu Hause PC" geeignet. Dann kam noch DOS und Windows und die Geschichte nahm ihren lauf. x86 wurde weiterentwickelt und dadurch auch immer billiger, alle anderen Architekturen hingegen nicht. Diese waren hauptsächlich im Server-Bereich zu finden und damit nicht verbreitet genug.

Mit dem aufkommen von Smartphones wurde schnell klar: hier hilft x86 nicht weiter. Die CPU, die Plattform... Alles zu groß und viel zu ineffizient.
Und kaum fließt endlich wieder das nötige Geld in die Entwicklung von nicht-x86 CPUs zeigt sich: x86 war Dreck, ist Dreck und wird immer Dreck bleiben. Ich möchte gar nicht wissen wo wir heute sein könnten, wenn genausoviel Geld in die RISC, MISC Entwicklung geflossen wäre, wie es für x86 versenkt wurde. x86 gehört abgeschafft. Je früher desto besser.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sioh, prayhe, bodd und 2 andere
Supra77 schrieb:
Und wieso sind macs und apple in spielen und realen Anwendungen dann so weit hinten? Richtig weil sie keine befehle können und nicht Universal sind wie Prozessoren von amd und intel die gefühlt jedes Programm dieser welt laufen lassen können bei relativ guter performance während die m reihe von apple schon alleine viele befehle einfach von grund auf nicht beherrscht. Also schon mal so aus Prinzip ist es so: wenn weniger schaltkreise, dann weniger stromverbrauch auch.

Ach, wo sind den Macs in realen Anwendungen soweit hinten? Wieso haben vor vier Jahren selbst die kleinsten M1 MacBook Air die besten Intel-MacBooks versenkt? Hab ich mir die deutlich bessere Leistung des JVM Compilers auf dem M1 nur eingebildet? Überraschung, dafür braucht's normale Rechenwerke, keine Video Encoder in Hardware.

Hört endlich auf zu sagen, dass ARM-CPUs keine General Purpose-CPUs sind. Das ist kompletter Unfug, wie ich nun schon mehrfach in längeren Posts erklärt hab. Wenn ARM in der Hinsicht so scheiße ist, wieso gibt's dann CPUs wie Altra-Reihe von Ampere oder andere Server-CPUs?

Aus meiner Berufspraxis als Software-Entwickler: ich arbeite nun seit 15 Jahren mit Macs, davon anfangs noch ein PowerBook, danach immer MacBook Pro (und privat das og. Air). Alle drei Jahre darf ich über die IT-Abteilung meiner Firma ein neues bestellen. Bisher habe ich diesem Termin immer entgegengefiebert, weil mir die Kisten chronisch zu langsam waren, zu viel Strom gesoffen haben und damit auch laut.

Nun sind die drei Jahre für mein 16" MacBook Pro (M1 Pro, 32 GB) um. Es ist das erste mal, dass ich nicht sehnsüchtig neue Hardware will. Der M1 Pro ist immer noch schnell genug für alles, was ich brauche und dazu zählt eben nicht die Hardware-Beschleunigung für Video Encoding, die Neural Engine etc, sondern rein die stink normale CPU-Leistung.
 
  • Gefällt mir
Reaktionen: sioh, prayhe, Haggis und 6 andere
Der M4 ist eine Wucht und im neuen Mac Mini in der Basiskonfiguration auch super erschwinglich. Leider wird das ganze aber schnell unattraktiv wenn man mehr RAM braucht:

Mac Mini M4 512GB SSD 32GB RAM: 1389€
Mac Mini M4 Pro 512GB SSD 64GB RAM: 2339€

Dann ist man eben mit einem Intel/AMD System doch besser beraten.
 
  • Gefällt mir
Reaktionen: x37
Brand10 schrieb:
Der einzige Grund warum sich x86 so stark verbreitet hat ist: Es war billig, Entwicklerfreundlich und somit gut als "zu Hause PC" geeignet.
Falsch. Der primäre Grund ist, dass IBM damals mit dem PC "verwachst" hat und aus Versehen eine offene Architektur (nicht auf die CPU bezogen, sondern das ganze PC-Ökosystem) geschaffen hat, bei der jeder mitmischen kann, was dazu geführt hat, dass Systeme so personalisierbar sind, wie sie es heute sind.
Dazu gibt es kein CPU-Monopol, sondern ein Duopol, weil Intel und AMD sich gegenseitig an den Eiern haben.

Die Fehler, die diese Situation geschaffen haben, wird nie wieder jemand machen.
Mit einer anderen Architektur werden wir es vermutlich nie erleben, dass man ein paar Teile aus einer riesigen Bandbreite an Herstellern zusammensteckt und dann da einfach einen Bootstick reinsteckt, der auch auf einem 15 Jahre älterem Laptop irgendeines Herstellers läuft.

Deswegen glaube ich übrigens auch nicht an Windows on Arm. Dass Apple sein eigens Süppchen kochen, ist man gewöhnt. Dass die von mir genannten Dinge in der Windows-Welt mit Arm wegfallen, ist ne ganz andere Nummer.


Brand10 schrieb:
Mit dem aufkommen von Smartphones wurde aber schnell klar: hier hilft x86 nicht weiter. Die CPU, die Plattform... Alles zu groß und viel zu ineffizient.
[..]
Ich möchte gar nicht wissen wo wir heute sein könnten, wenn genausoviel Geld in die RISC, MISC Entwicklung geflossen wäre, wie es für x86 versenkt wurde. x86 gehört abgeschafft. Je früher desto besser.
Dem "zu groß und ineffizient" werden wir uns mit Arm auch irgendwann nähern, wenn auch vermutlich langsamer. Hier wird ja gern von "alten Zöpfen" gesprochen, die gibt es in Arm auch mehr und mehr.
Auch Arm ist bald 40 Jahre alt und auch der Befehlssatz wurde immer wieder erweitert. Unter anderem deswegen (jaja, auch Lizenzen usw) kommt mit RISC-V schon "der neue heiße Scheiß" um die Ecke, der aber ebenfalls irgendwann mal das Problem haben wird, das x86 hat und langsam auch Arm.
Was ich sagen will: So argumentiert müssten wir wahrscheinlich alle 10-20 Jahre ne komplett neue Architektur aus dem Boden stampfen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ErichH.
Piktogramm schrieb:
Handbrake ist ein Wrapper für ffmpeg und solang man ffmpeg nicht die Parameter setzt Hardwarebeschleunigung zu nutzen, versucht es ffmpeg auch nicht.
Das dies bei Handbrake für X64 so der Fall ist weiß ich. Da ich selbst keinen M Mac hab, weiß ich eben nicht, wie Handbrake für MacOS (M SoCs) sich hier verhält. Laut Dokumentation von Handbrake gibt's es wohl auch GPU Beschleunigung (separat von ASICs) für Enkodierung, aber ob die automatisch eingesetzt wird oder nicht weiß ich auch nicht. Allerdings wäre es IMHO ja eine Stärke von Apple SoCs wenn sie ihre GPU Kerne auch hierfür mit heranziehen können (im Sinn von assist, nicht anstatt), solange die Qualität der Videos dieselbe ist.

Unabhängig von alledem sind die CPU Kerne der Apple M SoCs zweifellos hocheffizient und sehr leistungsfähig.
 
Supra77 schrieb:
Richtig weil sie keine befehle können und nicht Universal sind wie Prozessoren von amd und intel die gefühlt jedes Programm dieser welt laufen lassen können bei relativ guter performance während die m reihe von apple schon alleine viele befehle einfach von grund auf nicht beherrscht.
Soso… welche Befehle sollen dass denn sein, die die x86 ISA beherrscht, für die es kein funktionales Äquivalent auf ARMv8/v9 gibt?

MadCat[me] schrieb:
CISC kann mehrere mit einem Befehl mehrere Dinge erledigen. Einfaches Beispiel: die Werte zweier Speicher-Adressen multiplizieren und das Ergebnis in eine weitere Adresse schreiben. Das ist schneller, weil es innerhalb eines Cycles passieren kann, aber es hat seinen Preis: mehr Transistoren, mehr Energie bzw. Abwärme.
Keine CPU kann eine Memory to Memory Operation in einem Zyklus erledigen. Dafür braucht es immer mehrere. Klassische CISC Mikroarchitekturen wie z.b. die ersten x86 CPUs haben das z.B. mit Mikrocode dann wirklich in mehreren Zyklen erledigt. Ich habe hier noch ein altes Buch mit dem 8086 Befehlssatz rumliegen wo auch die Anzahl der Taktzyklen beisteht. Der 8086 hat z.B. da locker zweistellige Anzahl von Taktzyklen für manche Befehle gebraucht.Ab dem 286 wurde dann wenigstens die Adressberechnng (sowas wie mov ax, [bp+offset]) in Hardware gemacht, sodass man für das Berechnen der "effektiven Adresse" nur noch einen Takt brauchte.

Auch eine pipelined CPU braucht für die meisten Instruktionen mehrere Takte, nur durch die Pipeline kann man halt an mehrere Instruktionen gleichzeitig arbeiten und erreicht dadurch einen höheren Durchsatz. Selbst eine klassische, singe-issue in-order Pipeline hat im Idealfall so viele Befehle in Arbeit wie es Pipeline Stufen gibt.

Der Grund für die Erfindung von RISC war nicht, dass CISC grundsätzlich langsam ist, sondern, dass mit den Mitteln die man in den 80er Jahren hatte CISC nicht performanter zu realisieren war. Weder bekam man genügend Transistoren auf einem Chip unter, noch hatte man die Tools so komplexe Schaltungen zu entwerfen. Also speckte man den Befehlssatz radikal ab, brauchte auch keinen Microcode mehr und konnte die gesparte Chipfläche für ein größeres Registerfile und mehrere Pipeline Stufen verwenden.

Mit den heutigen Mitteln machen, zumindest bei Full Featured Application CPUs, RISC und CISC keinen Unterschied mehr. Im Prinzip hat man den Microcode-Interpreter früher CPUs durch einen Microcode-"Compiler" ersetzt, der aus den ISA Befehlen interne MicroOps macht, die die Pipeline ausführen kann. Durch Register-renaming ist es auch egal wie viele Register die ISA hat.

ARM ist auch eine recht verwässerte RISC-ISA, sie hat etliche Befehle (z.B Multi-Register Push/Pop) die eigentlich typisch CISC sind. Genauso sind die meisten x86 ISA Befehle auch nicht anders als RISC Befehle. Und die ganzen Erweiterungen wie Vektor sind ja auch hochkomplexe, spezialisierte Befehle, die eigentlich typisch CISC sind.
Der Unterschied zu früher ist: Heute weiß man welche Befehle wirklich was nützen, und baut nur diese ein. In der Frühzeit der Computer hat man sich eher danach gerichtet, dass sich Assembler Programmierer wohlfühlen...

Grundsätzlich gilt: Nicht eine ISA ist langsam oder schnell, sondern die Mikoarchitektur,
die sie implementiert.

Hier hat sich ARM sehr lange auf sparsame, kleine Designs für mobile Geräte fokusiert, daher der Ruf das ARM langsamer als x86 ist.

MadCat[me] schrieb:
Ich hab keine aktuelle Zahlen, aber so vor gut zehn Jahren, hieß es mal, dass der Overhead durchaus um die 10% betragen kann.
Der x86 Decoder kostet heute vermutlich einfach nur etwas mehr Fläche und Energie im Frontend. Auf die Leistung wird er keine Auswirkung haben.

Brand10 schrieb:
Egal zu welcher Zeit: x86 CPUs waren schon immer langsamer als die jeweils vergleichbaren Power-PC, Sun Sparc oder andere RISC, MISC Architekturen.
Das stimmt so nicht. In den 80ern und frühen 90ern haben die RISC Architekturen aus den oben genannten Gründen die CISC Designs wie x86 und m68k und auch VAX sehr schnell überholt. Dass hat den meisten CISC Designs den Todesstoss versetzt, nur Intel und IBM (Großrechner...) haben aus sehr verschiedenen Gründen überlebt. Aber mit zunehmender Integrationsdichte und besseren Werkzeugen (EDA) schmolzen die prinzipiellen Vorteile von RISC dahin. Und da hatte Intel einfach neben fähigen Personal auch einfach die tieferen Taschen und hat die ganzen RISC Architekturen überholen können. Mit Windows NT gab es auch dann ein Betriebsystem das von den Fähigkeiten und der Stabilität mit den Workstation Betriebsystemen von Sun oder SGI vergleichbar war.
Apple ist auch nicht zum Spaß von PowerPC auf Intel gewechselt.

Erst seit dem Apple M1 gibt es jetzt wieder eine "RISC" Implementierung die es mit Intel und AMD aufnehmen kann. Und das liegt weniger daran, dass es RISC ist, sondern daran, dass Apple einfach gute Arbeit geleistet hat.
Ergänzung ()

pseudopseudonym schrieb:
Hier wird ja gern von "alten Zöpfen" gesprochen, die gibt es in Arm auch mehr und mehr.
Bei ARM gibt es immerhin mittlerweile 64 Bit Only Designs, die also kein ARMv7 mehr ausführen können. Und ARMv8 hat den Wildwuchs an verschiedenen Floating-Point Eweiterungen aufgeräumt.

Bei x86 könnte man z.B. den 16 Bit Protected Mode auch einfach streichen. Bringt vermutlich nicht wirklich viel, macht vermutlich höchstens den Ingenieuren in der Verifikationabteilung das Leben leichter.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sioh, prayhe, iron_monkey und 2 andere
Fahre privat zwei gleisig und habe ein Mac Book Air M1 und ein Dell Latitude 7390. Habe gestern unserer HR Leiterin ein Lenovo L13 Yoga mit Zen 3+ hingestellt. Für das Geld auf jeden Fall auch kein schlechtes Gerät.
 
Land_Kind schrieb:
Seit wie lange baut Apple CPUs? Und wie lange die 86er-Konkurrenz? Hallo AMD und Intel? Nehmt mal eure F.... aus den H...!

Apple hat seit über 15jahren erfahrung mit dem designen von cpu‘s. Und das im bereich low energie. Es gibt Riesige unterschiede zwischen Intel/ AMD und Apple. Apple baut seid zig jahren ihr eigenes OS und verdienen sich dumm und dämlich mit ihrem Appstore. Dazu haben sie es geschafft die Consumer von teurer Hardware mit geschlossenen system zu überzeugen. Sie können Hardware und software entsprechend Anpassen und entsprechend gegenfinanzieren.

Intel und AMD verdienen den grossteil ihres Geldes mit Server/desktop cpus wo der verbrauch nicht entscheidend ist. Da gibt es keinen Milliarden schweren Appstore der Geld einspült. Sie sind auf Microsoft und Linux angewiesen damit ihre Hardware für consumer läuft und wir sehen ja seid jahren wie problematisch das teilweise ist. Dazu liefert Intel/Amd was OEMs wollen denn diese kaufen die Hardware. Apple hat das Problem nicht, hier geht eine komplette Plattform (Produkt) direkt zum Endkunden was eine ganz andere Margen planung mit sich bringt.

Sicher werden cpus auch für Laptops produziert diese waren zum großteil abwandlungen der Desktop cpus und keine anderen Architekturen die auf Low power ausgelegt waren.

software sells Hardware( war schon immer so)

Beim vergleich muss man schon etwas weitreichender denken um zu verstehen woher Apple seinen Vorteil und ihre erfahrung bezieht. Und wenn man sich das genau anschaut ist dieses Ergebnis was man hier sieht garnicht so ungewöhnlich, sondern eher erwartbar.



du siehst auch an Nvidia das Software/Features entscheidend für den verkauf und erfolg von Hardware ist. Man könnte AMD/Intel eher vorwerfen hier zuwenig investiert zuhaben. Wobei Intel ja die Marschrichtung vorgab und AMD immer versucht hat mit zuhalten. So langsam dreht sich das Blatt. Intels riesen kosten apparat die eigene fertigung ist momentan kein vorteil mehr und belastet nur noch.
 
  • Gefällt mir
Reaktionen: TomH22
Was sind die Grenzen der CPU? Es handelt sich nicht um X86/64, sondern um etwas Apple-eigenes. Gibt es Szenarien, in denen der Apple nicht gut ist?
 
Hancock schrieb:
@Muntermacher: Nope, alle Ryzen Kerne sind gleich daher performen die auch gleich, ist ja Singlecore.

Was der M4 eigentlich zeigt, ist wie viel Speicher auf dem Package bringen kann. Und das ist gleichzeitig die Achillesferse. Ich hab Workloads mehrfach am Tag die 64 GB (besser sogar 128 GB) brauchen, und das ist bei Apple entweder nicht drin oder lohnt sich dann doch nicht mehr (Multicoreskalierung). Bei x86 stopf ich mir standardmäßig die 64 rein und 128 wenn ich lustig bin, mehr gibts dann bis zu 2 TB oder mehr für Apple-Preise (Rdimm im Server).
D.h. die aufgezählten unterscheiden sich in Anza Kerne und/oder Cache. Danke Dir.
 
TomH22 schrieb:
Soso… welche Befehle sollen dass denn sein, die die x86 ISA beherrscht, für die es kein funktionales Äquivalent auf ARMv8/v9 gibt?
Lade eine 64-Bit Konstante (Immediate) in das Register Foo.
 
  • Gefällt mir
Reaktionen: TomH22
beckenrandschwi schrieb:
Was sind die Grenzen der CPU? Es handelt sich nicht um X86/64, sondern um etwas Apple-eigenes. Gibt es Szenarien, in denen der Apple nicht gut ist?
Ja, aber die haben nichts damit zu tun, dass es sich um ARM handelt. Die ISA spielt dafür kaum eine Rolle. Die größte Schwäche die Apple hat, ist die fehlende Flexibilität. Wie groß RAM und GPU sind skaliert stark mit der Größe CPU. Solange der eigene Bedarf dem von Apple vorgegebenen Verhältnis RAM/CPU/GPU entspricht, ist das auch absolut in Ordnung und für viele ist genau das der Fall. Aber soweit man davon abweichen will oder muss, zahlt man entweder massive Aufpreise für niemals benutztes Silizium oder kann schlichtweg gar nichts passendes bei Apple finden.

Das ist einfach der Preis den Apple dafür zahlt, dass sie ein hochintegriertes SoC entwickelt haben und eben alle Effizienzvorteile mitnehmen, die sich aus dieser Integration ergeben.
 
  • Gefällt mir
Reaktionen: sioh, guzzisti und beckenrandschwi
Aimero schrieb:
Würde mich mal interessieren, wie viel man aus einem AMD / Intel raus quetschen kann, wenn man hoch spezialisiere Betriebssysteme nimmt, wie sie eben in Datacenters zu finden sind
Dann installier dir Linux oder Unix dann hast du diese hochspezialisierten Betriebssysteme. Da ist nix anders oder hochspezialisiert.

Apple hat halt volle Kontrolle über ihr Ökosystem, ihr SDK braucht nicht viele Konfigurationen abzudecken bzw. zu berücksichtigen da kann der Code schon stark optimiert werden.
Ansonsten sind die M-Silicons auch sehr gut designt, Ram ist on Die und es braucht nur noch einen Memory Controller, CPU/GPU usw. können direkt auf den gemeinsamen Ram zugreifen (Unified Memory Architecture) und da wir auch die Power und Effizienz herkommen.

Wenn Intel/AMD das Adaptieren würden/könnten sehe die Sache vermutlich anders aus.
 
Zuletzt bearbeitet: (habs geändert Herr Lehrer!)
  • Gefällt mir
Reaktionen: sioh
Supra77 schrieb:
Und wieso sind macs und apple in spielen und realen Anwendungen dann so weit hinten? Richtig weil sie keine befehle können und nicht Universal sind wie Prozessoren von amd und intel die gefühlt jedes Programm dieser welt laufen lassen können bei relativ guter performance während die m reihe von apple schon alleine viele befehle einfach von grund auf nicht beherrscht. Also schon mal so aus Prinzip ist es so: wenn weniger schaltkreise, dann weniger stromverbrauch auch.
Bei Spielen habe ich keine Erfahrung und kenne auch niemanden der das ernsthaft auf Mac's versucht ... aber was Anwendungen angeht, egal ob Bild, Video, Musik oder Softwareentwicklung sehe ich nicht, dass Apple Silicons 'so weit hinten' liegen, wie von dir unterstellt. Egal ob ARRI, Davinci, Blender oder sonstige gängige Tools ... der Apple M# ist dort einfach brutal für den Verbrauch und als mobile einsetzbares Gerät ... Und nur weil Apple z.B. ein proprietäres AVX nicht lizensiert und damit implementiert hat, heißt es nicht, dass auf Apple Silicon nicht Vector Instruktionen unterstützt werden. Solche Operationen können bei entsprechender Implementierung ebenso 'beschleunigt' werden. Bei Apple heißt das Kind halt AMX/SVE und nicht AVX ...
Bei entsprechendem Interesse und einem Markt der da wäre, ginge in Sachen GPU vermutlich auch auf Apple relativ viel, da im Blender Benchmark der M4 locker mit einer 4070 Super mithält. Daran kann man erkennen, wie Metal performt, wenn man denn möchte ... Für einen SoC und die Leistungsaufnahme finde ich das beeindruckend ...
 
  • Gefällt mir
Reaktionen: sioh, prayhe und sikarr
foofoobar schrieb:
Lade eine 64-Bit Konstante (Immediate) in das Register Foo.
Gutes Beispiel, bei den meisten RISC ISAs (auch RISC-V) braucht man dafür zwei Befehle. Ist allerdings in der Praxis nicht performance relevant:
  • Meistens sind konstante Werte sowas wie 0,1 oder auch öfter 4,8 (Anzahl Bytes eines D oder Q Words) - gilt auch für z.B. immediate ADD
  • Konstanten lädt man üblicherweise außerhalb von Schleifen in ein CPU Register von dem RISC CPUs auch genug haben.
 
  • Gefällt mir
Reaktionen: Piktogramm
Zurück
Oben