Wieviele CPU Cores sinnvoll?
- Ersteller worel
- Erstellt am
Also, eigentlich ist es ganz simpel. Sowohl Linux als FreeBSD skalieren im Moment bis 8 CPUs etwa linear. Das bedeutet, fügst du eine neue CPU ein, bekommst du ihre Mehrleistungs fast vollständig. Darüber, also mit der neunten CPU, beginnt bei beiden Systemen der Overhead zu wachsen, die Mehrleistung wird mit jeder CPU geringer, bis sie bei etwa 16 Stück Null ist. Also leistungstechnisch sollte man sich im Moment mit acht CPUs begnügen oder Solaris nehmen, welches bis etwa 64 CPUs linear ist.
Für die Zukunft arbeiten beide Projekte an besserer Skalierung auf mehr CPUs. FreeBSD peilt mit 8.0 mindestens 16, eher 32 CPUs an. Möglich wird dies durch das Beachten der Topologie deiner Maschine, agressivere Lock-Mechanismen, Optimierungen am Threading und so weiter. Linux plant ebenfalls eine saubere Unterstützung für mindestens 32 CPUs, wofür sie allerdings viel mehr als FreeBSD anpassen müssen. Auch dort wird es also noch ein wenig dauern.
Das sagt nichts darüber aus, wie viele CPUs die Kernel verwalten können. Theoretisch gibt es keine Begrenzung, meines Wissens nach wird Linux bei 255 Stück und FreeBSD bei 128 Stück künstlich abgeregelt.
Bei anderen Systemen sieht es merklich schlechter aus. OpenBSD hat praktisch kein nutzbares SMP, schon die zweite CPU bringt nur etwa 50% Mehrleistung, weitere praktisch gar keine mehr. NetBSD ist auf dem Weg zu guter SMP-Unterstützung, aber hat noch eine weite Strecke vor sich. Windows skaliert ab dem dritten Kern zunehmend schlechter, der vierte bringt dir nur noch 25% Mehrleistung, spätestens ab dem sechsten ist der Zuwachs Null. OS X ebenfalls, mehr als zwei CPUs haben dort im Moment keinen großen Sinn. Was Apple nicht daran hindert dies 8-Kern Monster Mac Pro zu verhökern
Für die Zukunft arbeiten beide Projekte an besserer Skalierung auf mehr CPUs. FreeBSD peilt mit 8.0 mindestens 16, eher 32 CPUs an. Möglich wird dies durch das Beachten der Topologie deiner Maschine, agressivere Lock-Mechanismen, Optimierungen am Threading und so weiter. Linux plant ebenfalls eine saubere Unterstützung für mindestens 32 CPUs, wofür sie allerdings viel mehr als FreeBSD anpassen müssen. Auch dort wird es also noch ein wenig dauern.
Das sagt nichts darüber aus, wie viele CPUs die Kernel verwalten können. Theoretisch gibt es keine Begrenzung, meines Wissens nach wird Linux bei 255 Stück und FreeBSD bei 128 Stück künstlich abgeregelt.
Bei anderen Systemen sieht es merklich schlechter aus. OpenBSD hat praktisch kein nutzbares SMP, schon die zweite CPU bringt nur etwa 50% Mehrleistung, weitere praktisch gar keine mehr. NetBSD ist auf dem Weg zu guter SMP-Unterstützung, aber hat noch eine weite Strecke vor sich. Windows skaliert ab dem dritten Kern zunehmend schlechter, der vierte bringt dir nur noch 25% Mehrleistung, spätestens ab dem sechsten ist der Zuwachs Null. OS X ebenfalls, mehr als zwei CPUs haben dort im Moment keinen großen Sinn. Was Apple nicht daran hindert dies 8-Kern Monster Mac Pro zu verhökern
worel
Well-Known Member
Danke, jetzt ists auch mir klar!
Super Antwort wie schon so oft in diesem Forum (deswegen liebe ich es so)
Heftig finde ich die Sache mit Apple - gibts dazu irgendwelche "Belege", also über die Skalierung wenns denn mal mehr CPU's sein sollten?
Bzw. hat nicht Suse bei ihren Enterprise Servern eine Variante welche weit mehr als 32 CPU's unterstützt? Irgendwas hab ich da in dunkler Erinnerung.
Super Antwort wie schon so oft in diesem Forum (deswegen liebe ich es so)
Heftig finde ich die Sache mit Apple - gibts dazu irgendwelche "Belege", also über die Skalierung wenns denn mal mehr CPU's sein sollten?
Bzw. hat nicht Suse bei ihren Enterprise Servern eine Variante welche weit mehr als 32 CPU's unterstützt? Irgendwas hab ich da in dunkler Erinnerung.
Ja der Kernel unterstützt diese Mengen CPUs schon. Aber es ist sinnlos, da der Mehrgewinn an Leistung einfach zu gering oder sogar Null ist. Oder anders ausgedrückt, du jagst Strom durch den Schornstein, ohne einen sinnvollen Gewinn zu haben.
Zu Apple findet ich das tolle Diagram jetzt auf die Schnelle nicht wieder, dafür aber immerhin diesen Link, wo das Problem grob deutlich wird: http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=8
Zu Apple findet ich das tolle Diagram jetzt auf die Schnelle nicht wieder, dafür aber immerhin diesen Link, wo das Problem grob deutlich wird: http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=8
Zuletzt bearbeitet:
Das theoretische Limit bei FreeBSD liegt derzeit bei 64 CPUs [1]. Für Linux wird derzeit an der Unterstützung für 4096 CPUs (für die großen ALTIX-Maschinen von SGI) gearbeitet. Ich glaub der aktuelle Stand sind 1024 oder 2048 CPUs. Und wie kommst du darauf das Linux nur bis 8 CPUs skaliert? Das kommt wohl sehr auf den Benchmark an, d.h MySQL riegelt nach 8 CPUs ab. Postgres hingegen nicht, siehe z.B. http://people.redhat.com/mingo/misc/sysbench-rc6.jpg
Das ist eine 16-CPU Maschine. Größere x86-Maschinen sind derzeit sehr selten und sehr teuer, was sich aber ende des Jahres ändern dürfte, wenn Intel's Nehalem fertig ist.
[1] http://lists.freebsd.org/pipermail/cvs-src/2008-March/088052.html
Das ist eine 16-CPU Maschine. Größere x86-Maschinen sind derzeit sehr selten und sehr teuer, was sich aber ende des Jahres ändern dürfte, wenn Intel's Nehalem fertig ist.
[1] http://lists.freebsd.org/pipermail/cvs-src/2008-March/088052.html
Wie wäre es, wenn die Herren einfach mal das lesen würden was ich schreibe und mir nicht ständig meine Worte im Mund umdrehen, so wie sie einem passen? Ich habe nirgends geschrieben, dass Linux nicht mehr CPUs unterstützen würde, als man mit Geld bezahlen kann. Kann gilt für sie wie für FreeBSD. Was ich dort oben schrieb war, dass Linux auf 32 CPUs nicht mehr linear skaliert und man den Strom für sie sinnlos in Abwärme umwandelt, weil die Mehrleistung jeder weiteren CPU zu gering, null oder sogar negativ ist. Oder anders gesagt, eine CPU in der dmesg auftauchen zu lassen, bedeutet noch lange nicht, das das System außenrum auch in der Lage ist diese zu nutzen. Da gehört viel mehr zu, nämlich Lockstrukturen, antsprechnder Threading-Code, vernünftige Scheduler und so weiter....
Siehe zum Beispiel hier, der extrem threadlastige MySQL nippelt sowohl unter Linux als auch unter FreeBSD hoffungslos ab. Da ist auch nichts "abgeregelt", das System schafft es einfach nicht die Last sinnvoll auf mehr CPUs zu verteilen, es verhakelt sich und blockiert sich selbst: http://people.freebsd.org/~kris/scaling/os-mysql.png. Postgresql zeigt ein ähnliches Bild, auch hier blockiert eher das System als der Server: http://people.freebsd.org/~kris/scaling/os-pgsql.png.
Aus Redhats komischer Grafik werde ich nicht so wirklich schlau. Es ist nirgends erwähnt, auf wie vielen CPUs der Benchmark ausgeführt wurde, nur das er irgendwo knapp über 10 Threads abnippelt. Überhaupt die Skala irgendwie bedenklich, wenn man da noch irgendetwas sinnvolles rauslesen sollte, müsste sie schon linear sein. Meine Vermutung: Das war ein 16-Kern Server oder 32-Kern Server mit Beachtung der CPU-Topologie. Das würde vom gefühl her ins Schema passen, dort schaffen FreeBSD -CURRENT und neuere Linux-Kernel etwa 16 CPUs halbwegs linear.
Der gute Nehalem hat damit nicht viel zu tun. Was kann das Betriebssystem dafür, wenn Intel (im Gegensatz zu allen Konkurenten) ein grottiges, stinklahmes Speicherinterface aus den tiefsten achzigern nutzt, das sich ständig blockiert und nicht wirklich viel Durchsatz schafft? Sorry sniket, ließ dich erstmal ins Thema ein, bevor du hier trollst
Zuletzt bearbeitet:
Und wieder einmal denke ich: Yamagi, du Freak! Bemerkenswert wie du dieses Wissen schon wieder aus dem Ärmel schüttelst!
Aber zum Thema:
Wir hatten hier letztens ein 16 CPU System, das lief mit einem aktuellen Linux echt nicht merkenswert flott... aber wieso auch? Solche Systeme sind immer noch die Ausnahme! Für diese speziellen Fälle gibt es dann ja, wie hier schon gesagt, Alternativen zB. von SUN.
Da es hier aber rein theoretisch um die Leistung eines solches Systems geht würde ich sagen: "Einfach" ausprobieren oder den Benchmarks glauben.
Grüße!
Aber zum Thema:
Wir hatten hier letztens ein 16 CPU System, das lief mit einem aktuellen Linux echt nicht merkenswert flott... aber wieso auch? Solche Systeme sind immer noch die Ausnahme! Für diese speziellen Fälle gibt es dann ja, wie hier schon gesagt, Alternativen zB. von SUN.
Da es hier aber rein theoretisch um die Leistung eines solches Systems geht würde ich sagen: "Einfach" ausprobieren oder den Benchmarks glauben.
Grüße!
Vincent Vega
phisch
Skaliert Solaris auf einer SMP Architektur bis 64 CPUs?
Das Problem an einer SMP Hardware-Architektur ist, dass sich alle CPUs die Busse zum Speicher teilen. Irgendwann wird das zum Flaschenhals, d.h. eine SMP Architektur kann nicht unbegrenzt linear skalieren, unabhängig davon wie gut der Kernel skaliert. 64 Kerne in einer SMP Architektur erscheinen mir schon recht viel.
Endorphine
Well-Known Member
Moment.
Auf den Grafiken wird in positiver y-Richtung die Anzahl der ausgeführten Transaktionen dargestellt, in x-Richtung wird die Anzahl gleichzeitig laufender Threads dargestellt. Die Maschine ist für alle Tests die selbe: ein Intel Xeon mit 8 Kernen, ich vermute also ein heute übliches 2-Sockel Xeon DP System mit Clovertown/Harpertown Quadcores.
Die Grafiken sagen aus, dass sowohl FreeBSD 7.0 als auch Linux 2.6.22 auf diesem System linear mit der Anzahl der Threads skalieren, bis die Maschine mit parallelen Prozessen ausgelastet ist. Dann geht der Durchsatz in Transaktionen/s logischerweise nicht weiter in die Höhe, da alle Kerne voll ausgelastet sind.
Man sieht auch, dass DragonFly eigentlich kein SMP kann und dass bei diesem Test FreeBSD 7.0 am meisten effizient war.
Eine Aussage über die Skalierung auf Maschinen mit mehr als 8 CPUs wird aber durch diese Tests überhaupt nicht getroffen.
Nicht gleich aufregen Yamagi :-)
"Was ich dort oben schrieb war, dass Linux auf 32 CPUs nicht mehr linear skaliert"
Und das weißt du genau woher? Mal ehrlich, von welchen Benchmarks sprichst du hier? Ich habe noch keinen mit 32CPUs gesehn.
"Siehe zum Beispiel hier, der extrem threadlastige MySQL nippelt sowohl unter Linux als auch unter FreeBSD hoffungslos ab."
Jo, liegt aber weder an Linux noch an FreeBSD, sondern an MySQL's threading.
"das System schafft es einfach nicht die Last sinnvoll auf mehr CPUs zu verteilen"
[...] s.o. ein Problem von MySQL, dafür können FreeBSD und Linux nichts.
"Aus Redhats komischer Grafik werde ich nicht so wirklich schlau"
Ja sorry, hätte den dazugehörigen thread posten sollen.
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8819253.html
Es handelt sich dabei um eine 16CPU Maschine. Die "# of clients"-Achse entspricht "Concurrency" in Kris Kenneway's benchmarks. Der Rest dürfte klar sein.
"Meine Vermutung: Das war ein 16-Kern Server oder 32-Kern Server mit Beachtung der CPU-Topologie."
Die Topologie-Awareness, die Jeff Roberson neulich commit hat gibts unter Linux schon ein paar Jahre, nur so als Hinweis.
"Das würde vom gefühl her ins Schema passen, dort schaffen FreeBSD -CURRENT und neuere Linux-Kernel etwa 16 CPUs halbwegs linear."
Die letzten mir bekannten Benchmarks von Kris sind http://people.freebsd.org/~kris/scaling/pgsql-barcelona.png und
http://people.freebsd.org/~kris/scaling/pgsql-16cpu-2.png
Wenn du neuere kennst wäre ein Link sehr nett. Es geht nicht nur darum, dass das System linear skaliert, sondern auch wie stabil das Ganze über eine große Anzahl von Threads gehalten werden kann. Wie du auf den beiden Bildern oben sehen kannst bricht FreeBSD bei 14/15 Threads ein. Jetzt vergleich das nochmal mit den Linuxwerten. Vom Peak 9000 bei 16 Threads (daran erkannt man auch, dass es sich um eine 16CPU Maschine handelt) bis zu 7660 bei 256 Threads bricht die Kurve nur leicht ein.
"Der gute Nehalem hat damit nicht viel zu tun."
Ich meinte damit lediglich, dass es bald native 8-Cores geben wird.
"Sorry sniket, ließ dich erstmal ins Thema ein, bevor du hier trollst"
Netter Versuch :-)
Ich bin ja auch ein großer FreeBSD-Freund, aber wir sollten hier bitte bei der Wahrheit bleiben.
"Was ich dort oben schrieb war, dass Linux auf 32 CPUs nicht mehr linear skaliert"
Und das weißt du genau woher? Mal ehrlich, von welchen Benchmarks sprichst du hier? Ich habe noch keinen mit 32CPUs gesehn.
"Siehe zum Beispiel hier, der extrem threadlastige MySQL nippelt sowohl unter Linux als auch unter FreeBSD hoffungslos ab."
Jo, liegt aber weder an Linux noch an FreeBSD, sondern an MySQL's threading.
"das System schafft es einfach nicht die Last sinnvoll auf mehr CPUs zu verteilen"
[...] s.o. ein Problem von MySQL, dafür können FreeBSD und Linux nichts.
"Aus Redhats komischer Grafik werde ich nicht so wirklich schlau"
Ja sorry, hätte den dazugehörigen thread posten sollen.
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/8819253.html
Es handelt sich dabei um eine 16CPU Maschine. Die "# of clients"-Achse entspricht "Concurrency" in Kris Kenneway's benchmarks. Der Rest dürfte klar sein.
"Meine Vermutung: Das war ein 16-Kern Server oder 32-Kern Server mit Beachtung der CPU-Topologie."
Die Topologie-Awareness, die Jeff Roberson neulich commit hat gibts unter Linux schon ein paar Jahre, nur so als Hinweis.
"Das würde vom gefühl her ins Schema passen, dort schaffen FreeBSD -CURRENT und neuere Linux-Kernel etwa 16 CPUs halbwegs linear."
Die letzten mir bekannten Benchmarks von Kris sind http://people.freebsd.org/~kris/scaling/pgsql-barcelona.png und
http://people.freebsd.org/~kris/scaling/pgsql-16cpu-2.png
Wenn du neuere kennst wäre ein Link sehr nett. Es geht nicht nur darum, dass das System linear skaliert, sondern auch wie stabil das Ganze über eine große Anzahl von Threads gehalten werden kann. Wie du auf den beiden Bildern oben sehen kannst bricht FreeBSD bei 14/15 Threads ein. Jetzt vergleich das nochmal mit den Linuxwerten. Vom Peak 9000 bei 16 Threads (daran erkannt man auch, dass es sich um eine 16CPU Maschine handelt) bis zu 7660 bei 256 Threads bricht die Kurve nur leicht ein.
"Der gute Nehalem hat damit nicht viel zu tun."
Ich meinte damit lediglich, dass es bald native 8-Cores geben wird.
"Sorry sniket, ließ dich erstmal ins Thema ein, bevor du hier trollst"
Netter Versuch :-)
Ich bin ja auch ein großer FreeBSD-Freund, aber wir sollten hier bitte bei der Wahrheit bleiben.
Zuletzt bearbeitet:
Nun, das ist wohl auch das Problem, woran die ganze Geschichte bei heutigen Computerarchitekturen scheitern wird. AMD redete schon von 12-Kern CPUs, dann könnte ein normales Board mit vier Sockeln also 12 * 4 = 48 CPUs besitzen. Aber ob man so ein Monster schon von der Hardwareseite so konstruiert bekommt, dass es bezahlbar ist, kompatibel zu seinen Vorgängern und vergleichsweise stromsparend , ist zumindest aus heutiger Sicht zweifelhaft.
Nun, gut und schön, aber auch auf größeren Maschinen klappt er bei 8 Threads weg: http://people.freebsd.org/~kris/scaling/mysql-16cpu.png Hier hat die zu obrigen Grafiken vergleichbare Linie auch irgendwo zwischen 8 und 10 den Knicks. Postgresql sieht dort nicht wesentlich anders aus, erst Äderungen am Kernel (hier der Topologie-Patch) ändern das Verhalten: http://people.freebsd.org/~kris/scaling/pgsql-16cpu-2.png
Ich weiß, was unter FreeBSD auch immer ein wenig weh tat.
OK, dann habe ich das falsch verstanden.
Hmm... so direkt nicht. Seitens FreeBSD gab es seitdem am System auch keine Änderung, die wirklich drastische Auswirkungen zeigen dürfte. Das einzige wäre der lockmgr(), welcher allerdings nur größer ins Spiel kommt, wenn das VFS wirklich arbeiten muss. Bei diesen klassischen Benchmarks zum Threading ist da ja nur sekundär.
Ja, das stimmt schon. Und dort ist FreeBSD noch Linux unterlegen, was sich mit 8.0 aber sicher ändern dürfte. Allerdings ist das ganze meiner bescheidenen Meinung nach auch nur Esoterik, denn bevor ich eine Maschine hinstelle, die schlecht skaliert und mir mit weiteren CPUs nicht mehr die entsprechende Mehrleistung bringt, nehme ich lieber zwei kleinere Systeme und passe die Anlage halt entsprechend an.
Naja, ich weiß schon, wieso ich bei wirklich großen Installationen MySQL aus dem Weg gehe. Das Ding ist bekanntlich eher für kleinere Dinge geeignet. Aber der Einbruch liegt meiner Erfahrung nach nicht bei 8 Threads, sondern viel höher. So ein MySQL 5.0.x und neuer rennt bis etwa 30 bis 35 Threads schon noch fast linear, wenn Workload und die zugrunde liegende Maschine es hergeben. Allerdings beziehen sich dieser Erfahrungen auf UltraSPARC T1 und T2, deshalb sind sie mit "normalen" x86-CPUs vielleicht nicht unbedingt zu vergleichen
Wahrheit, Lüge... Das sind dehnbare Begriffe. Sowohl Linux als auch FreeBSD haben ihre Macken, aber hier wollen wir uns doch nicht schlechter machen, als wir sind. Oder?
Für den Troll muss mich wohl entschuldigen :/
Daemotron
Well-Known Member
Jein. Sun skaliert sogar bis 128 CPU-Kernen, allerdings ab ~64 aufwärts nicht mehr linear. Jedoch gilt das nicht für die Mini-Dinger mit Opteron, und auch nicht für die mittelkleinen Sparc-Systeme, sondern nur für die ganz großen (z. B. E10k und neuer). In den großen Kisten arbeitet Sun auch mit verteilten Speicherbänken; die Sub-Boards stecken in einer Backpane. Hat ein bisschen was von einem Blade-System, nur dass die Boards eben nur CPU und RAM integrieren. Der Rest läuft über die Backpane, womit nur für I/O (Netzwerk und Festspeicher) der Flaschenhals besteht.
Hi Yamagi!
Ja da gebe ich dir vollkommen recht. Im Grunde sind das ja Alles nur Momentaufnahmen. Sowohl FreeBSD als auch Linux entwickeln sich ständig weiter.
Kein Problem. Es ist einfacher weiter draufzukloppen, als zuzugeben das man daneben mal lag :-)
Bei welchen Benchmarks? Das muss man ja immer dazusagen. Ein Kompiliervorgang stellt andere Ansprüche an das System als eine Datenbank oder ein Webserver.
Ja da gebe ich dir vollkommen recht. Im Grunde sind das ja Alles nur Momentaufnahmen. Sowohl FreeBSD als auch Linux entwickeln sich ständig weiter.
Kein Problem. Es ist einfacher weiter draufzukloppen, als zuzugeben das man daneben mal lag :-)
Bei welchen Benchmarks? Das muss man ja immer dazusagen. Ein Kompiliervorgang stellt andere Ansprüche an das System als eine Datenbank oder ein Webserver.
Daemotron
Well-Known Member
Kein Benchmark, nur "Real Life". Ich hatte auf solchen Kisten bisher nur mit Datenbanken (Oracle) zu tun. Darin sind die Kisten wirklich gut; aber wenn's eher um CPU-Leistung (i. e. "Numbercrunching") als um Durchsatz geht, schaut man sich besser nach anderen Systemen um (z. B. IBM Regatta oder irgendwas auf Itanium-Basis).sniket schrieb:
Zuletzt bearbeitet:
M
meyert
Guest
Ja, in der Tat: Linux kann bald 4096 CPUs!
Siehe auch:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=shortlog;h=cpus4096
Siehe auch:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=shortlog;h=cpus4096
Endorphine
Well-Known Member
Was hilft mir das, wenn ich gar kein Linux haben will?
zyon
Rule Zero
Bei OpenBSD kommt es aber auch auf die Plattform an. Bei SPARC schauts da schon besser aus: OpenBSD on the UltraSPARC T1
Endorphine
Well-Known Member
In dem Thread wird Yamagis Meinung nur noch bestätigt. Multihreading skaliert bei OpenBSD lt. dem Thread gar nicht mit SMP. Nur Multitasking kann profitieren, aber dank Giant Lock ist die Frage, ob dabei bei so vielen CPUs noch ein Mehrdurchsatz ggü. 2 CPUs bei herauskommt. Genau diese harte Arbeit der SMP-Unterstützung hat FreeBSD seit 2002 (5.x) bereits hinter sich. Und wenn man sieht, welche Schmerzen das erzeugt hat (DragonFly-Abspaltung anfangs, suboptimale FreeBSD-5 Reihe, nur stabilisierte FreeBSD-6 Reihe) liegt da noch ein weiter Weg vor OpenBSD, bis die zusätzlichen Prozessoren nicht nur im dmesg angezeigt werden, sondern auch mehr Durchsatz oder sogar mehr Leistung bringen.
Die Frage ist doch, ob OpenBSD überhaupt bereit wäre den Weg so radikal zu gehen wie FreeBSD. GIANT zu ersetzen war bisher alles andere als schön, hat das ganze System destabilisiert, einige Bereiche (USB, TTY) sind nach wie vor kaputt. Mit dem Erscheinen von 7.0 machten wohl viele mehr als sieben Kreuze, das es endlich zum großen Teil durchgestanden ist. Mit 8.0 wird SMPng dann wohl seinen Abschluss finden, fast 10 Jahre nach seinem Start.
Das ganze Projekt war von Anfang an versaut. Die Übernahme von BSDi und damit das Ende von Wallnut Creek Software, den Verlust von David Greenman als Projektleiter direkt in der kritischen Phase, das Ausscheiden von Jordan K. Hubbard und jetzt Absehbar das Ende von Yahoo, welches FreeBSD zu SMPng gedrängt hat und als revanche Hardware, Entwickler und Anbindung im unaufrechenbaren Gegenwert gesponsert hat.
Ich bin nach wie vor einer der großen Verfechter von SMPng, immer noch denke ich, dass es FreeBSD nicht in seiner heutigen größe geben würde und die meisten von uns längst bei Linux wären, wenn man diesen Schritt nicht gegangen wäre. FreeBSD wäre einfach nicht performant genug, hätte viele Neuerungen im weitren Rahmen des SMPng nie bekommen, welche es heute aus der Masse hervorheben lassen. Man denke nur an GEOM. Aber wenn man wieder am 15. Juni 2000 in Sunnyvalle zusammen sitzen würde, würde man sicher stundenlang diskutieren, ob man SMPng noch einmal machen würde. Vermutlich ja, aber anders. Nicht so blauäugig. Perforce von Anfang an, andere Strukturen im Projekt, viel breitere Aufgabenteilung.
Genau das liegt das Problem. Wenn OpenBSD den Weg gehen will, können sie viel von FreeBSD lernen. Aber unsere Fehler nicht zu wiederholen bedeutet sich zu ändern. Das Projekt umstrukturieren, Schwerpunkte verlagern, neue Arbeitsweisen einführen. Man muss jede Zeile Kernelcode anfassen, man wird Bugs einbauen, die seit Jahren als erledigt galten. Man wird ganz neue Probleme bekommen, wie Race Conditions, Deadlocks und so weiter. Wäre OpenBSD bereit die damit einhergehende Destabilisierung zu akzeptieren? Würde man wirklich viele Arbeiten der letzten Jahre über den Haufen werfen wollen? Ich denke, nein. Es wäre einfach gegen OpenBSDs Stil. Die Frage der nötigen Manpower stellen wir hier erst gar nicht. Wenn ich OpenBSd wäre, würde ich nicht SMPng implementieren. Ich würde den GIANT-Lock aufweichen, schauen, wie ich ihn möglichst wenig invasiv zerteilen kann, so besser Skalieren und dabei die Stabilität möglichst wenig zu gefärden.
Das ganze Projekt war von Anfang an versaut. Die Übernahme von BSDi und damit das Ende von Wallnut Creek Software, den Verlust von David Greenman als Projektleiter direkt in der kritischen Phase, das Ausscheiden von Jordan K. Hubbard und jetzt Absehbar das Ende von Yahoo, welches FreeBSD zu SMPng gedrängt hat und als revanche Hardware, Entwickler und Anbindung im unaufrechenbaren Gegenwert gesponsert hat.
Ich bin nach wie vor einer der großen Verfechter von SMPng, immer noch denke ich, dass es FreeBSD nicht in seiner heutigen größe geben würde und die meisten von uns längst bei Linux wären, wenn man diesen Schritt nicht gegangen wäre. FreeBSD wäre einfach nicht performant genug, hätte viele Neuerungen im weitren Rahmen des SMPng nie bekommen, welche es heute aus der Masse hervorheben lassen. Man denke nur an GEOM. Aber wenn man wieder am 15. Juni 2000 in Sunnyvalle zusammen sitzen würde, würde man sicher stundenlang diskutieren, ob man SMPng noch einmal machen würde. Vermutlich ja, aber anders. Nicht so blauäugig. Perforce von Anfang an, andere Strukturen im Projekt, viel breitere Aufgabenteilung.
Genau das liegt das Problem. Wenn OpenBSD den Weg gehen will, können sie viel von FreeBSD lernen. Aber unsere Fehler nicht zu wiederholen bedeutet sich zu ändern. Das Projekt umstrukturieren, Schwerpunkte verlagern, neue Arbeitsweisen einführen. Man muss jede Zeile Kernelcode anfassen, man wird Bugs einbauen, die seit Jahren als erledigt galten. Man wird ganz neue Probleme bekommen, wie Race Conditions, Deadlocks und so weiter. Wäre OpenBSD bereit die damit einhergehende Destabilisierung zu akzeptieren? Würde man wirklich viele Arbeiten der letzten Jahre über den Haufen werfen wollen? Ich denke, nein. Es wäre einfach gegen OpenBSDs Stil. Die Frage der nötigen Manpower stellen wir hier erst gar nicht. Wenn ich OpenBSd wäre, würde ich nicht SMPng implementieren. Ich würde den GIANT-Lock aufweichen, schauen, wie ich ihn möglichst wenig invasiv zerteilen kann, so besser Skalieren und dabei die Stabilität möglichst wenig zu gefärden.
Zum Thema Solaris und Skalierung auf 64 CPUs. Habe letzt Benchmarks von einer Dual-T2 gesehen, sprich 16 Kerne, 128 Threads. Fast lineare Skalierung! Da man bei Sun ja außerdem an noch größeren Thread-Monstern arbeitet wird da wohl auch noch weiter dran gedreht werden.
Was Yamagis Zahlen zu OS X angeht stimmt es natürlich schon, dass OS X bei 8 Kernen nichtmehr toll skaliert aber Yamagis anandtech Artikel ist von 2005. Da war afaik OS 10.3 aktuell. Seitdem hat sich durchaus etwas getan. Ich kann das zwar auf die schnelle nicht Benchen da ich keinen Mac Pro besitze aber nachdem ich letzthin an einem mit Photoshop und InDesign gearbeitet habe kann ich durchaus sagen dass das deutlich flotter von statten ging als mit meinem Macbook.
Was Yamagis Zahlen zu OS X angeht stimmt es natürlich schon, dass OS X bei 8 Kernen nichtmehr toll skaliert aber Yamagis anandtech Artikel ist von 2005. Da war afaik OS 10.3 aktuell. Seitdem hat sich durchaus etwas getan. Ich kann das zwar auf die schnelle nicht Benchen da ich keinen Mac Pro besitze aber nachdem ich letzthin an einem mit Photoshop und InDesign gearbeitet habe kann ich durchaus sagen dass das deutlich flotter von statten ging als mit meinem Macbook.