Thema: L4-ähnlicher Kernel

[erik.vikinger]

Hallo,

Wie oben erwähnt, man kann dem Compiler Prolfing-Informationen übergeben, damit kann er den/die häufigsten Pfade optimieren. Das ist sogar noch viel effektiver, da es reale Informationen sind und nicht irgendwas vom Programmierer erdachtes.

Das kommt noch dazu. Es ging mir nur in erster Linie darum das es kein fairer Vergleich ist wenn der Assembler-Programmierer vorhandene Informationen nutzt und der C-Programmierer nicht. Das der Compiler das eigentlich sogar noch besser kann als der Mensch ist nur noch ein weiteres Argument gegen die Behauptung das der Compiler dumm sei.


Grüße
Erik

[Svenska]

FlashBurn meint folgenden Code:

Code: [Auswählen]

float SquareRootFloat(float number) {
    long i;
    float x, y;
    const float f = 1.5F;

    x = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;
    i  = 0x5f3759df - ( i >> 1 );
    y  = * ( float * ) &i;
    y  = y * ( f - ( x * y * y ) );
    y  = y * ( f - ( x * y * y ) );
    return number * y;
}

Man beachte dies hier zur Erklärung: http://www.codemaestro.com/reviews/9.

Dazu drei Hinweise:
(a) Handelt es sich hier um C. Ob du dies nun in Assembler oder in C programmierst, ist unerheblich, da die Idee an sich auf Genialität basiert. Im Gegenteil, in Assembler wäre das noch unverständlicher.
(b) Dieser Algorithmus berechnet die Quadratwurzel eines Float mit der Integereinheit der CPU (und stammt u.a. aus der Quake III-Engine). Grundgedanke ist das Näherungsverfahren von Newton, bei dem man iterativ aus einem gegebenen Schätzwert einen besseren Schätzwert erzeugt. Der Trick hierbei ist der gegebene Schätzwert, der die Anzahl der Iterationen hierbei auf eins reduziert.
(c) Laut Aussage auf der verlinkten Webseite ist dieses Codefragment - je nach CPU - bis zu viermal schneller als "1.0/sqrt(x)", welches üblicherweise mit der Gleitkommaeinheit berechnet wird. Zur Zeit von Quake III waren noch CPUs von Cyrix weitverbreitet, die eine sehr schnelle Integer- aber eine sehr langsame Gleitkommaeinheit hatten. Daher war das wichtig.

Gruß,
Svenska

[FlashBurn]

Gut auf was ich hinaus will ist, dass wenn man sagt, ein Mensch kann nie optimalen Code schreiben, aber der Compiler kann es, wie willst du dann als Mensch wissen das der Code vom Compiler optimal ist? Entweder du weißt es und damit hättest du ihn genauso schreiben können oder du weißt es nicht und kannst es dann auch nicht behaupten.

Desweiteren geht ihr hier alle vom GCC aus, was ist mit anderen Compilern die es gibt und anderen Sprachen? Wenn der GCC den optimalen Code erzeugt wieso ist dann der Intel Compiler meistens noch ein bißchen schneller?

Ich kenne genügend Programmierer die in der Lage wäre wirklich sehr schnellen Code in Assembler zu schreiben, aber da sie sich ja sagen der Compiler produziert ja optimalen Code machen sie sich über ihren Code weniger Gedanken und überlassen die ganze Arbeit dem Compiler. Aber woher will man wissen das dieser auch seine Arbeit so verrichtet wie man sich das denkt?

Was die Vorgaben an den Compiler betrifft, da ist halt das Problem das nicht jeder Compiler das unterstützt (??) und du damit auch vom Sprachstandard abweichst.

@Svenska

Jap, das war der Code.

Der Punkt ist doch halt der, wer heute programmieren lernt, bekommt von allen Seiten eingetrichtert der Compiler erzeugt grundsätzlich optimalen Code und du könntest es eh nicht besser. Wozu sich dann noch Gedanken machen ob man mit irgendwelchen Tricks (wie den von Svenska) nicht eine eigentlich "einfache" Sache noch schneller hinbekommt (da wo es auch nötig wäre, z.B. 3D oder irgendwas mit Video)?

Was aber an einer Hochsprache und damit auch an einem Compiler wesentlich besser ist als bei Assembler ist, dass man seinen Code Jahre später für eine neuere CPU übersetzen kann und der Compiler dann (hoffentlich) schnelleren Code erzeugt.

[bluecode]

