Hallo zusammen,
ich habe mich in letzter Zeit wieder ein bisschen in die Welt der Legacy-Hardware vertieft. Wahrscheinlich geht es einigen von euch ähnlich: Man findet im Keller oder in der Werkstatt ein altes Schätzchen und fragt sich, was man damit softwareseitig heute noch anstellen kann. In meinem Fall ist es ein altes System mit einem Core 2 Quad Q9550 auf einem soliden LGA775-Board. Damals war das Ding ein absolutes Biest, und ich erinnere mich noch genau daran, wie ich die ersten 1080p-Videos damit geschnitten habe, während andere noch mit ihren Dual-Cores kämpften.
Mein aktuelles Projekt ist es, eine schlanke Darwin-Umgebung (vielleicht auf Basis von OpenDarwin oder älteren macOS-Kernel-Sourcen) auf dieser Architektur zum Laufen zu bringen, die über das bloße "Booten" hinausgeht. Ich versuche gerade, ein paar spezifische Kernel-Extensions (Kexts) zu schreiben bzw. zu portieren, um die Hardware-Sensoren und das Power-Management unter einer neueren Darwin-Version besser anzusprechen.
Dabei bin ich auf einen sehr spezifischen Punkt gestoßen, der mich etwas fuchst: Die Handhabung von Thread-Affinität und dem Cache-Layout beim Core 2 Quad . Wie ihr wisst, besteht ein Core 2 Quad technisch gesehen aus zwei zusammengeklebten Dual-Core-Dies. Das bedeutet, dass der Datenaustausch zwischen Core 0 und Core 1 blitzschnell über den gemeinsamen L2-Cache läuft, während die Kommunikation mit Core 2 oder 3 über den Front Side Bus (FSB) gehen muss.
In den offiziellen Apple-Kernel-Sourcen für x86_64 scheint vieles auf die spätere i-Serie (Nehalem und neuer) optimiert zu sein, wo der integrierte Speicher-Controller alles verändert hat. Wenn ich versuche, rechenintensive Tasks unter Darwin auf diesem Q9550 zu verteilen, merke ich, dass der Scheduler oft nicht effizient unterscheidet, welche Kerne sich einen Cache teilen. Das führt zu massiven Latenzen, sobald Daten über den FSB geschubst werden müssen.
Ich habe versucht, über thread_policy_set ein bisschen manuelle Kontrolle zu gewinnen, aber unter Darwin 15+ scheint das System meine Wünsche oft zu ignorieren oder mit Kernel-Panics zu reagieren, wenn ich zu tief in die Topologie-Einstellungen eingreife. Es ist faszinierend und frustrierend zugleich, wie sehr die Architektur des Prozessors hier die Software-Entwicklung limitiert.
Hat von euch zufällig noch jemand Erfahrung mit der Kernel-Programmierung für diese spezifische "Multi-Chip-Modul"-Architektur unter macOS oder Darwin? Gibt es vielleicht versteckte Boot-Argumente oder undocumented APIs, mit denen man dem Scheduler beibringen kann, die Cache-Struktur des Core 2 Quad besser zu respektieren?
Oder ist es eurer Meinung nach heute reine Zeitverschwendung, sich mit der Optimierung für CPUs ohne SSE4.2 oder AVX unter modernen Darwin-Zweigen zu beschäftigen? Ich finde es persönlich eine tolle Übung, um Low-Level-Architekturen besser zu verstehen, aber vielleicht sehe ich den Wald vor lauter Bäumen nicht mehr.
Ich freue mich auf eure Gedanken und vielleicht den einen oder anderen Tipp aus der "Oldschool"-Ecke!
Beste Grüße!
ich habe mich in letzter Zeit wieder ein bisschen in die Welt der Legacy-Hardware vertieft. Wahrscheinlich geht es einigen von euch ähnlich: Man findet im Keller oder in der Werkstatt ein altes Schätzchen und fragt sich, was man damit softwareseitig heute noch anstellen kann. In meinem Fall ist es ein altes System mit einem Core 2 Quad Q9550 auf einem soliden LGA775-Board. Damals war das Ding ein absolutes Biest, und ich erinnere mich noch genau daran, wie ich die ersten 1080p-Videos damit geschnitten habe, während andere noch mit ihren Dual-Cores kämpften.
Mein aktuelles Projekt ist es, eine schlanke Darwin-Umgebung (vielleicht auf Basis von OpenDarwin oder älteren macOS-Kernel-Sourcen) auf dieser Architektur zum Laufen zu bringen, die über das bloße "Booten" hinausgeht. Ich versuche gerade, ein paar spezifische Kernel-Extensions (Kexts) zu schreiben bzw. zu portieren, um die Hardware-Sensoren und das Power-Management unter einer neueren Darwin-Version besser anzusprechen.
Dabei bin ich auf einen sehr spezifischen Punkt gestoßen, der mich etwas fuchst: Die Handhabung von Thread-Affinität und dem Cache-Layout beim Core 2 Quad . Wie ihr wisst, besteht ein Core 2 Quad technisch gesehen aus zwei zusammengeklebten Dual-Core-Dies. Das bedeutet, dass der Datenaustausch zwischen Core 0 und Core 1 blitzschnell über den gemeinsamen L2-Cache läuft, während die Kommunikation mit Core 2 oder 3 über den Front Side Bus (FSB) gehen muss.
In den offiziellen Apple-Kernel-Sourcen für x86_64 scheint vieles auf die spätere i-Serie (Nehalem und neuer) optimiert zu sein, wo der integrierte Speicher-Controller alles verändert hat. Wenn ich versuche, rechenintensive Tasks unter Darwin auf diesem Q9550 zu verteilen, merke ich, dass der Scheduler oft nicht effizient unterscheidet, welche Kerne sich einen Cache teilen. Das führt zu massiven Latenzen, sobald Daten über den FSB geschubst werden müssen.
Ich habe versucht, über thread_policy_set ein bisschen manuelle Kontrolle zu gewinnen, aber unter Darwin 15+ scheint das System meine Wünsche oft zu ignorieren oder mit Kernel-Panics zu reagieren, wenn ich zu tief in die Topologie-Einstellungen eingreife. Es ist faszinierend und frustrierend zugleich, wie sehr die Architektur des Prozessors hier die Software-Entwicklung limitiert.
Hat von euch zufällig noch jemand Erfahrung mit der Kernel-Programmierung für diese spezifische "Multi-Chip-Modul"-Architektur unter macOS oder Darwin? Gibt es vielleicht versteckte Boot-Argumente oder undocumented APIs, mit denen man dem Scheduler beibringen kann, die Cache-Struktur des Core 2 Quad besser zu respektieren?
Oder ist es eurer Meinung nach heute reine Zeitverschwendung, sich mit der Optimierung für CPUs ohne SSE4.2 oder AVX unter modernen Darwin-Zweigen zu beschäftigen? Ich finde es persönlich eine tolle Übung, um Low-Level-Architekturen besser zu verstehen, aber vielleicht sehe ich den Wald vor lauter Bäumen nicht mehr.
Ich freue mich auf eure Gedanken und vielleicht den einen oder anderen Tipp aus der "Oldschool"-Ecke!
Beste Grüße!
