Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Hardware>ARM-Macs, haben wir damit 99.9% Sicherheit, dass sie kommen?

ARM-Macs, haben wir damit 99.9% Sicherheit, dass sie kommen?

LoCal
LoCal09.06.2013:07
Also wenn Mark Gurman so deutlich darüber schreibt, dann dürfte es eine ausgemachte Sache sein!

„Ich hab zwar keine Lösung, doch ich bewundere dein Problem“
0

Kommentare

Marcel Bresink13.06.2009:46
gfhfkgfhfk
Aber es scheint so zu sein, dass es Dir so schwerfällt das in Erwägung zu ziehen, dass Du auch die technischen Möglichkeiten leugnest.

Nein, Deine Behauptungen verstoßen ganz einfach gegen die mathematische Logik.
gfhfkgfhfk
Nur es gab schon solche Systemen z.B. Spielekonsolen.

Welche Spielkonsole wurde denn mit einem Compiler veröffentlicht?
+1
misc13.06.2016:53
gfhfkgfhfk
Wenn Du nur als registrierter Entwickler in der Lage wärst Programme zu übersetzen und auszuführen, die Du selbst übersetzt hast, dann könnte man sehr wohl noch Software entwickeln und testen. Nur wie verteilst Du dann einen Compiler für eine bestimmte Sprache, mit dem man nur Code erzeugen kann, der auf dem eigenem Computer läuft?

Das ist dann der Tag, an dem sogar ich Apple Good Bye sage und zu Windows oder notfalls Linux switche.
0
Peter Eckel14.06.2002:58
macbeutling
Ist das wirklich noch so?
Ganz klar ja.

Zum einen gibt es viel branchenspezifische Software, die nicht unter macOS läuft und vermutlich auch nie unter macOS laufen wird. Zum zweiten ist "Virtualisierung" nicht nur "Windows", sondern das Feature wird viel weitergehend benötigt. Viele Kollegen und auch ich z.B. virtualisieren ganze Umgebungen mit mehreren Linux-Systemen für Test- und Entwicklungszwecke (Vagrant ist hier eines der Tools, die zum Einsatz kommen). Wenn die Möglichkeit wegfiele, bliebe diesen Nutzern nur eine Migration zu Linux oder Windows - wobei Windows dafür wenig Sinn hat, auch wenn es geht.
macbeutling
Das ist schon lange nicht mehr so, mittlerweile komme ich 100% ohne Virtualisierung aus.
Das hängt stark vom Einsatzzweck ab. Fürs tägliche Leben vieler Nutzer mag es stimmen, aber einige (auch ich) müßten neu bewerten, ob der Mac noch die richtige Plattform ist. Ich setze z.B. ein MacBook Pro 16" mit 64 GB RAM und 8 TB SDD als mobile Test- und Entwicklungsumgebung ein, genau deswegen - den Rechner würde ich so privat nicht brauchen. Wenn ich es mir überhaupt antäte, zwei Plattformen zu pflegen, dann bliebe vielleicht noch mein Mac Mini und mein MacBook Air.
macbeutling
Die Mac-Platform ist, auch dank des iPhones, mittlerweile so groß geworden, dass 90% der Anwender mit Mac-nativen Apps auskommt.
Das ist schwierig einzuschätzen. Es kann stimmen, aber diese 90% kämen dann vermutlich auch mit einem iPad aus.
macbeutling
Technisch bin ich zu wenig in der Materie um bewerten zu können, ob ein ARM-Chip einen lohnenswerten Benefit bringen wird, aber ich gehe mal davon aus, dass es so sein wird (Preis, Performance, Power Consumption), ansonsten würde eine weitere Transition sicherlich nicht angestrebt werden.
Ob die angestrebt wird, weiß man noch nicht. Und wie sie aussieht, wenn sie denn angestrebt wird, auch nicht. Bislang gibt es nur diverse Gerüchte von irgendwelchen "Leakern" und eine Menge wishful thinking. Das wird sich frühestens bei der WWDC klären - oder eben nicht, weil es keine Ankündigung gibt. Und wie ich die Situation einschätze, wird es dann ein weiteres Jahr der ARM-Gerüchte geben.

An Apples Stelle würde ich zügig Fakten auf den Tisch legen. Die Unsicherheit, ob nun ARM kommt oder nicht, ist den Verkäufen eher nichrt förderlich.
macbeutling
Dazu mal eine Frage an die Profis: würden ARM-CHips die Portierung von iOS-Apps hin zu macOS-Apps vereinfachen?
Ich denke nicht. Das bewegt sich eine Abstraktionsebene höher, auf API-Level. In was das Ergebnis dann compiliert wird, ist letztlich egal.
„Ceterum censeo librum facierum esse delendum.“
+1
gfhfkgfhfk14.06.2016:56
Marcel Bresink
Nein, Deine Behauptungen verstoßen ganz einfach gegen die mathematische Logik.
Du hast noch immer nicht erklärt, wie Du Software verteilen willst, die nicht das Wohlwollen des Systemanbieters hat. Momentan kann ein jeder ohne AppStore Software verteilen, bei iOS ist das schon jetzt nicht der Fall. D.h. wie verteilst Du Software, die nicht auf Apples Wohlwollen trifft, falls der AppStore Zwang kommen sollte? Erklär das mal bitte.
0
macbeutling
macbeutling14.06.2019:06
all: bis hierhin erstmal einen dank an die Experten mit ihren Meinungen.

jetzt muss ich noch etwas hinterherschicken: der Wechsel zu Intel kam ja, weil keine PowerPCs on Sicht waren, die man gut hätte in mobiler Geräte hätte einsetzen können (und wie wir sehen, geht Apples Mobilsparte ja deutlich mehr ab, als die stationäre), da sah die Zukunft also düster aus.
Der Switch hat ja auch die Abverkaufszahlen deutlich ansteigen lassen.

Wie seht ihr das bei ARM-CHips?

Sind die den Intel so deutlich überlegene, dass eine weitere Verbesserung des Marktanteils aufgrund einer neuen CPU möglich wäre?
Gibt es überhaupt schon ARM-CHips für Desktop-Rechner oder wäre Apple da der ersten Anbieter?

Ich finde das ganze sehr spannend. Hab den Switch vor 15 Jahren miterlebt und da war hier so einiges los....damals war das Feindbild WINTEL eben noch überall vertreten, heute redet da zum Glück keiner mehr von.

Was ich sagen will: es muss doch für Apple einen deutlichen Mehrwert bringen, auf ARM zu wechseln. Die Hoheit über die Chips alleine kann es doch nicht sein, oder?
„Glück auf🍀“
0
Mendel Kucharzeck
Mendel Kucharzeck14.06.2019:11
macbeutling
Apple wird einen Grund haben umzusteigen – und sie müssen es vermarkten. Das geht über schneller und/oder längere Akkulaufzeit. Eins von beidem oder beides wird zutreffen.

Benchmarks von A12/A13 vs. Intel/AMD-Chips sind vielversprechend, aber es muss sich noch zeigen, ob die A-Chips auch entsprechend skalieren, wenn Taktrate oder Kernanzahl erhöht wird. Apple hat hier sicher mehr Informationen – vielleicht erfahren wir schon am 22.6. etwas stichhaltiges zur Performance.
+2
xcomma14.06.2019:48
macbeutling
Was ich sagen will: es muss doch für Apple einen deutlichen Mehrwert bringen, auf ARM zu wechseln. Die Hoheit über die Chips alleine kann es doch nicht sein, oder?

Das Thema ist sicherlich von mehreren Flanken zu beleuchten und insbesondere einige technische Aspekte werden hier ja schon intensiv diskutiert.

Aber das ganze ist sicherlich primär business- und finanztechnisch getrieben und massgeblich entschieden worden, wie das halt immer so ist.
Produktentwicklung und -zyklen werden stark beeinflusst werden. Noch mehr Hard- und Software Kombination aus einer Hand.
Logischerweise wird der Vendor Lock-in weiter vorangetrieben bzw. damit aus Apple Sicht begünstigt.
Die strategische Entscheidung die Zuliefererkette zu verändern führt natürlich dazu, dass mehr von der Wertschöpfung bei Apple selbst hängen bleibt.

