News WWDC-Gerüchte: Nur noch ein „neuer Mac“ mit Intel vor dem Wechsel auf ARM

[Tommy Hewitt]

wobei es natürlich sein kann das Apple beim Chipdesign bei TSMC mehr Ideen/eigene Designs einbringen kann als bei Intel.

Hä? Du weißt schon, was TSMC macht, oder?

 

[Teralios]

Der A78 (als Bindeglied Kern zwischen big und little cores) und die Lightning Kerne bietet 3 Ports.

Hab ich ja geschrieben. 3 Ports, aber die Funktionseinheiten sind doppelte vorhanden.

Bei Lightning sind die Funktionseinheiten auch 3 Fach vorhanden.

Steht so aber nicht in deiner Quelle. Es wird davon gesprochen, dass hier 3 Pipelines/Ports für die FP/Vec-Funktionsblöcke zuständig sind, ansonsten aber keine Veränderungen zum Vorgänger vorhanden sind. Nur bei den Integer-ALUs ist eine dritte dazu gekommen.

Das nun alle Funktionseinheiten für die SIMD-Verarbeitung 3-fach vorhanden kann man zwar Mutmaßen, aber ob es wirklich so ist, kann man nicht sagen.

Beim neuen big Core (Cortex X) gibt es 4 ports.

Richtig und auch damit verbunden sind die SIMD-Funtkionseinheiten 4 fach vorhanden.

Du musst aber etwas auf Frontend und Backend aufpassen. Wenn man im Frontend einen zusätzlichen Port hinzufügt, heißt es nicht unbedingt, dass im Backend auch neue ALUs dazu kommen, sondern man versucht nur vorhanden ALUs besser auszulasten.

Ansonsten danke für die Info.

 

[Ferax]

Da bist aber bei Apple an der falschen Adresse.
iOS läuft ja vor allem Single Core.
Während Android alles greift was an Kernen da ist.

Und woher kommt diese Annahme?

Ergänzung (22. Juni 2020)

Hatte intel beim ARM surface aber vergessen... 🤫

Ich nehme mal an das soll Microsoft bedeuten.
Wie ich schon dargelegt habe, ist das ein Äpfel mit Birnen Vergleich.
Microsoft hat keinesweges ein bereits optimiertes und rein auf ARM geschriebenes Betriebssystem zum Einsatz gebracht, noch einen entsprechenden AppStore zu Verfügung.

 

[Teralios]

Microsoft hat keinesweges ein bereits optimiertes und rein auf ARM geschriebenes Betriebssystem zum Einsatz gebracht, noch einen entsprechenden AppStore zu Verfügung.

Auch Darwin - Kernel - als auch Linux sind keine reinen auf ARM geschriebenen Betriebssysteme.

Das Hauptproblem bei MS ist auch nicht Windows an sich, sondern die APIs. Die Win32-API ist stark veraltet, schlecht dokumentiert und läuft heutzutage nur auf x86.

Moderne Windows Programme, die auf .net sowie WinRT aufbauen, lassen sich auch jetzt bereits problemlos zwischen Windows 10 ARM und eben Windows 10 X86 portieren.

 

[Atent123]

Hab ich ja geschrieben. 3 Ports, aber die Funktionseinheiten sind doppelte vorhanden.

Ich wollte dir da auch gar nicht widersprechen.

"Steht so aber nicht in deiner Quelle. Es wird davon gesprochen, dass hier 3 Pipelines/Ports für die FP/Vec-Funktionsblöcke zuständig sind, ansonsten aber keine Veränderungen zum Vorgänger vorhanden sind. Nur bei den Integer-ALUs ist eine dritte dazu gekommen.

Das nun alle Funktionseinheiten für die SIMD-Verarbeitung 3-fach vorhanden kann man zwar Mutmaßen, aber ob es wirklich so ist, kann man nicht sagen. "

Ich hätte es jetzt angenommen, allerdings steht es wirklich nicht explizit in der Quelle.

"The microarchitecture at its heart is still a 7-wide decode front-end, paired with a very wide execution back-end that features 6 ALUs and three FP/vector pipelines."