*sigh* nochmal: nicht optimal, sondern optimaler als es den meisten Menschen in sinnvollen Zeitschranken und unter minimaler Beachtung normaler Softwareentwicklungskriterien (Wartbarkeit, iterative Entwicklung) je möglich wäre.
edit: Optimale Codegenerierung dürfte sehr wahrscheinlich sowieso nicht (algorithmisch) machbar sein, ich denke das geht der armen Turingmaschine dann doch zu weit.

Wozu sich dann noch Gedanken machen ob man mit irgendwelchen Tricks (wie den von Svenska) nicht eine eigentlich "einfache" Sache noch schneller hinbekommt (da wo es auch nötig wäre, z.B. 3D oder irgendwas mit Video)?

Exakt darüber - die Algorithmik und die Datenstrukturen - versuchen wir uns Gedanken zu machen und da verwenden auch C Programmierer wenn es nötig ist (d.h. es wurde vorher gemessen, dass die Performance nicht toll ist) Assembler. Das ist ein Job der komplementär zu dem des Compilers ist und ich würde niemals deswegen den Compiler wegwerfen wollen und alles selbst machen. Es wurde glaube ich auch schon gesagt, aber einen etwas schwierigeren Algorithmus bzw. eine etwas schwierigere Datenstruktur würde ich nicht in Assembler implementieren wollen, die sind schon so schwer genug zu verstehen.
Die wichtigste Frage ist aber: Wo lohnt es sich was selbst zu optimieren und wo nicht? Bei Matrixoperationen und einem 3D-Spiel lohnt es sich sicherlich das über SSE zu machen und das kann der Compiler nur bedingt automatisch machen.

[erik.vikinger]

Hallo,

Gut auf was ich hinaus will ist, dass wenn man sagt, ein Mensch kann nie optimalen Code schreiben, aber der Compiler kann es, wie willst du dann als Mensch wissen das der Code vom Compiler optimal ist? Entweder du weißt es und damit hättest du ihn genauso schreiben können oder du weißt es nicht und kannst es dann auch nicht behaupten.

Die Ausführungsgeschwindigkeit eines Programms kann man messen und dazu muss man noch nicht einmal wissen was Assembler überhaupt ist. Damit kann man zwar nicht feststellen ob der Code wirklich optimal ist (also das absolute Maximum an Performance erreicht) aber man kann damit recht gut bestimmen welche Umsetzung besser ist und nur darum geht es doch hier.

Desweiteren geht ihr hier alle vom GCC aus, was ist mit anderen Compilern die es gibt und anderen Sprachen? Wenn der GCC den optimalen Code erzeugt wieso ist dann der Intel Compiler meistens noch ein bißchen schneller?

Klar ist der Intel-Compiler oft noch einen Tick besser als der GCC aber was sagt das über den Vergleich von "Compiler vs. Mensch" aus? Der Mensch ist bei größeren Programmen weder dem GCC noch dem Intel-Compiler gewachsen. So what?

Ich kenne genügend Programmierer die in der Lage wäre wirklich sehr schnellen Code in Assembler zu schreiben, aber da sie sich ja sagen der Compiler produziert ja optimalen Code machen sie sich über ihren Code weniger Gedanken und überlassen die ganze Arbeit dem Compiler.

Genau für diese Drecksarbeit gibt es ja den Compiler, also warum soll ich dem das dann nicht auch überlassen?

Aber woher will man wissen das dieser auch seine Arbeit so verrichtet wie man sich das denkt?

Erfahrung und Vertrauen in die Fähigkeiten der menschlichen Compiler-Programmierer die ihr Werk sicherlich auch mal mit möglichst vielen verschiedenen Beispiel-Codes testen.

Was die Vorgaben an den Compiler betrifft, da ist halt das Problem das nicht jeder Compiler das unterstützt (??) und du damit auch vom Sprachstandard abweichst.

Und was sagt das über den Vergleich von "Compiler vs. Mensch" aus? Nichts! Du kannst nicht einfach sagen da es ja auch schlechte Compiler gibt ist der Mensch der bessere Code-Generator. Du versuchst die ganze Zeit Äpfel mit Birnen zu vergleichen! Wenn Du von einem guten und erfahrenen Assembler-Programmierer aus gehst dann musst Du für die andere Seite auch einen guten und aktuellen Compiler (zusammen mit einem fähigen Hochsprachen-Programmierer) annehmen.

wer heute programmieren lernt, bekommt von allen Seiten eingetrichtert der Compiler erzeugt grundsätzlich optimalen Code und du könntest es eh nicht besser.

Was ja auch auf über 99% aller Programmierer absolut zutrifft. Nebst dessen das nur weil man etwas theoretisch besser kann heißt das nicht das man das auch tatsächlich in die Praxis umsetzen kann, gerade bei großen Programmen (die iterativ entwickelt werden) ist das Erzeugen von optimalen Assembler-Code per Hand in endlicher Zeit absolut unmöglich.