Apple als Firma ist im Fokus. Was der Kunde will, braucht, usw. - ist schon länger nicht mehr der Rede wert. Wird mittels der vermutlich professionellsten Marketingmaschinerie natürlich anders verkauft werden.
0
Mendel Kucharzeck
Mendel Kucharzeck14.06.2021:40
xcomma
Apple als Firma ist im Fokus. Was der Kunde will, braucht, usw. - ist schon länger nicht mehr der Rede wert. Wird mittels der vermutlich professionellsten Marketingmaschinerie natürlich anders verkauft werden.

Natürlich ist Apple als Firma im Fokus von Apple – was auch sonst? Apple will, wie jedes profitbestrebte Unternehmen, möglichst hohen Umsatz und Gewinn schreiben. Dort kommt aber der Kunde sehr wohl ins Spiel: Sollte das Unternehmen den Bogen überspannen, rennen die Kunden weg. Verkaufen sich die Geräte weiterhin und nur man selbst ist unzufrieden hat man vielleicht Spezialanforderungen oder unrealistische Erwartungen. Brechen die Verkäufe jedoch ein, lag das Unternehmen mit der Strategie wohl falsch.
+1
fauental
fauental14.06.2022:12
Wenn nur die Akkulaufzeit steigt, wäre das für reine Desktop-Anwender wie mich unbedeutend. Auch mit der derzeitigen Lautstärke oder dem Stromverbrauch meines iMacs bin ich soweit zufrieden. Welche Vorteile hat denn ein Power-User ohne Spezialanwendungen wie Rendern oder 8K-Videobearbeitung vom Wechsel auf ARM-Prozessoren? Bis jetzt sehe ich nur aufkommende Gewitterwolken (Probleme) am Horizont.
0
gggfam14.06.2022:36
Wichtig zu betrachten ist, dass Apple dann alles selber baut, den ganzen SoC (System-on-a-Chip). Sie haben komplette Kontrolle darüber und können auch an den Preisen schrauben und sind weniger abhängig von einer Drittfirma wie Intel. Das sind alles Vorteile die auch Desktop Macs betreffen. Selbst wenn die Power gleich bleiben sollte im iMac, gibt es viele weitere Vorteile durch den Wechsel.
-4
Weia
Weia14.06.2022:50
gggfam
Wichtig zu betrachten ist, dass Apple dann alles selber baut, den ganzen SoC (System-on-a-Chip). Sie haben komplette Kontrolle darüber und können auch an den Preisen schrauben und sind weniger abhängig von einer Drittfirma wie Intel. Das sind alles Vorteile die auch Desktop Macs betreffen.
Aber das sind doch alles nur Vorteile für Apple? Wo sind die Vorteile für die Nutzer? (Nachteile haben die Nutzer dadurch schließlich jede Menge.)
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+4
AppleUser2013
AppleUser201314.06.2023:04
Ich bin gespannt wieviele Firmen den Arm Switch mitmachen... Avid,Steinberg,Ableton,Bitwig...Plugin Hersteller wie NI,Softube,UAD... Adobe, verschiedene Cad Anwendungen. Compositing..usw usw...

Der Umstieg auf X86 und AMD64 war realitiv leicht, da der Code bei den Windows Versionen ja schon vorhanden war...

Ich bin gespannt, ob alle den Arm Umstieg machen... Ich mein der Anteil an Macs ist eh nicht so hoch und dann werden wohl einige kalkulieren, ob es sich lohnt für eine relativ überschaubare Userschaft so einen Aufwand zu betreiben... Es ist und bleibt spannend...
+2
momirv14.06.2023:13
AppleUser2013
Der Umstieg auf X86 und AMD64 war realitiv leicht, da der Code bei den Windows Versionen ja schon vorhanden war...

Glaubst du, der Code ist Assembler geschrieben??? Der C-Code (oder was auch immer) sieht für X86 oder ARM oder MIPS immer gleich aus.
-4
momirv14.06.2023:30
Weia
gggfam
Wichtig zu betrachten ist, dass Apple dann alles selber baut, den ganzen SoC (System-on-a-Chip). Sie haben komplette Kontrolle darüber und können auch an den Preisen schrauben und sind weniger abhängig von einer Drittfirma wie Intel. Das sind alles Vorteile die auch Desktop Macs betreffen.
Aber das sind doch alles nur Vorteile für Apple? Wo sind die Vorteile für die Nutzer? (Nachteile haben die Nutzer dadurch schließlich jede Menge.)

Es dürfte selbst für Apple schwer sein, den Umstieg zu verkaufen, wenn dieser überhaupt keine Vorteile für den Endkunden bringen würde.

Ein always on MacBook, das leichter, schneller und ausdauernd ist, wäre denkbar und durchaus ein Argument.

Sicher bin ich mir aber nicht! Vllt wird auch die Marketingmaschine angekurbelt und man versucht die Kunden blenden. Da ist Apple immer noch spitze!
+1
gfhfkgfhfk15.06.2000:13
momirv
Glaubst du, der Code ist Assembler geschrieben??? Der C-Code (oder was auch immer) sieht für X86 oder ARM oder MIPS immer gleich aus.
Nein, das ist nicht unbedingt der Fall. Es gibt kleine subtile Unterschiede, die auftreten können. Z.B. eine MIPS CPU in einer SGI IRIX Maschine lief im Big-Endian Modus. Und der SSE bzw. AVX Code für eine x86 CPU läuft auch nicht auf einer ARM CPU.
+3
xcomma15.06.2001:20
Mendel Kucharzeck
Natürlich ist Apple als Firma im Fokus von Apple – was auch sonst?
..der Kunde?
Mendel Kucharzeck
Apple will, wie jedes profitbestrebte Unternehmen, möglichst hohen Umsatz und Gewinn schreiben.
Der Gedanke liegt zwar intuitiv auf der Hand bei den meisten Leuten, aber das wiederum führt zur immer wiederkehrenden Frage, vor allem in wirtschaftswissenschaftlich geprägten Studiengängen: was ist der Sinn und Zweck einer Unternehmung. Deine Antwort wäre so nicht zutreffend.
-1
Gammarus_Pulex
Gammarus_Pulex15.06.2007:13
AppleUser2013
Ich bin gespannt wieviele Firmen den Arm Switch mitmachen... Avid,Steinberg,Ableton,Bitwig...Plugin Hersteller wie NI,Softube,UAD... Adobe, verschiedene Cad Anwendungen. Compositing..usw usw...

Adobe hat es bis heute nicht hinbekommen ihre Aushängeschilder auf code-technisch auf moderne Hardware anzupassen. Mein Monster-Tower hier langweilt sich in Photoshop zu Tode während Photoshop selbst wegen Atemnot kurz vor dem Ende ist, weil es mit der Hardware überhaupt nicht umgehen kann...
+3
ssb
ssb15.06.2007:55
gfhfkgfhfk
momirv
Glaubst du, der Code ist Assembler geschrieben??? Der C-Code (oder was auch immer) sieht für X86 oder ARM oder MIPS immer gleich aus.
Nein, das ist nicht unbedingt der Fall. Es gibt kleine subtile Unterschiede, die auftreten können. Z.B. eine MIPS CPU in einer SGI IRIX Maschine lief im Big-Endian Modus. Und der SSE bzw. AVX Code für eine x86 CPU läuft auch nicht auf einer ARM CPU.
Der Code ist größtenteils in C geschrieben im Lower-End. Manches ist Assembler, zum Beispiel die Syshooks für diverse Std-C-Funktionen, die für I/O und anderes den Kernel brauchen. Kann man sich ja anschauen, ist OpenSource. Erst die Layer darüber wie AppKit sind nicht OpenSource.
Ansonsten SSE und AVX schreibt keiner per Hand, das macht der Compiler und es gibt da grad keinen besseren als clang/llvm.
Aber wen kümmert dieses Zeug. Darwin ist seit iOS auf ARM portiert. UIKit ist die iOS-Variante von AppKit. Der Funktionsumfang sind nicht 1:1, aber auf der Ebene ist der Aufwand beim programmieren geringer, dafür das Testen um so aufwändiger.
Der Umstieg auf Intel ging, weil es Darwin schon gab, nicht zuletzt noch aus NextStep/OpenStep Zeiten. Jetzt ist es noch leichter, weil das meiste schon existiert.
Wenn der ARM Umstieg kommt, wird es vielleicht nicht einmal Entwicklergeräte geben (ich hatte damals einen Marklar), sondern spezielle Profile, mit denen man macos auf einem ipad pro installieren kann. Klar muss ein ARM-Mac mehr drauf haben, aber für Entwickler, die den Umstieg mitmachen reicht das fürs erste. macos, standard Apps und Xcode, mehr braucht der nicht und das sollte auf ein iPad Pro mit 128 GB passen.
+1
AppleUser2013
AppleUser201315.06.2008:15
Zitat Jetzt ist es noch leichter, weil das meiste schon existiert.

