SuperGAU für Entwickler: Apple schmeißt OpenGL & OpenCL raus!

[haebbmaster]

Weil es nicht in Swift oder Objective-C geschrieben ist

das kompiliere ich einmal neu und gut ist.

Hm, wer da jetzt wohl recht hat?

 

[Grenzfrequenz]

Wenn der Massenmarkt auf Anwendungen steht, die heftig auf Fließkommaberechnungen setzen müssen, dann wird sich an x86 als etabliertem Standard so schnell wohl nichts ändern. Es nützt einfach nichts, wenn ein ARM-CPU zwar effizient, aber eben nicht effektiv ist.
Ein aktuelles Beispiel ist Nintendos Switch-Konsole, die neben dem ARM-Prozessor für die Bewältigung der ganzen Grafikberechnungen eben auch eine nVidia-Tegra X1-GPU braucht und extrem stromhungrig ist und entsprechend viel Abwärme abgibt. Ohne Coprozessoren geht auch bei ARM eben nicht viel, wenn pure Leistung wirklich gefragt ist.

Dieser Artikel ist zwar schon älter, aber in den letzten 5 Jahren wird es da keine Quantensprünge in den grundsätzlichen Verhältnismäßigkeiten gegeben haben.
https://www.anandtech.com/show/6971...ng-point-performance-of-modern-arm-processors

Oder mal ganz anders ausgedrückt: Es hat seinen Grund, warum selbst auf einem topaktuellen iPad a) erst jetzt und b) immer noch nur vierfache Polyphonie bei der jüngst veröffentlichten Moog Model D-App drin ist, während selbes (und viel mehr) auf der x86-Architektur in einem halben Dutzend verschiedenster VST-Implementierungen in diversen Qualitätsstufen quer über sämtliche Betriebssysteme schon seit gefühlten Ewigkeiten quasi zum guten Ton gehört.

2015 hat ein ARM Cortex A die gleiche Fliesskommaberechnung bereits viel effizienter durchgeführt als ein Xeon der Haswell oder Ivy Bridge Generation
http://iopscience.iop.org/article/10.1088/1742-6596/681/1/012049/pdf
Wenn die Performance für Otto Normalverbraucher reicht, wird x86 im Consumergedöns wohl verschwinden. Im Supercomputer und in Rechenzentren (außerhalb von Data Storage) wird x86 bestimmt bleiben. Also dort, wo wirklich maximale CPU Performance gefordert wird.

 

[Grenzfrequenz]

Hm, wer da jetzt wohl recht hat?

Für x86 wird OpenGL unterstützt und das bleibt auch so. Für x86 kompiliert er jetzt.

Aber wenn er jetzt in XCode für iOS kompiliert, geht das nicht. Die Portabilität von C++ ist erstmal noch nicht so richtig gut weil man auf verschiedenen Sytemen unterschiedliche Infrastruktur hat und sich das nicht komplett wegabstrahieren lässt. Mit oder ohne OpenGL wird das Programm nicht laufen.

Solange die x86 Architektur verwendet wird, gibt’s die OpenGL Unterstützung der CPU.

Und wenn man auf die Apple System Methoden migriert muss man später nicht so viel ändern, deswegen wird das auf der Entwicklerkonferenz announced.

Sich jetzt über @deprecated bei OpenGL aufzuregen ist wie wenn beim Dieselskandal die Radmutter für Empörung sorgt.

 

[2bit]

2015 hat ein ARM Cortex A die gleiche Fliesskommaberechnung bereits viel effizienter durchgeführt als ein Xeon der Haswell oder Ivy Bridge Generation
http://iopscience.iop.org/article/10.1088/1742-6596/681/1/012049/pdf

Es ging mir hier aber nun mal um die Betonung, dass Effizienz eben NICHT alleine über die Alltagstauglichkeit entscheidet.

