Ist die Apple M1 CPU wirklich so gut und schneller was es sonst von Intel bezahlbar für den Desktop gibt? Oder ist das das übliche Marketinggeschwätz von Apple?
Es scheint so. Erstaunlich, daß Apple die Platzhirsche amd/intel so übertrumpfen konnte. Insgesamt ist die CPU allerdings nicht interessant, da sie ja wohl nur signierten Code etc. nach Gutdünken des Hauses A ausführen wird.
Knösel schrieb: > Erstaunlich, daß Apple die Platzhirsche amd/intel so übertrumpfen > konnte. Bei Handys konnte man schon früher erkennen, dass Apple gegenüber den Cores von ARM selbst und von anderen wie Samsung deutlichen Abstand hatte. Es gibt Gründe, die gegen x86 sprechen, die RISC bevorzugen: hochgradig parallele Decodierung gehört dazu. Man nahm an, dass sich das ob des Aufwands, den Intel und AMD trieben, einigermaßen erledigt hatte. Und sieht sich nun korrigiert.
:
Bearbeitet durch User
Die Tatsache das Software und Hardware aufeinander abgestimmt werden können, ist bestimmt nicht von Nachteil für Effizienz und Geschwindigkeit.
Ein ganz wesentlicher Faktor ist die Tatsache, daß Apple mit 5nm produzieren läßt und deswegen ziemlich große Caches verbauen kann. Ein zweiter, daß das RAM verlötet ist und deswegen LPDDR4-4266 zum EInsatz kommt. Bedenkt man dies, dann ist der Abstand gegenüber AMDs 4000er Ryzens nicht mehr sonderlich groß - und ganz besonders hat das nichts mit dem Mythos zu tun, daß x86 ineffizient sei und ARM effizient.
Nop schrieb: > deswegen ziemlich große Caches verbauen kann Wobei besonders die L1 Caches ungewöhnlich gross sind. Was in der bisherigen Geschichte von Prozessoren mit höherer Zugriffszeit oder deutlich begrenzter Taktrate einher ging. Nop schrieb: > Ein zweiter, daß das RAM verlötet ist und deswegen LPDDR4-4266 > zum EInsatz kommt. Der Unterschied gegenüber Laptops mit Intel und AMD ist eher, dass es direkt auf dem SoC mit drauf ist. So sind auch Renoir Laptops oft mit 8GB oder 16GB auf dem Board verlötetem DRAM dieses Typs ausgestattet, deshalb auch nicht erweiterbar. Und das ist gleichzeitig auch ein Problem bei allen Geräten dieser Bauweise, denn 32GB Varianten (oder mehr) werden damit bisher nur wenige angeboten, sind aber angesichts der Leistungsfähigkeit dieser Prozessoren sehr wohl interessant.
:
Bearbeitet durch User
Ich denke auch es hat damit zu tun dass apple direkt auf 5nm gegangen ist. Intel und amd sind ja beide bei 7nm, scheinbar haben da die fabs, vor allem tsmc schneller eine neue node eingeführt als den beiden lieb war. Hab gehört Intel will erst 2023 5nm Produkte rausbringen.
(prx) A. K. schrieb: > Und das ist gleichzeitig auch ein Problem bei allen Geräten dieser > Bauweise, denn 32GB Varianten (oder mehr) werden damit bisher nur wenige > angeboten, sind aber angesichts der Leistungsfähigkeit dieser > Prozessoren sehr wohl interessant. Der Apple-Prozessor kann anscheinend nicht mal 32 GB. Für ein Macbook Pro ist das etwas ärmlich.
Thomas schrieb: > Intel und amd sind ja beide bei 7nm Intel ist bei 10nm, wobei das wohl ungefähr mit TSMCs 7nm Prozess vergleichbar ist. Und Intels 10nm Prozess hat eine lange Geschichte von Problemen, die dazu führen, dass sie sich zwecks halbwegs nutzbarer Ausbeute in der Die-Fläche von unten nach oben hochhangeln, mit kleinen Notebook-CPUs anfangen müssen.
:
Bearbeitet durch User
Thomas schrieb: > Intel und amd sind ja beide bei 7nm, scheinbar haben da die fabs, vor > allem tsmc schneller eine neue node eingeführt als den beiden lieb war. AMD produziert die CPU-Dies bei TSMC. Mit dem Zen 2 / Ryzen 3000 waren sie volles Risiko gegangen, ihn für eine Fabtechnik zu entwickeln, von der zu dem Zeitpunkt völlig unsicher war, wann sie wie gut sein würde. Intel tat das anfangs bei der 10nm Technik ebenso, die frühere Tic-Toc Strategie ignorierend. AMD hatte damit Glück, Intel nicht.
(prx) A. K. schrieb: > Intel ist bei 10nm, wobei das wohl ungefähr mit TSMCs 7nm Prozess > vergleichbar ist. Stimmt, die bezeichnungen werden aber sowieso eher in der marketingabteilung geschaffen. Aber scheinbar gibt es da ein echtes gap das eben apple und evtl in zukunft noch ein paar andere erkennen: tsmc will 2023 schon 3nm risk production einführen, intel will dort eben erst auf 5nm wechseln, dafür dürfte der prozess dann mehr ausgereift sein, oder auch nicht wie man bei den 10nm gesehen hat. wenn tsmc bei 3nm einen vernünftigen production yield zusammenbringt kann das einiges an marktanteilen kosten.
Rolf M. schrieb: > Der Apple-Prozessor kann anscheinend nicht mal 32 GB. Für ein Macbook > Pro ist das etwas ärmlich. Aus welcher Quelle scheint diese Info zu kommen? Hoffentlich doch nicht nur aus der Tatsache, dass die erste Generation der Prozessoren (in dem MacBook Air und dem Macmini) gerade auf dem Markt ist.
Kolja schrieb: > Hoffentlich doch nicht nur aus der Tatsache, dass die erste Generation > der Prozessoren (in dem MacBook Air und dem Macmini) gerade auf dem > Markt ist. Apple sieht im Moment keinen Markt für mehr RAM, was allerdings auch an den völlig absurden Preisen liegen dürfte, die Apple verlangt. Das setzt sich übrigens nahtlos bei der SSD fort, wo laut der deutschen Apple-Webseite je zusätzliche 256 GB satte 224 Euro fällig werden. Auf dem freien Markt bekommt man z.B. eine Samsung Evo 970 Plus M.2 NVMe mit 1 TB schon für 165 Euro! Die Apple-Abzocke erreicht da echt ein neues Niveau.
Kolja schrieb: > Rolf M. schrieb: >> Der Apple-Prozessor kann anscheinend nicht mal 32 GB. Für ein Macbook >> Pro ist das etwas ärmlich. > > Aus welcher Quelle scheint diese Info zu kommen? Das steht eigentlich überall, wo technische Daten des Prozessors stehen. Auf https://www.heise.de/news/ARM-Macs-Mehr-Details-zum-Apple-M1-4958755.html steht, dass der Speichercontroller nicht mehr als 16 GB ansprechen kann. > Hoffentlich doch nicht nur aus der Tatsache, dass die erste Generation > der Prozessoren (in dem MacBook Air und dem Macmini) ... und eben dem Macbook Pro. > gerade auf dem Markt ist. Nop schrieb: > Apple sieht im Moment keinen Markt für mehr RAM, was allerdings auch an > den völlig absurden Preisen liegen dürfte, die Apple verlangt. Und daran, dass es für Apple ja viel besser ist, wenn die Nutzer später, wenn 16 GB nicht mehr reichen, nicht upgraden können und dann gleich den ganzen Rechner neu kaufen müssen. Würde man jetzt gleich 32 GB anbieten, könnten die Nutzer das schon jetzt kaufen und könnten den Rechner so länger nutzen.
Thomas schrieb: > tsmc will 2023 schon 3nm risk > production einführen, intel will dort eben erst auf 5nm wechseln, Bei TSMC vs Intel lief es schon seit langer Zeit so, dass TSMC bei der nominellen Strukturgrösse stets vor Intel lag, die aber effektiv ungefähr vergleichbar waren. Wenn also TSMC bei 3nm liegt und Intel bei 5nm, muss das nichts heissen. Neu war nur, wie sehr Intel den 10nm Prozess vergeigte.
:
Bearbeitet durch User
Nop schrieb: > Ein > zweiter, daß das RAM verlötet ist und deswegen LPDDR4-4266 zum EInsatz > kommt. Ist die Anbindung auch 64 bittig wie bei normalen DDR4 Modulen oder geht man einen breiteren Weg wie bei dedizierten GPUs?
Knösel schrieb: > Insgesamt ist die CPU allerdings nicht interessant, > da sie ja wohl nur signierten Code etc. nach Gutdünken des Hauses A > ausführen wird. Und wie sollen die Nutzer auf Applegeräten programmieren lernen können wenn nur noch signierter Code ausgeführt wird? Wie kriegt man seine Open Source Programme zum laufen, von denen viele auch unter Windows keine Signatur haben?
Nano schrieb: > Wie kriegt man seine Open Source Programme zum laufen, von denen viele > auch unter Windows keine Signatur haben? Gar nicht. Das ist ja das schöne an der Apple Welt. Software bekommst du sowieso nur noch durch genehme Apple Distribution.
Nano schrieb: > Und wie sollen die Nutzer auf Applegeräten programmieren lernen können > wenn nur noch signierter Code ausgeführt wird? Du wirst deinen code signieren können. Ging immer schon wenn es erforderlich war.
Nano schrieb: > Wie kriegt man seine Open Source Programme zum laufen, von denen viele > auch unter Windows keine Signatur haben? Ich schätze, dass Apple nicht alle Programme selbst entwickeln will, also ein Entwickler seinen Code nicht für jeden Testlauf zu Apple schicken muss. Ich könnte mir aber vorstellen, dass Binärcode aus fremder Quelle durch den Filter von Apples Shop muss.
Nun ... der M1 ist jetzt am Anfang ein SoC für den unteren Preisbereich und auch für den unteren Leistungsbereich. Dafür hat der auch nur eine geringe Leistungsaufnahme. Der ist daher auch in genau den Produkten die bisher auch mit schwächeren Intel CPUs ausgestattet wurden: Air, kleines Macbook Pro, Mini. Es gab auch immer dickere Modelle vom Macbook Pro und auch vom Mini. Dafür ist dieser SoC aber vermutlich nicht gedacht. Meine Vermutung: Es kommt noch mindestens eine weitere Variante vom SoC für die stärkeren Modelle vom Macbook Pro, für das Highend-Modell vom Mini und eben auch für iMac und Mac Pro. Die bieten dann mehr RAM und mehr TB Anschlüsse. Rolf M. schrieb: > Das steht eigentlich überall, wo technische Daten des Prozessors stehen. > Auf > https://www.heise.de/news/ARM-Macs-Mehr-Details-zum-Apple-M1-4958755.html > steht, dass der Speichercontroller nicht mehr als 16 GB ansprechen kann. Nein, das steht da nicht. Da steht: ------------------------ Zudem hat der M1 einen RAM-Controller, der bis zu 16 GByte Speicher anbindet, vermutlich mit zwei 64-Bit-Kanälen für LPDDR4 oder LPDDR4X. ------------------------ Der bindet bis zu 16 GByte an, weil Apple nicht mehr Speicher verlötet. Ob der Controller mehr ansprechen kann oder nicht bleibt unbeantwortet. Tja, warum ist der jetzt so schnell? Laut Apple liegt es zu einem großen Teil an der unified memory architecture. Alle Teile wie CPU, NPU, GPU, ... können auf den gleichen Speicher zugreifen. Texturen müssen also z. B. nicht erst in den Speicher der GPU kopiert werden. https://arstechnica.com/gadgets/2020/11/we-are-giddy-interviewing-apple-about-its-mac-silicon-revolution/ Weitere Zahlen und so gab es hier: https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested ----------------------------------------------------------------- Generell finde ich das ziemlich krass von Apple. Vor allem aber wie sie das zusammen mit Mac OS so gebaut haben, dass es für die meisten Nutzer problemlos funktioniert. Intel-Programme laufen auf dem M1 mit Rosetta2 oft schneller als auf den Vorgängermodellen (Air, Mini) von Apple mit Intel-CPU. iOS-Apps laufen auch ohne Anpassungen auf dem M1. Auch Homebrew Apps laufen https://www.macrumors.com/2020/11/18/apple-m1-mac-tidbits/ . Finde ich für einen Architekturwechsel erstaunlich reibungslos. Damals 2006 war das noch recht holperig, ja, es gab damals auch Rosetta, aber PPC Programme waren auf den Intel-Macs meistens deutlich langsamer.
Gustl B. schrieb: > Laut Apple liegt es zu einem großen Teil an der unified memory > architecture. Alle Teile wie CPU, NPU, GPU, ... können auf den gleichen > Speicher zugreifen. Texturen müssen also z. B. nicht erst in den > Speicher der GPU kopiert werden. Lehrstück dafür, wie man einen Nachteil positiv ausdrückt. ;-) Das gilt naturgemäss für alle Prozessoren mit integrierter GPU, also auch AMDs Renoir und Intels Tiger Lake. Separate Grafikkarten haben nicht etwa deshalb eigenen Speicher, weil sie nicht an den Hauptspeicher rankämen, sondern weil deren Bandbreitenanforderungen mit eng gekoppelten eigenen Speicher modernsten Typs besser realisierbar sind: GDDR6 256 Bit bis 512 GB/s (RX 6800) gegenüber 70 GB/s DDR4 4266 (Renoir).
Gustl B. schrieb: > Damals > 2006 war das noch recht holperig, ja, es gab damals auch Rosetta, aber > PPC Programme waren auf den Intel-Macs meistens deutlich langsamer. Dafür konnte der PPC Kreise um Intel laufen. Und Windows lief ganz brauchbar auf dem PPC Mac. SETI@Home auf dem Mac lief auch schneller. Die Gruppe de.soc.mac war immer recht weit vorne.
(prx) A. K. schrieb: > Lehrstück dafür, wie man einen Nachteil positiv ausdrückt. ;-) > > Das gilt naturgemäss für alle Prozessoren mit integrierter GPU Hast du dazu Details? Die Frage ist nämlich: Was bedeutet dieses shared Memory bei integrierter GPU genau? Haben CPU und GPU getrennte Adressbereiche die nur im gleichen physischen Speicherbaustein liegen oder teilen sie sich den gleichen Adressbereich? Also müssen Texturen für das Rendering in der GPU einmal im Speicher kopiert werden oder nicht? So wie ich das kenne steht der Speicher für die GPU dann nicht der CPU zur Verfügung, für mich sieht das also so aus als wären das komplettt getrennte Speicherbereiche, also als hätten CPU und GPU eigene Speicher nur eben nicht physisch sondern logisch getrennt. Nick M. schrieb: > Dafür konnte der PPC Kreise um Intel laufen. Jap. Zumindest am Anfang. Aber so ein Dual G5 war halt auch teuer. Nick M. schrieb: > Und Windows lief ganz > brauchbar auf dem PPC Mac. Welche Windowsversion lief da? Ja gut mit VirtualPC ging das, war aber auch eher langsam und bei der 3D Leistung eher sehr schlecht.
Gustl B. schrieb: > Also müssen Texturen für das Rendering in der GPU einmal im Speicher > kopiert werden oder nicht? Tatsächlich ist das irrelevant, denn der Job von GPUs ist es, die gleiche Aufgabe bis zum Erbrechen zu wiederholen. Sie greifen also extrem häufig lesend auf diese Daten zu, während ein möglicher Upload in eigenen Speicher (-Bereich) der GPU nur einmal erfolgt.
:
Bearbeitet durch User
Gustl B. schrieb: > Was bedeutet dieses shared Memory bei integrierter GPU genau? "Memory Management on Embedded Graphics Processors" https://community.arm.com/developer/tools-software/graphics/b/blog/posts/memory-management-on-embedded-graphics-processors
Gustl B. schrieb: > Haben CPU und GPU getrennte Adressbereiche die nur im gleichen > physischen Speicherbaustein liegen oder teilen sie sich den gleichen > Adressbereich? > Also müssen Texturen für das Rendering in der GPU einmal im Speicher > kopiert werden oder nicht? Das Kopieren ist nicht das Problem. Die GPU muss die Texturen aber auch darstellen, und das in jedem Frame. Dazu muss sie diese dauernd aus dem Speicher lesen, und das kostet sehr viel Speicherbrandbreite. Deshalb haben dedizierte GPUs ja einen eigenen Speicher mit sehr viel Bandbreite. Wenn die CPU sich den Speicher mit der GPU teilt, muss die eh schon geringere Bandbreite noch mit den 8 CPU-Kernen geteilt werden. Deshalb eignet sich so eine Architektur eher für kleine bis mittlere Leistung, aber weniger für die richtig großen Power-Systeme. Deshalb wird es spannend zu sehen, was Apple bim Mac Pro machen wird. > So wie ich das kenne steht der Speicher für die GPU dann nicht der CPU > zur Verfügung, für mich sieht das also so aus als wären das komplettt > getrennte Speicherbereiche, also als hätten CPU und GPU eigene Speicher > nur eben nicht physisch sondern logisch getrennt. Aber der Zugriff erfolgt trotdem über den selben Kanal, und das ist das entscheidende. > Nick M. schrieb: >> Dafür konnte der PPC Kreise um Intel laufen. > > Jap. Zumindest am Anfang. Aber so ein Dual G5 war halt auch teuer. Was war bei Apple je nicht teuer?
Nick M. schrieb: > Und Windows lief ganz brauchbar auf dem PPC Mac. Windows läuft auch ganz brauchbar auf Microsofts Surface mit ARM Prozessor und Samsungs GalaxyBook (*), die eine sehr ähnliche Systemkonstellation haben wie die neuen Apples - allerdings andere Leistungsbereiche adressierend. Native Anwendungen sind zwar schneller als x86-Code, und x86 Programme sind auf x86 schneller als auf ARM. Dennoch sind x86 Programme auf der ARM Version keineswegs langsam. * Von dem gibts zwei sonst sehr ähnliche Typen: mit ARM und mit Intels Lakefield, der einen High-end Core und vier Atom Cores hat. Nützlich bei fairen Vergleichen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Tatsächlich ist das irrelevant Rolf M. schrieb: > Das Kopieren ist nicht das Problem. Und das Gegenteil behaupten die bei Apple. Zitat von Federighi https://arstechnica.com/gadgets/2020/11/we-are-giddy-interviewing-apple-about-its-mac-silicon-revolution/ : We not only got the great advantage of just the raw performance of our GPU, but just as important was the fact that with the unified memory architecture, we weren't moving data constantly back and forth and changing formats that slowed it down. And we got a huge increase in performance. And so I think workloads in the past where it's like, come up with the triangles you want to draw, ship them off to the discrete GPU and let it do its thing and never look back—that’s not what a modern computer rendering pipeline looks like today. These things are moving back and forth between many different execution units to accomplish these effects. Rolf M. schrieb: > Deshalb wird es spannend zu sehen, was Apple bim Mac Pro machen wird. So wirklich glaube ich nicht an eine 1-Chip-Lösung, das würde sehr groß werden. Und PCIe werden sie weiterhin als Steckplatz anbieten, vermute ich, wobei das bei der Tonne auch nicht der Fall war. Vielleicht können sie auch mehrere M1 quasi als Chiplets zusammen zu einem größeren SoC verheiraten? Apple hat da viele Möglichkeiten weil sie jetzt eben sehr viel in der eigenen Hand haben.
:
Bearbeitet durch User
Rolf M. schrieb: >> Also müssen Texturen für das Rendering in der GPU einmal im Speicher >> kopiert werden oder nicht? > > Das Kopieren ist nicht das Problem. Außer wenn sich die Textur ständig ändert, z.B. bei Video. Zumindest bei manchen SoCs (z.B. i.MX8) ist es so, dass Videodekodierung nicht in der GPU geschieht, sondern in unabhängigen Einheiten. Ich glaub, das ist auch bei PCs teilweise so, aber da bin ich nicht sicher.
Nano schrieb: > Ist die Anbindung auch 64 bittig wie bei normalen DDR4 Modulen Ganz normal mit 64 bit als dual channel. Also das, was man bei x86-Laptops auch haben kann. > oder geht man einen breiteren Weg wie bei dedizierten GPUs? Die nutzen kein DDR4, eben weil sonst die Bandbreite zum Flaschenhals würde. Das ist ja auch der Grund, wieso AMD bei neueren APUs zwar bessere Kerne liefert, aber weniger davon, was sich erst mit AM5-Sockel und dann DDR5 ändern kann.
Markus K. schrieb: > Außer wenn sich die Textur ständig ändert, z.B. bei Video. Bei Video sind die Datenraten aber auch so gering, daß auch eine APU ohne eigenes Graka-RAM schnell genug ist. Sogar, wenn sie von Intel ist.
Nop schrieb: > schnell genug Das ist aber nicht das Ziel. Auch die alten Modelle ohne M1 waren für Vieles schnell genug. Man wollte es trotzdem schneller bauen und das hat man geschafft. Wenn da einmal weniger hin und her kopiert werden muss, dann bleibt zur gleichen Zeit mehr Bandbreite für andere Dinge.
-gb- schrieb: > Wenn da einmal weniger hin und her kopiert werden muss, dann bleibt zur > gleichen Zeit mehr Bandbreite für andere Dinge. Das ist nicht das Argument für APUs (egal ob Apple, AMD oder Intel), sondern daß sie für Alltagsaufgaben, Office und Video schnell genug sind. Deswegen läßt man die dGPU weg, was vor allem Kosten spart und zudem den Akku schont. Beim Spielen wird es dann allerdings eng.
Nop schrieb: > Sogar, wenn sie von Intel ist. Wobei Videodekodierung in Software allerdings erheblich Last erzeugen kann, besonders bei 8K-Displays und neuen Codecs wie AV1. Weshalb Hardware-Support für AV1 allmählich auch in die integrierten Lösungen einzieht, mindestens um Strom zu sparen - Intels Tiger Lake hat ihn, Apples M1 vmtl auch, AMDs Renoir nicht.
:
Bearbeitet durch User
Nick M. schrieb: > Gustl B. schrieb: >> Damals >> 2006 war das noch recht holperig, ja, es gab damals auch Rosetta, aber >> PPC Programme waren auf den Intel-Macs meistens deutlich langsamer. > > Dafür konnte der PPC Kreise um Intel laufen. Und Windows lief ganz > brauchbar auf dem PPC Mac. Apple ist damals zu Intel gewechselt, weil die PPC zu langsam waren. Wenn also jemand um irgend jemand herumgekreist ist, dann die Intelprozessoren um den PPC. > SETI@Home auf dem Mac lief auch schneller. Die Gruppe de.soc.mac war > immer recht weit vorne. Das muss gar nichts heißen. Vielleicht hatten die schlichtweg mehr Geld um ihre Macs über Nacht laufen zu lassen. Stromkosten egal. Und ob es überhaupt ein Mac war, geht aus einer Gruppenzugehörigkeit auch nicht vor.
Nano schrieb: > Apple ist damals zu Intel gewechselt, weil die PPC zu langsam waren. Nein, weil Motorola / IBM kein Intresse an Low-Power-Versionen für Laptops hatte. Nano schrieb: > Und ob es überhaupt ein Mac war, geht aus einer Gruppenzugehörigkeit > auch nicht vor. War halt eine Mac-Gruppe aus dem usenet. Die hatten das im usenet abgesprochen und auf ihren Macs (daher der Gruppenname) laufen lassen. U.a. ich auch.
Nick M. schrieb: > Nano schrieb: >> Apple ist damals zu Intel gewechselt, weil die PPC zu langsam waren. > > Nein, weil Motorola / IBM kein Intresse an Low-Power-Versionen für > Laptops hatte. Siehe: "Für Intel sprächen hingegen zwei Vorteile - die hohe Leistung und der geringe Stromverbrauch. Mancher rieb sich verwundert die Augen: Hatte Apple bis vor kurzem nicht genau das Gegenteil behauptet? Jobs aber versicherte mit Hilfe eines Diagramms, dass der PowerPC nur 15, ein Intel-Prozessor jedoch 70 Leistungseinheiten pro Watt erreicht. " https://www.heise.de/ct/artikel/Apple-faellt-vom-Stamm-289950.html Und weiter unten geht's dann weiter mit: " Hier ist Apple auf die G4-Prozessoren der Motorola-Halbleiter-Sparte Freescale angewiesen, die zwar sparsame und kompakte, aber trotz jahrelanger Entwicklungsarbeit einfach nicht ausreichend schnelle Prozessoren liefert - bei 1,67 GHz ist zurzeit Schluss. " Es war die Leistung, weswegen man zu Intel wechselte. Die PPC waren zu dem Zeitpunkt arschlahm verglichen mit den x86 CPUs. Man darf hier auch nicht vergessen, dass AMD und Intel zu diesem Zeitpunkt sich in den letzten 5 Jahren ein Kopf an Kopf Rennen leisteten und die GHz Schraube immer weiter noch oben schraubten und auch in anderen Bereichen die Leistung immer mehr verbesserten. IBM und Motorola konnten da allein von den verkauften Stückzahlen und Fertigungskosten nicht mehr mithalten.
Nano schrieb: >> Nein, weil Motorola / IBM kein Intresse an Low-Power-Versionen für >> Laptops hatte. > > "Für Intel sprächen hingegen zwei Vorteile - die hohe Leistung und der > geringe Stromverbrauch. Wo ist jetzt der Widerspruch?
Man wird sehen, wie sie sich bewähren. Ich rechne ja nicht mit einer Revolution.
Nano schrieb: > Die PPC waren zu > dem Zeitpunkt arschlahm verglichen mit den x86 CPUs. Zumindest jene, die ins Apple-Schema passten. IBMs dickere Kisten waren besser drauf, aber dafür nicht geeignet.
Nick M. schrieb: > Nano schrieb: >>> Nein, weil Motorola / IBM kein Intresse an Low-Power-Versionen für >>> Laptops hatte. >> >> "Für Intel sprächen hingegen zwei Vorteile - die hohe Leistung und der >> geringe Stromverbrauch. > > Wo ist jetzt der Widerspruch? Weil da auch hohe Leistung steht und nicht nur ein geringer Stromverbrauch. Also genau wie ich eingangs sagte.
Ich habe mir privat einen M1 Mac Mini bestellt (16GB) um endlich mal mein 2012 Macbook Pro abzuloesen. Die Standardausstattung mit 8GB RAM ist allerdings enttaeuschend, auch wenn viel RAM bei schnellen SSDs heute weniger wichtig scheint als noch vor 10 Jahren. Leider gibt es die 16GB nur mit inzwischen recht langer Lieferzeit bis knapp vor Weihnachten. Knösel schrieb: > Gar nicht. Das ist ja das schöne an der Apple Welt. Software bekommst du > sowieso nur noch durch genehme Apple Distribution. Leute, bitte schreibt doch nicht so einen Unsinn. Macs sind bei vielen Firmen in US der Standard fuer Entwicklerrechner. Meint ihr das waere so, wenn man da keinen eigenen Code ausführen oder OSS installieren koennte? Nop schrieb: > Das ist nicht das Argument für APUs (egal ob Apple, AMD oder Intel), > sondern daß sie für Alltagsaufgaben, Office und Video schnell genug > sind. Deswegen läßt man die dGPU weg, was vor allem Kosten spart und > zudem den Akku schont. Beim Spielen wird es dann allerdings eng. Ich bin mir nicht sicher ob diese Ansicht noch zeitgemäß ist. Schau dir z.B. mal die Architektur der PS5 an, das ist quasi auch eine APU, und die spielt bei der Grafikleistung wohl relativ weit vorne mit. Irgendwie ist so eine Vereinheitlichung auch ueberfaellig. Das Konzept, zwei Recheneinheiten (CPU und GPU) auf verschiedene Platinen mit getrennten Speichern zu setzen und mit einem langen Bus zu verbinden wuerde einem heute sehr seltsam vorkommen, wenn es sich nicht durch das Konzept "Grafikkarte" historisch so ergeben haette. Dazu noch ein interessantes Zitat aus dem von Gustl verlinkten Artikel (https://arstechnica.com/gadgets/2020/11/we-are-giddy-interviewing-apple-about-its-mac-silicon-revolution/): > Where old-school GPUs would basically operate on the entire frame at once, we operate on tiles that we can move into extremely fast on-chip memory, and then perform a huge sequence of operations with all the different execution units on that tile. It's incredibly bandwidth-efficient in a way that these discrete GPUs are not. And then you just combine that with the massive width of our pipeline to RAM and the other efficiencies of the chip, and it’s a better architecture.
Andreas schrieb: > Ich bin mir nicht sicher ob diese Ansicht noch zeitgemäß ist. Schau dir > z.B. mal die Architektur der PS5 an, das ist quasi auch eine APU, und > die spielt bei der Grafikleistung wohl relativ weit vorne mit. Für Konsolengraphik ja, aber die reißt auf dem PC niemanden vom Hocker. Wenn man Auflösung und Details am PC runterdreht, kann man auch da mit APUs spielen - was aber eben nicht gleichwertig zu einer dGPU ist. > Das Konzept, zwei > Recheneinheiten (CPU und GPU) auf verschiedene Platinen mit getrennten > Speichern zu setzen und mit einem langen Bus zu verbinden wuerde einem > heute sehr seltsam vorkommen Nein, würde es nicht, sobald man versteht, daß der RAM-Zugriff zur Laufzeit der Flaschenhals ist und man deswegen auf Graphikkarten GDDR6 einsetzt. Mit DDR4 ist das nicht gleichwertig zu machen. Das Umkopieren in die Graka findet ja z.B. beim Betreten eines neuen Levels statt, wenn die Texturen reingeladen werden, und nicht während des Levels.
Andreas schrieb: > Ich habe mir privat einen M1 Mac Mini bestellt (16GB) um endlich mal > mein 2012 Macbook Pro abzuloesen. Die Standardausstattung mit 8GB RAM > ist allerdings enttaeuschend, auch wenn viel RAM bei schnellen SSDs > heute weniger wichtig scheint als noch vor 10 Jahren. Leider gibt es die > 16GB nur mit inzwischen recht langer Lieferzeit bis knapp vor > Weihnachten. Bin auch am Überlegen ... habe hier noch einen Mini von Mitte 2011 mit dem Quadcore i7 und 16 GByte RAM. Bei Apple hat man sich vermutlich angeguckt was die Leute so kaufen. Und die kaufen sich echt oft Macs mit wenig RAM. Ich sehe das hier immer wieder bei meinen Bekannten. Und das reicht denen auch. Würde mir vermutlich auch reichen, denn die SSDs sind gerade bei Apple sehr schnell. Im Air wurde die SSD mit dem M1 jetzt grob doppelt so schnell https://www.macrumors.com/2020/11/16/apple-silicon-macbook-air-ssd-benchmarks/ ob das zusätzliches RAM kompensieren kann? Unklar, aber für die meisten Nutzer wird das trotzdem reichen, die nehmen das Gerät zum Sufen, Filme gucken, ... Man bedenke: Das mit dem M1 ist das unterste Preissegment, es werden sehr wahrscheinlich noch stärkere Macbook Pros kommen und vermutlich auch ein Highend-Mini. Die haben dann wahrscheinlich auch ein dickeres SoC und zumindest optional mehr RAM. Ich werde jetzt erstmal abwarten ob noch Fehler im M1 auftauchen wie damals beim 2018 Mini der Probleme mit USB2.0 Audio Hardware hatte. Andreas schrieb: > Knösel schrieb: >> Gar nicht. Das ist ja das schöne an der Apple Welt. Software bekommst du >> sowieso nur noch durch genehme Apple Distribution. > > Leute, bitte schreibt doch nicht so einen Unsinn. Exakt, auf dem Mac kann man aktuell (noch) Software einfach so bauen und installieren. Auch auf den Macs mit M1 läuft Homebrew. Wird der goldene Käfig auch da irgendwann kommen wie bei dem iPhone/iPad? Mal gucken, kann sein, bin mir aber nicht sicher.
Gustl B. schrieb: > Bin auch am Überlegen ... habe hier noch einen Mini von Mitte 2011 mit > dem Quadcore i7 und 16 GByte RAM. Mein Mini ist mid 2010. Aber mit RAM komplett ausgebaut (8 GB) und einer SSD statt der HD. Leider verlötet Apple die Komponenten (die SSD doch auch, oder?) und da fällt es mir schwer den gesalzenen Aufpreis zu zahlen.
Nick M. schrieb: > Leider verlötet Apple die Komponenten (die SSD doch auch, oder?) Ja natürlich - sonst würde doch keiner die komplett wahnsinnigen Preise dafür zahlen, sondern sich am Markt für einen Bruchteil selber eine NVMe-SSD kaufen.
Nick M. schrieb: > Leider verlötet Apple die Komponenten Das ist leider ein allgemeiner Trend. Akku verklebt, RAM, CPU, SSD, WLAN verlötet. Aber warum ist das so? Die Mehrheit der Leute rüsten ihre Geräte nie auf. Selbst dann wenn sie das könnten. Ich betreue hier einige PC und Mac Nutzer in meiner Umgebung und sehe nur extrem selten Geräte die aufgerüstet wurden. Eigentlich nur, wenn die Leute in ihrer Verwandtschaft computeraffine Leute haben. Sonst ertragen die Alles, wirklich Alles. Computer die schnarchlangsam sind, bei denen Norton und Kaspersky sich dauernd gegenseitig in Quarantäne schieben, ASK Toolbar im Browser die mehrere Zeilen umfasst, diverse Popups von Adware, ... das ist vielen Leuten egal solange sie damit einmal die Woche Mails lesen oder Onlinebanking machen können. Und dann gibt es noch eine zweite Gruppe die ihre Rechner sehr viel nutzt und trotzdem nicht aufrüstet: Junge Leute (auch Erwachsene) die einfach jedes Jahr neu kaufen. Die melden sich wenn was kaputt geht oder nicht mehr funktioniert, aber sobald die Reparatur etwas komplizierter oder teurer würde kaufen die gleich neu. Ja, es gibt auch Leute die aufrüsten, aber das sind wenige und die kennen sich zumindest etwas aus. Für Hersteller wie Apple deren Nutzer lieber schicke dünne Geräte als aufrüstbare Geräte kaufen lohnt sich diese Kundengruppe nicht.
@GustlB: Mit der Einschätzung hast du wohl Recht wenn ich mich im privaten Umfeld umschaue. Da gabs u.a. einen Laptop, der eine halbe Stunde zum Starten brauchte.
Gustl B. schrieb: > Das ist leider ein allgemeiner Trend. CPU: Platzproblem, Sockel zu gross und zu hoch. Heatpipe behindert. RAM: Bis 3200 geht Sockel, 4266er sind nur verlötet möglich. Bei Schenker/Tuxedo sind SSDs/WLAN/Mobilfunk gesockelt, RAM teilweise. Akku ist verschraubt statt geklebt. Alles gut zugänglich durch verschraubte Bodenplatte.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Bei Schenker/Tuxedo sind SSDs/WLAN/Mobilfunk gesockelt, RAM teilweise. Was auch zur Folge hat, daß sie mit den Preisen dafür nicht wesentlich über die Marktpreise gehen können. Ein kleiner Bequemlichkeitszuschlag für den Kunden geht in Ordnung, aber nicht ein Vielfaches wie bei Apple.
Gustl B. schrieb: > Junge Leute (auch Erwachsene) die einfach jedes Jahr neu kaufen. Die > melden sich wenn was kaputt geht oder nicht mehr funktioniert, aber > sobald die Reparatur etwas komplizierter oder teurer würde kaufen die > gleich neu. Was machen solche Leute mit ihren alten Rechnern? Die Können damit ja nicht ihren Keller vollstellen und der Gebrauchtmarkt auf ebay ist durch solche Leute ja auch nicht gerade attraktiv, sprich es gibt wenig gute Angebote und meist ist alles zu teuer.
Ich habe hier ein Video zum M1 gefunden. Leider mit sehr viel Marketing-Geblubber und Diagrammen ohne Beschriftung der Achsen. Aber einiges konnte ich da doch erfahren, auch wenn ich natürlich nicht weiß ob alles dort gesagte auch stimmt. https://www.youtube.com/watch?v=105iYP6wem8 Inhaltlich hätte man das alles auch in unter 10 Minuten bringen können. Ich hasse solche aufgeblähten Videos. Er hat am Anfang auch versprochen, dass er ins Detail gehen wird. Darauf habe ich dann bis zu Ende erfolglos gewartet. Naja vielleicht in seinem nächsten Video.
Kalle schrieb: > Was machen solche Leute mit ihren alten Rechnern? Oft werden die verschenkt an die Verwandtschaft und landen dann irgendwann entweder im Keller/Dachboden oder werden von Jemandem mit wenig Anspruch so lange genutzt bis sie defekt sind. Es gibt da eine Gruppe älterer Leute, die haben nur deshalb einen Computer weil man den eben für manche Dinge braucht. Nicht weil man den haben will oder irgendwie interessiert ist. Ich denke viele von euch haben solche Verwandte, Bekannte, ... Die werden irgendwann von Verwandten überredet oder sehen es selber ein, dass sie doch auch einen PC/Mac haben sollten, nehmen einen geschenkt, und der steht da dann eben rum und wird genutzt bis der defekt ist. Das sind auch die Leute denen Verwandte irgendwann mal ein Smartphone aufgeschwatzt und dann geschenkt haben, die das aber kaum nutzen und wenn dann für SMS. Leute die jetzt ein Samsung S2 haben das die meiste Zeit ausgeschaltet im Regal liegt. Ich kann das den Leuten auch nicht übel nehmen, wenn ich mal alt bin, dann empfinde ich neue Technik vermutlich auch eher als lästig und sehe darin keinen Mehrwert. Aber diese Personengruppe gibt es, die ist nicht gerade klein, und dorthin wandern viele Gebrauchtgeräte der jungen Generationen die immer das Allerneuste haben möchten.
In diesem anderen Thread wurde behauptet, dass amd64 Emulation sehr schnell sein soll: Beitrag "Re: Apple Mac für Elektronik-Entwicklung" Wie ist das möglich? Auf Linux mit qemu und kvm, also gleiche Architektur, hab ich ja auch sehr gute Performance, aber bei Emulation einer anderen Architektur? Bei Emulation mit Qemu, arm64 auf arm64, oder auch umgekehrt, wird's recht langsam, sicher 2 bis 3 mal, selbst in user mode. Und qemu macht ja glaub ich auch schon JIT. Was ist das Geheimnis von Apple, was machen die anders? Ist die CPU einfach derart schnell, dass es nicht auffällt? (Oder ist es doch nur Marketing Bullshit?)
🐧 DPA 🐧 schrieb: > aber bei Emulation einer anderen Architektur? Bei > Emulation mit Qemu, arm64 auf arm64, oder auch umgekehrt, wird's recht > langsam, sicher 2 bis 3 mal, selbst in user mode. Und qemu macht ja > glaub ich auch schon JIT. Guggstu da: https://www.heise.de/tests/MacBook-Pro-mit-M1-Prozessor-im-ersten-Test-Tolle-Performance-4963035.html Stichwort Rosetta Das hat schon mit dem PowerPC funktioniert und jetzt halt auch mit dem Arm. Apple wird sicherlich nicht so dumm sein alle Kunden zu verärgern die sich neue Hardware kaufen.
Beitrag #6494384 wurde von einem Moderator gelöscht.
🐧 DPA 🐧 schrieb: > Emulation einer anderen Architektur? Um die 70% der Leistung nativen Codes ist nicht ungewöhnlich, da der zu emulierende Binärcode in Binärcode des Hosts umgesetzt wird: https://en.wikipedia.org/wiki/Binary_translation
:
Bearbeitet durch User
(prx) A. K. schrieb: > Je nach Programm sind um die 70% der Leistung nativen Codes nicht > ungewöhnlich, Scheinbar ist die Emulation aber über 100%. Ich zitiere aus dem verlinkten Artikel: "Unter Steam liefen bei uns alle Titel in der Emulation – und zwar bemerkenswerterweise immer schneller als nativ auf dem Intel-Mac. Bei Rise of the Tomb Raider in 1080p-Auflösung gewann der ARM-Mac mit 41 zu 16 Bildern pro Sekunde, bei Shadow of the Tomb Raider war er mit 24 zu 21 fps nur knapp überlegen." 250% find ich "nicht schlecht". Ja, ich hab mir das Beste Extrembeispiel rausgepickt. Und klar, da braucht es noch einiges mehr an Messwerten.
Nick M. schrieb: > Scheinbar ist die Emulation aber über 100%. Das ist bei einem auf aktuellen x86 Systemen emulierten C64 auch nicht anders. ;-) Bei einem Host, der beispielsweise doppelt so schnell wie das Vergleichssystem ist, sind die 70% immer noch mehr als die 100% auf dem Vergleichssystem. Wenn du dann vmtl auch noch verschiedene GPUs mit vergleichst...
:
Bearbeitet durch User
(prx) A. K. schrieb: > Bei einem Host, der beispielsweise doppelt so schnell wie das > Vergleichssystem ist, sind die 70% des emulierten Codes immer noch mehr > als die 100% auf dem Vergleichssystem. Wenn du dann auch noch > verschiedene GPUs mit vergleichst... Dann nenn doch den von dir geforderten Skalierungsfaktor um eine schnellere ARM-Achitektur mit X GHz vergleichbar mit einer Intel-Architektur mit Y GHz und zusätzlich einem um den Faktor Z höheren Stromverbrauch vergleichbar zu machen. Einige werden gespannt auf deine Phantasiezahl warten ...
Nick M. schrieb: > Einige werden gespannt auf deine Phantasiezahl warten ... Falscher Adressat. Die Experten dafür sitzen im Marketing. ;-)
(prx) A. K. schrieb: > Falscher Adressat. Die Experten dafür sitzen im Marketing. ;-) Na, zumindest stammt die Aussage von dir. Oder ist es jetzt nur noch eine nicht belegbare Behauptung?
Beitrag #6494422 wurde von einem Moderator gelöscht.
Wenn man die exakt selbe Anwendung für beide Architekturen kompiliert vorliegen hat, kann man den Geschwindigkeitsunterschied nativ vs. emuliert dort messen. Wenn die Compiler relativ gut sind, müsste es dann hautsächlich darauf ankommen, wie gut die Emulation ist, und (im falle von user mode Virtualisierung) wie viel überhaupt noch emuliert werden muss. Aber so wie ich das hier lese, scheint der Konsensus zu sein: 1) JIT Emulation hat schon einen gewissen Impact aber weniger als 50% verglichen zu nativ 2) der M1 ist schneller als vergleichbar (teure? Energieverbrauchende? was Eigentlich?) Intel CPUs was es wieder ausgleicht 3) und qemu ist nur etwas langsamer weil es noch nicht gleich stark Optimiert wurde wie z.B. rosetta, aber funktioniert ansonsten gleich? So weit richtig?
🐧 DPA 🐧 schrieb: > Wenn man die exakt selbe Anwendung für beide Architekturen kompiliert > vorliegen hat, kann man den Geschwindigkeitsunterschied nativ vs. > emuliert dort messen. LOL! Ja, wenn man es so macht, dann muss die Emulation langsamer sein. Aber auch nur, weil sie maximal unsinnig ist. Wer halbwegs bei Trost ist, wird nicht auf einem Prozessor A einen Code für Prozessor A emuliert durch einen Prozessor B laufen lassen. Das ist aber leider das, das du vorschlägst. Du musst es auf zwei verschiedenen Prozessoren laufen lassen. Alles Andere ist kein Vergleich.
Nick M. schrieb: > Du musst es auf zwei verschiedenen Prozessoren laufen lassen. Alles > Andere ist kein Vergleich. Ganz im Gegenteil. Wenn man aussagen über die Effizienz des Emulators machen will, ist es nicht sinnvoll, da andere Störfaktoren drin zu haben. Zudem kann der Wert danach auch sinnvoll zum Vergleich der Prozessoren verschiedener Architekturen sein. Bei Benchmarks kann man dann ja z.B. den Wert als Korrekturfaktor nehmen, um den Emulationsoverhead raus zu rechnen. Den Sinn dahinter, nur Endanwendungsperformance mit einem zufällig gewählten anderen PC zu vergleichen, kann ich hingegen nicht sehen. Das sagt dann ja nur etwas über exakt die 2 PC Systeme aus, aber sonst nichts.
🐧 DPA 🐧 schrieb: > Den Sinn dahinter, nur Endanwendungsperformance mit einem zufällig > gewählten anderen PC zu vergleichen, kann ich hingegen nicht sehen. Das > sagt dann ja nur etwas über exakt die 2 PC Systeme aus, aber sonst > nichts. Wenn es dein Ziel ist, Vergleiche zu verhindern, dann ist dein Ansatz optimal. So kann ich immer behaupten dass mein Apple II (den ich nicht hab) schneller als der Ryzen von 2025 ist (den ich auch nicht hab).
(prx) A. K. schrieb: > Bis 3200 geht Sockel, 4266er sind nur verlötet möglich. Das würde ich so nicht unterschreiben. Bei mir läuft der RAM mit 3600 und auch schon mit 3800. Es gibt mittlerweile auch Module mit 5000 (Corsair wenn ich mich nicht irre), zugegeben muss hier ein Mainboard mit sehr gutem Layout her. Der Hauptgrund für die Hersteller alles in einen SOC zu integrieren und zu verlöten ist meiner Meinung nach hauptsächlich um Platz zu sparen und um die Energieeffizienz zu maximieren. Natürlich hat man dadurch auch ein Stück weit gewisse Vorteile was die Taktraten und die Produktion angeht. Bei Apple spielt imho auch mit, dass man eben nichts mehr aufrüsten kann, wodurch der Nutzer gezwungen ist ein neues Gerät zu kaufen. Eine Schiene die sie schon länger fahren, sie hatten ja zuletzt auch ihren "eigenen M.2 Anschluss" und dergleichen. Zu der Geschichte mit den iGPUs und dGPUs finde ich es persönlich quatsch Äpfel mit Birnen zu vergleichen. Natürlich sind iGPUs mittlerweile für vieles brauchbar aber weit davon entfernt an eine dGPU ran zu kommen. Alleine die zur Verfügung stehende Chipfläche ist dafür viel zu gering und fehlt unter umständen auch der CPU. Wie soll man eine iGPU mit 192 Shadern (UHD630) mit einer dGPU die 3000 oder teilweise 8000 oder mehr hat vergleichen? Von den zusätzlichen Recheneinheiten für Raytracing und Tensorflow mal abgesehen. Ein anderer Punkt ist die mögliche Leistung, eine dGPU genehmigt sich in der Spitzenklasse gut und gerne mal 200W bis 300W, zusammen mit den 100W+ der CPU bekommt man die Abwärme mit normalen Kühlmethoden nie nimmer vom Die weg. Mal davon abgesehen, dass die Speicherbandbreite in einer komplett anderen Liga spielt. DDR4 auf den die iGPUs zurückgreifen kommen vielleicht auf 20-25GB/s, wohingegen GDDR6 bei 400-500GB/s und GDDR6X um die 750GB/s liegt. HBM2 ist mit bis zu 1TB/s nochmal eine Hausnummer dicker wobei das zugegeben nur in compute Karten Sinn macht.
Beitrag #6494526 wurde vom Autor gelöscht.
Nick M. schrieb: > 🐧 DPA 🐧 schrieb: >> Wenn man die exakt selbe Anwendung für beide Architekturen kompiliert >> vorliegen hat, kann man den Geschwindigkeitsunterschied nativ vs. >> emuliert dort messen. > > LOL! > Ja, wenn man es so macht, dann muss die Emulation langsamer sein. Natürlich. Deshalb klangen deine >100% auch sehr abenteuerlich. > Aber auch nur, weil sie maximal unsinnig ist. Um Programme zu nutzen ja, aber um die den Leistungsverlust durch die Emulation zu beurteilen, ist das die einzige Möglichkeit. Und darum ging es ja in der Aussage: (prx) A. K. schrieb: > Um die 70% der Leistung nativen Codes ist nicht ungewöhnlich, > Wer halbwegs bei Trost ist, wird nicht auf einem Prozessor A einen Code > für Prozessor A emuliert durch einen Prozessor B laufen lassen. Das ist > aber leider das, das du vorschlägst. > > Du musst es auf zwei verschiedenen Prozessoren laufen lassen. Alles > Andere ist kein Vergleich. Nein. Wenn du wissen willst, wieviel dich die Emulation kostet, musst du das Programm einmal nativ und einmal auf der selben CPU in der Emulation laufen lassen. Wenn du dagegen wissen willst, welcher Prozessor schneller ist, musst du das Programm auf beiden CPUs jeweils nativ laufen lassen. Du willst jetzt aber beides vermischen.
Und wenn du wissen willst, ob der neue Rechner auch dann schneller ist, wenn er (teilweise) mit alten Programmen gefüttert wird, darf man auch die native Ausführung auf dem alten Rechner mit der Emulation auf dem neuen vergleichen. Hängt alles davon ab, was man eigentlich wissen will.
Rolf M. schrieb: > Nein. Wenn du wissen willst, wieviel dich die Emulation kostet, musst du > das Programm einmal nativ und einmal auf der selben CPU in der Emulation > laufen lassen. Schön! Und wie kann ich jetzt damit einen aktuellen MacBook Pro mit einem Aktuellen MacBook Pro ARM vergleichen? Garnicht. Und scheinbar ist das aber dein Ziel. Sorry, aber damit ist niemanden geholfen.
Nick M. schrieb: > Rolf M. schrieb: >> Nein. Wenn du wissen willst, wieviel dich die Emulation kostet, musst du >> das Programm einmal nativ und einmal auf der selben CPU in der Emulation >> laufen lassen. > > Schön! > Und wie kann ich jetzt damit einen aktuellen MacBook Pro mit einem > Aktuellen MacBook Pro ARM vergleichen? Nochmal: Es ging um die Aussage, dass man mit Emulation etwa 70% der nativen Geschwindigkeit auf der selben CPU erreichen kann, nicht mehr und nicht weniger. Und dann kamst du mit deinen >100%, die aber auf einem Vergleich mit einer anderen CPU basieren. > Garnicht. Und scheinbar ist das aber dein Ziel. Das Ziel war die Frage, wie effizient eine Emulation sein kann, weil sich jemand gewundert hat, dass die Emulation so schnell läuft.
Beitrag #6494629 wurde vom Autor gelöscht.
Rolf M. schrieb: > Das Ziel war die Frage, wie effizient eine Emulation sein kann, weil > sich jemand gewundert hat, dass die Emulation so schnell läuft. Der thread-Titel ist, ob die M1 CPU wirklich so gut ist. Dabei wurde gesagt, dass es doch nicht sein kann, dass ein emulierter Intel auf dem M1 schneller sein kann. Das hab ich mit link für jeden selbst nachvollziehbar aufgezeigt. Wenn das dein eigenes Hobby-thema ist, dass eine Emulation immer langsamer als die emulierende CPU sein muss (was zweifelsfrei richtig ist), dann bringt das den thread nicht wirklich weiter. Und damit solls das für mich gewesen sein.
Nick M. schrieb: > Der thread-Titel ist, ob die M1 CPU wirklich so gut ist. Dabei wurde > gesagt, dass es doch nicht sein kann, dass ein emulierter Intel auf dem > M1 schneller sein kann. Nein, das war im anderen Thread, auf den ich verlinkt hatte. Ich fragte, nicht ob, sondern wie das möglich sei, weil mich wunder nahm, ob deren ARM CPU oder deren Emulation so gut ist (und ob andere Emulationstechnologien da noch was lernen könnten). Nick M. schrieb: > Und wie kann ich jetzt damit einen aktuellen MacBook Pro mit einem > Aktuellen MacBook Pro ARM vergleichen? Wenn die Emulation Dinge um ~30% verlangsamt, und das MacBook Pro ARM ein amd64 Program trotzdem gleich schnell oder schneller ausführt als ein MacBook Pro, dann müsste das MacBook Pro ARM mindestens ~143% (100%=x*70%) schneller sein als das MacBook Pro. Schlechtere Emulationseffizienz impliziert dabei bessere CPU Leistung. Wobei, das ist noch kein wirklicher Vergleich der CPUs. Jenachdem, ob diese z.B. auf niedrigen Energieverbrauch oder auf Leistung optimiert sind kann sich das Verhältnis eventuell wieder ändern. Und die ~30% sind ja auch nur wild geraten.
🐧 DPA 🐧 schrieb: > MacBook Pro ARM mindestens ~143% > (100%=x*70%) schneller sein als das MacBook Pro. Wobei für den Praktiker nicht unbedingt der Vergleich mit dem neuesten Intel-Mac zählt, sondern mit alten Teil, was er rumstehen hat. Soll heissen: Ist der neue derart schneller als der alte, um die Ausgabe zu rechtfertigen? Wobei da noch der sonst eher seltene Effekt hinzu kommt, dass der neue mit der Zeit schneller wird, wenn anfangs emulierte Programme später nativ zur Verfügung stehen.
:
Bearbeitet durch User
Wenn Apple das wirklich konsequent durchzieht, könnte das bald Intel alt aussehen lassen. Klar, solche Computer kann man nicht aufrüsten, aber das will die Zielgruppe von Apple ja ohnehin nicht. https://www.heise.de/news/ARM-Macs-High-End-Modelle-mit-viel-mehr-Kernen-in-Arbeit-4982499.html
Intel wird von zwei Seiten in die Zange genommen. Einerseits springt Apple ab, andererseits liegt AMD auf Windows/Linux bei hochparallelen Anwendungen um Längen vorne.
:
Bearbeitet durch User
Hochparallele Anwendungen sind und bleiben aber Nischenanwendungen. Die meisten Anwendungen kann man nicht extrem paralellisieren. Und wenn Apple auf den Server will, müssen sie sich überlegen wie sie mehr RAM anbinden wollen und sie müssen dafür sorgen, dass Linux auf ihren Systemen läuft. Ob der M1 wirklich so bahnbrechend ist, muss sich erst noch zeigen. Die extremen Lobgesänge hört man eher von technischen Laien als von Leuten, die was davon verstehen.
Hansi schrieb: > Hochparallele Anwendungen sind und bleiben aber Nischenanwendungen. Auf dem Server sicher nicht. Davon abgesehen beeindruckt der M1 aber gerade bei der single core performance, wenn der die Intel-Konkurrenz nur durch stumpfe Parallelisierung überholt hätte, dann hätte das wohl keine so große Aufmerksamkeit erregt. Apple auf dem Server sehe ich nicht wirklich, allerdings ist da ARM (Gravitron2) auch schon am Start. Und ebenfalls mit recht beeindruckenden Ergebnissen. Wenn man sich anschaut welche Rolle heutzutage die großen Cloud-Anbieter spielen, und dann vergegenwärtigt dass die problemlos ihre Dienste von heute auf morgen auf eine andere Architekturen verschieben können, dann kann man sich auch ein Szenario vorstellen in dem Intel auf dem Servermarkt durch CPUs überholt wird die niemals auf dem freien Markt auftauchen.
(prx) A. K. schrieb: > Intel wird von zwei Seiten in die Zange genommen. Einerseits springt > Apple ab, andererseits liegt AMD auf Windows/Linux bei hochparallelen > Anwendungen um Längen vorne. Dazu kommt, das nun auch die Asiaten auch wieder vermehrt in den x86 Markt einsteigen: https://en.m.wikipedia.org/wiki/Zhaoxin Andreas schrieb: > Apple auf dem Server sehe ich nicht wirklich, allerdings ist da ARM > (Gravitron2) auch schon am Start. Und ebenfalls mit recht > beeindruckenden Ergebnissen. Ich zweifle daran, das Apple noch mal versuchen würde in den Markt einzusteigen.
Hansi schrieb: > Hochparallele Anwendungen sind und bleiben aber Nischenanwendungen. In Benchmarks, die von AMD im Rahmen der Renoir Notebook-Prozessoren präsentiert werden, sind sie die Regel. Also allerlei Rendering, Videokomprimierung etc. Denn da liegt AMD sehr weit vor Intel. In Benchmarks, die von Intel im Rahmen der Tiger Lake Notebook-Prozessoren präsentiert werden, sind sie die Ausnahme. Die ziehen es vor, Office, Browser und so zu präsentieren. Denn da liegt Intel etwas vor AMD. Wobei ein AMD 4800H mit ~50W Dauerleistung in 14-15 Zoll Notebooks locker auch als Desktop-Ersatz bei lastintensiven Anwendungen einsetzbar ist.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 🐧 DPA 🐧 schrieb: >> MacBook Pro ARM mindestens ~143% >> (100%=x*70%) schneller sein als das MacBook Pro. > > Wobei für den Praktiker nicht unbedingt der Vergleich mit dem /neuesten/ > Intel-Mac zählt, sondern mit alten Teil, was er rumstehen hat. Soll > heissen: Ist der neue derart schneller als der alte, um die Ausgabe zu > rechtfertigen? > > Wobei da noch der sonst eher seltene Effekt hinzu kommt, dass der neue > mit der Zeit schneller wird, wenn anfangs emulierte Programme später > nativ zur Verfügung stehen. Ich hatte ja schonmal woanders geschrieben das sich für mich die Möglichkeit ergeben hatte hier einen, zugegebenermaßen stark Anwendungsspezifischen und möglicherweise auch nicht super aussagekräftigen, Test mit verschiedenen Windows, Linux und auch dem Apple M1 im Macbook machen konnte. (Wiresharkdatei von etwa 600MB öffen (vorher entpacken, also aus dem Cache)) und danach noch filtern. Auf dem M1 lief die Intel version des Wireshark. Der ist tatsächlich erstaunlich schnell dabei und schlägt von der Zeit her alle verfügbaren Windows Notebooks inklusive Core i7-xxxxH. Bei Linux ist der Abstand nicht mehr so groß und im Vergleich zum Linux Desktop war er langsamer (aber nicht viel). Wie groß der Vorsprung zu einem Intel-Mac ist konnten wir leider nicht testen. Ich werde die Ergebnisse bei Gelegenheit mal auf eine Seite packen. Ja der M1 ist wirklich schnell, der Test hat aber auch ergeben, das Windows 10 bei der Aufgabe sehr schlecht abschneidet. (auch im Vergleich mit Linux, trotz höherer CPU Leistung) Was mich schon gewundert hat.
Nick M. schrieb: > Scheinbar ist die Emulation aber über 100%. Der JIT auf dem Host kann sich die besten Opcodes auf der verfügbaren CPU rauspicken. Je nach originalem Compiler kann das einen deutlichen Unterschied ausmachen. Das hat man bei Rosetta bereits gesehen. Ich hab hier einen i8080-Simulator in C gebastelt (kein JIT). Ein Durchlauf der gesamten Testsuite (testet fast alle Instruktionen, dauert etwa 3h bei real 2 MHz) ergibt auf einem Notebook mit älterem Core i5 ein i8080-Äquivalent von etwa 700 MHz. Soweit nicht besonders überraschend. Auf einem neueren Notebook mit recht aktuellem Core i7 ergibt sich ein i8080-Äquivalent von über 6 GHz. Der Host taktet mit weniger als der Hälfte und die Hauptschleife ist nicht gerade winzig. Und was Spiele angeht... da spielt die GPU-Performance auch eine Rolle, und wenn zusätzlich noch optimierte Host-Bibliotheken eingebunden werden, die für das Original nicht existierten... da geht einiges.
Andreas schrieb: >> Hochparallele Anwendungen sind und bleiben aber Nischenanwendungen. > > Auf dem Server sicher nicht.... Habe auch nie gegenteiliges behauptet. Aber wenn du ein Zitat von mir aus dem Zusammenhang reißt, um mir etwas in den Mund zu legen, sagt das schon etwas gewisses über dich aus.
Auf Heise ist ein kurzer Artikel wie "jetzt" Microsoft auf den Mac-ARM reagiert. "Windows on ARM: x64-Emulation als Insider-Preview verfügbar" https://www.heise.de/news/Windows-on-ARM-x64-Emulation-als-Insider-Preview-verfuegbar-4986997.html Jedenfalls gibt es nicht wirklich eine Windows-Hardware mit ARM. Heise beziffert die mit "einer Handvoll". Als ARM für Windows gibt es auch nichts was aktuell wäre, Qualcomm hat bis jetzt keinen Nachfolger für den Snapdragon 8cx angekündigt.
Hansi schrieb: > Hochparallele Anwendungen sind und bleiben aber Nischenanwendungen. Die > meisten Anwendungen kann man nicht extrem paralellisieren. Gegenfrage: Für welche Singlecore-Anwendungen reicht denn der einzelne Kern des M1 nicht aus? Das meiste was Rechenleistung braucht wird doch auf die Kerne oder gleich in die GPU verteilt. Letzteres ist aktuell der einzige Schwachpunkt. Wenn man für seine Anwedung eine richtig schnelle dedizierte GPU oder sehr viel RAM braucht, taugt der M1 noch nicht. Aber da wird Apple ja wohl noch nachlegen. Ein SoC-Variante mit ein paar PCIe-Lanes und externer Speicherschnittstelle würde beide Probleme erledigen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.