Wozu sich dann noch Gedanken machen ob man mit irgendwelchen Tricks (wie den von Svenska) nicht eine eigentlich "einfache" Sache noch schneller hinbekommt (da wo es auch nötig wäre, z.B. 3D oder irgendwas mit Video)?

Der gezeigte Trick hat aber auch nichts mit der verwendeten Programmiersprache zu tun sondern ist algorithmischer Natur.

@FlashBurn:
Diese Behauptung das der Mensch den besseren Code generieren kann ist rein akademischer Natur weil es einfach in der Praxis nicht umsetzbar ist! Die maximale Lebenserwartung eines Menschen ist nun mal beschränkt (und ich hoffe das bleibt auch für immer so).


Grüße
Erik

[FlashBurn]

nicht optimal, sondern optimaler als es den meisten Menschen in sinnvollen Zeitschranken und unter minimaler Beachtung normaler Softwareentwicklungskriterien (Wartbarkeit, iterative Entwicklung) je möglich wäre.

Du sagst also im Endeffekt ist es durchaus möglich besseren Code als ein Compiler zu schreiben Dass das länger dauert, Assembler nicht wirklich wartbar oder portierbar ist, dagegen sage ich auch nichts. Es ist aber möglich und genau diese Möglichkeit wird doch von den meisten in Frage gestellt.

Ich sage auch nicht das man Compiler wegwerfen sollte, auf keinen Fall, da wird man ja gar nicht mehr fertig Aber auch ein Compiler hat nur soviel Wissen wie man ihm beigebracht hat, er ist nicht in dem Sinne intelligent, das er lernen könnte, er kann nur so intelligent sein wie man ihn programmiert hat.
Nach eurer Logik wäre dann ja jeder Computer intelligent, ist er aber nicht, nur so weit wie man ihn programmiert hat!

@erik

Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann. Sicher wenn man Einschränkungen macht, aber rein theoretisch ist es halt möglich und das wird grundsätzlich ausgeschlossen.

Wenn ich mir einen bestimmten Zeitpunkt aussuche, dann kann ein Mensch ohne großen Aufwand besseren Code als ein Compiler erzeugen. Nämlich dann wenn es noch keinen Compiler für eine bestimmte Architektur gibt oder wenn der Compiler noch nicht richtig angepasst ist. Das gilt auch für moderne Compiler.

[bluecode]

Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann. Sicher wenn man Einschränkungen macht, aber rein theoretisch ist es halt möglich und das wird grundsätzlich ausgeschlossen.

Von wem wird das grundsätzlich ausgeschlossen (ohne Randbedingungen)? Ich würde ja vermuten, dass das niemand war oder das derjenig implizit "realistische" Randbedinungen gewählt hat.

[kevin]

Du sagst also im Endeffekt ist es durchaus möglich besseren Code als ein Compiler zu schreiben Dass das länger dauert, Assembler nicht wirklich wartbar oder portierbar ist, dagegen sage ich auch nichts. Es ist aber möglich und genau diese Möglichkeit wird doch von den meisten in Frage gestellt.

Also zumindest, dass man von Hand gleich guten Code schreiben kann wie der Compiler, ist trivialerweise wahr: Ich kann mir den Compilercode anschauen und mit genügend Zeit und Konzentration (Fehler sollten lieber nicht passieren ) kann ich den Algorithmus auch von Hand ausführen. Toll als theoretischer Beweis, aber ich nehme an, jeder wird mir zustimmen, dass das in der Praxis Blödsinn ist.

Ich sage auch nicht das man Compiler wegwerfen sollte, auf keinen Fall, da wird man ja gar nicht mehr fertig Aber auch ein Compiler hat nur soviel Wissen wie man ihm beigebracht hat, er ist nicht in dem Sinne intelligent, das er lernen könnte, er kann nur so intelligent sein wie man ihn programmiert hat.

Richtig, aber "man" ist in dieser Fall nicht jeder einzelne, der Hochsprachen-Code schreibt, sondern die Programmierer des Compilers. Die haben hoffentlich genug Arbeit reingesteckt und den Compiler gut genug gemacht, dass ich es mir sparen kann, das Rad neu zu erfinden. Die Compilerleute arbeiten auch eng mit den Prozessorherstellern zusammen (oder arbeiten sogar direkt für sie), so dass ihnen die genauen Details sehr wahrscheinlich besser bewusst sind als mir. Und damit kann der Compiler dann besser optimieren als ich es ohne dieses Wissen kann.