Was nützt mir ein einziger Wasserträger, der 1000 Liter in der Stunde den Berg hochtragen soll und nur einen Krug dabei hat, der einen einzigen Liter fasst? Gut, der gerät über diese Aufgabe wohl nicht ins Schwitzen, aber vor Sonnenuntergang ist der dann auch nicht fertig geworden.

Die Alternative ist es, 5 Typen mit je einem 20-Liter-Kanister loszuschicken. Die werden schwitzen und fluchen, aber die sind nach 10 Touren dann auch damit durch.

 

[Grenzfrequenz]

Wir sprechen hier aber explizit von Heimanwender Systemen.

Und Wasserträger haben nicht in 75 Jahren Millionen Milliarden Mal an Leistung zugelegt.

Außerdem geht es ja gerade um konkurrierende Alternativen, zB Wasserträger gegen Wasserrohr. Und wo das Wasserrohr nach langer Entwicklung plötzlich Wasser für die gesamte Stadt liefern kann, dann das erstmal keiner glauben und die Leute sind verärgert, weil irgend ein Hersteller sagt, dass er in ein paar Jahren keine Schulterkissen mehr unterstützt, während er im Hingergrund die Transition zur Pipeline vorbereitet. Oder so ähnlich

 

[c1151]

C++ ist plattformneutral, das ist ja gerade der Witz an der Sprache. Und sicher kann ich das dann auf einem RaspberryPi neu kompilieren, der hat ARM und OpenGL.

@Grenzfrequenz Wie lange entwickelst du schon in C++?

Ich werde aber den Grafiklayer abtrahieren um jederzeit den Backend austauschen zu können, dazu kommt noch ein Software Renderer für Geräte die gar keine Grafikschnittstelle haben. Starten werde ich aber mit OpenGL.

 

[Grenzfrequenz]

Mitnichten ist C++ richtig Plattform neutral. Es ist Plattform neutraler als Assembler aber noch nicht wirklich Plattform neutral. Die Gründe wurden bereits genannt.

So 20 Jahre?

 

[2bit]

Wir sprechen hier aber explizit von Heimanwender Systemen.

Und zu diesen gehört auch diese nicht ganz unbedeutende Sparte:

https://www.gamesindustry.biz/artic...ndustry-biz-presents-the-year-in-numbers-2017

Mit Xbox One und Playstation 4 wurden über 80% der Konsolenneuverkäufe des letzten Jahres mit x86-Technologie bestritten. Auf Platz 3 kommt mit 7,5% erst die Switch mit ARM-Technologie. Die musste sich nämlich gegen Smartphones und Tablets behaupten.

Es zeigt sich, dass Videospiele erstens ein gigantischer Markt sind und zweitens die Konsumenten klare Vorstellungen von der Leistungsfähigkeit haben, die sie sich wünschen. Sony und Microsoft stellen mit ihren Konsolen gänzlich andere Leistungsparameter zur Verfügung, als Nintendo dies tut.

Außerdem geht es ja gerade um konkurrierende Alternativen, zB Wasserträger gegen Wasserrohr.

Völlig falsches Bildnis. ARM-CPUs müssen FP-Operationen entweder über mehrere Zyklen aufteilen (langsamer) oder an einen Coprozessor (höherer Stromverbrauch) delegieren. Das geht sowohl aus deiner, als auch aus meiner Quelle hervor (siehe dazu insbesondere die Tabellen zu "flop/cycle") . Die Antwort auf dieses Problem lautet bei ARM, wie auch schon seit Jahren bei x86: Mehr Kerne & höherer Takt.

Irgendwann ist halt auch bei ARM Schluss, wenn die DAW auf Apples zukünftigem Flaggschiff 120 Cubasespuren (Audioproduktion @ 96 KHz auf ARM? ) gleichzeitig abspielen und dazu auch noch ein paar Plugins stemmen soll. Oder man geht halt woanders hin, wenn Apple brauchbare Technik nur noch für Konsumenten liefert, die mit dem Firmenlogo alleine schon zufrieden sind.