Wie meinst du das...Protools und co laufen sofort auf Arm...? Oder was ist mit Massiv X von Ni, welche die Intel Routinen nutzt..(AVX...wenn ich mich nicht irre)

Ich meine, nichts existiert zur Zeit auf Arm...oder verstehe ich das falsch
+3
gacki15.06.2008:42
Mich würde ja interessieren, ob und wie schnell solche Dinge wie Qt oder JUCE verfügbar wären.
M.E. setzen heute wesentlich mehr Applikationen auf solche Frameworks und Toolkits als beim Intel-Umstieg; und so lange die nicht stabil angepasst sind...
Gibt es eigentlich inzwischen Qt für Windows on ARM?
0
gacki15.06.2008:45
fauental
Wenn nur die Akkulaufzeit steigt, wäre das für reine Desktop-Anwender wie mich unbedeutend.

Für viele (sicherlich nicht für alle!) Laptop-Anwender dürfte das auch eine untergeordnete Rolle spielen - bei mir und vielen meiner Kollegen ist es so, dass wir einen mobilen Rechner brauchen, aber trotzdem eigentlich immer eine Steckdose verfügbar haben.
+5
gacki15.06.2008:51
ssb
Wenn der ARM Umstieg kommt, wird es vielleicht nicht einmal Entwicklergeräte geben (ich hatte damals einen Marklar), sondern spezielle Profile, mit denen man macos auf einem ipad pro installieren kann. Klar muss ein ARM-Mac mehr drauf haben, aber für Entwickler, die den Umstieg mitmachen reicht das fürs erste. macos, standard Apps und Xcode, mehr braucht der nicht und das sollte auf ein iPad Pro mit 128 GB passen.
Klar, weil Entwickler es ja schon immer lieben, auf komplett vernagelten Systemen zu programmieren...
+2
gfhfkgfhfk15.06.2008:55
ssb
Ansonsten SSE und AVX schreibt keiner per Hand,
Da täuschst Du Dich aber gewaltig, schau Dir mal den Sourcecode von FFTW an, das enthält auch Code für Neon. Compiler sind sehr viel besser geworden, aber bei typischen HPC Problemen ist von Hand angepasster Code noch immer deutlich besser.
+3
LoCal
LoCal15.06.2010:08
Peter Eckel
macbeutling
Wellenbrett
Ja, verstehe ich. Der Bedarf Windows oder Linux auf dem Mac zu virtualisieren ist da.
Ist das wirklich noch so?
Ganz klar ja.
macbeutling
Das ist schon lange nicht mehr so, mittlerweile komme ich 100% ohne Virtualisierung aus.
Das hängt stark vom Einsatzzweck ab. Fürs tägliche Leben vieler Nutzer mag es stimmen,

Ich zitiere mal die Sterne: "Kannst du dich nicht endlich mal verbindlich entscheiden"

Ich tendiere auch stark in die Richtung, dass 90% der Mac-User ohne eine VMs auskommen.
Peter Eckel
macbeutling
Die Mac-Platform ist, auch dank des iPhones, mittlerweile so groß geworden, dass 90% der Anwender mit Mac-nativen Apps auskommt.
Das ist schwierig einzuschätzen. Es kann stimmen, aber diese 90% kämen dann vermutlich auch mit einem iPad aus.

Ob sie die Arbeit dann auch rein mit einem iPad machen können möchte ich, obwohl ich ein grosser Freund des iPads als Computerersatz bin, bezweifeln. Für die allermeisten ADMs usw. sehe ich das iPad also 100% Notebookersatz und das ist auch heute schon so.
Anders sieht es bei stationären Arbeitsplätzen aus, da sehe ich auch aus ergonomischen Gründen z.B. einen grossen Bildschirm als unabdingbar.
Aber die darunter liegende CPU-Architektur spielt eine untergeordnete Rolle.
Peter Eckel
macbeutling
Dazu mal eine Frage an die Profis: würden ARM-CHips die Portierung von iOS-Apps hin zu macOS-Apps vereinfachen?
Ich denke nicht. Das bewegt sich eine Abstraktionsebene höher, auf API-Level. In was das Ergebnis dann compiliert wird, ist letztlich egal.

Vielleicht doch, den mit SwiftUI und Catalist werden macOS, iPadOS und iOS-Anwendungen was die Codebasis betrifft immer ähnlicher und es können dann schneller und einfacher "Universal-Apps" gebaut bzw. verteilt werden. Aber noch wesentlich vorteilerhafter, vor allem für Apple ist, dass die der Code für die Frameworks wieder schlanker wird.

Und auf z.B. Linux muss erstmal niemand verzichten. Warum sollte man z.B. Docker nicht mit ARM-Macs nutzen?
„Ich hab zwar keine Lösung, doch ich bewundere dein Problem“
0
gggfam15.06.2010:49
Weia
gggfam
Wichtig zu betrachten ist, dass Apple dann alles selber baut, den ganzen SoC (System-on-a-Chip). Sie haben komplette Kontrolle darüber und können auch an den Preisen schrauben und sind weniger abhängig von einer Drittfirma wie Intel. Das sind alles Vorteile die auch Desktop Macs betreffen.
Aber das sind doch alles nur Vorteile für Apple? Wo sind die Vorteile für die Nutzer? (Nachteile haben die Nutzer dadurch schließlich jede Menge.)

Die Vorteile gehen auf die Nutzer über. Zum Beispiel ist Apple komplett losgelöst von Intel und kann wie beim iPhone und iPad theoretisch jedes Jahr ein CPU update ihrer Macs anbieten. Das sind Vorteile für Nutzer. Stell dir vor du musst nicht 2-3 oder manchmal sogar 4-5 Jahre warten bis ein Mac ein Update bekommt, wie beim Mac mini. Stattdessen kann jedes Jahr im Oktober ein neuer AXX chip angeboten werden. Keine Ahnung ob Apple das machen würde.

Die Preise sollten drastisch fallen, außer Apple möchte die Marge erhöhen. CPUs gehören mit dem Display zu den teuersten Komponenten. Entweder Apple behält die Marge gleich und die Macs werden allesamt günstiger oder Apple erhöht den Gewinn bei gleichbleibenden Preisen. Ich hoffe und tippe eher auf ersteres, da man so aggressiver sein kann.

Jede Hardware läuft auf derselben Architektur. Wie viele hier schon geschrieben hat, sollte das den Entwicklern und besonders Apple helfen viel bessere Software zu schreiben, da man sich komplett auf ARM konzentrieren kann. Das ist am Ende ein Riesen Vorteil für den Endkunden.