[XanClic]

Du sagst also im Endeffekt ist es durchaus möglich besseren Code als ein Compiler zu schreiben

Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann. Sicher wenn man Einschränkungen macht, aber rein theoretisch ist es halt möglich und das wird grundsätzlich ausgeschlossen.

Ich kann auch /dev/urandom (oder die Ausgabe von 10000 Affen an Schreibmaschinen) in eine Datei pipen, versuchen, die zu assemblieren und das Ergebnis ausführen, wenn der Dateiinhalt syntaktisch in Ordnung war. Dann teste ich, ob er auch semantisch in Ordnung ist. Das mache ich dann so oft, bis ich ein paar korrekte Ergebnisse zusammen habe, die schneller als der compilergenerierte Code sind und suche mir dann davon das schnellste aus.
Kann man auch machen, ist theoretisch möglich. Dauert nur halt ein kleines bisschen. Wenn man aber ∞ Affen nimmt, wäre das beste Ergebnis sogar sofort da.

Nach eurer Logik wäre dann ja jeder Computer intelligent, ist er aber nicht, nur so weit wie man ihn programmiert hat!

Du weißt schon, dass ein menschliches Gehirn (meiner Annahme nach das Ding, was wir zum Assemblercode schreiben nutzen) aus Synapsen besteht, die einzeln ohne Probleme von einem Computer simuliert werden können? Wenn man einen genügend leistungsfähigen Computer hätte, könnte der mal nebenbei ein ganzes menschliches Gehirn simulieren. Da könnte man dann auch einen intelligenten Compiler drauf laufen lassen.
Das menschliche Gehirn ist also auch nur so weit intelligent, wie es „programmiert“ worden ist. imho.

[erik.vikinger]

Hallo,

Aber auch ein Compiler hat nur soviel Wissen wie man ihm beigebracht hat, er ist nicht in dem Sinne intelligent, das er lernen könnte, er kann nur so intelligent sein wie man ihn programmiert hat.
Nach eurer Logik wäre dann ja jeder Computer intelligent, ist er aber nicht, nur so weit wie man ihn programmiert hat!

Der Hinweis mit den "Profiling-Informationen" kam ja schon! Was willst Du denn da noch? Wirklich intelligent ist der Compiler natürlich nicht aber es stehen ihm eine ganze Menge sehr guter Werkzeuge zur Verfügung die Du als Mensch nicht so ohne weiteres hast.

Es geht mir nur darum, das die Behauptung ein Mensch kann auf keinen Fall besseren Code erzeugen als ein Compiler nicht gehalten werden kann.

Das habe ich auch nie behauptet! Ich versuche Dir nur klar zu machen das es die Realität eben nicht ohne Nebenbedingungen gibt. Zu diesen Nebenbedingen gehört die begrenzte Lebenserwartung des Menschen genauso wie Kunden/Auftraggeber die 10 Minuten vor dem Liefertermin noch zu Dir kommen und Sätze aussprechen die mit "Ich bräuchte da aber noch ...." oder "Da kann man doch bestimmt noch ...." anfangen. Solange Du diese Nebenbedingen komplett ausschließen kannst ist es sicher theoretisch möglich das ein Mensch besseren Code abliefert als ein Compiler aber in der Realität ist das eben nicht so. Da wir aber nun mal alle in der Realität leben (zumindest vermute ich das von uns allen) müssen wir eben auch die zugehörigen Nebenbedingen mit einkalkulieren und so ergibt sich eben das der Mensch keine Chance gegen einen guten Compiler hat.

Wenn ich mir einen bestimmten Zeitpunkt aussuche, dann kann ein Mensch ohne großen Aufwand besseren Code als ein Compiler erzeugen. Nämlich dann wenn es noch keinen Compiler für eine bestimmte Architektur gibt oder wenn der Compiler noch nicht richtig angepasst ist. Das gilt auch für moderne Compiler.

Und wieder versuchst Du spezielle Bedingunen zu schaffen die dem Menschen einen Vorteil geben. Klar kann ich für meine CPU derzeit den besten Code abliefern einfach weil es noch keinen Compiler gibt aber das ist hoffentlich kein Dauerzustand. Nebst dessen das ich es doof finde das Du versuchst Bedingungen auszuschließen die die Realität einfach unumstößlich vorgibt aber selber versuchst mit untypischen Annahmen doch noch die Compiler schlecht zu machen. Wenn Du einen guten menschlichen Assembler-Programmierer aufs Feld führen möchtest dann musst Du auch einen guten modernen Compiler als Gegner akzeptieren! Der Ausgang eines solchen fairen Duells dürfte wohl ziemlich eindeutig zu Gunsten des Compilers ausfallen.


