News M1-Prozessor: Apples Notebook-SoC soll die Konkurrenz abhängen

[foo_1337]

Zumindest Linux ist auf ARM weit verbreitet. Hier sollte eine Distribution für M1 kein Problem darstellen.

Das Secure Boot Äquivalent ist das Problem. Ich bin hier aber zuversichtlich, dass das recht schnell umgangen wird.

 

[Unnu]

Ich bin mal auf den direkten Vergleich von den 13" MacBooks gespannt. Da kann man dann ja hoffentlich sehen, wie gut M1 wirklich geworden ist.

 

[Apocalypse]

Und dass sie in Sachen (integrierte) Grafik an AMD rankommen, glaube ich keine Sekunde.

An die XBSS oder PS5 wahrscheinlich nicht, aber alles was kein UMA mit direkt angebundenen Speicher hat? Alleine weil man nicht vom Speicher eingeschränkt ist wird das schneller werden.

Ist doch das was alle seit Jahren sagen, das APUs für Desktops und Notebooks SOCs mit integrierten Speicher brauchen um brauchbare Performance zu bringen. Jetzt hat das Apple halt gemacht und dabei gleich x86 über Bord geworfen.
Das man damit an dedizierte GPUs und Desktop PCs ran kommt, muss man dann abwarten. Aber für den Notebookbereich dürfte das sehr effizient werden. Nur Software hat man dann erstmal nicht soviel im Angebot.

 

[bodd]

Weiß jemand ob man mit Parallels auch X86 auf nem ARM virtualisieren kann? Zielsetzung ist auf nem Mac M1 auch nen Windows haben zu können (falls man eine Windows Only Applikation braucht).

 

[k0ntr]

Ich wüsste nicht wie ich durch dieses Apple Zeugs profitieren soll?
Außer überteuerte Hardware mit Hypen Eigennamen kann ich da jetzt nicht wirklich erkennen.

Weil andere Hersteller mitziehen werden und dann auch bessere Produkte anbieten werden? Sei es beim Smartphone, Ipad etc... da darf man Apple Danke sagen, weil der Markt belebt wird und nicht still steht. Wie bei AMD und Intel mit den Prozessoren

 

[NameHere]

Dafür das es ein 5 nm Chip ist hauen mich die Laufzeiten bei gleicher Akkugröße nicht um.
Max. 16GB RAM im MacBook Pro und MacMini ist nicht Pro und an Zielgruppe vorbei. Keine Unterstützung für externe Grafikkarten (eGPU) und nur ein externer Monitor möglich.
Dennoch eine interessante Entwicklung mit ARM. Apple geht schon mal in die richtige Richtung.

 

[Yumix]

Software-Entwicklern ? Was programmieren sie und was für Software/Infrastrukturen nutzen sie denn ? Nutzen sie bspw. Docker, oder eher komplette VMs ? Würde mich intessieren, da ich selbst einer bin.

Also im Alltag komme ich easy auf 25GB und dafür brauchts keine VMs. Wir haben ne Microservice Infrastruktur. Frontend besteht aus mehreren Angular apps, Backend / Proxies basieren auf Spring Boot. In der Regel habe ich 3 IntelliJ Idea Instanzen offen, eine für UI, eine Backend und eine Legacy java Project. Das alleine knackt schon die 16GB. Ich könnte das etwas reduzieren in dem ich jedes Project in ner einzelnen Instanz öffne, ob man das aber bei einer Microservice Infrastruktur mit unzähligen in sich greifenden Projekten will....eher nicht. Wenn ich dann an einem Ticket arbeite das UI, Proxy + Legacy System benötigt, bin ich schnell bei 25GB. Wenn man dann noch ne VM oder anderes Zeug startet, kann man sich ja ausdenken wie viel Spaß das mit 16GB macht

Wer natürlich nur an ner kleinen Frontend App in VSCode oder einer iOS app arbeitet, dem reichen 16GB locker. Kommt halt immer an den Anwendungszweck an. Für Studenten werden die 16GB auch sicherlich reichen, von einem Pro Modell würde ich jedoch erwarten, dass es halt auch wirklich für Professionelle und deren Anforderungen ausgelegt ist. Mit solchen Limitierungen ist das Pro nur noch Marketing, wie beim iPhone

 

[or2k]

An die XBSS oder PS5 wahrscheinlich nicht, aber alles was kein UMA hat? Alleine weil man nicht vom Speicher eingeschränkt ist wird das schneller werden.