Es gibt sicher noch viele andere Vorteile, aber das sind doch schon ganz gute wie ich finde.
-5
ssb
ssb15.06.2011:07
gfhfkgfhfk
ssb
Ansonsten SSE und AVX schreibt keiner per Hand,
Da täuschst Du Dich aber gewaltig, schau Dir mal den Sourcecode von FFTW an, das enthält auch Code für Neon. Compiler sind sehr viel besser geworden, aber bei typischen HPC Problemen ist von Hand angepasster Code noch immer deutlich besser.
Im Verhältnis zur Code-Basis sind das aber nur kleine Stellen, wo sich Hand-Optimierung lohnt. Wo das ist, erkennt man mit "Profile-Guided-Optimizations" und Instruments. Dann kann man gezielt dort rangehen, wo am meisten Zeit verbraucht wird. In der Regel geht man dann her, lässt sich vom Compiler Assembler erzeugen und dann wird dieser per Hand optimiert. In sehr vielen Fällen ist das aber gar nicht notwendig. Wenn doch, dann hat man dafür noch Zeit zwischen Ankündigung auf der WWDC und der Verfügbarkeit für Alle.
gacki
ssb
Wenn der ARM Umstieg kommt, wird es vielleicht nicht einmal Entwicklergeräte geben (ich hatte damals einen Marklar), sondern spezielle Profile, mit denen man macos auf einem ipad pro installieren kann. Klar muss ein ARM-Mac mehr drauf haben, aber für Entwickler, die den Umstieg mitmachen reicht das fürs erste. macos, standard Apps und Xcode, mehr braucht der nicht und das sollte auf ein iPad Pro mit 128 GB passen.
Klar, weil Entwickler es ja schon immer lieben, auf komplett vernagelten Systemen zu programmieren...
Glaubst du, die ersten macos Varianten auf dem Marklar waren tauglich? Im Ernst - wir haben unsere Daemons zuvor auch einem normalen PC mit Darwin X86 und GCC gebaut, bevor der Marklar ankam.
Es geht nicht darum, ob das System vernagelt ist - wichtig ist, dass man Code übersetzen, starten, unit-testing ausführen und debuggen kann. Ein Entwickler wird das tun, wenn ARM-Support für ihn wichtig ist. Anfangs wegen Aufwandsabschätzung, dann für die Implementierung. Wichtig dabei für die meisten: je früher sie damit anfangen können, desto besser können sie planen.
Wenn macos auf einem iPad läuft ist es auch nicht mehr vernagelt sondern eben ein macos inkl. Multi-User, offenem Dateisystem, Finder usw. Wie gesagt, das wäre eine Möglichkeit für Apple den Versand von Entwicklergeräten zu umgehen.
In wie weit "Power-User" mit einem ARM-Mac glücklich werden, wird sich zeigen. Ich vermute, der ARM-Mac wird deutlich mehr Cores haben und das muss von der Software ausgenutzt werden. Man erinnere sich an die PS3 mit Cell CPU. Die war rasant mit ihren 7 Cell-Cores und dem Bussystem - Single-Core PowerPC war aber gemütlich. Da mussten die ganzen Spieleentwickler erst einmal Lernen mit Multi-Threading korrekt umzugehen, was nicht so einfach ist, wenn man die Bildwiederholfrequenz als Taktvorgabe hat. Da mag es bei manchen Programmen mehr Aufwand ergeben, manche Aufgabenstellungen sind aber auch linear und können nicht Parallelisiert werden.
0
LoCal
LoCal15.06.2011:17
gggfam

Die Vorteile gehen auf die Nutzer über. Zum Beispiel ist Apple komplett losgelöst von Intel und kann wie beim iPhone und iPad theoretisch jedes Jahr ein CPU update ihrer Macs anbieten. Das sind Vorteile für Nutzer. Stell dir vor du musst nicht 2-3 oder manchmal sogar 4-5 Jahre warten bis ein Mac ein Update bekommt, wie beim Mac mini. Stattdessen kann jedes Jahr im Oktober ein neuer AXX chip angeboten werden. Keine Ahnung ob Apple das machen würde.

Hier zeigt sich übrigens ein leicht ähnliches Bild wie der Switch vom PPC zu intel.
Damals konnte oder wollte* IBM keine weiterentwickelten CPUs liefern**
und Apple musste sich nach einem neuen CPU-Lieferanten umschauen.

Intel steckt heute in einem ähnlichem Dilemma … zwar liefert man regelmäßig neue CPUs, aber die sind hauptsächlich "mehr Cores, leicht höherer Takt".
Aber beim wichtigen Punkt der kleineren Strukturen hinkt intel noch hilflos zurück. So sehr, dass sie einen Schritt schon auslassen und für den übernächsten Planen.
Ein hin und her hüpfen zwischen AMD und intel will sich Apple wohl sparen und setzt deshalb lieber auf eigene Technologien.
Und dass Apple da ein ziemlich gutes Teil am Start hat ist mittlerweile hinlänglich bekannt.


* Von XBox und CELL (PS3) versprach man sich bei IBM mehr

** ich zähle mal langsam von 10 rückwärts … spätestens bei 3 sollen die PPC-Verschwörungstheoretiker auf mich eindreschen
„Ich hab zwar keine Lösung, doch ich bewundere dein Problem“
-1
piik15.06.2012:29
gggfam
Stell dir vor du musst nicht 2-3 oder manchmal sogar 4-5 Jahre warten bis ein Mac ein Update bekommt, wie beim Mac mini. Stattdessen kann jedes Jahr im Oktober ein neuer AXX chip angeboten werden. Keine Ahnung ob Apple das machen würde.
Das lag aber definitiv nicht an den verfügbaren CPUs, sondern an Apples schräger Geschäftspolitik, genau wie beim Mac Pro.
gggfam
Die Preise sollten drastisch fallen, außer Apple möchte die Marge erhöhen.
Wieder voll daneben. Die Kosten werden steigen, da Apple einen großen Aufwand auf relativ wenige CPUs umverteilen muss. Das sind sehr viel kleinere Zahlen als bei den ARM-SoCs für iPhone & Co. und auch sehr viel weniger als Intel oder AMD verkauft.

Insgesamt bist du ein super Beispiel für wishful thinking, bei denen die Fakten einfach Pech gehabt haben, wenn sie Deiner Erwartung widersprechen.
0
LoCal
LoCal15.06.2012:51
piik
gggfam
Stell dir vor du musst nicht 2-3 oder manchmal sogar 4-5 Jahre warten bis ein Mac ein Update bekommt, wie beim Mac mini. Stattdessen kann jedes Jahr im Oktober ein neuer AXX chip angeboten werden. Keine Ahnung ob Apple das machen würde.
Das lag aber definitiv nicht an den verfügbaren CPUs, sondern an Apples schräger Geschäftspolitik, genau wie beim Mac Pro.
Da liegst Du falsch, Apple hat schon Updates für iMac, und wenn ich mich richtig erinnre auch die für MacBook Pros, wegen nichtvorhandenen neuen intel-CPUs verschoben
piik
gggfam
Die Preise sollten drastisch fallen, außer Apple möchte die Marge erhöhen.
Wieder voll daneben. Die Kosten werden steigen, da Apple einen großen Aufwand auf relativ wenige CPUs umverteilen muss. Das sind sehr viel kleinere Zahlen als bei den ARM-SoCs für iPhone & Co. und auch sehr viel weniger als Intel oder AMD verkauft.

Auch hier dürftest Du falsch liegen. Apple hat schon die ARM-CPUs, der AxxX für die iPads wird nicht nicht gross von den AxxX in den MacBooks unterscheiden.