Tatsächlich wird es am Ende wohl auf eine hybride Lösung hinauslaufen, bei der die Vorzüge beider Technologien miteinander verbunden werden. Aber an Wunder glaube ich nicht. Für effektive Leistung muss man halt in Strom bezahlen oder eben länger auf das Ergebnis warten.

 

[Grenzfrequenz]

Ein besserer Vergleich als der Wasserträger sind vielleicht Flugzeuge.

Bei Flugzeugen geht es primär um Geschwindigkeit. Es ist schneller als alternative Reisemöglichkeiten, ab einer gewissen Entfernung.

In früheren Zeiten ging es dann auch lange Zeit darum, die Dinger schneller zu machen.

Aber irgendwann wurde ein Punkt erreicht, da war es für die Masse der Konsumenten schnell genug. Man kam immerhin noch nicht ohne Tank Zwischenlandung nach Australien. Die Masse der Konsumenten wollte dennoch nicht mehr zahlen für mehr Geschwindigkeit. Zu diesem Zeitpunkt war es eh schon schwieriger geworden, schneller zu werden. Ähnlich wie das Moor‘sche Gesetz nicht unbegrenzt weitergeht, kann man einen Airliner nicht mehr ohne große Änderungen schneller machen gegenüber dem letzten Modell, wenn man der Schallmauer näher kommt.

Letztendlich kann ein Flugzeughersteller den neuen Airliner mit besserer Effizienz verkaufen, die Modelle für kürzere Reisezeit haben einen schwierigen Stand.

Für’s Militär wird der Düsenjet trotzdem weiter entwickelt. Und manche Konsumenten haben auch Interesse an einem Concorde Nachfolger.

Der effizientere Turbofan (RISC) hat dem leistungsfähigeren Turbojet (CISC) den Rang abgelaufen im Massenmarkt für konsumierende Bürger.

 

[Grenzfrequenz]

Und zu diesen gehört auch diese nicht ganz unbedeutende Sparte:

https://www.gamesindustry.biz/artic...ndustry-biz-presents-the-year-in-numbers-2017

Mit Xbox One und Playstation 4 wurden über 80% der Konsolenneuverkäufe des letzten Jahres mit x86-Technologie bestritten. Auf Platz 3 kommt mit 7,5% erst die Switch mit ARM-Technologie. Die musste sich nämlich gegen Smartphones und Tablets behaupten.

Es zeigt sich, dass Videospiele erstens ein gigantischer Markt sind und zweitens die Konsumenten klare Vorstellungen von der Leistungsfähigkeit haben, die sie sich wünschen. Sony und Microsoft stellen mit ihren Konsolen gänzlich andere Leistungsparameter zur Verfügung, als Nintendo dies tut.



Völlig falsches Bildnis. ARM-CPUs müssen FP-Operationen entweder über mehrere Zyklen aufteilen (langsamer) oder an einen Coprozessor (höherer Stromverbrauch) delegieren. Das geht sowohl aus deiner, als auch aus meiner Quelle hervor (siehe dazu insbesondere die Tabellen zu "flop/cycle") . Die Antwort auf dieses Problem lautet bei ARM, wie auch schon seit Jahren bei x86: Mehr Kerne & höherer Takt.

Irgendwann ist halt auch bei ARM Schluss, wenn die DAW auf Apples zukünftigem Flaggschiff 120 Cubasespuren (Audioproduktion @ 96 KHz auf ARM? ) gleichzeitig abspielen und dazu auch noch ein paar Plugins stemmen soll. Oder man geht halt woanders hin, wenn Apple brauchbare Technik nur noch für Konsumenten liefert, die mit dem Firmenlogo alleine schon zufrieden sind.

