Objektorintiert vs Harvard

Nochmals besten Dank an die ausführlichen Antworten. Obiges kann ich nachfühlen. Der Rechenzeitbedarf kommt ja meistens plötzlich und unerwartet :-]. Steigt er von 1 us auf 1ms, merkt man nichts, von 1ms auf 1s merkt man es eventuell als winzige Verzögerung, von 1s auf 1000s meint man, der Rechner sei kaputt oder in einer Endlosschleife....

Allerdings. Die theoretischen Chemiker nehmen als Daumenregel native C dreimal langsamer als Fortran, f2c-Gewurstel eher

10 mal langsamer. Die Vorgehensweise, Semesterstudent wurstelt Fortranprogramm auf C um, nur damit man einen Gratiscompiler brauchen kann, hat auch schon viele Opfer gefordert. Spice- Implementierungen sollen auch drunter sein. "Complex" ist so eine Falle. Ist unter Fortran übrigens nicht notwendigerweise schneller als ausgeschriebener Code, kommt etwas darauf an, ob Multiplikationen oder Additionen häufiger sind. Katastrophal wird es erst, wenn beim Umschreiben in C der Datentyp und die Operationen definiert werden, wieder so ein Eleganz geht vor Effizienz-Vorgehen. Der Mie-Code von Warren Wiscombe war ein sehr effizentes Fortran-Programm, wurde dann auf C umgedichtet, war dann dermassen lahm, dass ich von Fortran mal aus Jux auf VB umgeschrieben habe. Läuft wesentlich schneller ;-)), obwohl ich annehme, dass VB auch nur irgend ein C Präprozessor ist.

Ich meinte eben, nebst der Dimension des Zeitbedarfs gibt es eben auch noch Vorfaktoren ;-). Kein Grund, diese zu verschenken.

Hatte mich zu knapp ausgedrückt. Ich habe Implementierungen von Quicksort gesehen, die waren bei nicht-astronomischen Punktemengen langsamer als Heapsort oder gar Shellsort, aber hauptsache sie waren mit allen Struktur-Gadgeds gewürzt, das was der möchtegern-Theoretiker als "elegant" bezeichnet. Also möglichst viele rekursive Aufrufe, ja keine explizite eigene Stackverwaltung usw.

Und ich finde es schade, wenn man vor lauter abgehobener Theoretisiererei einen Faktor 3 oder so in der Effizienz verschenkt, indem man lediglich für den Wald viel überlegt und die Bäume egal sein lässt.

Ja, meistens. Erinnere gern an den $100M AT&T Netzcrash. Argument zählt allerdings nur, falls der Compiler wirklich gut optimieren kann. Da aber alles heute möglichst gratis sein muss, kommen mir da Zweifel.

Das ist klar; auch ist die Grenze zu scheusslichem Code sehr schnell überschritten. Ich dachte eher ans Opfern der Effizienz zugunsten einer nicht näher definierten "Eleganz", je nach Modeerscheinung.

Sehr guter Einwand, hatte ich ausser Acht gelassen, da in der Zeit, als ich so was angeschaut hatte, es Cache noch nicht gab. Oder, wie Convex immer betonte, aller Speicher ist bei uns Cache. Waren interessante Zeiten, da man nur die Wahl hatte zwischen Code optimieren oder Warten auf St. Nimmerlein.