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

Supra77 schrieb:
Und wieso sind macs und apple in spielen und realen Anwendungen dann so weit hinten?
Bei Spielen könnte es evtl. daran liegen das diese einfach nicht für Mac portiert wurden?
Und bei anderen Anwendungen wie Audio und Videoediting ist Apple ganz weit vorne.
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.
Sorry das ist Blödsinn, ARM ist genauso eine "Universal" Architektur wie x86, MIPS, PPC oder SPARC.
Apple hat es sogar geschafft das teilweise x86 Anwendungen in Rosetta2 schneller liefen als nativ auf x86, dafür hatte Apple extra den M1 angepasst.
Und ARM hat genauso Extension wie x86 um bestimmte Berechnungen zu beschleunigen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sioh und BorstiNumberOne
Die Zocker und Raketenwissenschaftler wieder unter sich.
Einfach mal die Leistung anderer anerkennen und für sich den Hacken setzen: Bleibe bei Windows und Linux und gut ist, Ihr braucht hier niemanden missionieren. Ja,die Upgrade Preise sind teuer bei Apple, aber niemand wird gezwungen sich einen Mac in einer bestimmten Konfiguration zu kaufen.
Einige von euch kaufen sich die teuersten Komponenten für einen “Spiele-PC” und es juckt niemanden.
Btw, das Runterbeten von Mythen über Macs, MacOs und den angeblichen Storezwang machen euch nicht gerade glaubwürdig.
 
  • Gefällt mir
Reaktionen: sioh, prayhe, Ryoukou und 3 andere
run_for_fun schrieb:
Einige von euch kaufen sich die teuersten Komponenten für einen “Spiele-PC” und es juckt niemanden.
Wenn ich mir dir Diskussionen bei Ankündigung und erscheinen der 4090 angeschaut habe muss ich dir widersprechen :D und bei der 5090 wirds bestimmt genauso sein.
 
Multicore verliert Apple mit Abstand, wen wundert es? Apple wird immer interessanter für Menschen mit Hintergrundwissen. Aber Apple zieht ja mehr auf die Casuals. Also alles gut 😉
 
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.

Ich möchte hier nochmal betonen, dass es absolut NICHT so ist, dass ARM irgendetwas "nicht kann".

ARM erlaubt so gut wie alles zu programmieren was man programmieren wollen würde. Inklusive Spiele. Factorio läuft völlig problemlos auf ARM. Handyspiele laufen problemlos auf ARM.

Und auf Apple würde es auch AAA Spiele geben wenn sich Apple die klitze-kleinste Mühe geben würde, Spiele-Entwicklung und das entsprechende Software-Ökosystem zu unterstützen, aber das tun sie halt nicht.

Das hat nix mit ARM zu tun, sondern nur mit Apple.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: sioh und Lutscher
Mobil bin ich nur noch mit Apple unterwegs.
Auf dem Desktop würde mir die Flexibilität der Windows Welt fehlen.
Zudem kann ich bei meinem PC defekte Teile einzeln tauschen oder gezielt Upgraden, dass fehlt bei Apple völlig.
Dafür sind die Apple Desktops in meinen Augen viel zu teuer. 🫰
 
eastcoast_pete schrieb:
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.
Nur weil das Ziel vom Compiler anders ist, ändert sich nicht das Verhalten der Programme. Auch ist es nicht möglich einfach so x86 oder ARM Code einfach auf eine GPU zu werfen, GPUs haben ihre komplett eigene ISA.

sikarr schrieb:
Ram ist on Die und es braucht keinen Memory Controller mehr jeder Core kann direkt auf den Ram zugreifen (Unified Memory Architecture) und da wir auch die Power und Effizienz herkommen.

  • Der Ram ist on Package und nicht on Die. Wie bei den aktuellen Ryzen gibt es da ein organischen Träger und klassische Leiterbahnen zwischen den Ram und SoC Chips.
  • Es braucht IMMER einen MemoryController
  • Das einzelne Kerne RAM direkt adressieren ist die Regel
  • Unified Memory bedeutet, dass div. Komponenten (CPU, GPU, DSPs, heute auch NPUs..) auf den selben Speicher zugreifen können. Wobei der Memory Controller dafür sorgt, dass es keine Konflikte beim Speicherzugriffe gibt. Das ist Stand der Technik seit über einer Dekade und Apple hatte das auch schon in MacOS aktiv genutzt als Intel Broadwell zum Einsatz kam. Ebenso wie AMD bei Jaguar.