Weiter werden sich sehr viele Kosten einsparen lassen, da der gesamte Aufbau wesentlich einfacher wird, alleine die aufwendige Kühlung der x86er die man beim AxxX nicht benötigt …
„Ich hab zwar keine Lösung, doch ich bewundere dein Problem“
0
gfhfkgfhfk15.06.2012:56
LoCal
** ich zähle mal langsam von 10 rückwärts … spätestens bei 3 sollen die PPC-Verschwörungstheoretiker auf mich eindreschen
Irgendwie hat man im Jahr 2020 ein Problem damit die Meinungen anderer zu akzeptieren. Die Beurteilung des damaligen Switchs ist insofern von Bedeutung, weil es um die intrinsische Motivation von Apple geht. Waren es in erster Linie die Bedürfnisse der Kunden, oder waren es vor allem wirtschaftliche Interessen von Apple? Und genau die gleichen Fragen, treten doch jetzt exakt gleich wieder auf. Für den Kunden sind die Wechsel eigentlich immer mit Nachteilen verbunden. Wobei der Wechsel von 68k auf PowerPC sehr weich ablief. Die meisten 68k Programme liefen sogar noch unter MacOS X 10.4 auf einem PowerPC – dank Classic Umgebung.
+2
gfhfkgfhfk15.06.2012:59
ssb
Im Verhältnis zur Code-Basis sind das aber nur kleine Stellen, wo sich Hand-Optimierung lohnt. Wo das ist, erkennt man mit "Profile-Guided-Optimizations" und Instruments. Dann kann man gezielt dort rangehen, wo am meisten Zeit verbraucht wird. In der Regel geht man dann her, lässt sich vom Compiler Assembler erzeugen und dann wird dieser per Hand optimiert. In sehr vielen Fällen ist das aber gar nicht notwendig. Wenn doch, dann hat man dafür noch Zeit zwischen Ankündigung auf der WWDC und der Verfügbarkeit für Alle.
Nur lässt sich so ein Code nicht einfach so portieren. Üblicherweise muss man sich auf der neuen Plattform zuerst mit den notwendigen APIs vertraut machen, um eine hochoptimierte Version entwickeln zu können. Normaler Standardcode wird die Aufgabe lösen, aber halt nicht entsprechend performant.
+1
gggfam15.06.2012:59
piik
Das lag aber definitiv nicht an den verfügbaren CPUs, sondern an Apples schräger Geschäftspolitik, genau wie beim Mac Pro.
Da muss ich dir leider widersprechen. Muss Apple nicht ständig auf Intel warten? Das haben doch andere hier auch schon so beschrieben. So viel ich weiß liefert Intel zu langsam neue CPUs hinterher.
piik
Wieder voll daneben. Die Kosten werden steigen, da Apple einen großen Aufwand auf relativ wenige CPUs umverteilen muss. Das sind sehr viel kleinere Zahlen als bei den ARM-SoCs für iPhone & Co. und auch sehr viel weniger als Intel oder AMD verkauft.
Insgesamt bist du ein super Beispiel für wishful thinking, bei denen die Fakten einfach Pech gehabt haben, wenn sie Deiner Erwartung widersprechen.
Das verstehe ich nicht. Wo liegt denn zum Beispiel noch der Unterschied zwischen einem iPad Pro und einem MacBook. Im Inneren wären da kaum Unterschiede oder? Das Display (Touch) und die Tastatur (MacBook) sind doch dann Hardwareseitig das einzige was die beiden Unterscheiden könnte oder? Board mit Chips und Akku wären fast identisch. Apple spart doch immens an Kosten, wenn sie nicht die teuren CPUs von Intel kaufen müssen, sondern ihre eigenen jetzt schon produzierten CPUs einfach vermehrt. Wo ist das wishful thinking? Apple baut mehr seiner eigenen jetzt schon gebauten Chips für noch mehr iPads, die jetzt ohne Touch und mit Tastatur gekauft werden können und MacBooks heißen. Auf dem Gerät läuft dann nur macOS statt iPadOS. Übersehe ich da etwas?
-2
gggfam15.06.2013:09
LoCal
Apple hat schon die ARM-CPUs, der AxxX für die iPads wird nicht nicht gross von den AxxX in den MacBooks unterscheiden.
Weiter werden sich sehr viele Kosten einsparen lassen, da der gesamte Aufbau wesentlich einfacher wird, alleine die aufwendige Kühlung der x86er die man beim AxxX nicht benötigt …
Genauso sehe ich das auch
-1
LoCal
LoCal15.06.2013:38
gfhfkgfhfk
LoCal
** ich zähle mal langsam von 10 rückwärts … spätestens bei 3 sollen die PPC-Verschwörungstheoretiker auf mich eindreschen
Irgendwie hat man im Jahr 2020 ein Problem damit die Meinungen anderer zu akzeptieren. Die Beurteilung des damaligen Switchs ist insofern von Bedeutung, weil es um die intrinsische Motivation von Apple geht. Waren es in erster Linie die Bedürfnisse der Kunden, oder waren es vor allem wirtschaftliche Interessen von Apple? Und genau die gleichen Fragen, treten doch jetzt exakt gleich wieder auf. Für den Kunden sind die Wechsel eigentlich immer mit Nachteilen verbunden. Wobei der Wechsel von 68k auf PowerPC sehr weich ablief. Die meisten 68k Programme liefen sogar noch unter MacOS X 10.4 auf einem PowerPC – dank Classic Umgebung.

Ich kann sehr gut Meinungen anderer Menschen akzeptieren, nur kann ich dieses verdrehte geschwurbel mancher (von denen niemand hier in der Diskussion ist) mehr hören.
Aber besonders in der Retrospektive sieht man mehr als deutlich, dass der damalige Schritt der richtige war und das hat nichts mit "man kann jetzt auch Windows installieren". Wer sich übrigens genau zurück erinnert, der wird merken, dass Apple das ursprünglich überhaupt nicht wollte. BootCamp kam erst, als es schon Tools gab, die die Installation ermöglichten.
Aber wie stand es denn um den G5 vor dem intel-Switch? IBM konnte keine neuen und keine höher getakteten CPUs liefern. Und man gab Microsoft mit der XBox und Sony mit dem CELL eine wesentlich höhere Priorität. An einen notebookfähigen G5 war überhaupt nicht zu denken.
Es hätte zwar noch alternative Hersteller gegeben, aber ob diese die Kapazitäten gehabt hätten Apple zu beliefern und ob diese dem Druck von Apple standgehalten hätten, das möchte ich bezweifeln.

Für Apple lösten sich zum damaligen Zeitpunkt mit dem Switch mehrere Probleme und eines der grössten war: die Verfügbarkeit neuer CPUs.

Und wenn ich mir den Stand der Power-Plattform anschaue, dann bin ich mir alles andere als sicher, ob ich deren Zukunft als rosig bezeichnen würde. Und ein Blick über den Tellerrand: Wieviele der CPU-Plattformen haben denn "überlebt"?
Damals gab die SGIs mit MIPS, Suns SPARC, HP mit Itaniums und Alpha.
Plus Kleinkram wie z.B. der Cursoe …
Sie sind alle weg und das nicht ohne Grund!
Was heute geblieben ist sind ARMs und x86 und ARMs sind die weit grössere Plattform, das sollte man auch mal nicht unter den Tisch fallen lassen.
„Ich hab zwar keine Lösung, doch ich bewundere dein Problem“
0
Weia
Weia15.06.2014:48
gggfam
Weia
Aber das sind doch alles nur Vorteile für Apple? Wo sind die Vorteile für die Nutzer? (Nachteile haben die Nutzer dadurch schließlich jede Menge.)
Die Vorteile gehen auf die Nutzer über. Zum Beispiel ist Apple komplett losgelöst von Intel und kann wie beim iPhone und iPad theoretisch jedes Jahr ein CPU update ihrer Macs anbieten. Das sind Vorteile für Nutzer.
Ich sähe das als Nachteil. Beim jetzigen Reifegrad der IT-Technologie sehe ich (von Spezialsituationen wie Rendering-Farmen abgesehen) im Gegensatz zu den 0er Jahren und mit Einschränkungen dem letzten Jahrzehnt kaum Vorteile mehr in hektischen Updatezyklen, aber enorme Nachteile von ökologischen Aspekten bis hin zu mangelnder Ausgereiftheit und Dokumentensicherheit über lange Zeiträume.