Grüße
Erik

[FlashBurn]

@XanClic
Intelligenz erfordert doch aber auch die Fähigkeit zu lernen oder? Und dazu sind Compiler noch nicht fähig, man muss sie programmieren, aber von alleine schaffen sie es noch nicht.

Man würde also unendlich lange für ein bestimmtes komplexes Problem in Assembler brauchen, das man in endlicher Zeit mit Hilfe eines Compilers/Hochsprache lösen kann?

@taljeth

Du willst das Rad also nicht neu erfinden. Wieso erfindest du dann das Rad=OS neu? Es gibt doch schon genügend Räder=OS.

Und auch du setzt wieder Compiler mit GCC oder meinetwegen noch LLVM gleich. Es gibt aber noch andere Compiler, die weniger guten Code erzeugen.

Um es mal auf einen anderen Fall zu übertragen. Man nehme sich 2 Sportler und die laufen gegeneinander 100m, aber es hat nicht der gewonnen der weniger Zeit benötigt hat, sondern der der das auch noch mit weniger Training geschafft hat.

Das wäre so in etwa das gleiche, ein Assembler-Programmierer kann also nicht gewinnen, weil er immer länger brauchen wird als z.B. ein C-Programmierer.

Desweiteren geht ihr auch von sehr hardwarenahen Sprachen aus. Denn wenn ich das mal ummünze, heißt es also auch ein Assembler-Programmierer kann keinen schnelleren Code schreiben als ein Java-Compiler (das Java nunmal in einer VM läuft ist ja egal, es geht um das Ergebnis).

@erik

Du schaffst doch auch gute Nebenbedingungen für einen Compiler, sprich du baust dir deine Realität auch so wie du sie brauchst!

Was den Kunden und Änderungen kurz vor Schluss betrifft. Dafür gibt es ein Pflichtenheft und was da nicht drinsteht muss auch für die Erfüllung des Auftrages zu einem bestimmten Termin nicht gemacht werden. Wenn der Auftraggeber dann noch was will, muss halt neu verhandelt werden, inklusiver eines neuen Termines.
Aber zurück zum Thema, wer als Hobby ein OS schreibt, hat keine Termine die eingehalten werden müssen. Angefangen hat doch die Diskussion dadurch:

Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest

Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.

Auch ein moderner Compiler will erstmal auf eine neue Architektur portiert werden, dass nimmt Zeit in Anspruch. Es ist also durchaus möglich, das auf einem neuem Mikrokontroller, ein Assemblerprogrammierer wesentlich schneller ein Problem lösen kann (in Form von Code) als jemand der erst noch nen Compiler portieren muss (nur den Codegenerator und eventuell den Optimierer).
Also gibt es durchaus auch in der Realität Fälle, wo man mit Assembler schneller ist.

[kevin]

Du willst das Rad also nicht neu erfinden. Wieso erfindest du dann das Rad=OS neu? Es gibt doch schon genügend Räder=OS.

Es reicht ja, ein Rad neu zu erfinden, oder?

Ich schreibe auch nicht zusätzlich noch einen Bootloader, Firmware, baue mir keine passende CPU und sonstige Hardware, bau mir keinen eigenen Reaktor, um das Ding zu betreiben...

Und auch du setzt wieder Compiler mit GCC oder meinetwegen noch LLVM gleich. Es gibt aber noch andere Compiler, die weniger guten Code erzeugen.

Das ist ein Nullargument. Es gibt auch schlechte Assemblerprogrammierer. Guter Compiler gegen guten Programmierer, schlechter Compiler gegen schlechten Programmierer, schon passt die Welt wieder.

Desweiteren geht ihr auch von sehr hardwarenahen Sprachen aus. Denn wenn ich das mal ummünze, heißt es also auch ein Assembler-Programmierer kann keinen schnelleren Code schreiben als ein Java-Compiler (das Java nunmal in einer VM läuft ist ja egal, es geht um das Ergebnis).

Ich erhalte meine Aussage auch für Java aufrecht.

Wo du immer das "Programmierer kann keinen schnelleren Code schreiben" hernimmst, weiß ich nicht. Das ist weder meine Aussage noch die irgendeines anderen in diesem Thread. Anderen blödsinnige Aussagen unterzuschieben ist eine typische Trolltechnik.

