gregor hat geschrieben:Ist es nicht das Geschick des Programmierers, die Hardware so zu nutzen, dass ...
Hallo Gregor,
nein, so wird i.a. nicht programmiert. D.h. der Programmierer sieht die Hardware üblicherweise gar nicht mehr. Der Programmierer sieht seine Aufgabe, die Entwicklungsumgebung und die verwendeten Funktionen. Wie dann was im Betriebssystem abläuft, entzieht sich zum Großteil der Kenntnis des Programmierers.
Beispiel:
Ausgabe Sound an Soundkarte per Windows-Treiber. Man weiss, was man ausgeben will. Dann nutzt man die Funktionen der Windows-API (application programming interface). Windows stellt hierzu Funktionen wie MMSystems, Direct Sound, WASAPI (Windos audio sound application programming interface) oder kernel streaming zu Verfügung. Damit ist man schon weit oben in der Hierarchie, vor allem ganz weit weg davon, welche Caches die CPU nutzt. Es hilft hier auch nicht, parallel zum Betriebssystem mit Assembler zu programmieren. Es ist ja gerade Aufgabe eines guten Betriebssystems, das eigene System sauber zu halten und abzukapseln.
Beispiel2:
Ausgabe Sound an Sundkarte per Asio-Treiber. Auch hier liegt die Schnittstelle fest. Man bekommt von der Soundkarte ein Event bzw. Ereignis. Innerhalb dieses Ereignisses muss man die Puffer lesen bzw. beschreiben, die der Soundkartentreiber zur Verfügung stellt. Alles definiert seitens der API. Wie die Daten aus einem Puffer an die Hardware gelangen, obliegt dem Treiber der Soundkarte. Für den jeder Hersteller selbst verantwortlich ist.
An dieser Stelle programmiert man schon weit unten, ist aber trotzdem weit weg von einer optimierten Programmierung der Hardware. Welche Qualität der Treiber hat, ist ebenfalls nicht bekannt.
Und schon gar nicht bekannt ist, wie, an welcher Stelle und mit welchen Kriterien das Betriebssystem mit höherwertigen Prozessen dazwischenfunkt. Man hat als Programmierer allenfalls eine Chance, durch eine saubere Aufteilung von Threads und durch Zuteilung von Prioritäten dafür zu sorgen, dass das Programm im Wettbewerb mit anderen Prozessen etwas mehr Chancen hat.
Man könnte vieleicht noch andere Prozesse abwürgen, siehe JPlay.
Jetzt waren wir grad mal bei der Ausgabe von bekannten Daten. Wie diese nun von einem bekannten Speicherort zur Ausgabe gelangen, ist wiederum kaum durch den Programmierer beeinflussbar. Man nutzt APIs für eine TCP/IP-Kommunikation oder für eine uPnP-Schnittstelle, aber man schraubt nicht wirklich selbst am TCP/IP-Protokoll herum.
Und das ist bei allen Betriebssystemen so, ob Windows, MacOS oder Linux. Und das sind nun einml vor allem keine Echtzeitbetriebssysteme.
Tja, und wie optimiert man nun? Die Vielfalt der APIs ist fast unüberschaubar. Und es gibt ja auch eine Weiterentwicklung dabei. Alte APIs werden erweitert oder durch neue ersetzt. Es obliegt dem Geschick des Programmierers, aus dem Baukasten etwas Effizientes auszuwählen und zusammenzustecken.
Es sollte aber klar geworden sein, dass man weit weit weg ist von einer Cache-Optimierung. Oder von einer optimierten Hardware-Nutzung.
Grüsse
Uli