Da sich bei Grafikkarten noch immer viel tut und Massensppeicherbedarf mit der Lebensdauer trivialerweise kontinuierlich wächst und SSDs zudem eine begrenzte Lebensdauer haben, wären meines Erachtens austauschbare Grafikkarten und SSDs in allen Macs weit hilfreicher für den Nutzer als jährliche Update-Zyklen für die Prozessoren.
Stell dir vor du musst nicht 2-3 oder manchmal sogar 4-5 Jahre warten bis ein Mac ein Update bekommt, wie beim Mac mini. Stattdessen kann jedes Jahr im Oktober ein neuer AXX chip angeboten werden.
Fände ich keine schöne Vorstellung. Je öfter neue Genrationen erscheinen, desto mehr besteht die Gefahr, dass ältere Macs frühzeitig nicht mehr unterstützt werden. Ich erwarte aber von einem Computer, ihn mindestens 10 Jahre ohne Kompromisse nutzen zu können; das ist für mich eines der wichtigsten Usabilty-Kriterien überhaupt. Wenn nur alle paar Jahre neue Hardware-Genrationen erscheinen, ist das viel eher gewährleistet.

Die 1-jährigen Updatezyklen bei iPhones sind Kapitalismus at its worst. Wir müssen schleunigst weg von einer hohldrehenden Wegwerfgesellschaft. Und wenn man sich den Qualitätsverfall von macOS aufgrund der hektischen Updatezyklen ansieht, ist damit ebenfalls niemandem gedient. Es ist ja praktisch nicht mehr möglich, mit einem weitgehend fehlerfreien macOS zu arbeiten. In der Version, die Bug x fixt, taucht Bug y auf …

Nach den aufgrund technischen Fortschritts unvermeidbaren Umstellungen auf 64 Bit und schnelle Grafikkarten (Metal) sah es gerade so aus, als könnte eine Phase der Stabilität eintreten, in der es keinen technischen Grund mehr gibt, dass macOS nicht auch noch 10 Jahre alte Macs unterstützt. Wenn Apple jetzt konsequent auf ARM schwenkt, wird mit einiger Wahrscheinlichkeit eine jetzt > 6000 € teure Maschine wie der Mac Pro bereits in wenigen Jahren nicht mehr mit aktuellen macOS-Versionen versorgt werden, obwohl seine Modularität ansonsten lange Lebensdauer gewährleisten würde. Wenn es so kommt, hielte ich das für inakzeptabel.
Die Preise sollten drastisch fallen
Träum weiter. Was immer sich an Einsparungen für Apple ergeben sollte (falls es die gibt, siehe die Argumente von piik), wird Apple einstreichen. Die bringen es fertig und erhöhen stattdessen die Preise mit dem Hinweis auf die tollen neuen Prozessoren …
Jede Hardware läuft auf derselben Architektur. Wie viele hier schon geschrieben hat, sollte das den Entwicklern und besonders Apple helfen viel bessere Software zu schreiben, da man sich komplett auf ARM konzentrieren kann. Das ist am Ende ein Riesen Vorteil für den Endkunden.
Falsch. Welche Vorteile sollten Endkunden davon haben, wenn die Entwicklung leichter wird? Das ist wenn, dann wieder nur ein Vorteil für Apple und die Entwickler. (Ist es aber gar nicht, weil die These, das würde irgendwas vereinfachen, nicht stimmt – Cocoa ist schon jetzt perfekt Cross-Platform, ob Du für ein oder zwei Prozessortypen kompilierst, macht praktisch keinen Unterschied.)

Für Endkunden hingegen bedeutet dies Zwangsupdates für alle ihre Software. Das kann je nach Software in die Zehntausende an Kosten gehen und wichtige Programme, die dummerweise nicht mehr aktualisiert werden, fallen damit völlig aus, was im Einzelfall ein Riesenproblem sein kann.

Ich fürchte auch, dass Apple das machen wird, aber für Nutzer ist das, nachdem nach 64 Bit und Metal endlich mal Ruhe hätte einkehren können, eine Alptraumnachricht.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+6
gacki15.06.2015:21
ssb
gacki
Klar, weil Entwickler es ja schon immer lieben, auf komplett vernagelten Systemen zu programmieren...
Glaubst du, die ersten macos Varianten auf dem Marklar waren tauglich? Im Ernst - wir haben unsere Daemons zuvor auch einem normalen PC mit Darwin X86 und GCC gebaut, bevor der Marklar ankam.
Es geht nicht darum, ob das System vernagelt ist - wichtig ist, dass man Code übersetzen, starten, unit-testing ausführen und debuggen kann. Ein Entwickler wird das tun, wenn ARM-Support für ihn wichtig ist. Anfangs wegen Aufwandsabschätzung, dann für die Implementierung. Wichtig dabei für die meisten: je früher sie damit anfangen können, desto besser können sie planen.
Wenn macos auf einem iPad läuft ist es auch nicht mehr vernagelt sondern eben ein macos inkl. Multi-User, offenem Dateisystem, Finder usw. Wie gesagt, das wäre eine Möglichkeit für Apple den Versand von Entwicklergeräten zu umgehen.

Dann erzähl doch mal, wie man am iPad Pro gleichzeitig einen vernünftig großen externen Monitor UND ein vernünftig großes Audiointerface betreiben soll. Im Audiobereich wäre so was das Minimum, um überhaupt über Entwicklung nachdenken zu können. Wie ist es mit dem Datendurchsatz, wenn man 8 Spuren Audiomaterial mit 24/96 (oder höher) aufnimmt? Wo speichert man das überhaupt?
Was ist mit den Entwicklern, die zwingend eine eGPU brauchen?
Als Entwicklungsmaschine ist ein iPad Pro aus meiner Sicht herzlich ungeeignet, selbst wenn ein vollwertiges macOS drauf laufen sollte.
+3
ssb
ssb15.06.2015:36
gfhfkgfhfk
Nur lässt sich so ein Code nicht einfach so portieren. Üblicherweise muss man sich auf der neuen Plattform zuerst mit den notwendigen APIs vertraut machen, um eine hochoptimierte Version entwickeln zu können. Normaler Standardcode wird die Aufgabe lösen, aber halt nicht entsprechend performant.
Welche APIs?
Die vom Kernel? Den Darwin Kernel gibt es schon für ARM (iOS).
Die vom System? Der Kernel ist das System, gibt es also schon.
Die Framework APIs? Die macht Apple doch selbst.
Meinst du die ABIs? Gibt es auch schon für iOS.

Was bleibt übrig? Der Finder, anderes Sandboxing, ein paar Frameworks. Ich sehe da kein großes Problem bei der Portierung an sich nachdem die großen Knackpunkte für iOS bereits gemacht wurden. So viel fällt da an Tuning gar nicht an. Problem sind eher die dedizierten Treiber für die zukünftige Hardwareplatform, Boarddesign und wie dies alles in IOKit repräsentiert wird und das der (U)EFI-Bootloader dazu passt.
Ist ja nicht so, dass man für einen Dieselmotor das Auto neu erfinden muss, wenn man vorher nur Benziner gebaut hat. Viel weiter ist die Umstellung bei macOS von Intel auf ARM nicht entfernt und das meiste wurde eben schon mit iOS gelöst. Da war die Umstellung von PowerPC auf Intel schwieriger, weil sogar die Firmware komplett neu war. Aber der Mach-Kernel ist grundsätzlich dafür konzipiert worden, möglichst portabel zu sein und würde es sogar zulassen in einem Verbund verschiedene CPUs zu benutzen.