Kurze Korrektur.
Es sind 6 Integer Alus. Jetzt können allerdings 3 von 6 Alus alle flags nutzen.

 

[Teralios]

Ich wollte dir da auch gar nicht widersprechen.

Alles gut. Ich fand es ja gut, dass du dein Wissen eingebracht hast. Man übersieht ja heute gerne wirklich mal was. Entsprechend hab ich ja auch noch mal nach geforscht und mir das angesehen.

Man kann nicht alles wissen und auch nicht immer alles richtig interpretieren. Wichtig ist halt nur, dass man inhaltlich etwas liefert, auf das man aufbauen kann.

 

[Turrican101]

Aus ergonomischer Sicht ist die MM2 Schrott, keine Frage. Aus mobiler Sicht und aus Sicht eines Designers aber absolut gelungen - keine Tasten, keine Ports sichtbar.

Und das ist oft das Problem bei Apple. Sieht schön aus, aber zum Benutzen ists dann doch schlecht durchdacht. Siehe iMacs mit Anschlüssen auf der Rückseite, fehlender Höhenverstellung usw. "Hauptsache das Ding sieht von vorne schön aus."

Man muss sie doch nicht als Desktopmaus für den 8h Arbeitstag sehen

Und warum wird sie dann bei den iMacs mitgeliefert? Bestimmt nicht um dann damit mobil zu sein.
Die Gesten sind schon toll, aber der Rest ist halt Müll. Nur eine Größe, symmetrischer Aufbau, Aufladen mit Kabel von unten (genial).

 

[Ferax]

Auch Darwin - Kernel - als auch Linux sind keine reinen auf ARM geschriebenen Betriebssysteme.

Das Hauptproblem bei MS ist auch nicht Windows an sich, sondern die APIs. Die Win32-API ist stark veraltet, schlecht dokumentiert und läuft heutzutage nur auf x86.

Moderne Windows Programme, die auf .net sowie WinRT aufbauen, lassen sich auch jetzt bereits problemlos zwischen Windows 10 ARM und eben Windows 10 X86 portieren.

Ja darauf wollte ich hinaus, habe es nur etwas allgemein gehalten.
Microsoft ist dafür bekannt sich schwer zu tun wenn es um das trennen von alten Sachen geht.
Deswegen erwarte ich mir da aus der iOS Erfahrung deutlich mehr bei Apple.

 

[Plumpsklo]

Und das ist oft das Problem bei Apple. Sieht schön aus, aber zum Benutzen ists dann doch schlecht durchdacht. Siehe iMacs mit Anschlüssen auf der Rückseite, fehlender Höhenverstellung usw. "Hauptsache das Ding sieht von vorne schön aus."

Es ist alles eine Frage des Bedürfnisses... Wenn ich jemand bin, der täglich mehrmals die Anschlüsse benutzt, dann werde ich mir entweder a) ein Dock besorgen um das komfortabel zu erledigen oder b) ein anderes Gerät kaufen.

Ich zB. bin jemand, der quasi nie etwas ansteckt - maximal einen USB-Stick im Monat. Wofür brauche ich da permanent Steckplätze in mein Gesicht? Mir ist das so lieber, ich versteh es aber auch, wenn man das anders sieht. Für mein Benutzen ist das dann alles andere als schlecht sondern besser.

Und warum wird sie dann bei den iMacs mitgeliefert? Bestimmt nicht um dann damit mobil zu sein.
Die Gesten sind schon toll, aber der Rest ist halt Müll. Nur eine Größe, symmetrischer Aufbau, Aufladen mit Kabel von unten (genial).

Weil das Apple's eigene Lösung ist. Alternativ kannst du natürlich das Trackpad nehmen und dann sieht die Welt wieder anders aus. Wer damit täglich 8h arbeitet, der wird sich am Ende des Tages sowieso eine MX Master kaufen. Für alle anderen reicht dann wohl auch die normale Magic Maus. Manchmal ist 1a Optik eben auch eine Art Funktion.

 