Ist doch das was alle seit Jahren sagen, das APUs für Desktops und Notebooks SOCs mit integrierten Speicher brauchen um brauchbare Performance zu bringen. Jetzt hat das Apple halt gemacht und dabei gleich x86 über Bord geworfen.
Das man damit an dedizierte GPUs und Desktop PCs ran kommt, muss man dann abwarten. Aber für den Notebookbereich dürfte das sehr effizient werden. Nur Software hat man dann erstmal nicht soviel im Angebot.

Offiziell bietet Apple ja mehr TFlops als AMD momentan mit der Vega 8 eines 4800U bieten kann, zusätzlich hat das iPad Pro schon einen Vorsprung in 3DMark Wild Life vor der Vega 8.
Da aber generell es sehr schwer ist zwei unterschiedliche Architekturen auf etwas zu testen ohne eine besonders zu bevorzugen, weiß ich nicht wie viel man daraus interpretieren soll.
Viel Grafikleistung bringt halt nichts, wenn die Software einfach nicht läuft, die man nutzen möchte, das gilt für beide Seiten

 

[deekey777]

Ich bin mal auf den direkten Vergleich von den 13" MacBooks gespannt. Da kann man dann ja hoffentlich sehen, wie gut M1 wirklich geworden ist.

Nimm dir die Zeit und gehe kurz die ganzen Fußnoten durch.
Apple hat große Klappe, aber alle "bis zu"-Werte beziehen sich anscheinend immer auf das Einsteiger MBP 13'' mit dem i5 der achten Generation (Iris Pro 645 und nur DDR3-2133; dieses ersetzt ja das MBP 13'' M1). Wenn also zB die GPU des M1 die schnellste integrierte GPU sein will, warum dann vergleich Apple diese nicht mit Iris Plus Graphics G7 (64 EUs) und LPDDR4X-3733?

Irgendwie auffällig. Ok, die G7 wird kaum schneller als die GPU des M1 sein, eher im Gegenteil, aber viele Geschwindigkeitsvorteile kommen eher aus Optimierungen auf eigene SoCs (dass die Videowiedergabe mit der TV-App bis zu 20 Stunden ist, ist kaum überraschend, wenn die gleiche App auf dem iPhone/iPad läuft und für mobile Wiedergabe optimiert ist).

 

[KurzGedacht]

Und was hat das nun mit dem RAM zu tun? Schau dir mal bitte an, wie Rosetta funktioniert.. Gab's ja bei der PPC -> Intel Transition schon.

Ich verstehe dein Argument nicht. Rosetta hatte genau das gleiche Ram Problem, das ich jetzt auch hier erwarte (https://www.osnews.com/story/13398/rosetta-memory-overhead/).

Zu dem Overhead durch die emulation kommt dann teiwleise noch der Overhead durch die parallele Ausführung. Die Entwickler haben einen Arm Apache/PHP lokal + einen x86 apache/php in docker via Qemu. Da es komplett inkompatible Binaries sind, gibt es auch kein same page merging im Ram mehr und man braucht für das Setup in etwa 100% mehr Ram.

 

[deekey777]

Hiess es nicht, dass bereits während der Installation einer x86-Anwendung diese on-fly in ARM-Code übersetzt wird?

 

[KurzGedacht]

Hiess es nicht, dass bereits während der Installation einer x86-Anwendung diese on-fly in ARM-Code übersetzt wird?

Ja, aber ich bezweifle stark, dass das für ganze Docker Umgebungen überhaupt möglich ist.
1)
Man übersetzt nicht mal eben eine komplette Betriebssystemumgebung auf eine andere Prozessorarchitektur.
2)
Docker Container werden nicht klassisch installiert.

Es wird bei Docker auf eine Qemu Emulation hinauslaufen und das kostet einfach mindestens 50% Performance.

 

[Emil Galotti]

Könnte der M1 Chip nicht ein Vorbote für PC-Systeme der Zukunft sein.

Wird man in einigen Jahren nicht einen „ganzen“ Computer, bestehend aus einem einzigen Teil, zum Beispiel in ITX-Board -Größe“ erwerben, mit allen relevanten Bauteilen direkt vernetzt, erwerben können? CPU, GPU, Ram,Festplatte, alles fix und fertig ohne Gefummele und Gestecke und Kompabilitätsproblemen, weil irgendwo wieder ein passender Treiber oder ein Upgrade fehlt?

 

[foo_1337]