Also die Kommentare zu diesem Artikel hier und zum Google Quantenchip strotzen vor Fehlern, Unwissen und viel Meinung, aber mit diesem einem Satz hast du die höchste Dichte an Fehlern erreicht.
 
  • Gefällt mir
Reaktionen: sioh, Seven2758, ErichH. und eine weitere Person
Bzgl. der tobenden Kommentarschlacht von x86 vs ARM, CISC vs RISC ist es mal wieder Zeit für einen alten Beitrag:
CDLABSRadonP... schrieb:
In dem Kontext kann auch nur immer wieder an AMDs Projekt K12 erinnert werden:
https://www.golem.de/news/jim-kelle...derweise-eingestellt-von-amd-2206-166280.html
Oder auf englisch:
During his time at AMD, Jim and his team noticed that the cache design for ARM and x86 CPU was mostly the same among other things such as the execution unit and the only difference between the two processor architectures was the decode unit so they decided to work on a new chip, known to us as K12 that was later canceled by AMD.

https://wccftech.com/legendary-chip...12-arm-cpu-project-after-he-left-the-company/

Effektiv heißt es, dass wir ARM-Ryzens hätten haben können. Ungewöhnlicherweise (es ist immerhin Jim Keller) stimme ihm dabei übrigens nicht zu, dass das ganze Dummheit war, sondern bloß auf einer Erkenntnis fußte: Während der Beschäftigung ist AMD halt zu der Erkenntnis gekommen, dass die beiden Varianten sich dann eben unterm Strich auch ziemlich ähnlich verhalten. Und wieso sollten sie dann noch eine ARM-Variante anbieten? Software (auch im Serverbereich) liegt ja auch für x86 problemlos vor.

Das ganze sieht anders aus, wenn sich die Softwarelandschaft von x86 wegbewegen würde. Vielleicht würde dann ein AMD hingehen und sagen: Ja, Zen7 kommt auch in einer ARM-Variante heraus.
Ich würde mittlerweile noch folgendes hinzufügen: Dass viele ihre eigenen ARM-Prozessoren herstellen liegt in erster Linie daran, dass sie das dann InHouse halten wollen und sich den Gewinn nicht mit Prozessordesignherstellern teilen wollen. Ab und an läuft das aber nicht so gut, wie sich in letzter Zeit immer wieder zeigt. Das wäre dann tatsächlich ein Moment, in dem AMD auf Tuchfühlung gehen könnte, ob jemand der großen Fische, die ihre Software nun eben für ihre InHouseProzessoren auf ARM optimiert hatten, nicht Interesse daran hätten, zu einem EPYC ARM zu wechseln (und damit sozusagen zurückzuwechseln). Sobald das der Fall ist, werden wir diese Produkte auch sehen und als Abfallprodukte kann es sein, dass dann auch Ryzen ARMs runterfallen.
 
  • Gefällt mir
Reaktionen: sioh und Piktogramm
sikarr schrieb:
Ram ist on Die und es braucht keinen Memory Controller mehr jeder Core kann direkt auf den Ram zugreifen (Unified Memory Architecture) und da wir auch die Power und Effizienz herkommen.
Piktogramm schrieb:
Also die Kommentare zu diesem Artikel hier und zum Google Quantenchip strotzen vor Fehlern, Unwissen und viel Meinung, aber mit diesem einem Satz hast du die höchste Dichte an Fehlern erreicht.
Ich gebe dir Recht, dass der Kommentar wirklich absurd ist (allein das mit jeder Core kann auf RAM direkt zugreifen --- je nach Perspektive, was direkt meint, ist das entweder der Normalfall oder (falls latenzfreier Zugriff gemeint ist) nie gegeben), aber das mit der höchsten Dchte an Fehlern stimmt wahrscheinlich nicht. Der Satz enthält 31 Wörter, 188 Buchstaben. Man kann sich streiten, wie viele Fehler das jetzt tatsächlich waren, aber zehn sind es sicher nicht. Wenn hier also jemand einen Satz mit drei Wörtern und einem Fehler verfasst hat, weißt der eine höhere Fehlerdichte pro Wort auf. Wenn jemand einen Satz mit 18 Buchstaben und einem Fehler verfasst hat ebenfalls.