Den Standard-Code mit bereits verfügbaren Optimierungen (iOS) wird es in den Entwicklerversionen geben, dann wird weiter optimiert. Aber glaubst du, dass Metal auf iOS schlampig gemacht ist und auf macOS viel besser optimiert ist? Wohl kaum. Es wird noch Optimierungsbedarf geben, den gibt es immer, aber die Hilfsmittel dazu hat Apple bereits innerhalb Xcode.
0
Weia
Weia15.06.2015:40
ssb
gfhfkgfhfk
Nur lässt sich so ein Code nicht einfach so portieren. Üblicherweise muss man sich auf der neuen Plattform zuerst mit den notwendigen APIs vertraut machen, um eine hochoptimierte Version entwickeln zu können. Normaler Standardcode wird die Aufgabe lösen, aber halt nicht entsprechend performant.
Welche APIs?
gfhfkgfhfk bezieht sich doch offenkundig auf handoptimierten Assembler-Code im eigenen Programm. Und da hat er recht.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
-1
gacki15.06.2015:45
ssb
gfhfkgfhfk
Nur lässt sich so ein Code nicht einfach so portieren. Üblicherweise muss man sich auf der neuen Plattform zuerst mit den notwendigen APIs vertraut machen, um eine hochoptimierte Version entwickeln zu können. Normaler Standardcode wird die Aufgabe lösen, aber halt nicht entsprechend performant.
Welche APIs?
Die vom Kernel? Den Darwin Kernel gibt es schon für ARM (iOS).
Die vom System? Der Kernel ist das System, gibt es also schon.
Die Framework APIs? Die macht Apple doch selbst.
Meinst du die ABIs? Gibt es auch schon für iOS.

Was bleibt übrig?

Ich hatte weiter oben schon die Frage nach Qt und JUCE gestellt.
0
ssb
ssb15.06.2015:45
gacki
Dann erzähl doch mal, wie man am iPad Pro gleichzeitig einen vernünftig großen externen Monitor UND ein vernünftig großes Audiointerface betreiben soll. Im Audiobereich wäre so was das Minimum, um überhaupt über Entwicklung nachdenken zu können. Wie ist es mit dem Datendurchsatz, wenn man 8 Spuren Audiomaterial mit 24/96 (oder höher) aufnimmt? Wo speichert man das überhaupt?
Was ist mit den Entwicklern, die zwingend eine eGPU brauchen?
Als Entwicklungsmaschine ist ein iPad Pro aus meiner Sicht herzlich ungeeignet, selbst wenn ein vollwertiges macOS drauf laufen sollte.
USB-C Hub oder Dock? Braucht der Entwickler eine eGPU oder der Anwender diese, um die Software nutzen zu können (weswegen der Entwickler die eGPU dann auch hat)?

Es geht um Entwicklermaschinen, um die Software zu portieren, bevor die ARM-Macs da wären. Für 90% der Software würde das sogar reichen und natürlich würde Apple selbst ihre ProApps auf vollwertigen ARM-Macs testen müssen. Ein neuer Mac darf ja nicht weniger können als sein Vorgänger. Aber man kann die Software darauf neu bauen (oder dafür neu bauen) und erste Tests machen.
Der Marklar war auch nur ein Pentium 4, Schnittstellen waren nicht verfügbar, usw. Trotzdem konnte man seine Software damit portieren und bis zu einem gewissen Grad auch testen.
Es mag dann noch Entwickler-ARM-Macs geben, die dann die Schnittstellen haben, dedizierte Grafikkarte etc. - aber 90% der Entwickler werden die dann gar nicht brauchen.
-1
ssb
ssb15.06.2016:06
@weia:
Code den er in seiner Anwendung handoptimiert kann Apple nicht kennen und wird sich darum nicht kümmern. Empfehlung von Apple: vDSP oder ähnliche Frameworks benutzen, die werden von Apple optimiert oder vom Compiler und clang/llvm ist da sehr gut, eventuell kommt zudem Bitcode-Submission, dann kannst du keinen Assembler mehr benutzen sondern müsstest LLVM-IR verwenden.

@gacki:
JUCE kenne ich nicht. QT basiert auf C++ und die libcpp wird von Apple mitgeliefert. Da muss halt, wenn man QT baut, das CMake-Script entsprechend angepasst werden und >95% sollten sich damit erledigt haben. Bei QT vielleicht sogar 100% weil es QT schon für viele Plattformen inkl. ARM gibt. Dürfte bei Boost ähnlich sein. Aber dennoch wird die OpenSource-Community damit viel Arbeit haben, daher eben früh Geräte bereitstellen.

Keiner sagt, dass es ein Spaziergang wird und je weniger man die offiziellen Frameworks benutzt, desto mehr Arbeit wird man haben. Ich kenne das zum Beispiel daher, dass meine iPadOS App nicht mit Catalyst auf macOS portiert werden kann, weil sie VLCKit/libVLC benutzt, welches OpenGL benutzt und das gibt es unter Catalyst nicht. Spannender könnte also werden, welche Zöpfe Apple da abschneidet.
-1
gacki15.06.2016:18
ssb
gacki
Dann erzähl doch mal, wie man am iPad Pro gleichzeitig einen vernünftig großen externen Monitor UND ein vernünftig großes Audiointerface betreiben soll. Im Audiobereich wäre so was das Minimum, um überhaupt über Entwicklung nachdenken zu können. Wie ist es mit dem Datendurchsatz, wenn man 8 Spuren Audiomaterial mit 24/96 (oder höher) aufnimmt? Wo speichert man das überhaupt?
Was ist mit den Entwicklern, die zwingend eine eGPU brauchen?
Als Entwicklungsmaschine ist ein iPad Pro aus meiner Sicht herzlich ungeeignet, selbst wenn ein vollwertiges macOS drauf laufen sollte.
USB-C Hub oder Dock? Braucht der Entwickler eine eGPU oder der Anwender diese, um die Software nutzen zu können (weswegen der Entwickler die eGPU dann auch hat)?
Da dürfte die Datenrate nicht mehr ausreichen.
ssb
Es geht um Entwicklermaschinen, um die Software zu portieren, bevor die ARM-Macs da wären. Für 90% der Software würde das sogar reichen und natürlich würde Apple selbst ihre ProApps auf vollwertigen ARM-Macs testen müssen. Ein neuer Mac darf ja nicht weniger können als sein Vorgänger. Aber man kann die Software darauf neu bauen (oder dafür neu bauen) und erste Tests machen.

ProTools? Cubase? Ableton Live? Tracktion?
Wie soll man solche Software auf so einer Krücke denn sinnvoll testen?

Hat das iPad nicht bloß 4GB RAM? Arg wenig für macOS, Entwicklungsumgebungen und App...
+2
gacki15.06.2016:25
ssb
@gacki:
JUCE kenne ich nicht. QT basiert auf C++ und die libcpp wird von Apple mitgeliefert. Da muss halt, wenn man QT baut, das CMake-Script entsprechend angepasst werden und >95% sollten sich damit erledigt haben. Bei QT vielleicht sogar 100% weil es QT schon für viele Plattformen inkl. ARM gibt. Dürfte bei Boost ähnlich sein. Aber dennoch wird die OpenSource-Community damit viel Arbeit haben, daher eben früh Geräte bereitstellen.

Ich frage deshalb, weil ich bei Qt bei den "supported platforms" bei Windows 10 lediglich "x86 and x86_64" finde.
Bei den mobilen Applikationen gibt es noch "Universal Windows Platform 10" für ARM; aber so weit ich weiß, sind das eben keine "vollwertigen" Windows-Programme.
Sofern ich mich täusche, bitte ich um Korrektur - aber bedeutet das nicht, dass es von Qt bisher keinen Port für "Windows on ARM" gibt?
0
piik15.06.2016:27
LoCal
piik
gggfam
Stell dir vor du musst nicht 2-3 oder manchmal sogar 4-5 Jahre warten bis ein Mac ein Update bekommt, wie beim Mac mini. Stattdessen kann jedes Jahr im Oktober ein neuer AXX chip angeboten werden. Keine Ahnung ob Apple das machen würde.
Das lag aber definitiv nicht an den verfügbaren CPUs, sondern an Apples schräger Geschäftspolitik, genau wie beim Mac Pro.
Da liegst Du falsch, Apple hat schon Updates für iMac, und wenn ich mich richtig erinnre auch die für MacBook Pros, wegen nichtvorhandenen neuen intel-CPUs verschoben
Nein, das ist einfach nicht wahr. Das glaubst Du nur. Mehr nicht. Apple hat definitiv nicht zu jeder CPU-Generation von Intel ein Update gebracht. bei weitem nicht.
Das ist Fakt und nicht Deine Wahrnehmungsverzerrungen.
quote=LoCal]
piik
gggfam
Die Preise sollten drastisch fallen, außer Apple möchte die Marge erhöhen.
Wieder voll daneben. Die Kosten werden steigen, da Apple einen großen Aufwand auf relativ wenige CPUs umverteilen muss. Das sind sehr viel kleinere Zahlen als bei den ARM-SoCs für iPhone & Co. und auch sehr viel weniger als Intel oder AMD verkauft.

