News CachyOS: Gaming-Distribution dominiert auch Workstation-PCs

Dass Code nicht zwangsweise tun muss, was er soll, nur weil er kompiliert und nicht abstürzt, lernt man eigentlich extrem früh, wenn man sich mit Softwareentwicklung beschäftigt. Da helfen nur Tests. Mein Fazit stand heute: Wenn der Quellcode die Optimierung nicht überlebt, dann hat jemand gepfuscht und je schneller man das bemerkt und behebt, desto besser.

Hört sich so an, als wolltest Du damit sagen, dass nicht die höheren Optimierungsstufen des Compilers, sondern der Code selbst das Problem wäre.

Das halte ich für etwas weit hergeholt, wenn Code syntaktisch richtig ist und der Compiler nur bei höheren Optimierungsstufen falschen Code erzeugt.

Was Tests anbelangt. Nur wenige Programmpakete eignen sich für automatisierte Regression Tests und bieten das in den Sources an.

Vor allem: Wer soll das alles umschreiben bzw. testen? Das zu erwarten, wäre etwas realitätsfern.

Der pragmatische Weg, den die überwiegende Zahl von Entwicklern folgt, ist, nur solche Optimierungen für gcc & Co. zu verwenden, die sich im Laufe der Jahrzehnte als zuverlässig erwiesen haben.
 
Hört sich so an, als wolltest Du damit sagen, dass nicht die höheren Optimierungsstufen des Compilers, sondern der Code selbst das Problem wäre.
Das ist exakt, was ich sagen wollte.
Das halte ich für etwas weit hergeholt, wenn Code syntaktisch richtig ist und der Compiler nur bei höheren Optimierungsstufen falschen Code erzeugt.
Ich würde es eher als definitionstreu als als syntaktisch richtig bezeichnen, weil man ja auch innerhalb der Syntax Dinge tun kann, deren Verhalten nicht definiert ist. Wenn das bei definitionstreuem Code passieren würde, würde ich das nicht denken. Es scheint aber alles darauf zu deuten, dass dem schon seit einer ganzen Weile nicht mehr so ist.
 
Wie kommst du darauf? Der meiste Code ändert sich doch ständig.

Ja, im üblichen Rahmen, mit den üblichen Unzulänglichkeiten.

Aber Du meintest doch, wenn Code besser geschrieben wäre, dann müssten theoretisch auch höhere compiler Optimierungen "gefahrlos" möglich sein.

Frommer Wunsch. Das ist aber eher eine Idealvorstellung, die realistisch betrachtet so schnell nicht eintreffen wird.
 
Aber Du meintest doch, wenn Code besser geschrieben wäre, dann müssten theoretisch auch höhere compiler Optimierungen "gefahrlos" möglich sein.
Ich glaube eher, dass der meiste Code schon längst "besser", also definitionstreu geschrieben ist. Wie gesagt kann einem nicht definiertes Verhalten aus allen möglichen Gründen um die Ohren fliegen, weil kein Teil der Ausführungskette dieses garantiert.
 
Wenn Du den wilden Maxen spielen willst, der meint, es besser zu wissen, bitte, mach es bei Dir zu Hause.
Aber wirf verantwortungsvollen Entwicklern nicht vor, sie würden es sich zu einfach machen, frei nach dem Motto
"das haben wir schon immer so gemacht".
Keine Ahnung, wieso du so einen aggressiven Ton ansetzt. Finde ich unangebracht.
Aber das Thema ist halt auch durch.
Phoronix hat die Benchmarks geliefert. O3 hat jetzt auch keine nennenswerten Gewinne gegenüber O2 geliefert.
Jemand hat sich damit eingehend beschäftigt und damit erübrigt sich die Diskussion um den möglichen Vorteil. Dass die CachyOS Rechner scheinbar stabil laufen liegt womöglich daran, dass wir nicht mitbekommen, dass es gelegentlich Probleme gibt.

Nur weil etwas seit vielen Jahren auf eine bestimmte Weise gemacht wird, bedeutet das nicht automatisch, dass es veraltet oder falsch ist. Es gibt so viele Standards die älter als 30-40 Jahren sind und bis heute ihre gültigkeit haben. Gerade bei einem Betriebssystem steht Stabilität und Zuverlässigkeit an erster Stelle, oder sollte es zumindestens.
Absolut! Es mag alt sein, aber nicht veraltet, schlecht oder falsch. Nur habe ich auch schon oft genug erlebt, dass Leute Lösungen immer weiter (über)-tragen und sich neuen Ideen verschließen, obwohl sie sachlich begründbare Vorteile bringen.
Konkretes Beispiel? Es werden immer noch Schnittstellen gebaut, die Daten erst einmal einfach ablegen. Der Folgeprozess läuft (meist) zeitgesteuert los. Ich lehne mich mal aus dem Fenster und wage zu behaupten, dass solche Lösungen gerne Nachts loslaufen und irgendwelche Aufträge verarbeiten. Wenn eine vermeintliche Kleinigkeit 2-3 Tage braucht, dann liegt es vielleicht am Timing der Systeme. Es mag Gründe dafür geben. Aber bestimmt auch reichlich dagegen. Und vielleicht auch etwas Komplexität.

Und wenn es etwas gibt, dass alt, aber mit verdammt viel Weitsicht gebaut wurde, dann sind es Netzwerkprotokolle. Ich schätze es wirklich sehr, wie vielfältig und robust z.B. das Internet Protocol (4) gebaut ist, dass es wirklich viele Fälle vorgesehen hat und mit Masking auch viel auf Hardwareebene oder Bit-Arithmetik möglich machte.
 
Und wenn es etwas gibt, dass alt, aber mit verdammt viel Weitsicht gebaut wurde, dann sind es Netzwerkprotokolle. Ich schätze es wirklich sehr, wie vielfältig und robust z.B. das Internet Protocol (4) gebaut ist, dass es wirklich viele Fälle vorgesehen hat und mit Masking auch viel auf Hardwareebene oder Bit-Arithmetik möglich machte.

Ja das stimmt, gerade die Netzwerktechnik (obwohl schon zum Teil über 50 Jahre alt) wurde mit richtig viel Weitsicht gebaut, z.B Das TCP und Ethernet Protokol das wir alle noch heute verwenden.

Hab das gerne gelesen und studiert in meinem Studien (Computernetzwerk von A. Tanenbaum :love::love::love: )
 
Zurück