Aber wenn nicht diese, dann sind wahrscheinlich andere Probleme vorhanden, wie das eben der Fall ist bei solchen Projekten, die eine gewisse Komplexität erreicht haben.
Tolle Zusammenfassung der Arbeit! Ich finde es aber ziemlich komisch, dass das noch keinem Betreiber von Hochleistungssystemen aufgefallen ist. Auch finde ich die Aussage etwas befremdlich, dass Heim- und Unternehmensrechner kaum betroffen sind. Bekommt man denn heute überhaupt noch eine CPU mit nur einem Kern? Selbst die billigen Medion-Gerümpel haben doch schon 2x2. Oder bezieht sich das eher auf die typische Anwendersoftware dieser zwei Bereiche, dass die nicht so Multi CPU lastig sind?
Da einen Unterschied zu machen macht sogar sehr viel Sinn.
Heute haben viele CPUs einen Cache (meist L3 Cache) den alle Kerne gemeinsam nutzen können, aber nicht andere CPUs. Dadurch kann es wesentlich besser sein einen Thread (falls ein Wechsel nötig ist) innerhalb einer CPU von Kern zu Kern zu wechseln als von einer CPU auf eine andere.
Nicht nur der Cache spielt da eine Rolle. Bei heutigen NUMA-Systemen ist auch der Hauptspeicher mal direkt und im anderen Fall nur über eine andere CPU erreichbar. Moderne Scheduler berücksichtigen wohl auch das.
Ungeachtet dessen das es wie Singlekore schrieb nur Multi-CPU multi-core Systeme betrifft ist es wohl auch zumindest für mich nicht direkt ersichtlich wie relevant die Fehler in der Praxis sind (Benchmark != realer Einsatz) davon einmal abgesehen ist es natürlich auch nochmal ein Unterschied zu bemerken das da was irgendwie träge ist und tatsächlich das ganze soweit runter zu isolieren und zu analysieren um einen nutzbaren Bugreport zu erstellen. Wenn wir von normal bezahlter Arbeit irgendwo in einer Firma sprechen wird es billiger gewesen sein drum rum zu arbeiten oder einfach damit zu leben.
Naja, bei den sogenannten Supercomputern wird das mit Sicherheit stark ins Gewicht fallen. Dort muss so programmiert werden, dass die Berechnung möglichst parallel stattfindet, d.h. aber auch, dass man es deutlich spürt, wenn plötzlich einige Kernel gar nichts mehr tun, weil der Scheduler Mist baut.
Das heißt aber eigentlich auch, dass man das Problem längst hätte bemerken müssen, evtl. dachten die Leute halt auch, dass sie Mist beim Programmieren gebaut haben? Keine Ahnung.
"Es ist anzunehmen, dass die beschriebenen Fehler bereits in Kürze in den Kernel aufgenommen werden." im vorletzten Absatz
Ob der alternative BFS auch von diesem Problem betroffen ist?
Hat wahrscheinlich noch keiner ausgetestet.
Aber wenn nicht diese, dann sind wahrscheinlich andere Probleme vorhanden, wie das eben der Fall ist bei solchen Projekten, die eine gewisse Komplexität erreicht haben.
Tolle Zusammenfassung der Arbeit! Ich finde es aber ziemlich komisch, dass das noch keinem Betreiber von Hochleistungssystemen aufgefallen ist. Auch finde ich die Aussage etwas befremdlich, dass Heim- und Unternehmensrechner kaum betroffen sind. Bekommt man denn heute überhaupt noch eine CPU mit nur einem Kern? Selbst die billigen Medion-Gerümpel haben doch schon 2x2. Oder bezieht sich das eher auf die typische Anwendersoftware dieser zwei Bereiche, dass die nicht so Multi CPU lastig sind?
" Alle Fehler scheinen nur auf Systemen mit mehreren Mehrkern-Prozessoren aufzutreten,"
Den Satz nochal genau lesen
Ah, danke für den Hinweis
Dann finde ich es aber interessant, dass der Scheduler einen Unterschied macht zwischen CPUs und deren physischen Kernen.
Da einen Unterschied zu machen macht sogar sehr viel Sinn.
Heute haben viele CPUs einen Cache (meist L3 Cache) den alle Kerne gemeinsam nutzen können, aber nicht andere CPUs. Dadurch kann es wesentlich besser sein einen Thread (falls ein Wechsel nötig ist) innerhalb einer CPU von Kern zu Kern zu wechseln als von einer CPU auf eine andere.
Nicht nur der Cache spielt da eine Rolle. Bei heutigen NUMA-Systemen ist auch der Hauptspeicher mal direkt und im anderen Fall nur über eine andere CPU erreichbar. Moderne Scheduler berücksichtigen wohl auch das.
Ungeachtet dessen das es wie Singlekore schrieb nur Multi-CPU multi-core Systeme betrifft ist es wohl auch zumindest für mich nicht direkt ersichtlich wie relevant die Fehler in der Praxis sind (Benchmark != realer Einsatz) davon einmal abgesehen ist es natürlich auch nochmal ein Unterschied zu bemerken das da was irgendwie träge ist und tatsächlich das ganze soweit runter zu isolieren und zu analysieren um einen nutzbaren Bugreport zu erstellen. Wenn wir von normal bezahlter Arbeit irgendwo in einer Firma sprechen wird es billiger gewesen sein drum rum zu arbeiten oder einfach damit zu leben.
Naja, bei den sogenannten Supercomputern wird das mit Sicherheit stark ins Gewicht fallen.
Dort muss so programmiert werden, dass die Berechnung möglichst parallel stattfindet, d.h. aber auch, dass man es deutlich spürt, wenn plötzlich einige Kernel gar nichts mehr tun, weil der Scheduler Mist baut.
Das heißt aber eigentlich auch, dass man das Problem längst hätte bemerken müssen, evtl. dachten die Leute halt auch, dass sie Mist beim Programmieren gebaut haben? Keine Ahnung.