Auch ein moderner Compiler will erstmal auf eine neue Architektur portiert werden, dass nimmt Zeit in Anspruch. Es ist also durchaus möglich, das auf einem neuem Mikrokontroller, ein Assemblerprogrammierer wesentlich schneller ein Problem lösen kann (in Form von Code) als jemand der erst noch nen Compiler portieren muss (nur den Codegenerator und eventuell den Optimierer).
Also gibt es durchaus auch in der Realität Fälle, wo man mit Assembler schneller ist.

Hat das irgendjemand bestritten? Es gibt Fälle, in denen der Einsatz von Assembler sinnvoll ist (Entwicklungsgeschwindigkeit ist dabei auch nur das eine, Fehleranfälligkeit nochmal eine ganz andere Baustelle), aber für komplette Großprojekte ist das eher nicht der Fall.

[XanClic]

Intelligenz erfordert doch aber auch die Fähigkeit zu lernen oder? Und dazu sind Compiler noch nicht fähig, man muss sie programmieren, aber von alleine schaffen sie es noch nicht.

Dass sie es jetzt können, habe ich ja auch nicht gesagt. Ich wollte nur zeigen, dass letzten Endes auch das menschliche Gehirn nicht viel mehr als ein Computer ist, wenn auch sehr viel komplexer als unsere heutigen Rechner.
Aber um auf das Lernen einzugehen: Ist es denn wichtig, dass Compiler von sich aus lernen können? Macht sie das besser? Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.

Man würde also unendlich lange für ein bestimmtes komplexes Problem in Assembler brauchen, das man in endlicher Zeit mit Hilfe eines Compilers/Hochsprache lösen kann?

Nein. Ich wollte nur zeigen, dass die Aussage „Es ist theoretisch möglich“ nicht viel Sinn in sich trägt, da ich dann nicht mal einen Menschen zum Programmieren brauche.

Und auch du setzt wieder Compiler mit GCC oder meinetwegen noch LLVM gleich. Es gibt aber noch andere Compiler, die weniger guten Code erzeugen.

Die nehme ich dann aber definitiv nicht.
Du kannst keinen guten Assemblerprogrammierer mit einem schlechten Compiler vergleichen. Geht nicht.

Um es mal auf einen anderen Fall zu übertragen. Man nehme sich 2 Sportler und die laufen gegeneinander 100m, aber es hat nicht der gewonnen der weniger Zeit benötigt hat, sondern der der das auch noch mit weniger Training geschafft hat.

Nicht ganz richtig. Es hat schon der gewonnen, der weniger Zeit benötigt hat, aber: Wenn der Zeitunterschied marginal (0,1 s), aber der der Trainingsunterschied gewaltig (drei Monate gegen fünf Jahre) ist, sollte sich der Gewinner mal fragen, ob es das wirklich wert war.

Auch ein moderner Compiler will erstmal auf eine neue Architektur portiert werden, dass nimmt Zeit in Anspruch. Es ist also durchaus möglich, das auf einem neuem Mikrokontroller, ein Assemblerprogrammierer wesentlich schneller ein Problem lösen kann (in Form von Code) als jemand der erst noch nen Compiler portieren muss (nur den Codegenerator und eventuell den Optimierer).

Klar. Das hat erik doch auch schon geschrieben. Und? Wer von uns, der nicht gerade seine eigene Architektur entwickelt, schreibt sein OS für eine nicht von GCC/Binutils unterstützte Architektur?

[MNemo]

@FlashBurn
WT*?

Natürlich gibt es auch schlechte Compiler. Aber es gibt auch noch schlechtere Programmierer. Wir reden hier von modernen Compilern. Und zwei gleich guten Programmierern. Und das Java langsam ist weil es in einer VM Ausgeführt wird ist nun auch schon Überholt.

Und nochmal, es beschreitet hier niemand das der Mensch theoretisch in der lange ist den, den Perfekten Code(so fern er denn existiert) zu schreiben. Und auch nicht das Spezialfälle gibt in den das auch Praktisch umsetzbar ist.

Und es geht hier ja um die Entwicklung eines Kernels, nicht um ein strlen oder eine Matrixmultiplikation.

[FlashBurn]

@XanClic

Bei dem Vergleich mit den 100m Lauf ist aber 0,1s schon gewaltig Und auf nem Computer kommt es halt drauf an wie oft der Code ausgeführt wird (auch Kleinvieh macht mist).

Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.

Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".

Ansonsten baut sich jeder von uns (das schließt mich mit ein) seine Randbedingungen so wie er sie gerade braucht

@taljeth

Das mit dem Troll geht jetzt dann aber doch etwas zu weit, ich werde doch auch nicht gleich persönlich Zumal ich ja geschrieben habe, wo soetwas gesagt wurde!