Ich verstehe dein Argument nicht. Rosetta hatte genau das gleiche Ram Problem, das ich jetzt auch hier erwarte (https://www.osnews.com/story/13398/rosetta-memory-overhead/).

Ich hatte erst 2009 mit Rosetta zu tun, ggf war das Thema da schon entschärft.

Zu dem Overhead durch die emulation kommt dann teiwleise noch der Overhead durch die parallele Ausführung. Die Entwickler haben einen Arm Apache/PHP lokal + einen x86 apache/php in docker via Qemu. Da es komplett inkompatible Binaries sind, gibt es auch kein same page merging im Ram mehr und man braucht für das Setup in etwa 100% mehr Ram.

Die ganze Docker Geschichte ist natürlich suboptimal, das ist klar: Die x86 Emulation wird deutlich mehr auf die Performance gehen als die aktuelle docker-vm, die von vt profitiert. Aber vielleicht wird es eben Zeit, dass der Kram nicht mehr lokal ausgeführt wird, sondern via gitlab-ci/jenkins etc. direkt via k8s Pod oder zumindest auf ner remote ec2 instanz o.Ä.

 

[tidus1979]

Nimm dir die Zeit und gehe kurz die ganzen Fußnoten durch.

Die Tests wurden von Apple im Oktober 2020 durchgeführt mit Prototypen von 13" MacBook Pro Systemen mit Apple M1 Chip sowie mit handelsüblichen 13" MacBook Pro Systemen mit 1,7 GHz Quad‑Core Intel Core i7 Prozessor und Intel Iris Plus Graphics 645, die alle mit 16 GB RAM und 2 TB SSD konfiguriert waren.

i7, nicht i5

 

[caruniom]

Alleine wegen der Akkuaufzeit wäre das Pro als Arbeitsgerät interessant.
Leider verwende ich meine IDE momentan schon über Crossover unter MacOS und dann noch als Übersetzung von x86-->ARM würde das sicher noch schlimmer werden.


Wird für die nächsten Jahre wohl ein Dell XPS in der Firma.

 

[foo_1337]

Docker Container werden nicht klassisch installiert.

Aktuell laufen sie unter macOS auch nicht "klassisch", sondern in einer Linux VM. Und die IO Performance ist da nach wie vor miserabel.

 

[iSight2TheBlind]

Das Problem wird wohl mehr die Software als die Verfügbarkeit einer CPU sein - ich würde Nvidia, Qualcomm usw schon zutrauen da etwas zumindest ähnliches auf den Markt zu bringen.

Naja, Qualcomm schafft es jetzt ja auch nicht den A14 zu schlagen und das war in der Vergangenheit seit langer Zeit nicht anders.

Entweder will man nicht oder man kann nicht.
Und bei Nvidia sieht es erstmal auch so aus.

 

[KurzGedacht]

Aber vielleicht wird es eben Zeit, dass der Kram nicht mehr lokal ausgeführt wird, sondern via gitlab-ci/jenkins etc. direkt via k8s Pod oder zumindest auf ner remote ec2 instanz o.Ä.

Wir haben unsere Staging Umgebungen bei AWS ECS und jenkins baut die uns auch automatisch, aber so kann man nicht entwickeln.
Ein Jenkins Build + Deployment braucht je nach App 5 bis 20 Minuten. Wenn die Entwickler bei jeder Änderung so lange warten müssen, dauert alles ewig.
Ein Entwickler muss seine Änderungen direkt testen können. Dafür sind lokale Umgebungen fast unersetzbar. Die einzige Alternativen ist direkt komplett Remote zu arbeiten, aber dann brauchst du auch kein überteuertes Macbook mehr, sondern nur irgendeinen Thin-Client.

Ergänzung (11. November 2020)

Aktuell laufen sie unter macOS auch nicht "klassisch", sondern in einer Linux VM. Und die IO Performance ist da nach wie vor miserabel.

Das kommt erschwerend noch hinzu. Unsere Mac Entwickler fragen regelmäßig die Linux User, ob sie mal eben schnell ein paar Testscripte laufen lassen und ein Release bauen können, da unter MacOS alles was I/O lastig ist ewig dauert. Aber zumindest die CPU Performance war bisher in Ordnung.

Es wird halt immer schwerer zu argumentieren, warum man so viel Geld für Macbooks ausgeben soll, wenn die Dinger dann die theoretische Performance nicht auf die Straße bringen können.

Es mag Bereiche geben in denen das anders ist, aber zumindest Software Development auf Macs kommt mit einem riesen Haufen Einschränkungen (wobei Windows noch viel schlimmer ist).

 

[Sithys]

https://www.cpu-monkey.com/en/cpu-apple_m1-1804