Tatsächlich wird es am Ende wohl auf eine hybride Lösung hinauslaufen, bei der die Vorzüge beider Technologien miteinander verbunden werden. Aber an Wunder glaube ich nicht. Für effektive Leistung muss man halt in Strom bezahlen oder eben länger auf das Ergebnis warten.

Du hast meine Quelle nicht hinreichend zur Kenntnis genommen.

Und ausgerechnet Spiele sollen jetzt plötzlich allerschnellste CPUs benötigen? In der ersten Xbox hat n oller Celeron gereicht, die Xbox One wird bis heute mit ner AMD CPU ausgeliefert von anno dazumal als AMD gegen Intel geschwächelt hat, PC Spiele nutzen oftmals sogar nur einen Core weil man die Leistung gar nicht braucht obwohl man die Spiele multicorefähig machen kann wenn es für die Konsole gebraucht wird...

 

[c1151]

Mitnichten ist C++ richtig Plattform neutral. Es ist Plattform neutraler als Assembler aber noch nicht wirklich Plattform neutral. Die Gründe wurden bereits genannt.

So 20 Jahre?

Jetzt bin ich aber mal gespannt, welche Teile von C++ sind denn bitte nicht plattformneutral?

 

[2bit]

Und ausgerechnet Spiele sollen jetzt plötzlich allerschnellste CPUs benötigen?

Im Segment des Massenmarkts bzw. der Heimanwender gibt es keine einzige andere Anwendung, die annähernd so viel effektive Leistung in Echtzeit benötigt. Warum sonst kaufen sich manche Leute denn wohl z.B. eine Grafikkarte, die alleine schon so viel wie ein iPhone X kostet?

Du hast meine Quelle nicht hinreichend zur Kenntnis genommen.

Und da hast mein Argument, nämlich dass Effizienz nicht der allein wirksame Faktor ist, ebenfalls nicht hinreichend zur Kenntnis genommen. Damit sind wir dann mit dem Thema wohl durch. Damit kann ich aber leben.

ARM ist ein Weg. Aber nicht der einzige. Auch nicht beim Endverbraucher und das hab ich hinreichend gut belegt.

 

[Grenzfrequenz]

Im Segment des Massenmarkts bzw. der Heimanwender gibt es keine einzige andere Anwendung, die annähernd so viel effektive Leistung in Echtzeit benötigt. Warum sonst kaufen sich manche Leute denn wohl z.B. eine Grafikkarte, die alleine schon so viel wie ein iPhone X kostet?

GPUs nutzen gar keine x86 Architektur

Und da hast mein Argument, nämlich dass Effizienz nicht der allein wirksame Faktor ist, ebenfalls nicht hinreichend zur Kenntnis genommen.

Doch

Damit sind wir dann mit dem Thema wohl durch. Damit kann ich aber leben.

Das ist schön

ARM ist ein Weg. Aber nicht der einzige. Auch nicht beim Endverbraucher und das hab ich hinreichend gut belegt.

Huch? Darüber wurde gar nicht diskutiert.

 

[Grenzfrequenz]

Jetzt bin ich aber mal gespannt, welche Teile von C++ sind denn bitte nicht plattformneutral?

Ähhhh... Wie wäre es zB mit OpenGL Unterstützung?

 

[c1151]

Ähhhh... Wie wäre es zB mit OpenGL Unterstützung?

OpenGL gehört nicht zu C++ wie da ja weißt wenn du schon 20 Jahre C++ programmierst. Und OpenGL hat nix mit x86 zu tun, die Schnittstellen kann auch auf einer ARM CPU angesprochen werden wenn ein Grafikkern existiert der OpenGL unterstützt. Aber das weißt du ja sicherlich alles, oder doch nicht?

Ich fühle mich hier ein wenig veräppelt...ehrlich und weiß nicht ob ich mir noch die Zeit nehme darauf einzugehen und bei den Grundlagen anzufangen.

 

[Grenzfrequenz]