[AlphaKaninchen]

Ja darauf wollte ich hinaus, habe es nur etwas allgemein gehalten.
Microsoft ist dafür bekannt sich schwer zu tun wenn es um das trennen von alten Sachen geht.
Deswegen erwarte ich mir da aus der iOS Erfahrung deutlich mehr bei Apple.

MacOS, iOS, iPadOS, tvOS, watchOS, audioOS alles Darwin Distributionen. Also welche iOS Erfahrungen? Es ist das selbe OS, es läuft schon auf ARM

 

[LamaTux]

Wir werden es bald sehen, was Apple alles für die Zukunft vor hat

 

[Old Knitterhemd]

Apple ist erfolgreich, weil sie liefern was der Kunde will. Manche können das nicht akzeptieren.

Ausnahmslos alle die ich kenne, die mit MacOS arbeiten, beklagen sich non stop über Apple.

Als Musiker soll das Ding angehen und funktionieren, das hat früher auch sehr gut geklappt, aber so langsam ist jeder HW Ausfall eine kleine Katastrophe, weil lieber die alten Macbooks für teuer Geld gebraucht gekauft werden, als eines der aktuellen Modelle (Mojave und co).

All die Grafiker, Modedesigner, Musiker und co die ich betreue, haben nicht die geringste Ahnung von ihrer Technik (Musiker und ihre Audio Hardware mal ausgenommen) und deswegen sollten es damals auch unbedingt Apple Produkte sein, weil die laufen einfach.

Video Produktion unter Apple HW ist immer eine Herausforderung, da selbst ein Adobe premiere Projekt nicht immer problemlos zwischen Win und Mac getauscht werden kann.

All das dolle einfache bei Apple, beißt die Leute jetzt in den Arsch, weil sie Apples Weg mitgehen müssen.

 

[dampflokfreund]

Gut so, je schneller desto besser.

 

[Scie]

Vielleicht wird dadurch auch Windows 10 für ARM gepusht werden[...]

Ich glaube den Käufern geht es eher bei Windows 10 mit Bootcamp eher darum Windows 10 mit ihren bekannten Programmen, wie z.B. Spiele, etc auf schönere Hardware nutzen zu können. Es gibt bestimmt einen nicht zu kleinen Nutzerkreis, der Macs nur aus ästhetischen Gründen und nicht für MacOS gekauft haben und nur Windows 10 oder Linux auf ihren Macs nutzen

EDIT: Was mir auch noch als Möglichkeit einällt ist, dass Apple den T2 Chip aufbort. Der T2 wird doch heute schon für nicht wenige Aufgaben genutzt. Apple könnte einen potenten T3 Chip einbauen, der alle Aufgaben übernimmt und eine weitere x86 CPU. Wenn die Leistung nicht genutzt wird oder idled, dann läuft alles über den T3 und der x86 könnte bei Bedarf einfach dazugeschaltet werden.

 

[Qualcom]

Ich sehe nicht, wo das für den Endnutzer vorteilhaft sein soll.
Wenn man ARM aufbläst, damit man mit den großen x86 Jungs mithalten kann, wird doch der Effizienzvorteil zusammenschrumpfen.

Es geht nie um den Vorteil des Endkunden.
Eigene Komponenten zu verwenden erhöht die Marge.


MfG

 

[Steini1990]

den Käufern geht es eher bei Windows 10 mit Bootcamp eher darum Windows 10 mit ihren bekannten Programmen, wie z.B. Spiele, etc auf schönere Hardware nutzen zu können

Das ist mir schon klar. Zumindest für einen Teil der Spiele würde Windows 10 für ARM das bieten was sie suchen. Hat ja ein CB Nutzer ausführlich getestet welche Spiele möglich sind und welche nicht. 64 Bit Anwendungen sind natürlich noch außen vor. Ich erwarte aber eigentlich das Apple den Bootloader sperrt und Bootcamp ins Nirvana schickt. Wir werden aber eh bald mehr wissen.

 

[Hayda Ministral]

Apple wäre halt komplett unabhängig von Intel.

