Das ist schon richtig, aber da ist der große Schritt eher von gcc 2.x auf 3.x gegangen worden. Seit dem ist der gcc erheblich standardkonformer geworden, das war ja sogar ein Ziel der 3er Version mit den ganzen gcc Gutmütigkeiten und Erweiterungen aufzuräumen. So weit ich weiß war dies unter anderem ein Wunsch der "Optimierer", die sich von restriktiverem Code bessere Möglichkeiten effizienten Code zu erzeugen erhoffen. Auch beim Kernel gibt es (natürlich auch als Reaktion auf die "neueren" gcc) eine Bewegung "sauberer" zu programmierten, AFAIK kann man den Kernel ja auch mittlerweile mit ein paar Tricks mit dem Intel Compiler compilieren (ohne allerdings nennenswerte Performancegewinne).
Mal abwarten wie sich der gcc4 so entwickelt, aber bei manchen Reaktionen hier werden wohl einige sowieso enttäuscht sein. Die Möglichkeiten zur weiteren Optimierung bewegen sich im wesentlichen im einstelligen Prozentbereich, das merkt man bei normaler Nutzung des Rechners nicht.
| Das ist schon richtig, aber da ist der große Schritt eher von gcc 2.x auf 3.x gegangen | worden. Seit dem ist der gcc erheblich standardkonformer geworden, das war ja sogar ein | Ziel der 3er Version mit den ganzen gcc Gutmütigkeiten und Erweiterungen aufzuräumen.
Das stimmt wohl für den gcc. Aber nicht unbedingt für den c++! Da ist selbst innerhalb der 3.x-Reihe einiges umgebaut worden. Code, der mit dem c++ 3.[23] geht, geht sehr oft nicht mehr mit dem 3.4. Das ist schon ziemlich nervig, wenn man selber Pakete optimiert übersetzen will und dann das Grauen bekommt, wenn im c++-Teil fast gar nix mehr klappt, weil der vor Fehlern nur so strotzt. Wenn es sich um Kleinigkeiten handelt, dann gehts noch, aber wenn man so stark eingreifen muss, dass es Auswirkungen auf den geamten Code hat und man diesen quasi erst komplett durchschauen/verstehen muss, hat man verloren.
Und wenn diese Entwicklung aus der 3er-Reihe des gcc/c++ auch sich in der 4er-Reihe wiederholt, dann gute Nacht. :-|
Dann bleibt einem nur noch, wirklich jedes Paket passend zum System vom Distributoren zu holen (wenn es denn dort eines gibt!) oder zu hoffen, dass jemand anderes (vertrauens- würdiges) eines zur Verfügung stellt.
Mal abwarten wie sich der gcc4 so entwickelt, aber bei manchen Reaktionen hier werden wohl einige sowieso enttäuscht sein. Die Möglichkeiten zur weiteren Optimierung bewegen sich im wesentlichen im einstelligen Prozentbereich, das merkt man bei normaler Nutzung des Rechners nicht.
| worden. Seit dem ist der gcc erheblich standardkonformer geworden, das war ja sogar ein
| Ziel der 3er Version mit den ganzen gcc Gutmütigkeiten und Erweiterungen aufzuräumen.
Das stimmt wohl für den gcc. Aber nicht unbedingt für den c++! Da ist selbst innerhalb der
3.x-Reihe einiges umgebaut worden. Code, der mit dem c++ 3.[23] geht, geht sehr oft nicht
mehr mit dem 3.4. Das ist schon ziemlich nervig, wenn man selber Pakete optimiert
übersetzen will und dann das Grauen bekommt, wenn im c++-Teil fast gar nix mehr klappt,
weil der vor Fehlern nur so strotzt. Wenn es sich um Kleinigkeiten handelt, dann gehts
noch, aber wenn man so stark eingreifen muss, dass es Auswirkungen auf den geamten Code
hat und man diesen quasi erst komplett durchschauen/verstehen muss, hat man verloren.
Und wenn diese Entwicklung aus der 3er-Reihe des gcc/c++ auch sich in der 4er-Reihe
wiederholt, dann gute Nacht. :-|
Dann bleibt einem nur noch, wirklich jedes Paket passend zum System vom Distributoren zu
holen (wenn es denn dort eines gibt!) oder zu hoffen, dass jemand anderes (vertrauens-
würdiges) eines zur Verfügung stellt.
A.