Hi Leute, mal eines Vorweg: Ich will hier jetzt keine generelle Diskussion pro / contra Apple führen. Fakt ist aber, dass es extrem viele Gerüchte im Netz aktuell gibt, dass Apple nächste Woche auf der WWDC bekannt geben wird, dass zukünftige Mac Plattformen wahrscheinlich auf ARM statt auf Intel CPUs aufsetzen werden. Das heißt also, Apple wird die CPUs selber designen. Als Hauptargument wird dort immer wieder Energieeffizienz genannt. Jetzt stelle ich mir nur so paar Fragen: 1. Ich dachte immer der x86 Befehlssatz wäre "machtvoller" als der von ARM 2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz -> Muss also eine ARM CPU einen vergleichbar komplexen Algorithmus wie eine Intel-CPU rechnen (und man hat vergleichbare Technologiegröße + Taktfrequenz) müsste doch eigentlich ARM immer im Nachteil liegen? Mir geht es nicht in den Kopf, wie man eine ähnlich performante CPU wie einen Core i7 o.ä. auf die Beine stellen will, der komplett ohne Kühlung auskommen soll.
> dass zukünftige Mac Plattformen wahrscheinlich auf ARM
Das ist mir sowas von voellig egal.
Der Obstkonzern spielt bei Plattformen die "echte" Leistung
bringen schon lange keine Rolle mehr.
Markus schrieb: > 1. Ich dachte immer der x86 Befehlssatz wäre "machtvoller" als der von > ARM x86 schleppt eine lange Geschichte von Architekturvarianten und Befehlssatzerweiterungen mit rum. Das macht den Befehlssatz vor allem grösser und die CPU aufwändiger, aber nicht zwingend mächtiger. Dafür hat ARMv8 32 Register, amd64 nur 16. Interessanter als der skalare Befehlssatz ist der Vektor-Kram, also beispielsweise die SSE-Varianten. Wenn man das brauchen kann. > 2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein > Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz Und zwar multipliziert mit der Anzahl pro Takt schaltender Komponenten. Ebendort liegt der Hase im Pfeffer, denn x86 ist wesentlich aufwändiger zu dekodieren. Das war allerdings früher bedeutender als heute. > Mir geht es nicht in den Kopf, wie man eine ähnlich performante CPU wie > einen Core i7 o.ä. auf die Beine stellen will, der komplett ohne Kühlung > auskommen soll. Wieso ohne Kühlung? Geh davon aus, dass Macs auf ARM-Basis andere CPUs verwenden werden, als jene in den iPhones. Die Cores könnten vielleicht die gleichen sein, zumal anfangs, aber dafür mehr Cores bei höherer Taktfrequenz. Mit Kühlung. Je nach Zielmarkt des Gerätes mit niedrigen TDPs für extrem leichte Notebooks und Prozessoren mit zig Watt für Desktops.
:
Bearbeitet durch User
Vor Jahren sind sie den umgekehrten Weg gegangen. Weil die exklusive Hardware zu teuer wurde. Warum nicht wieder anders, wenn die Bedingungen stimmen?
Wenn man sich die Performance-Daten von Apples Prozessoren in den iPhones ansieht, dann entsteht der Eindruck, dass Apple einen verdammt guten Job macht. Sie haben die wohl leistungsfähigsten Cores aller in Handys verbauten ARMs, bei vergleichbarem Stromverbrauch. Samsung hat natürlich auch das nachzumachen versucht, mit den vollständig selbst entwickelten M1..M6 Cores. Aufgrund chronischer Erfolglosigkeit wurde das aber im Herbst letzten Jahres eingestellt. Samsung hat es nicht geschafft, die durchaus höhere Leistungsfähigkeit dieser Cores so umzusetzen, dass dabei für den Anwender mehr Leistung bei ähnlicher Akkulaufzeit rauskam - im Gegenteil. Wer sich für Details zum Unterschied zwischen den Samsung- und Qualcomm-Prozessoren interessiert, der sollte sich die Artikel von Andrei Frumusanu von Anandtech über die beiden CPU-Varianten des Galaxy S9(+) ansehen.
:
Bearbeitet durch User
> Weil die exklusive Hardware zu teuer wurde. > Warum nicht wieder anders, wenn die Bedingungen stimmen? Die PowerPC-Architektur war fuer Apple ein intellektuelles Zukaufteil. Keine Chance um es mit eigenen Resourcen nennenswert zu verbessern. Das PowerPC nicht tot ist, beweisen aktuelle Modelle der IBM. Wenn ich mir aber Rechner wie den neuen Mac Pro ansehe, habe ich so meine Zweifel ob die Rechnung da aufgeht. Sinnarmes "Designer-"Zubehoer steht mit 3-4 stelligen Summen in der Preisliste. Die Kunden die wirklich Leistung brauchen, werden Apple nicht mal im Ansatz in Erwaegung ziehen. Und Software fuer ARM in diesem Umfeld steht auch noch nicht bereit. > Performance-Daten von Apples Prozessoren in den iPhones ansieht Das ist ein Consumerspielzeug. Vielleicht sehr leistungsfaehig. Aber trotzdem nur ein Conumserspielzeug.
Markus schrieb: > Fakt ist aber, dass es extrem viele Gerüchte im Netz aktuell gibt, dass > Apple nächste Woche auf der WWDC bekannt geben wird, dass zukünftige Mac > Plattformen wahrscheinlich auf ARM statt auf Intel CPUs aufsetzen > werden. Wenn das so ein Fakt ist, wo ist dann die Quelle? Meines Wissens ist das Gerücht, sie steigen von Intel auf AMD um (!= ARM) Und da bleibt die Architektur erstmal gleich.
oerks schrieb: > Aber trotzdem nur ein Conumserspielzeug. Deine Meinung sei dir unbenommen (wenngleich sie auf die Fragen des TE in keiner Weise eingeht), aber die Einhaltung der Forenregeln ist auch für dich erforderlich: ein Name pro Thread bitte.
Markus schrieb: > Mir geht es nicht in den Kopf, wie man eine ähnlich performante CPU wie > einen Core i7 o.ä. auf die Beine stellen will, der komplett ohne Kühlung > auskommen soll. Naja, weil für den Computernutzer von heute die Performance der CPU's von vorgestern völlig ausreichend ist. Und die Anwendungen die wirklich Performance brauchen, sind eh nicht für Apples verfügbar. bspw FPGA-synthese. >2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein >Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz Ach, je kleiner die Struktur, desto geringer die Verlustleistungen? - ja wenn es die leckströme nicht gäbe.
https://www.zdnet.de/88380636/bericht-apple-stellt-plaene-fuer-eigene-cpus-in-macs-auf-der-wwdc-vor/#:~:text=Die%20ersten%20Mac%20mit%20Apples,zufolge%202021%20auf%20den%20Markt.&text=Apple%20soll%20anl%C3%A4sslich%20seiner%20Entwicklerkonferenz,f%C3%BCr%20seine%20Mac%2DComputer%20ank%C3%BCndigen. Und es stimmt nicht, Apple hat nicht erst zweimal die CPU-Familie in seinem Computern gewechselt sondern viermal: 6502->68k->PowerPC->intel Falls man den Newton PDA hinzuzählt wäre es eine fünfte, und mit den pod/pads/tablets ARM als sechste CPU-Familie im Portfolio.
Radar mit der Rute schrieb: > Und es stimmt nicht, Apple hat nicht erst zweimal die CPU-Familie in > seinem Computern gewechselt sondern viermal: > > 6502->68k->PowerPC->intel Zähl lieber noch einmal nach. Die Wechsel, also die Pfeile, nicht die CPU-Familien. ;-) Und wenn du den 6502 mitrechnest, der ja kein Mac antrieb, dann ist ARM nichts Neues, denn den haben sie schon in den iPhones.
:
Bearbeitet durch User
A. K. schrieb: > Radar mit der Rute schrieb: >> Und es stimmt nicht, Apple hat nicht erst zweimal die CPU-Familie in >> seinem Computern gewechselt sondern viermal: >> >> 6502->68k->PowerPC->intel > > Zähl lieber noch einmal nach. Die Wechsel, also die Pfeile, nicht die > CPU-Familien. ;-) Hehe, ich zähl von Undefiniert auf Init-Zustand (hier 6502) auch als Wechsel, isse wohl Berufskrankheit ;-) > Und wenn du den 6502 mitrechnest, der ja kein Mac antrieb, dann ist ARM > nichts Neues, denn den haben sie schon in den iPhones. Nee, iphone war nicht das erste ARM-Geschoß bei Apple, davor gabs es IPod (ARM7TDMI) und davor der Newton (ARM610-StrongARM). Und ARM ohne Apple reicht sogar noch weiter zurück, zum Acorn Archimedes und so (Ja das A in ARM, steht nicht für Apple, sondern für Acorn). Aber OK, manche sagen Apple ohne Steve Jobs war nicht Apple und lassen den Newton unter den Tisch fallen (so wie Steve Jobs es bei seiner Rückkehr tat). >Sie hatten auch noch 6809 und VAX probiert. VAX ist mir neu, da lern ich gern zu, 6809 war die kaputtgesparte Spec von Jef Raskin für den Ur-Mac, die glücklicherweise nie als Apple-Produkt realisiert wurde. Da war es Steve Jobs, der den 68k durchdrückte. Ohne diesen (zweiten) Schritt zum 68k wäre Apple nach dem Lisa-Desaster nie in die Profiliga aufgestiegen.
Den 6809 kippten sie, weil das geplante Mac-GUI darauf nicht realisierbar war. Die VAX emulierte Macs, als sie QuickTime entwickelten und die Macs wohl zu der Zeit zu langsam waren.
michael_ schrieb: > Vor Jahren sind sie den umgekehrten Weg gegangen. > Weil die exklusive Hardware zu teuer wurde. > Warum nicht wieder anders, wenn die Bedingungen stimmen? Ich glaube mich an die Rede von Steve Jobs zu erinnern, in der er den Weggang vom PowerPC zu Intel begründete. Grob vereinfacht ging es darum, dass Apple immer zuletzt und nur unzureichend beliefert wurde, weil PowerPCs gerade für die Server anderer Hersteller wie geschitten Brot gingen ... so nach dem Motto: Jetzt reichts!
Frank E. schrieb: > Grob vereinfacht ging es darum, > dass Apple immer zuletzt und nur unzureichend beliefert wurde, weil > PowerPCs gerade für die Server anderer Hersteller wie geschitten Brot > gingen ... so nach dem Motto: Jetzt reichts! Da der heise-report zum Wechsel PPC->intel: https://www.heise.de/ct/artikel/Apple-faellt-vom-Stamm-289950.html Das Top-End (3 GHz, dualCore) hat IBM ewig nicht lieferbar bekommen, und mit intel als CPI hat man auch Zugriff auf deren Chipsätze, die nebenher einige wichtige Peripherie und integrierte Graphikbeschleuniger mitbrachten.
Jetzt ist es offiziell: Macs werden auf ARM umgestellt. Das heißt wohl dann auch Windows per Bootcamp wirds nicht mehr geben :( https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/
Markus schrieb: > Fakt ist aber, dass es extrem viele Gerüchte im Netz aktuell gibt Na wenn wenigstens das Vorhandensein von Gerüchten ein Fakt ist… A. K. schrieb: >> 2. Verlustleistung ist zumindest meines Wissens nach hauptsächlich ein >> Produkt aus verwendeter Technologie(Strukturgröße) und Taktfrequenz > > Und zwar multipliziert mit der Anzahl pro Takt schaltender Komponenten. > Ebendort liegt der Hase im Pfeffer, denn x86 ist wesentlich aufwändiger > zu dekodieren. Das war allerdings früher bedeutender als heute. Ja, schon alleine deshalb, weil trotz dieser Komplexität moderne CPUs eh vor allem aus Cache bestehen. oerks schrieb: >> Performance-Daten von Apples Prozessoren in den iPhones ansieht > > Das ist ein Consumerspielzeug. Vielleicht sehr leistungsfaehig. > Aber trotzdem nur ein Conumserspielzeug. Leistungsfähig für ein Handy. Aber Laptops arbeiten doch in ganz anderen Leistungsklassen. Da frage ich mich schon, wie die mal kurz einen ARM aus dem Hut zaubern wollen, der es mit einem i7 oder einem aktuellen Ryzen aufnehmen kann. Und wo sie die "higher performance GPUs" aus ihrem Announcement her kriegen wollen, bleibt auch unklar. Was gibt's denn da aktuell, das schneller ist als die PC-Grafikchips von NVidia und AMD?
Einen eigenen Prozessor .. so, so. Es gab auch schon mal so eine Firma, eine Riesenfirma, sehr erfolgreich, die dachte als Marktfuehrer muessten sie was Eigenes haben. Die Firma hiess DEC (Digital Equipment Corporation) der Prozessor Alpha-64, war als 64bit Controller gedacht. Extrem advanced in den mid-80ern. Irgendwie gibt's die Firma heute nicht mehr...
Die hatten auch nicht ein paar hundert Milliarden auf der hohen (offshore) Kante :-) Dafür läuft dann Bootcamp "nur" noch mit Linux und ChromOS, vielleicht gibts dann sogar noch RiscOS ;-)
Markus schrieb: > 1. Ich dachte immer der x86 Befehlssatz wäre "machtvoller" als der von > ARM Ich bin in dem Thema nicht mehr so drin, aber ich glaube, dass RISC eher Vorteile hat. Früher als die Compiler noch nicht so gut optimiert haben, war es gut, spezielle komplexe Befehle zu haben, die für komplexe Aufgaben aufgerufen werden konnten. Heute optimieren die Compiler sehr gut und da ist man flexibler und nicht langsamer, wenn man die komplexen CISC-Befehle aus einer Reihe von RISC-Befehlen nachbaut.
Joggel E. schrieb: > Einen eigenen Prozessor .. so, so. Es gab auch schon mal so eine Firma, > Die Firma hiess DEC (Digital Equipment Corporation) der Prozessor > Alpha-64, war als 64bit Controller gedacht. Extrem advanced in den > mid-80ern. Irgendwie gibt's die Firma heute nicht mehr... Nur sind die nicht so sehr an Alpha ersoffen, sondern am vorherigen Versuch, die VAX Architektur über das natürliche Ende ihrer architekturbedingten Zeitspanne hinaus am Leben zu erhalten. Da wurde zu viel Zeit und Geld drin versenkt. Alpha war allerdings zu ziemlich das Gegenteil eines Controllers. Und es waren die 90er, nicht die 80er.
:
Bearbeitet durch User
Dussel schrieb: > Früher als die Compiler noch nicht so gut optimiert haben, war es gut, > spezielle komplexe Befehle zu haben, die für komplexe Aufgaben > aufgerufen werden konnten. Bereits in den 70ern stellte IBM intern fest, dass die Compiler solche komplexen Befehle wenig bis überhaupt nicht verwendeten und eine einfacher aufgebaute RISC Maschine den Mainframes das Wasser abgesehen könnte. Auch VAX Anwender, die sich in Assembler abmühten, nutzten hochkomplexe gut gemeinte Befehle hauptsächlich dann, wenn sie es nicht eilig oder keine Ahnung hatten. Denn zu Fuss wars meist schneller.
xyz schrieb: > Jetzt ist es offiziell: > > Macs werden auf ARM umgestellt. > Das heißt wohl dann auch Windows per Bootcamp wirds nicht mehr geben :( > https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/ Das erste Argument ist dabei aber auch nicht "mehr Leistung" oder "weniger Energieverbrauch" sondern: > This transition will also establish a common architecture across all Apple > products, making it far easier for developers to write and optimize their > apps for the entire ecosystem. Ich halte es nicht für unmöglich, dass das sogar für Apple das wichtigste Argument ist. Und es gibt durchaus Windows auf ARM. Muss also nicht das Ende für Windows per Bootcamp sein. MfG, Arno
A. K. schrieb: > Alpha war allerdings zu ziemlich das Gegenteil eines Controllers. Und es > waren die 90er, nicht die 80er. Und lebt ein bisschen bei AMD weiter. Viele ehemalige DEC-Entwickler sind nach der Pleite zu AMD und haben entscheidend zum Athlon (oder war es der K6?) beigetragen.
Arno schrieb: >> This transition will also establish a common architecture across all Apple >> products, making it far easier for developers to write and optimize their >> apps for the entire ecosystem. > > Ich halte es nicht für unmöglich, dass das sogar für Apple das > wichtigste Argument ist. Warum? Ob man das jetzt für x86 oder ARM compiliert, ist doch für den Entwickler ziemlich egal. Intel hat bei seinen Atom-Prozessoren mal behauptet, der große Vorteil von x86 gegenüber ARM im Handy sei genau das, dass Entwickler leichter Code dafür schreiben und optimieren können. Hat dort auch schon nicht geklappt. Es gibt aber den Vorteil, dass man für iPad compilierte Apps nativ auf dem Mac laufen lassen kann, was ja auch erwähnt wurde: "And for the first time, developers can make their iOS and iPadOS apps available on the Mac without any modifications." > Und es gibt durchaus Windows auf ARM. Aber wie viele Programme laufen da auch drunter?
:
Bearbeitet durch User
Rolf M. schrieb: > Arno schrieb: >>> This transition will also establish a common architecture across all Apple >>> products, making it far easier for developers to write and optimize their >>> apps for the entire ecosystem. >> >> Ich halte es nicht für unmöglich, dass das sogar für Apple das >> wichtigste Argument ist. > > Warum? Ob man das jetzt für x86 oder ARM compiliert, ist doch für den > Entwickler ziemlich egal. Intel hat bei seinen Atom-Prozessoren mal > behauptet, der große Vorteil von x86 gegenüber ARM im Handy sei genau > das, dass Entwickler leichter Code dafür schreiben und optimieren > können. Hat dort auch schon nicht geklappt. Den ersten Teil, "common architecture across all Apple products". Ob das den Entwicklern von Apps etwas bringt, wage ich zu bezweifeln, aber intern für Apple könnte es etwas bringen. Sorry, das habe ich nicht klar herausgestellt. MfG, Arno
Arno schrieb: > Den ersten Teil, "common architecture across all Apple products". Ach so. Na dann stimme ich dir zu.
Rolf M. schrieb: > Leistungsfähig für ein Handy. Aber Laptops arbeiten doch in > ganz anderen Leistungsklassen. Da frage ich mich schon, wie > die mal kurz einen ARM aus dem Hut zaubern wollen, der es mit > einem i7 oder einem aktuellen Ryzen aufnehmen kann. Man kann aktuelle Smartphone-CPUs durchaus als gebrauchbare Buildserver benutzen - wenn man da entsprechende Kühlung ranflanscht. Was natürlich mit dem Smartphone-Formfaktor nicht geht, weil niemand mit einem 70°C-Telefon in der Tasche umherlaufen will. A. K. schrieb: > Bereits in den 70ern stellte IBM intern fest, dass die Compiler > solche komplexen Befehle wenig bis überhaupt nicht verwendeten > und eine einfacher aufgebaute RISC Maschine den Mainframes das > Wasser abgesehen könnte. Naja, und heute haben wir eine RISC-Architektur namens ARM mit so Befehlen wie "FJCVTZS" ("Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero"). Ich weiß ja nicht. Alle 10 Jahre muss Krypto erneut verboten werden. Alle 30 Jahre müssen CISC-CPUs neu erfunden werden? (Natürlich immer unter anderem Namen, wissenschon.)
:
Bearbeitet durch User
S. R. schrieb: > Rolf M. schrieb: >> Leistungsfähig für ein Handy. Aber Laptops arbeiten doch in >> ganz anderen Leistungsklassen. Da frage ich mich schon, wie >> die mal kurz einen ARM aus dem Hut zaubern wollen, der es mit >> einem i7 oder einem aktuellen Ryzen aufnehmen kann. > > Man kann aktuelle Smartphone-CPUs durchaus als gebrauchbare Buildserver > benutzen - wenn man da entsprechende Kühlung ranflanscht. Was natürlich > mit dem Smartphone-Formfaktor nicht geht, weil niemand mit einem > 70°C-Telefon in der Tasche umherlaufen will. Nun sind Apple-Rechner nicht die typischen Geräte, die man als Build-Server verwendet. Soweit ich weiß, kann x86 im Bezug auf die Energiesparfunktionen nicht mit ARM mithalten, dafür kann ARM bei der maximalen Leistung nicht mithalten. Mein letzter Stand war, dass die schnellsten ARM-Prozessoren gerade so an die Einsteiger-CPUs von Intel ran reichen. Das kann sich inzwischen etwas geändert haben, aber dass sie flotter sein sollen als ein i5 oder gar i7, will ich erst sehen, bevor ich es glaube. > A. K. schrieb: >> Bereits in den 70ern stellte IBM intern fest, dass die Compiler >> solche komplexen Befehle wenig bis überhaupt nicht verwendeten >> und eine einfacher aufgebaute RISC Maschine den Mainframes das >> Wasser abgesehen könnte. > > Naja, und heute haben wir eine RISC-Architektur namens ARM mit so > Befehlen wie "FJCVTZS" ("Floating-point Javascript Convert to Signed > fixed-point, rounding toward Zero"). Ich weiß ja nicht. Naja, ich finde es eher krass, wie viele verschiedene Instruktionen es alleine gibt, um einen Wert von A nach B zu kopieren. Da sind dann so Sachen dabei wie: CASPA - "Compare and Swap Pair of words or doublewords in memory." Die Instruktion hat 5(!) Operanden. Die Beschreibung: "reads a pair of 32-bit words or 64-bit doublewords from memory, and compares them against the values held in the first pair of registers. If the comparison is equal, the values in the second pair of registers are written to memory." Also wenn das noch RISC sein soll, dann weiß ich auch nicht…
:
Bearbeitet durch User
Rolf M. schrieb: > Mein letzter Stand war, dass die schnellsten ARM-Prozessoren gerade so > an die Einsteiger-CPUs von Intel ran reichen. Meldung von heute: "ARM-based Japanese supercomputer is now the fastest in the world" https://www.theverge.com/2020/6/23/21300097/fugaku-supercomputer-worlds-fastest-top500-riken-fujitsu-arm
:
Bearbeitet durch User
Ich habe keine Zweifel daran, das Apple den Architektur-Wechsel problemlos schafft (haben sie ja schon mehrfach bewiesen). Die Frage ist eher ob die neuen Produkte von der vollen Markt-Breite angenommen werden. Die Fraktion Internet, Multimedia und Office wird den Wechsel vermutlich nicht einmal merken. Ich kann mir aber vorstellen, das im professionellen Bereich sich einige von Apple abwenden werden. Ich kenne einige die mit Macs ihr Geld verdienen und der Großteil hat ein virtualisiertes Windows zusätzlich am laufen. Mich würde es interessieren wie sich in Zukunft die Hackintosh Szene entwickelt.
A. K. schrieb: > Meldung von heute: "ARM-based Japanese supercomputer is now the fastest > in the world" Ja, gut, der braucht dazu aber auch über 150.000 Prozessoren mit je 52 Kernen. Die Frage ist, wie ein einzelner Kern so im Vergleich abschneidet, weil normale PC-Anwendungen größtenteils nicht hochparallelisierbar sind. Und das, was man sehr gut parallelisieren kann, wird eher in der Grafikkarte gerechnet. René F. schrieb: > Die Frage ist eher ob die neuen Produkte von der vollen Markt-Breite > angenommen werden. Die Fraktion Internet, Multimedia und Office wird den > Wechsel vermutlich nicht einmal merken. Das kommt aber auch darauf an, wie schnell es die Anwendungen für ARM gibt, bzw. wie performant die x86-Emulation sein wird. > Ich kann mir aber vorstellen,das im professionellen Bereich sich einige von > Apple abwenden werden. Ich kenne einige die mit Macs ihr Geld verdienen und > der Großteil hat ein virtualisiertes Windows zusätzlich am laufen. > > Mich würde es interessieren wie sich in Zukunft die Hackintosh Szene > entwickelt. Vielleicht gibt's dann MacOS für den Raspi.
oerks schrieb: > Die PowerPC-Architektur war fuer Apple ein intellektuelles > Zukaufteil. Keine Chance um es mit eigenen Resourcen nennenswert > zu verbessern. Da sollte man unterscheiden. Apple hat selber keine PPC entwickelt, sie haben die PPCs von IBM gekauft. Aber sie haben eine Chipentwicklerbude gekauft. Und zwar PA-Semi. Und das zu Zeiten als Apple von PPC nach Intel gewechselt ist/war. Meine Vermutung ist also, dass die auf Basis von ARM ihre eigenen SoCs bauen und gebaut haben - für die Mobilgeräte eben. Operator S. schrieb: > Meines Wissens ist das Gerücht, sie steigen von Intel auf AMD um (!= > ARM) Nein. Allerdings ist auch unklar ob sie auf ARM umsteigen. Ja, Apple hat ARM Lizenzen und auch IP und zumindest am Anfang waren die iPhone SoCs ziemliche standard ARM CPUs. Aber das hat sich deutlich geändert. Aktuelle Apple SoCs sind deutlich schneller als das was man mit dem bauen kann was man von ARM als IP bekommt. Ich vermute, das wird zwar noch ein ARM oder ARMähnlicher Befehlssatz sein, aber sonst haben die die CPUs und GPUs im SoC stark verändert dass die nurnoch wenig mit dem gemeinsam haben was ARM als IP verkauft. Arno schrieb: > Ich halte es nicht für unmöglich, dass das sogar für Apple das > wichtigste Argument ist. Jap und auch, dass man möglichst viel der Herstellungskette in eigener Hand hat und aufeinander optimieren kann. Das siehet man auch bei Tesla und Amazon, beide haben ihre eigenen Chips gebaut, Amazon für die Cloud und Tesla weil sie so ein deutlich schnellerers neuronales Netz haben als es mit Chips von Nvidia möglich wäre bei gleichzeitig geringerer Leistungsaufnahme (der Tesla IC hat ziemlich viel SRAM und eine extrem breitbandige Speicheranbindung). Ich finde das auch die richtige Strategie. Während hier in Deutschland die Autobauer und Andere immer mehr outsourcen gibt es ein paar aufstrebende/wachsende Firmen die möglichst alles selber bauen wollen. Tja wie ist das mit den Binarys? Gar nicht so tragisch. LLVM und somit auch Xcode können Bitcode, das ist eine intermediate representation und unabhängig von der Architektur. Wenn man seine Software also schon als Bitcode gebaut hat oder Xcode das kann, dann kann man daraus recht einfach auch Binarys für eine andere Architektur bauen. Man kann sich das wohl so vorstellen wie webassambly. Also ein Binary, aber nicht für iregendeine real existierende Architektur, sondern nur um entweder nochmal auf eine Architektur übersetzt zu werden oder um in einer VM ausgeführt zu werden. Jedenfalls hat Apple in den letzten Jahren ziemlich viel in diese Richtung getan und es würde mich nicht wundern wenn der Großteil der Apps problemlos neu kompiliert werden kann. Tja und wie ist das mit Windows? Nun, warum denn Windows auf dem Mac, da gibt es doch günstigere Hardware. Aber egal, Windows 10 gibt es für ARM und Apple hat mit Rosetta 2 einen echten Emulator für x86 der angeblich auch recht flott ist. Wenn man schon für manche Programme mit Rosetta 2 x86 anbietet, dann geht das vermutlich auch für ein ganzes OS. Bootcamp wird das aber nicht, Windows x86 wird wenn überhaupt in einer VM laufen. Aber auch das mit dem ARM Windows ist fraglich. Ich vermute (oben), dass sich Apple in letzter Zeit ein ganzes Stück von dem standard-ARM entfernt hat. Ob da Windows also kompatibel ist zu dem eigenen Chip und ob man das überhaupt möchte und da Zeit und Geld investiert weiß ich nicht. Ich vermute nein.
Gustl B. schrieb: > Allerdings ist auch unklar ob sie auf ARM umsteigen. Hmm, das ist ein gute Punkt. Der Begriff "ARM" kommt in dieser Ankündigung von Apple nicht vor. Es ist immer nur von "Apple silicon" die Rede.
:
Bearbeitet durch User
Gustl B. schrieb: > LLVM und somit auch Xcode können Bitcode, das ist > eine intermediate representation und unabhängig von der Architektur. > Wenn man seine Software also schon als Bitcode gebaut hat oder Xcode das > kann, dann kann man daraus recht einfach auch Binarys für eine andere > Architektur bauen. LLVM IR ist nicht platformspezifisch, generiertes IR ist aber meist NICHT platformunabhängig!
OK, ich kenne mich da nicht wirklich aus, ich habe das vor ein paar Jahren gelesen und da wurde das als großer Schritt von LLVM gefeiert und schon damals (2015) gemutmaßt, dass Apple bald auf ARM umsteigen wird. Und seit spätestens 2017 erlaubt Apple im Appstore nur noch Apps mit Bitcode. Ich habe gelesen, dass Apple die App dann besser auf das Gerät optimieren kann. Ob sie die App dann auch noch für eine andere Architektur bauen könnten ist für mich unklar. Wäre aber cool. Also wenn der Entwickler die App nur als Bitcode abliefert und Apple die dann einmal für alle Geräte übersetzt.
Also so wie Google das seit Jahren bei Android macht. Der Entwickler liefert generischen Code, die Maschine setzt den auf sich um. Damit ist nämlich auch eine Optimierung für die konkrete Version des Prozessors möglich. Und - heute nicht unwichtig - das Umschiffen von später erkannten Prozessorproblemen auch für bestehende Anwendungen.
:
Bearbeitet durch User
Ich denke auch - es wird in Richtung Emulation gehen. Ich habe privat ein 13" MBP von 2014. Nutze es zusammen mit einem 27" Thunderbolt Display auch an meinem Schreibtisch. Das ist aber nicht mein erster Mac. Ich war relativ am Anfang dabei als Apple auf Intel rübergegangen ist. Für mich die absolute Traumkombi bisher! Habe dadurch faktisch ein MacBook und oder quasi ein iMac und dazu zwei Betriebssysteme. Quasi ein 4 in 1. Normalerweise nutze ich immer das Mac OS. Wenn ich aber produktiv was basteln will (Altium, Xilinx Vivado, ADI SigmaStudio, uC programmieren, 3D CAD, etc.. pp..) dann habe ich immer Windows im Backup. Ich beobachte schon die ganze Zeit was Apple macht, da mein Laptop jetzt schon 6 Jahre auf dem Buckel hat, aber prinzipiell noch absolut ohne Probleme läuft. Ein neuer Mac ->war<- daher die ganze Zeit schon mehr oder weniger auf meiner Investmentliste gestanden für die nächsten 1-2 Jahre. Ich bin aber seit einiger Zeit auch schon mit der Preispolitik nicht mehr so ganz einverstanden. Mein MBP (i5, 8GB ram, 256Gb SSD) habe ich 2014 für 1149 Euro gekauft wenn ich mich recht erinnere. Heute geht das MBP bei 1499 Euro los und hat mehr oder weniger immer noch die gleichen Specs wie mein MBP damals (8GB ram und 256GB ssd)... Ok um fair zu bleiben, es gibt inzwischen einen quad-core im Basismodell statt eines dual-cores. Will ich zumindest etwas 2020-mäßiges haben, also 16GB ram + 1TB ssd, ist man gleich > 2000 euro los. Jetzt nochmal einen Mac mit Intel kaufen? Ich weiß es nicht. Damals beim PPC auf Intel Umstieg hat Apple den OS Support bereits 3 Jahre nach der Übergangsphase eingestellt. Wenn Apple jetzt mit der Transition anfängt und man gutmütig die Übergangszeit rausrechnet, wäre also 2025 Supportende. Werde ich mich wohl oder übel wirklich mal wieder nach normalen Laptops umschauen müssen.
A. K. schrieb: > Damit ist nämlich auch eine Optimierung für die konkrete Version des > Prozessors möglich. Und - heute nicht unwichtig - das Umschiffen von > später erkannten Prozessorproblemen auch für bestehende Anwendungen. Exakt das ist ein großer Vorteil und wenn man sowieso nurnoch Appstores hat dann ist das ein bequemer Weg. Hubert schrieb: > Ich war relativ am Anfang dabei als > Apple auf Intel rübergegangen ist. Da war ich auch dabei. 2006 mit einem Hackintosh auf AMD Venice CPU und mit Nvidia 5200 iirc. Und dann 2007 mit einem MBP. Aber da ist dann leider zuerst DVD Laufwerk, dann Akku und am Ende auch noch die Nvidia GPU gestorben. Danach hab ich mir einen Mac Mini 2011 geholt. Hubert schrieb: > Werde ich mich wohl oder übel wirklich mal wieder nach normalen Laptops > umschauen müssen. Ich bin nie komplett von Windows weg, eben weil ich das für manche Software brauche. Bootcamp hatte ich probiert, aber eigentlich finde ich zwei Geräte sehr fein. Ich habe hier den alten Mac Mini und ein Thinkpad auf dem Schreibtisch mit zwei Monitoren. Jeder Monitor ist sowohl mit dem Thikpad als auch mit dem Mac verbunden, ich kann also ganz einfach am Monitor einstellen welche Quelle ich haben will. Meist habe ich rechts Mac für Mail, Browser, iTunes, Skype und links Windows. Aber manchmal auch zweimal Mac oder zweimal Windows. An einem kleinen Notebookdisplay würde ich nicht lange arbeiten wollen. Edit: Rechne mal damit, dass wenn du dir jetzt einen Intel Mac kaufst der noch einige Zeit unterstützt werden wird. Aber du kannst auch den Umstieg von Apple abwarten und angucken wie der läuft und vor allem auch welche Software dann tatsächlich als Universal Binary angeboten werden wird und ob die dann neu kostet. Ich habe hier noch eine ältere Creative Suite von Adobe, wenn ich sowas auf Apple Silicon haben möchte dann muss ich das entweder emulieren lassen oder neu kaufen. Adobe wird das garantiert nicht kostenfrei anbieten. Nichtmal bei der neusten CS6 die jetzt auch schon alt ist, die wollen ihr Creative Cloud Abo verkaufen. Genauso auch bei Microsoft Office. Da kann man entweder eine neue Version kaufen oder eine alte mit Rosetta 2 nutzen.
:
Bearbeitet durch User
Rolf M. schrieb: > Soweit ich weiß, kann x86 im Bezug auf die Energiesparfunktionen nicht > mit ARM mithalten, dafür kann ARM bei der maximalen Leistung nicht > mithalten. Mein letzter Stand war, dass die schnellsten ARM-Prozessoren > gerade so an die Einsteiger-CPUs von Intel ran reichen. So ungefähr. Ich habe vor 2 Jahren mal einen (damals) state-of-the-art ARM Server von Qualcomm mit einem schon etwas abgehangenen Xeon E5 Server verglichen. Der Testfall war ein RDBMS und der ARM Server lieferte im Schnitt 20% mehr Durchsatz als der Intel Server. Allerdings hatte der ARM Server 48 echte Kerne (davon 46 nutzbar) und der Intel Server 16 echte Kerne, aber 32 Threads dank Hyperthreading. Besonders bemerkenswert fand ich das Skalierungsverhalten. Intel lieferte dank Turbo Boost sehr beachtliche Leistungen in single-thread Benchmarks. Aber wenn mehrere Threads aktiv waren, dann sackte der Durchsatz per Core (respektive Hyperthread) schnell ab. Von 1 bis 256 Threads ging der Durchsatz pro genutzem Core für das Intel System bis auf 53% des single-thread Durchsatzes zurück. Das ARM System hingegen lieferte bis 23 Threads einen Skalierungsfaktor von ca. 95%, der bis 256 Threads nicht unter 83% abfiel [1] Dieser Benchmark hat im wesentlichen die Integer Funktionen der CPU genutzt (weder FP noch gar Vectoring). Allerdings war der Stromverbrauch der ARM Büchse auch unter Vollast weniger als halb so groß. Insofern kann ich das Fazit bestätigen: ARM liefert mehr MIPS pro Watt, aber weniger Spitzenleistung. Auf einem einzelnen Kern sogar noch weniger. > Das kann sich > inzwischen etwas geändert haben, aber dass sie flotter sein sollen als > ein i5 oder gar i7, will ich erst sehen Davon gehe ich nicht aus. Aber wenn man sieht, welche Klimmzüge Intel dafür machen muß, dann will man das gar nicht. [1] zur Verdeutlichung: das Intel System liefert single-threaded den Durchsatz X. Bis 32 Threads steigt der Durchsatz an und stagniert dann, der Spitzenwert ist 32·X·53%. Arm liefert single-threaded Y, das steigt bis auf 46·Y·83%.
Hier ein aktuellerer Vergleich mit dem ARM Prozessor/SoC von Amazon https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd Also ich sehe da auch recht gute Chancen für ARM oder das was Apple daraus gemacht hat für einen Mac Pro. https://de.wikipedia.org/wiki/Apple_A12_Bionic Also das ist zwar ARM von der Architektur her, wurde aber von Apple entwickelt. Und was auffällt ist, dass die im Vergleich zu anderen Herstellern wie Qualcom eher wenige Kerne haben. Der Apple A10 hatte 4 Kerne. Zwei schnelle und zwei langsame. Und das als andere Hersteller in Handys schon 8 Kerne verbaut haben. Apple war trotzdem schneller. Die haben da vermutlich Vorsprung und trauen sich jetzt das auf den Desktop auszurollen.
:
Bearbeitet durch User
Christoph Z. schrieb: > Dafür läuft dann Bootcamp "nur" noch mit Linux und ChromOS, vielleicht > gibts dann sogar noch RiscOS ;-) hast Du dafür eine Quelle? Was ich bis jetzt gelesen habe wird nur noch die Ausführung von (legacy) macOS erlaubt.
Jan V. schrieb: > Christoph Z. schrieb: > >> Dafür läuft dann Bootcamp "nur" noch mit Linux und ChromOS, vielleicht >> gibts dann sogar noch RiscOS ;-) > > hast Du dafür eine Quelle? Was ich bis jetzt gelesen habe wird nur noch > die Ausführung von (legacy) macOS erlaubt. Nein, war ja mehr gedacht als Anregung, was sich wirklich ändert, wenn Apple auf ARM wechselt. Kenne doch noch relativ viele MacBook Besitzer die das Ding nur mit Windows benutzen. Das Linux darauf nativ Bootet würde ich nicht so schnell erwarten. Würde mich nicht wundern, wenn Apple da gleich alle alten Zöpfe abschneidet und auch der Bootloader eine eigene Entwicklung ist. Vielleicht brauchts dann auch auf den MacBooks einen Jailbrake. Wir werdens sehen.
Rolf M. schrieb: > Also wenn das noch RISC sein soll, dann weiß ich auch nicht… Der Unterschied zwischen RISC und CISC liegt nicht darin, dass bei RISC keine behämmerten Befehle vorkommen können, sondern darin das bei RISC jeder Befehl die gleiche Anzahl an Bytes verwendet. Dadurch ist natürlich die Menge der möglichen Befehle unter RISC begrenzt. Bei CISC kann jeder Befehl unterschiedlich lang sein, und es muss erst mit einem sogenannten "microkernel" herausgefunden werden um welchen Befehl es sich handelt und wo die Parameter des Befehls anfangen. Das kostet natürlich Zeit und Energie. Daher ist es egal ob im RISC Befehlssatz Herstellerspezifische Nischenbefehle existieren. Wenn der Bus groß genug ist, warum nicht?
bmoe schrieb: > Rolf M. schrieb: >> Also wenn das noch RISC sein soll, dann weiß ich auch nicht… > > Der Unterschied zwischen RISC und CISC liegt nicht darin, dass bei RISC > keine behämmerten Befehle vorkommen können, sondern darin das bei RISC > jeder Befehl die gleiche Anzahl an Bytes verwendet. Ich würde sie nicht "behämmert", sondern "komplex" nennen, aber die zu vermeiden, ist eigentlich die Design-Idee von RISC. Vor allem trennt man arithmetische Instruktionen von welchen, die Speicherzugriffe machen. Dadurch lässt sich zwar auch ein Befehlssatz leichter umsetzen, bei dem alle Befehle gleich lang sind, aber das ist eher ein indirekter Effekt. > Daher ist es egal ob im RISC Befehlssatz Herstellerspezifische > Nischenbefehle existieren. Wie bei vielen anderen Dingen ist die klassische Aufteilung in RISC und CISC heute nicht mehr so ganz eindeutig, weil es sich heute meist in gewissem Rahmen um Mischformen handelt. > Wenn der Bus groß genug ist, warum nicht? Was hat die Größe vom Bus damit zu tun?
Rolf M. schrieb: > Wie bei vielen anderen Dingen ist die klassische Aufteilung in RISC und > CISC heute nicht mehr so ganz eindeutig, weil es sich heute meist in > gewissem Rahmen um Mischformen handelt. Schönes Beispiel: Cortex-M. Der klassische reine 32bit-Befehlssatz bei ARM hatte das Problem zu großen Platzbedarfes der Programme. 16bit-Thumb hingegen mußte zuviele Befehle in zwei Instruktionen aufspalten, so daß die Performance litt. Deswegen kann Cortex-M nur noch Thumb2, was ein gemischter Befehlssatz von 16bit- und 32bit-Befehlen ist. Damit bekommt man sowohl den Platzbedarf als auch die Performance unter einen Hut, bricht aber mit der reinen RISC-Lehre. Auf der Gegenseite sind x86-CPUs heute intern auch RISC-CPUs, weil die komplexen externen Befehle in µOps zerlegt und dann erst ausgeführt werden.
Nop schrieb: > Deswegen kann Cortex-M nur noch Thumb2, was ein gemischter Befehlssatz > von 16bit- und 32bit-Befehlen ist. Damit bekommt man sowohl den > Platzbedarf als auch die Performance unter einen Hut, bricht aber mit > der reinen RISC-Lehre. Vor allem sind die 16-bittigen und 32-bittigen Befehle nicht durchgängig äquivalent, was die Decodierung erschwert. RISC-V hat das besser gelöst.
Ihr wisst wahrscheinlich mehr zu dem Thema als ich. Ich dachte halt, das der Performance Gewinn durch eine einfachere Zuordnung entsteht. Wie bei einem LUT.
bmoe schrieb: > Ich dachte halt, das der Performance Gewinn durch > eine einfachere Zuordnung entsteht. Nö, intern werden (in der Regel) die 16-bittigen Befehle zu vollen 32-bittigen Befehlen ausdecodiert. Der Performancegewinn entsteht, weil bei mangelnder Speicherbandbreite "weniger Daten übertragen" einfach schneller geht.
Es sieht echt so aus als wäre die ARM-Architektur jetzt auch außerhalb von Embedded kurz vor dem Durchbruch. Bei AWS ist Graviton 2 jetzt schon günstiger als entsprechende x64-Maschinen (nachdem der Graviton 1 eher "proof of concept" war). Auf Desktopseite hat Apple mit dem M1 den ersten überzeugenden x64-Ersatz am Start. Interessant wird, wer als nächstes auf den Markt kommt.
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.