OpenGL hat Hardwareunterstützung in x86 und ist abhängig von Systembibliotheken. RISC Architekturen wie ARM verfügen üblicherweise nicht über OpenGL Hardware Unterstützung und die Apple Systembibliotheken für ARM Prozessoren ebenfalls nicht.

In den Grundlagen hast Du erhebliche Defizite, Deine Überheblichkeit ist völlig unangebracht.

 

[c1151]

ARM verfügen üblicherweise nicht über OpenGL Hardware Unterstützung
In den Grundlagen hast Du erhebliche Defizite, Deine Überheblichkeit ist völlig unangebracht.

Dir ist schon klar das Android meist ARM CPUs mit OpenGL ES Grafikernanbindung auf einem SoC sind oder? OpenGL hat rein gar nichts mit x86 zu tun. Das wurde mal auf SGI Maschinen entwickelt, da waren gar keine x86 CPUs drin. Quelle: https://de.wikipedia.org/wiki/Silicon_Graphics

Wenn ich eine rudimentäre OpenGL GUI fertig habe, dann werde ich dir Screenshots von einer Windows-, eine Linux Version auf x86 und einer Linux Version auf ARM Basis(RaspPI) schicken. Vielleicht glaubst du es ja dann.

 

[Grenzfrequenz]

Dir ist schon klar das Android meist ARM CPUs mit OpenGL ES Grafikernanbindung auf einem SoC sind oder?

Ja klar. Aber ist dir nicht klar, dass dafür Systembibliotheken verwendet werden?

OpenGL hat rein gar nichts mit x86 zu tun.

Informier Dich doch endlich mal. x86 bietet Hardwareunterstützung für OpenGL, was wiederum dazu führt, dass Systembibliotheken von Systememn die auf x86 laufen es verstärkt implementieren.

Das wurde mal auf SGI Maschinen entwickelt, da waren gar keine x86 CPUs drin. Quelle: https://de.wikipedia.org/wiki/Silicon_Graphics

https://de.wikipedia.org/wiki/Silicon_Graphics
Was hat das mit unserem Thema zu tun, dass Apple OpenGL Unterstützung in seinen Systembibliotheken abgekündigt hat?

Wenn ich eine rudimentäre OpenGL GUI fertig habe, dann werde ich dir Screenshots von einer Windows-, eine Linux Version auf x86 und einer Linux Version auf ARM Basis(RaspPI) schicken. Vielleicht glaubst du es ja dann.

OpenGL gibts ja sogar für die alte Acorn ARM Architektur. Ich habe den Eindruck, Du weißt selbst nicht so recht, worüber Du gerade diskutierst?

 

[Jörg]

Interessantes Thema. Wär etwas leichter zu lesen ohne gegenseitige Kompetenz-Mutmaßungen.

 

[c1151]

Danke, endlich mal einer mit Kompetenz

@Grenzfrequenz Das ist ja der Punkt. OpenGL gibt es für so ziemlich alle Plattformen genau wie einen C++ Compiler, somit kann ich den gleichen Code auf allen Plattformen wieder verwenden, wo ich OpenGL Unterstützung und einen C++ Compiler für habe. Das ist für mich plattformunabhängig, da ich nicht auf eine Plattform festgenagelt bin. Da hast ja selbst der Sprache C++, die nichts mit OpenGL zu tun hat, abgesprochen dass sie plattformunabhängig ist.
Vielleicht reden wir hier auch aneinander vorbei. Ich weiß das mein Code unter Windows, Linux x86 und ARM laufen wird und das ist entscheidend für mich. Das ist plattformunabhängig genug. Wenn Apple weiterhin OpenGL mit auf ARM nehmen würde, dann könnte ich die Plattform auch out of the box unterstützen, darum geht ja der ganze Thread hier.

 

[Grenzfrequenz]

alles falsch... die x86-Architektur hat keine Opengl-Unterstützung. Opengl ist eine programmierSchnittstelle, die unter arm genauso implementiert werden kann wie auf x86-Systemen.