Auch hier dürftest Du falsch liegen. Apple hat schon die ARM-CPUs, der AxxX für die iPads wird nicht nicht gross von den AxxX in den MacBooks unterscheiden.

Weiter werden sich sehr viele Kosten einsparen lassen, da der gesamte Aufbau wesentlich einfacher wird, alleine die aufwendige Kühlung der x86er die man beim AxxX nicht benötigt …
[/quote]
Da spricht der volle Nichtexperte, der eigenen Fantasien mehr Gewicht beimisst als Fakten.
Die bisherigen A-Chips von Apple taugen nullkommaüberhauptnicht für einen Laptop und schon gleich überhaupt nicht für einen Desktop. Es existiert bisher überhaupt nicht ein einiger Dekstop-Chip von Apple. Denn zu entwickeln ist eine enorme Aufgabe. Ein Mobil-SoC unterscheidet sich massiv von einer richtigen CPU. Diese Entwicklung kostet enorm viel Geld. Und das für die paar CPUs, die Apple für MBPs und iMacs braucht? Oder für einen Mac Pro, der ein ganz anderes Kaliber von CPU erfordert?
Woher willst Du denn wissen, dass der Aufbau einfacher würde. Bauchgefühl?
Oder dass eine CPU für Desktops auf ARM-Basis wirklich so viel weniger Strom verbrauchen würde?
Es gibt keine solche CPU. Also ist alles, was Du sagst, unbelegte Spekulation.
Es ist zum Haare raufen, was Leute so glauben.
Nächste Woche wissen wir Bescheid.
Ich freu mich schon drauf
+3
piik15.06.2016:30
gggfam
piik
Das lag aber definitiv nicht an den verfügbaren CPUs, sondern an Apples schräger Geschäftspolitik, genau wie beim Mac Pro.
Da muss ich dir leider widersprechen. Muss Apple nicht ständig auf Intel warten? Das haben doch andere hier auch schon so beschrieben. So viel ich weiß liefert Intel zu langsam neue CPUs hinterher.

Das ist nicht wahr.
Einfach nicht.
Schau mal, wieviel CPU-Generationen es gab und ob Apple nicht immer wieder Generationen übersprungen hat.
Ist es so schwierig, bei den Fakten zu bleiben? Stattdessen einfach die Wiederholung der Behauptung. Du behauptest, also belege Deine Behauptung. Kannst Du nicht. Weil sie einfach nicht stimmt.

Aber es ist jetzt gut für mich. Bitte schön weiterträumen...
+3
ssb
ssb15.06.2016:44
gacki
ProTools? Cubase? Ableton Live? Tracktion?
Wie soll man solche Software auf so einer Krücke denn sinnvoll testen?

Hat das iPad nicht bloß 4GB RAM? Arg wenig für macOS, Entwicklungsumgebungen und App...
iPad Pro 2020 hat 6GB, aber ja, das könnte eng werden.
Und ja es wird eine Krücke, so wie es der Marklar auch war. Trotzdem konnte man portieren. Die Audio- oder Videotools mögen für dich wichtig sein und den größten Teil deiner Zeit am Computer in Anspruch nehmen. Für den Großteil der Anwender trifft das aber nicht zu und der Großteil der Software hat keine solchen Ansprüche an die Hardware.
Du würdest Cubase ja auch nicht auf einem MacBook Air von 2015 einsetzen, zumindest nicht, wenn du mitten in einer Produktion bist. Die Pro Geräte werden den Wechsel zu ARM erst später vollziehen.

Denke mal nicht an deine Maximal-Profi-Anwendungen, sondern denke mal an: wir machen das Zug um Zug... War beim Intel-Switch auch so. Es ist insgesamt der 4. große Wechsel von Apple: 68k PPC, System 9 OS X, PPC Intel und jetzt eben (wenn er kommt) Intel ARM. Jedes Mal wurde Panik geschoben und doch hat es am Ende immer geklappt. Ich habe jeden dieser Wechsel mit gemacht und gerade der PPC-Architektur trauere ich ein wenig nach (immerhin ist ARM wieder RISC). Dennoch ist jedesmal etwas gutes bei rausgekommen, wenn auch manchmal nicht auf Anhieb. Man muss Apple nur Zeit lassen, na gut, und den Softwareherstellern. Selbst Adobe wird da nachziehen, sonst werden die Abos gekündigt und die User laufen endgültig zur Konkurrenz über, die da sehr flott reagieren wird.
-3
gfhfkgfhfk15.06.2018:21
ssb
Welche APIs?
Die C API für die Anwendungen hochoptimierter Funktionen. Man muss kein Assembler nutzen, um direkt SSE oder AVX zu nutzen, das geht über die intrinsischen Funktionen für SSE und AVX. Wenn man von x86 auf ARM portiert, muss man NEON erlernen. Das geht nicht in ein paar Minuten, aber ist eine lösbare Aufgabe. Nur sollte man da nicht so tun, als ob keine Arbeit anfallen würde.
ssb
Ich habe jeden dieser Wechsel mit gemacht und gerade der PPC-Architektur trauere ich ein wenig nach (immerhin ist ARM wieder RISC).
Wenn man die Benchmarks kennt, dann erscheint der Wechsel auf ARM wie eine extrem unsinnige Idee. Kurzform die ARM CPUs haben bis auf den Java Benchmark keine Chance gegen die POWER9 oder die x86 CPUs. Mal sehen was Apple an CPUs liefern wird, aber diese CPUs sind keine Alternative zu den x86 oder den POWER CPUs.
+6
Weia
Weia15.06.2019:40
ssb
Code den er in seiner Anwendung handoptimiert kann Apple nicht kennen
Behauptet ja auch keiner.
und wird sich darum nicht kümmern. Empfehlung von Apple: vDSP oder ähnliche Frameworks benutzen
Und das heißt eben Code neu schreiben. Mehr hat gfhfkgfhfk doch nicht behauptet.
„“I don’t care” is such an easy lie. (The Warning, “Satisfied”)“
+2
Apple@Wien
Apple@Wien15.06.2019:58
piik

Hier spricht einer der auch nicht viel Ahnung mit bringt. Zum einen gibts es bereits ARM Desktops, ARM Server und Apple ist hier nicht allein am probieren.

Huawei hat einen Desktop am Start...





Verschiedene Linux Derivate haben Desktop Systeme für ARM. Windows 10 existiert nun für ARM, Apple wäre hier sogar relativ spät dran.


Erster Super Computer mit ARM in Entwicklung und der ist ganz Nebenbei schneller als x86...




Aber in einem Punkt gebe ich dir Recht. Am 22. Juni wissen wir alle mehr.😉
+1
Cersei8615.06.2020:12
Weia
Da sich bei Grafikkarten noch immer viel tut und Massensppeicherbedarf mit der Lebensdauer trivialerweise kontinuierlich wächst und SSDs zudem eine begrenzte Lebensdauer haben, wären meines Erachtens austauschbare Grafikkarten und SSDs in allen Macs weit hilfreicher für den Nutzer als jährliche Update-Zyklen für die Prozessoren.
Die 1-jährigen Updatezyklen bei iPhones sind Kapitalismus at its worst. Wir müssen schleunigst weg von einer hohldrehenden Wegwerfgesellschaft. Und wenn man sich den Qualitätsverfall von macOS aufgrund der hektischen Updatezyklen ansieht, ist damit ebenfalls niemandem gedient. Es ist ja praktisch nicht mehr möglich, mit einem weitgehend fehlerfreien macOS zu arbeiten. In der Version, die Bug x fixt, taucht Bug y auf.
+1
Amen to that!
+4

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.