Point.

Da lassen sich ordentlich Kosten sparen.

Das muss sich erst noch beweisen. Apple braucht meines Erachtens künftig ein eigenes Design für den Desktop/Laptop, kann dessen Kosten aber auf nur relativ wenige Käufer verteilen.

 

[AssembIer]

Für 99,9% des Codes von Anwendungsentwicklern übernimmt der Compiler die Optimierungen. Ich bin mir nicht mal sicher, ob man überhaupt Code mit eingebettetem Assembler in den AppStore einchecken kann/darf. Sowas will bei Apple auch sicherlich niemand freiwillig überprüfen.

Dazu kommt noch, dass man in der Regel heutzutage mit Frameworks und APIs arbeitet und noch gegen Interfaces programmiert. Soll heißen: Man schreibt keinen Code, der direkte Instruktionen für die CPU enthält, sondern man ruft Funktionen des Betriebssystems auf.
D.h. wenn der Source Code vorhanden ist - was ja bei Programmen aus dem AppStore so ist -, sollten sich diese Programme auch relativ problemlos für ein macOS on ARM kompilieren lassen und einfach laufen.

So wie ich es mal verstanden habe liegen Apps als LLVM Bitcode vor, wenn das stimmt könnte Apple einfach sagen alle Apps aus dem Store laufen. Punkt. Ansonsten muss der Entwickler halt XCode starten, Compile drücken und dann ist es auch auf ARM lauffähig.

Das trifft aber nur auf "nativen" Code zu, welcher in Objective-C oder Swift geschrieben wurde. Jede Software mit mehr als 1-2 Funktionen kommt aber mit Abhängigkeiten in Form von vorkompilierten Bibliotheken daher, welche ebenfalls auf ARM kompiliert werden müssen.

Einige dieser Libs brauchen wiederum Anpassungen, damit man sie ūberhaupt auf (Darwin)ARM kompilieren kann. Viele Programme nutzen zum Teil veraltete Bibliotheken, welche bei einer Aktualisierung wieder Anpassungen im Code mit sich ziehen. Das kann ganz schnell ein nicht überschaubarer Aufwand werden.

Viele Programme die nur noch rudimentär gepflegt werden, erhalten mit Sicherheit kein Update mit Kompatibilität zu ARM mehr. Ich wäre daher vorsichtig, was die Akzeptanz der Entwickler betrifft.

 

[benneq]

Jede Software mit mehr als 1-2 Funktionen kommt aber mit Abhängigkeiten in Form von vorkompilierten Bibliotheken daher, welche ebenfalls auf ARM kompiliert werden müssen.

Ich weiß nicht, wie Apple das mit externen Libs handhabt. Aber die müssten ja auch im Quellcode vorliegen, damit sie überprüfen können, dass das nichts unerlaubtes abläuft. Sonst könnte ich ja meinen gesamten Quellcode als Binary abliefern und im Quellcode, den Apple zu Gesicht bekommt, wird einfach nur blob.run() aufgerufen, und hätte damit das gesamte Sicherheitskonzept umgangen.

 

[AssembIer]

Ich weiß nicht, wie Apple das mit externen Libs handhabt. Aber die müssten ja auch im Quellcode vorliegen, damit sie überprüfen können, dass das nichts unerlaubtes abläuft. Sonst könnte ich ja meinen gesamten Quellcode als Binary abliefern und im Quellcode, den Apple zu Gesicht bekommt, wird einfach nur blob.run() aufgerufen, und hätte damit das gesamte Sicherheitskonzept umgangen.

Der Code dieser Libs liegt bei dir oder dem Entwickler der sie dir zur Verfügung gestellt hat, aber mit Sicherheit nicht bei Apple. Welches Sicherheitskonzept soll das sein? Glaubst du es wird die Logik deines Codes beim AppStore Review geprüft?

Du kannst im Prinzip alles mögliche machen, solange es nicht entdeckt wird. Es gibt einen guten Grund warum alle Mac Apps in einer Sandbox mit eingeschränkten Zugriffsrechten ausgeführt werden.