Es zu wiederholen macht es nicht wahr.

Schau doch einfach mal auf die Spezifikation von so ner modernen Intel x86 CPU:
https://ark.intel.com/de/products/126684/Intel-Core-i7-8700K-Processor-12M-Cache-up-to-4_70-GHz

Dort siehst Du dann, dass die CPU selbst OpenGL 4.5 unterstützt.

 

[2bit]

Dort siehst Du dann, dass die CPU selbst OpenGL 4.5 unterstützt.

Das bezieht sich auf die iGPU. Dieser Prozessor hat nämlich ne GPU eingebaut.

 

[Grenzfrequenz]

Danke, endlich mal einer mit Kompetenz

@Grenzfrequenz Das ist ja der Punkt. OpenGL gibt es für so ziemlich alle Plattformen genau wie einen C++ Compiler, somit kann ich den gleichen Code auf allen Plattformen wieder verwenden, wo ich OpenGL Unterstützung und einen C++ Compiler für habe. Das ist für mich plattformunabhängig, da ich nicht auf eine Plattform festgenagelt bin. Da hast ja selbst der Sprache C++, die nichts mit OpenGL zu tun hat, abgesprochen dass sie plattformunabhängig ist.
Vielleicht reden wir hier auch aneinander vorbei. Ich weiß das mein Code unter Windows, Linux x86 und ARM laufen wird und das ist entscheidend für mich. Das ist plattformunabhängig genug. Wenn Apple weiterhin OpenGL mit auf ARM nehmen würde, dann könnte ich die Plattform auch out of the box unterstützen, darum geht ja der ganze Thread hier.

Das heißt, wenn Du die OpenGL Aufrufe raus nimmst, dann kannst Du in Xcode einfach fürs iPhone kompilieren. Folglich nutzt Du auch keinen der CISC Befehle und außer OpenGL kein Framework, um Deinen SoftSynth in ein bestehendes Ökosystem (wie zB CoreAudio oder VST) zu integrieren. Das ist dann aber ein absoluter Ausnahmefall für einen SoftSynth.

BTW wenn C++ so plattformunabhänig wäre, dann wäre sowas wie Java niemals entwickelt worden.

 

[Grenzfrequenz]

Das bezieht sich auf die iGPU. Dieser Prozessor hat nämlich ne GPU eingebaut.

Das hast Du es doch. C++ hin oder her, es garantiert mitnichten eine Plattformunabhängigkeit. Und der Hersteller über den wir hier sprechen plant halt demnächst nicht mehr damit, dass in all seiner Hardware OpenGL untestützt wird und dort wo es komplett in Softwre umgesetzt werden müsste bevorzugt man einen anderen Weg

 

[c1151]

Das heißt, wenn Du die OpenGL Aufrufe raus nimmst, dann kannst Du in Xcode einfach fürs iPhone kompilieren. Folglich nutzt Du auch keinen der CISC Befehle und außer OpenGL kein Framework, um Deinen SoftSynth in ein bestehendes Ökosystem (wie zB CoreAudio oder VST) zu integrieren. Das ist dann aber ein absoluter Ausnahmefall für einen SoftSynth.

BTW wenn C++ so plattformunabhänig wäre, dann wäre sowas wie Java niemals entwickelt worden.

