Skylake und der Albtraum-Bug: Entwickler schildert, wie er ihn entdeckt hat

Jetzt ist Ihre Meinung gefragt zu Skylake und der Albtraum-Bug: Entwickler schildert, wie er ihn entdeckt hat

Entwickler Joris Giovannangeli hat in einen sehr ausführlichen Blog-Beitrag beschrieben, wie er zusammen mit anderen den sogenannten Albtraum-Bug in Skylake-Prozessoren entdeckt hat.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Skylake und der Albtraum-Bug: Entwickler schildert, wie er ihn entdeckt hat

Sprachen mit integriertem Garbage-Collector sind eh nur was für Faule

Zeigt deutlich wie kompliziert CPUs sind.
Kleine Schleifen die im Register bleiben, 2 Threads auf dem selben Kern und das nutzen gewisser Register und dann dazu noch nur mit bestimmten Daten.....

Malkolm schrieb:

Sprachen mit integriertem Garbage-Collector sind eh nur was für Faule

Zum Vergrößern anklicken....

oder diejenigen die nicht 50 stunden verschwenden wollen um Speichermanagment zu schreiben das dennoch schlechter funktioniert.

Zumal dann auch schnell Use-After-Free Fehler passieren können. So etwas kann aber ein guter Kompiler schon im Quelltext erkennen.

Malkolm schrieb:

Sprachen mit integriertem Garbage-Collector sind eh nur was für Faule

Zum Vergrößern anklicken....

Jaja, genauso wie bei den Compilern: Echte "Männer" schreiben in Assembler....

Die Realität ist eine andere: Sowohl die automatisierten Garbage-Collectoren als auch die Compiler produzieren in den allermeisten Fällen ein schnelleres Ergebnis als ein mühsam per Hand zusammen opimiertes Programm - das meistens ganz ohne Speicherlecks und Bugs

Oder man gewöhnt sich einfach eine Methodik an, dass man unmittelbar nach Reservierung die Freigabe programmiert oder die Aufrufe dazu implementiert. Es könnte ja so einfach sein....

Exinferis schrieb:

Oder man gewöhnt sich einfach eine Methodik an, dass man unmittelbar nach Reservierung die Freigabe programmiert oder die Aufrufe dazu implementiert. Es könnte ja so einfach sein....

Zum Vergrößern anklicken....

Umm, und was wenn man bei Reservierung noch gar nicht weiß wie lange man den entsprechenden Speicherbereich braucht? Denn dein Fall beschreibt ja praktisch nur den Trivialfall, dass man schon beim Kompilieren weiß wann man was wieder freigeben will - dafür braucht man aber keine dynamische Speicherallokierung, dafür reichen statische Variablen. Und die erledigen sich selbst in C/C++ und Fortran wieder von selbst, einfach weil sie auf dem Stack liegen.

Das Problem sind dynamische Speicherbereiche, bei denen man nicht mal zur Laufzeit genau weiß wann man sie wieder freigeben können wird. Da muss man dann schon eine Menge Grips in die Speicherverwaltung stecken wenn man den Speicher effizient nutzen will. Und da sind moderne Garbage-Collectoren eben nicht nur zuverlässiger, sondern auch schneller (sprich sie gehen mit dem Speicher effizienter um).

Mephisto_xD schrieb:

Umm, und was wenn man bei Reservierung noch gar nicht weiß wie lange man den entsprechenden Speicherbereich braucht? Denn dein Fall beschreibt ja praktisch nur den Trivialfall, dass man schon beim Kompilieren weiß wann man was wieder freigeben will - dafür braucht man aber keine dynamische Speicherallokierung, dafür reichen statische Variablen. Und die erledigen sich selbst in C/C++ und Fortran wieder von selbst, einfach weil sie auf dem Stack liegen.

Das Problem sind dynamische Speicherbereiche, bei denen man nicht mal zur Laufzeit genau weiß wann man sie wieder freigeben können wird. Da muss man dann schon eine Menge Grips in die Speicherverwaltung stecken wenn man den Speicher effizient nutzen will. Und da sind moderne Garbage-Collectoren eben nicht nur zuverlässiger, sondern auch schneller (sprich sie gehen mit dem Speicher effizienter um).

Zum Vergrößern anklicken....

Das sehe ich anders. In einem sauber strukturierten Programm mit vernünftiger Aufteilung von Gültigkeitsbereichen und der eben sauber implementierten Pointen sehe ich nicht so das Problem. Man muss sich eben VORHER über sowas Gedanken machen und nicht erst dann wenn man auf Probleme trifft.
Und gerade die aktuellen Versionen von C++ bieten zahlreiche Werkzeuge um eine Speicherverwaltung sauber zu programmieren.
Ausser in Java würde ich mich nie auf einen Garbagecollector verlassen.
Dafür weiß ich lieber genau was wann wo mit meinem Speicher genau passiert.
Auch die Compiler bieten ja reichlich Möglichkeiten den Speicherverlauf zu verfolgen.
Vielleicht komme ich einfach aus einer anderen Zeit, wo eben immer selbst auf die Speichernutzung bis ins letzte Bit geachtet werden müsste, aber für mich sind das einfach Grundsätze, die in Zeiten von billigem Speicher und genug Rechenleistung den meisten abgehen.