Möglicherweise nehme ich das ein bisschen zu ernst --- oder möglicherweise will ich einfach nur mit auskosten, wie fehlerhaft der Beitrag ist. ;)
 
  • Gefällt mir
Reaktionen: stefan92x
sikarr schrieb:
@Piktogramm @CDLABSRadonP... na Gott sei Dank haben wir mit euch ja genug geballte Quantenphysik und Informatik Gelehrte hier bei CB
Lies doch mal deinen Beitrag selbstkritisch nochmal...
sikarr schrieb:
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.
...und überprüfe, ob nicht ein bisschen Demut in ihm auch angemessen gewesen wäre. Du hast ihn so geschrieben, als hättest du die Weisheit mit Löffeln gefressen und willst es jetzt @Piktogramm und mir vorhalten? Das wirkt reichlich vermessen. (sicherlich nicht bloß auf mich)
 
  • Gefällt mir
Reaktionen: sioh, Seven2758, iron_monkey und eine weitere Person
Mit welcher Windows Version wurde die "Windows Desktop" Leistungsaufnahme mit dem M4 getestet?

Apfel 10 oder Birne 11?
 
Temporä schrieb:
Da muss der Combiler dann bei ARM erstmal zwei Befehle schreiben und der Decoder schaut mal, ob diese zusammengefügt werden können oder nicht.
Vier Befehle nicht zwei:
Code:
foo(int):
        sub     sp, sp, #16
        str     w0, [sp, 12]
        mov     x0, 26231
        movk    x0, 0x4455, lsl 16
        movk    x0, 0x2233, lsl 32
        movk    x0, 0x11, lsl 48
        add     sp, sp, 16
        ret
 
  • Gefällt mir
Reaktionen: Piktogramm
Völlig egal, wahrscheinlich macht das Frontend dann Macro op fusion und es ist effektiv dann nur noch ein Befehl. (Gibts bei x86 auch, z.B. klassischerweise cmp und jxx (Compare and jump on flags)). RISC-V z.B. dokumentiert macro op fusion opportunities direkt in der ISA spec.

Ja, viel Mist (von mir vielleicht auch), aber es ist ein Forum, kein wissenschaftliches Journal.
 
Schnack schrieb:
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.
Es hängt stark von den spezifischen Anforderungen deiner Anwendung und der verwendeten Software ab.

Eine L
 
Hmm. Apple selbst gibt den Stromverbrauch des M4 im Maximum deutlich höher an.
https://support.apple.com/de-at/103253


Wow - Apple lässt die Seite nicht extern verlinken - Screenshot:
1733857305297.png

Videokonvertierung kann eine heutige CPU nicht voll auslasten und gerade Apples CPUs sind auf Videoaufgaben spezialisiert.
Ich will damit die Effizienz nicht kleinreden, aber seit dem M1 hat Apple hier eher Seitwärtsschritte gemacht und die Performance über mehr Takt und Verbrauch (und kleinere Fertigungsprozesse) geholt. Der M4 liegt deutlich weniger voran als noch der M1. Und die Geräte sind nun auch wieder lauter zu hören unter Last, bzw. haben wieder Thermalthrottling. Wie eben genau der neue Mac mini sowohl mit M4 als auch M4 Pro.

Das Basismodell ist damit grundsätzlich P/L technisch interessant, wenn man mit der kleinen onboard SSD leben kann, aber der Pro bzw. alle Upgradevarianten keinesfalls.
 
Zuletzt bearbeitet:
Zurück
Oben