Ok ich versuche mal zu antworten. Mein Code für den Softsynth selbst ist reines C++, ohne irgendwelche Assemblerspezifschen Sachen. Der Code kompiliert also wirklich überhall wo es einen C++-Compiler für gibt(x86, ARM, 68000, PowerPC, whatever). Dann habe ich eine Audio-Libs die sowohl CoreAudio, WASAPI, ASIO, Jack etc unterstützt. Diese kann ich einsetzen wo entsprechende Audioschnittstellen exisitieren. Meine Grafik, Fenster, Input Verwaltung wird über die GLFW-Lib genutzt, diese kann ich unter macOS, Linux, FreeBSD und Windows ohne Anpassungen nutzen. Mehr Abhängigkeiten habe ich derzeit nicht.
Nun zum Begriff der Plattformunabhängigkeit. Diese ist bei mir dann gegeben, wenn ich mein Programm auf mehr als einer Plattform kompilieren kann. Auf allen verfügbaren Plattformen kann ich nur meinen Softsynth selbst kompilieren, da Grafik und Soundausgabe auf die drei Hauptplattformen grob festgelegt sind. Die Anbindung an das Audio system ist aber extrem schwach. Wenn sich da was ändert ist das keine große Arbeit das anzupassen. Ich wollte bei OpenGL eigentlich keine zusätzliche Schicht einbauen, da es bis heute immer DIE Grafikschnittstellen für alle großen Plattformen war. Ist nun Pustekuchen dank Apple, also werde ich doch eine Schicht einbauen müssen.

Nochmal zum Schluss. Der reine Softsynth ist reines C++ und muss null geändert werden, egal mit welchem C++Compiler und auf welcher CPU ich das immer auch kompiliere.

Ich hoffe, ich habe das genug aufgedröselt.


C ist übrigens der erste plattformunabhängige Assembler gewesen und wurde genau deswegen erfunden. Java ist da plattformunabhängi wo es die JRE für gibt. Java wurde auch erfunden um die Speicherverwaltung einfacher zu gestalten, mit den üblichen Vor- und Nachteilen. C und C++ war schon immer plattformunabhängig.

 

[Grenzfrequenz]

Wie gesagt geht es ja nicht nur um die OpenGL Unterstützung. Wenn man von CISC auf RISC geht, dann fallen ja auch die ganzen erweiterten Befehlssätze weg - und die komplexen Instruktionen sind ja gerade der Witz an CISC.

Die Systembibliotheken können sich aber bei nativer Software in dieser Hinsicht bei weitem nicht um alles kümmern. Um die komplexen Befehlssätze auszureizen, muss die Anwendungssoftware sie selbst auch verwenden.

Wenn jetzt von einer CISC Architektur auf eine andere gewechselt wird (zB PowerPC auf x86), kann man sich - unter signifikantem Aufwand - noch gut mit Emulationen behelfen. Beim Wechsel nach RISC wird man das aber nicht alles implementieren wollen, weil es 1. viel mehr ist und 2. den Vorteilen der Architektur zuwieder ist.

 

[c1151]

Das hängt immer davon ab wie gut der C++Compiler optimiert.

 

[2bit]

Das hast Du es doch. C++ hin oder her, es garantiert mitnichten eine Plattformunabhängigkeit.

Nein. Die von dir verlinkte CPU selbst unterstützt keine einzige OpenGL-Extension, die in einer höheren Programmiersprache formuliert ist. Das tut nur der GPU-Teil, der logisch unabhängig von der CPU ist, und sogar abgeschaltet und durch eine GPU via PCIe ersetzt werden kann. Das ist aber auch genau das, was ckoehler früher bereits sagte:

Und OpenGL hat nix mit x86 zu tun, die Schnittstellen kann auch auf einer ARM CPU angesprochen werden wenn ein Grafikkern existiert der OpenGL unterstützt.

 

[Grenzfrequenz]

Ok ich versuche mal zu antworten. Mein Code für den Softsynth selbst ist reines C++, ohne irgendwelche Assemblerspezifschen Sachen. Der Code kompiliert also wirklich überhall wo es einen C++-Compiler für gibt(x86, ARM, 68000, PowerPC, whatever). Dann habe ich eine Audio-Libs die sowohl CoreAudio, WASAPI, ASIO, Jack etc unterstützt. Diese kann ich einsetzen wo entsprechende Audioschnittstellen exisitieren. Meine Grafik, Fenster, Input Verwaltung wird über die GLFW-Lib genutzt, diese kann ich unter macOS, Linux, FreeBSD und Windows ohne Anpassungen nutzen. Mehr Abhängigkeiten habe ich derzeit nicht.
Nun zum Begriff der Plattformunabhängigkeit. Diese ist bei mir dann gegeben, wenn ich mein Programm auf mehr als einer Plattform kompilieren kann.