Was Assembler als Sprache betrifft, ist es durchaus gängige Meinung, das man sie nicht mehr benötigt und das es keinen Sinn macht in ihr zu programmieren. Alle hier sollten wissen das es Dinge gibt, die nur in Assembler gelöst werden können und das es immer Fälle geben wird, wo man Assembler benötigt.

@MNemo

Naja, ein OS hat igendwo auch nen strlen, aber der Compiler sollte das eigentlich ganz gut optimieren können

@all

Hat eigentlich irgendjemand hier das gelesen was ich gequotet habe?

[MNemo]

Naja, ein OS hat igendwo auch nen strlen, aber der Compiler sollte das eigentlich ganz gut optimieren können

Nur das 'strlen' nicht auch irgendwo ein OS hat. Sprich nur weil du eins besser hin bekommst als ein Compiler, heißt das nicht gleich das das andere auch besser hin bekommst.

[edit]Wenn es nur darum ginge das tev sein strlen in assembler programmiert weil der das besser Optimieren kann als ein Compiler hätte auch keiner was dagegen gesagt[/edit]

Hat eigentlich irgendjemand hier das gelesen was ich gequotet habe?

Sicher. Nur das sich Svenska, mit dem ersten Satz nicht auf irgend welche mini-proceduren bezieht, sonder in dem Kontext wohl eher auf den Gesamten Kernel, sollte eigentlich klar sein.

Der Konjunktiv ist wohl unglücklich gewählt, besser wäre "können wirst", um deutlicher zu machen das er sich auf die Praxis bezieht nicht auf die Theorie.

Insofern widerspricht sich das nicht mit Unseren aussagen.

[FlashBurn]

Sprich nur weil du eins besser hin bekommst als ein Compiler, heißt das nicht gleich das das andere auch besser hin bekommst.

Naja, wir reden ja auch von einem konkreten Problem und nicht das ich (also irgendjemand) alle Probleme lösen könnte und das auch noch besser als der Compiler.

Der Konjunktiv ist wohl unglücklich gewählt, besser wäre "können wirst", um deutlicher zu machen das er sich auf die Praxis bezieht nicht auf die Theorie.

Ich kenne tev jetzt nicht, aber wer kann dir garantieren das er es nicht doch hinbekommt. Sowas wie 100% Sicherheit gibt es halt nicht, niemand kann die Zukunft voraussagen.

Ich weiß aus eigener Erfahrung das solche "du schaffst das eh nie" Aussagen einfach falsch sind.

[XanClic]

Bei dem Vergleich mit den 100m Lauf ist aber 0,1s schon gewaltig

Tja. Wenn du fünf Jahre deines Lebens vergeuden möchtest, von mir aus.

Und auf nem Computer kommt es halt drauf an wie oft der Code ausgeführt wird (auch Kleinvieh macht mist).

Es geht hier eben nicht um die Frage, ob ich einen C-Kernel verbessern kann, wenn ich an einigen Stellen handoptimierten Assemblercode einfüge. Es wurde oft genug gesagt, dass das auf jeden Fall so ist. Wie MNemo schreibt, es geht darum, ob es sinnvoll ist, den ganzen Kernel in Assembler zu schreiben.

Mir persönlich ist es ziemlich egal, ob sich ein Compiler sein „Wissen“ selbst beibringt, oder ob er es beigebracht bekommt.

Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".

Ich weiß zwar nicht genau, was du damit meinst, aber ich würde dem zustimmen. Mir geht es ziemlich am Hinterteil vorbei, wer den Compiler wie geschrieben hat. Das Ergebnis zählt, und dieses ist gut.

Naja, ein OS hat igendwo auch nen strlen, aber der Compiler sollte das eigentlich ganz gut optimieren können

Was er im Allgemeinen sogar tut. Und nochmal: Es geht nicht darum, dass der Compiler immer den perfekten Code erzeugt. Es ist nur eine Frage vom Verhältnis von Aufwand zu Nutzen. Von fünf Jahren gegen 0,1 Sekunden.

Hat eigentlich irgendjemand hier das gelesen was ich gequotet habe?

Wenn du die Aussage von Svenska meinst: Ja, und ich stimme ihr sogar zu. Dennoch würde ich das so nie als Argument verwenden und auch Svenska hat das imho eher wieder zurückgenommen.


