Hallo Hans-Peter,
Du schriebst am Fri, 3 Mar 2017 04:04:34 +0100:
[Breite des Datenbus vs. Zugriffsgeschwindigkeit]
Post by Hans-Peter DiettrichPost by Sieghard SchicktanzUnd Du bist Dir auch ganz sicher, daß das die Ursache ist und nicht
...
Post by Hans-Peter DiettrichDamals stieg die Busbreite schneller als die Taktraten, da war die
Hmm. Also ich weiß nur von _2_, dann allerdings sprunghaften, Anstiegen der
Busbreite "damals", von 8 auf 16 und später von 16 auf 32 Bit. Anstiege der
Taktrate gab es aber relativ kontinuierlich laufend, und zusätzlich jeweils
bei der Einführung einer neuen Busbreite einen gehörigen "Zuschuß".
Post by Hans-Peter DiettrichUrsache schon mit einer Stopuhr zu ermitteln. Kerne, Register-Renaming
Habe ich anders in Erinnerung, da gab es eher öfters Klagen, daß die
Programme mit der größeren Bus- und damit i.a. auch Datenbreite _langsamer_
(und natürlich viel größer) waren als früher bzw. als dem Taktzuwachs
entsprechen müßte.
Post by Hans-Peter Diettrichund anderes Gedöns kamen erst später, da optimierte dann ein Compiler
meist besser als ein Assembler-Programmierer.
"Damals"? Daß ein _Compiler_ besser optimieren sollte als ein Programmierer
ist eine Behauptung der Hersteller, die noch garnicht so alt ist - sie kam
so in etwa mit den späten RISC-Prozessoren auf, deren Befehlsabarbeitung
teilweise enorm verzwickt lief und völlig uneinsichtige Befehlsfolgen
verlangte (z.B. wurde der Befehl _hinter_ einem Sprung noch ausgeführt,
bevor es am Ziel weiterging). Einigermaßen akzeptabel ist dieser Anspruch
wohl bei den neuen hochkomplexen Prozessoren, die eigentlich Interpretatoren
für eine externe Pseudo-"Maschinensprache" sind, die beim Laden mittels
mikroprogrammierter Programmfunktionen verarbeitet werden. Da blickt dann
kaum noch wer durch, was bei einer Befehlssequenz intern eigentlich abgeht.
Neben bisserl PC-Programmierung (meistens Pascal, leider "Delphi no more",
ist für Kleinkram unbezahlbar geworden und läuft immer noch ausschließlich
auf Windows, während ich das eher für Linux brauche) ist mein Hauptgebiet
eher die Mikrocontroller-Programmierung. Da sind dann die (C-) Compiler
i.a. dermaßen katastrophal beim Optimieren, daß es einem die Haare
aufstellt, und durch die Implementation der Hochsprache müssen da
Konstrukte verwendet werden, die auch eine maximal mögliche Optimierung
gegenüber einer direkten Programmierung in Assembler miserabel aussehen
lassen. Leider verhindern die Hersteller zunehmend die Assembler-
Programmierung, indem sie ihre Bibliotheken nur noch für ihre (C-) Compiler
zur Verfügung stellen und diese dann so auslegen, daß eine Einbindung in
Assembler-Programme praktisch unmöglich wird.
(Läuft derzeit bei Microchip so. Der Assembler, auf dem ich mein Multi-
Threading-System aufgebaut habe, ist mit seinem Objekt-Format inkompatibel
zu den neuen C-Compilern, und diese bieten praktisch keine nutzbare
Assembler-Programmiermöglichkeit mehr.)
Post by Hans-Peter DiettrichPost by Sieghard SchicktanzVielleicht, um solche Fehleinschätzungen zu vermeiden, wie Du sie oben
präsentierst?
Ach, noch ein Fachmann, der's besser weiß? ;-)
Nee, besserwissen tust doch alles Du.
Post by Hans-Peter DiettrichPost by Sieghard SchicktanzVielleicht kommt derjenige auch mal dazu, sich professionell mit diesen
Dingen zu befassen und kann durch sein Verständnis Verbesserungen
einbringen?
Ich warte immer noch auf solche Fachleute und ihre Beiträge :-]
Du wirst sie nie finden, wenn Du sie nicht erkennst...
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------