Das ist dann aber nur eine eingeschränkte Plattformunabhängigkeit und in diesem Thread geht es ja um eine Kompatibilität zu einer bestimmten Plattform. Ich weiß nicht, ob Du einfach iOS als Zeilplattform verwenden kannst, wenn Du den OpenGL Kram testweise raus löschsts? Ich tue mich jedenfalls weiterhin schwer, es zu glauben. Hast Du es mal ausprobiert? Nur darum geht es ja schließlich in diesem Thread: Wenn eines Tages iOS die Basis ist, kannst Du angeblich Deinen Code nicht mehr für die neue Zielplattform kompilieren, nur weil OpenGL nicht mehr unterstützt wird.

Auf allen verfügbaren Plattformen kann ich nur meinen Softsynth selbst kompilieren, da Grafik und Soundausgabe auf die drei Hauptplattformen grob festgelegt sind. Die Anbindung an das Audio system ist aber extrem schwach. Wenn sich da was ändert ist das keine große Arbeit das anzupassen. Ich wollte bei OpenGL eigentlich keine zusätzliche Schicht einbauen, da es bis heute immer DIE Grafikschnittstellen für alle großen Plattformen war. Ist nun Pustekuchen dank Apple, also werde ich doch eine Schicht einbauen müssen.

Wo wir wieder beim eigentlichen Punkt wären: Bislang hast Du keine iOS Zielplattform im Programm. Das ist klar, weil ja alle Deine Zielplattformen OpenGL unterstüzten. Wenn nun das klassische macOS weg fällt bzw etwas auf iOS Basis an dessen Stelle rückt, dann ist der große Aufreger, dass es dann kein OpenGL mehr gibt? Das würde mich zumindest wundern, wenn das jetzt der große Aufreger an dieser Umstellung wäre.

Nochmal zum Schluss. Der reine Softsynth ist reines C++ und muss null geändert werden, egal mit welchem C++Compiler und auf welcher CPU ich das immer auch kompiliere.

Ich hoffe, ich habe das genug aufgedröselt.

Ja, das ist dann der einfachste Fall und die Interfaces können dann immer nur generisch sein sowie speziellen Nektar zur Codeoptimierung kann man dann kaum nutzen. Ist aber bei einfachen Programmen durchaus üblich.

C ist übrigens der erste plattformunabhängige Assembler gewesen und wurde genau deswegen erfunden. Java ist da plattformunabhängi wo es die JRE für gibt. Java wurde auch erfunden um die Speicherverwaltung einfacher zu gestalten, mit den üblichen Vor- und Nachteilen. C und C++ war schon immer plattformunabhängig.

Da fehlt das Wörtchen "eingeschränkt", "bedingt", whatever

 

[Grenzfrequenz]

Nein. Die von dir verlinkte CPU selbst unterstützt keine einzige OpenGL-Extension, die in einer höheren Programmiersprache formuliert ist. Das tut nur der GPU-Teil, der logisch unabhängig von der CPU ist, und sogar abgeschaltet und durch eine GPU via PCIe ersetzt werden kann. Das ist aber auch genau das, was ckoehler früher bereits sagte:

Willste es jetzt nicht verstehen oder wie? Die GPU ist sehr wohl im Package der CPU. Und dort wo es das nicht gibt wird es derzeit von der GPU unterstützt. Die GPU ist Hardware.

Wenn Apple nun seine Betriebssysteme vereinheitlichen will, wo kommt dann die Hardware Unterstützung für OpenGL her? Ins iPhone werden so schnell keine GPUs mit entsprechenden Fähigkeiten rein kommen.