Ich fasse mal meine Meinung zusammen: Ein Compiler erzeugt selten perfekten Code. Wie gut der Code ist, den ein Mensch schreibt, das hängt von seinen Fähigkeiten ab, von der zur Verfügung stehenden Zeit, etc. pp.. Im Allgemeinen brauche ich für eine Optimierung des Codes hin zu einer Stufe, die compileroptimiertem würdig ist, ein Vielfaches der Zeit, die ich für das Schreiben des Codes in der Hochsprache benötige, abgesehen davon, dass ich persönlich eh länger dafür brauche, überhaupt Assemblercode zu schreiben als den Hochsprachencode (schon allein, weil es normalerweise mehr Zeichen sind, die man zu tippen hat).
Eine weitere Optimierung dauert dann nochmal so lange. Insgesamt ist es deshalb für den größten Teil eines Großprojektes sinnvoll, ihn in einer Hochsprache zu schreiben. Potenziert sich der Nutzen von Handoptimierung hingegen erheblich (extrem häufig durchlaufene Funktionen, etc.), so ist es wiederum für einzelne Teile sinnvoll, sie von Hand zu optimieren – wenn das Ergebnis besser als das des Compilers ist.

[MNemo]

Ich weiß aus eigener Erfahrung das solche "du schaffst das eh nie" Aussagen einfach falsch sind.

Für ein hinreichend großes N schaffst du es nie eine N-Bit Verschlüsslung zu brute-forcen. Und um das zu sagen brauch dich nicht mal zu kennen.

[erik.vikinger]

Hallo,

Du schaffst doch auch gute Nebenbedingungen für einen Compiler, sprich du baust dir deine Realität auch so wie du sie brauchst!

Wo hab ich das getan? Beweise!
Das einzigste was ich fordere ist das Dein Vergleich fair sein soll, also wenn Du auf die eine Seite einen guten menschlichen Assembler-Programmierer stellst dann muss auf der anderen Seite auch ein guter Compiler (zusammen mit einen fähigen Hochsprachen-Programmierer) stehen. Mehr nicht!

Aber zurück zum Thema, wer als Hobby ein OS schreibt, hat keine Termine die eingehalten werden müssen.

Also spätestens Dein Todestag ist ein Termin den auch Du einhalten musst (ich hoffe bis dahin ist noch viel Zeit).
Wieso kommen eigentlich immer wieder Leute auf die Idee das bei Hobby-Projekten keine zeitliche Beschränkung existiert? Auch ich habe ein RL und auch meine Lebenszeit ist begrenzt und kostbar so das ich auch bei Hobby-Projekten immer überlegen muss ob ich das wirklich machen will.

Angefangen hat doch die Diskussion dadurch:

Wie ich an anderen Stellen schon mehrfach erwähnt habe, kann ein C-Compiler wesentlich besser optimieren als du es je könntest

Außerdem kennen gute C-Compiler deine CPU besser als du es je könntest.

Eine mit hoher Wahrscheinlichkeit wahre Aussage von Svenska, ohne jetzt tev schlecht machen zu wollen. Die Wahrscheinlichkeit das tev sich mit dem P4 und der ganzen Plattform drum herum auch nur halb so gut auskennt wie die Leute die den GCC entwickelt haben ist recht gering wenn auch nicht ganz 0. Klar ist es theoretisch Möglich das tev diesen Wissensrückstand mehr als nur aufholt aber wie viel Zeit müsste tev dafür investieren und wird er das als lohnend betrachten? Vielleicht schafft es tev ja tatsächlich mal besseren Code für einen kompletten Kernel zu erzeugen als der GCC das kann aber reicht dafür überhaupt sein restliches Leben aus?

So lange man die realitätsgebundenen Randbedingungen einhält (und dazu gehört vor allem das man nicht unbegrenzt viel Zeit und Ressourcen hat um ein Programm zu entwickeln) hat der Mensch (inklusive tev) keine echte Chance gegen einen guten Compiler.

Also gibt es durchaus auch in der Realität Fälle, wo man mit Assembler schneller ist.

Das hat niemand bestritten, nur sie entsprechen eben nicht der üblichen realen Praxis. Das sind Ausnahmesituationen!

Das ist die typische Aussage "der Strom kommt ja aus der Steckdose".

Das ist eine sehr praxistaugliche Annahme. Nicht jeder von uns hat die Möglichkeit (oder gar die Fähigkeit) sich mit der Erzeugung der von ihm verbrauchten elektrischen Energie zu befassen. Aber genau darum geht es doch hier. Wie praxistauglich ist es denn ein großes Programm komplett in Assembler zu entwickeln? In der Zeit die man dafür länger benötigt als der Hochsprachen-Programmierer haben sich die Computer bereits so sehr weiterentwickelt das der theoretische Vorsprung des handoptimierten Assembler-Codes obsolete ist!


Ansonsten möchte ich mich der Aussage von taljeth anschließen.


Grüße
Erik