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

Teralios

Commander
Dabei seit
Mai 2008
Beiträge
2.631
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

Lt. Junior Grade
Dabei seit
Apr. 2010
Beiträge
382
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 ()

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

Commander
Dabei seit
Mai 2008
Beiträge
2.631
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

Lieutenant
Dabei seit
Aug. 2016
Beiträge
848
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

Commander
Dabei seit
Mai 2008
Beiträge
2.631
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

Rear Admiral
Dabei seit
Aug. 2007
Beiträge
5.530
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

Lt. Junior Grade
Dabei seit
Apr. 2010
Beiträge
382
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

Commander
Dabei seit
Mai 2012
Beiträge
3.010
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

Lieutenant
Dabei seit
Mai 2018
Beiträge
940
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

Lt. Junior Grade
Dabei seit
Jan. 2015
Beiträge
293
Wir werden es bald sehen, was Apple alles für die Zukunft vor hat :)
 
Dabei seit
Jan. 2016
Beiträge
2.525
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.
 

Scie

Ensign
Dabei seit
Mai 2016
Beiträge
135
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.
 
Zuletzt bearbeitet:

Steini1990

Captain
Dabei seit
Okt. 2011
Beiträge
3.935
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

Rear Admiral
Dabei seit
Nov. 2017
Beiträge
5.688

AssembIer

Ensign
Dabei seit
Juni 2018
Beiträge
241
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

Fleet Admiral
Dabei seit
Juli 2010
Beiträge
10.629
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. :D
 

AssembIer

Ensign
Dabei seit
Juni 2018
Beiträge
241
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. :D
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.
 
Top