007
11.08.2019, 02:39 Uhr
Hans
Library Walker
(Operator)
|
| Zitat von ao: |
Wer bisher gedacht hat, das Win32-API von Microsoft wäre kryptisch, der möge sich mal das hier zu Gemüte führen https://www.menuetos.de/dokumente/Systemfunktionen und sich vorstellen, er müsste in diesem Stil ein verkaufbares (d.h. auch im nächsten Jahr noch pflegbares) Programm schreiben.
|
Wow! - Das ist x86 32-Bit Code, - also nur auf x86 CPUs lauffähig. Portabilität? - Fehlanzeige!
Anekdote:
Das erinnerte mich an eine Story aus dem Buch "C-Tools", das es in den 80er Jahren mal gab. Darin beschreibt einer, wie er sich hingesetzt hat, um das grösste Projekt der Welt in Angriff zu nehmen. Er schrieb einige Zeilen Assemblercode hin, und begann nachzudenken. Die Überlegungen führten dazu, das Programm schliesslich doch in C zu entwickeln, einfach, weil es einfacher war. Es handelte sich dabei um einen einfachen C-Compiler, den er sinnigerweise dann auch Small-C genannt hat. Standardisiert war da nicht viel, weil es zu der Zeit nur das Buch von K&R gab, aber noch keinen offiziellen Standard vom ANSI. - Der kam erst einige Jahre später.
Anekdote Ende.
Ein Grund also, warum man in einer Hochsprache schreibt, und nicht in Assembler ist der, dass es einfacher ist. Sofern es für die Sprache einen Standard gibt, reicht es aus, etwas einmal zu schreiben. Die Details einer Prozessorarchitektur kann man dem Compiler zu überlassen. Und selbst den Compiler kann (und wird) man zum grössten Teil in einer Hochsprache schreiben. Was man u.U. noch in Assembler schreibt, sind ganz fundamentale Dinge, wie mathematische Operatoren für die Grundrechenarten. Oder wenn man irgendwo an bestimmten Stellen, wo es extrem auf Geschwindigkeit ankommt, auch die letzten Optimierungen einbauen will, die möglich sind. Diese Stellen werden aber vorher mit speziellen Programmen (Profiler) entdeckt, und erst wenn sämtliche Optimierungsoptionen des Compilers ausgereizt sind, man es aber dennoch schneller braucht, kann man hingehen und den Code analysieren, den der Compiler erzeugt hat, um zu sehen, ob da von Hand noch was an Overhead gestrichen werden kann. - An dieser Stelle stellt sich aber auch die Frage, ob man den richtigen Algorithmus gewählt hat, und falls ja, ob man ihn auch optiomal umgesetzt hat? - Wenn eine dieser beiden Fragen mit Nein zu beantworten ist, macht auch die beste Handoptimierung das Programm an dieser Stelle nicht mehr schneller als es im Idealfall sein könnte. Als Beispiel sei das Sortieren von Daten genannt. Dafür gibt es verschiedene Algorithmen, wovon der Schnellste der Quicksort ist. Wenn man einen anderen Algorithmus als den Quicksort wählt, ist das Programm langsamer. Der Grund liegt in der Natur der Algorithmen.
--
Man muss nicht alles wissen, aber man sollte wissen, wo es steht. Zum Beispiel hier: Nachdenkseiten oder Infoportal Globalisierung. |
