FreeBSD 'langsamer' als NetBSD? (slashdot)

T

TobiasM

Active Member
Servus.

Auch wenn die meisten hier mit /. wahrscheinlich nicht viel anfangen können (*), finde ich folgenden Kommentar trotzdem erwähnenswert:

http://bsd.slashdot.org/comments.pl?sid=128776&cid=10745990

Ich habe natürlich vollstes Vertrauen in euch, aus diesem Thema *keinen* Flamewar zu machen *g*. Sonst hätte ich das ja auch gleich auf heise posten können..

Eure persönlichen Erfahrungen würden mich dazu interessieren - falls jemand technische Erklärungen parat hat, wäre das natürlich noch besser. Hat FreeBSD möglicherweise ein (Software-)Design-Problem? Die Entstehung von DragonFlyBSD wurde in diesem Zusammenhang auch genannt - ich habe das zwar ein wenig mitverfolgt, hatte aber nur in Erinnerung, dass dem entsprechenden Entwickler die Zahl der neuen Features für 5.x zu hoch war.

Falls NetBSD tatsächlich flotter arbeiten sollte (bei gleicher Stabilität), würde ich eben daraus ableiten, dass das FreeBSD Team vielleicht ein paar konzeptionelle Fehler gemacht hat.

Ciao, Tobias


(*) Ich bin auch nur durch Zufall auf die Seite gekommen. Ehrlich. (Wo ist der Smiley mit dem Heiligenschein?) :D
 
Inwiefern ist der NetBSD-Kernel präemptiv? Durch das "fine-grained" locking in FreeBSD 5.x wird verdammt viel CPU mit sinnlosem locking verbraten. Wuerde mich nicht wundern, wenn NetBSD mit einem nicht-praemptiven Kernel und einem Scheduler, der unnoetige Context-Switches vermeidet, besser abschneidet als FreeBSD.

Matt Dillion hat genau wegen dem Mutex-Locking 5.x verlassen und bastelt auf der 4er Reihe einen Threaded Kernel (LWKT). Ich bin mir ziemlich sicher, dass dies fuer SMP mit mehr als 4 CPUs oder fuer ASMP-Systeme den 5er Kernel weit hinter sich lassen wird.

Aber da musst du echte Kernel Hacker fragen.... und die sind hier im Board recht spaerlich vertreten :(
 
Effizienz ist ein Qualitätskriterium und kein konzeptioneller Fehler. Zuerst kommt der Funktionsumfang, die Fehlerrate und die Stabilität. Am Ende kann man jeweils optimieren. Bei einem sauber gestalteten System (wovon ich übrigens bei NetBSD wegen der Portabilität ausgehe, falls Portabilität SO umgesetzt wurde wie ich mir es vorstelle), kann man super optimieren. FreeBSD ist aber auch ein konzeptionell gut aufgebautes System. Fehler in der Programmierung von Komponenten müssen keine Konzeptfehler sein und sind es eher selten.

NetBSD kann evtl schneller sein. Linux und MS-Windows sind wahrscheinlich sogar noch schneller. Mich interessiert die Effizienz aber nicht. Es soll erst mal stabil sein und d.h. so gebaut, dass ich im Notfall manuell eingreifen kann.

Du siehst, jeder hat so seine Präferenzen.
 
Mir fehlt der direkte Vergleich. Aber Stabilität ist ja wohl das Thema von NetBSD. Rein subjektiv habe ich immer das Gefühl, daß das Teil (1.6.2) selbst auf den gammligsten Kisten abgeht wie der sprichwörtliche Nachbars Lumpi.

Grundsätzlich würde ich sagen, ein sauberes, klares Design (wie bei NetBSD) bringt auch Vorteile bei der Performance. FreeBSD kann ich - wie gesagt - (noch) nicht beurteilen.
 
Auch wenn ich irgendwann gefragt werde, ob ich noch was anderes zu erzählen habe (und der Artikel sich auf NetBSD 2.0 bezieht, ich aber bis morgen ausschließliche 1.6.2 laufen habe):
Mit der wichtigste Grund für den Komplett-Umstieg auf NetBSD auf meinen brauchbaren Computern ist das Gefühl, daß das System unglaublich viel gleichzeitig machen kann. Es hat echten Seltenheitswert, wenn bei mehreren rechenintensiven Anwendungen gleichzeitig irgendwann mal z.B. der Sound kurz aussetzt. Außer mit BeOS habe ich noch nie mit einem so verdammt schnellen System gearbeitet. Die Ausführung kommt sofort nach dem Befehl, egal was sonst noch läuft. Auch Gentoo konnte hier nicht mithalten, SuSE erst recht nicht. Von WinXP ganz zu schweigen.
Ich habe keinen Benchmark gemacht, es ist Gefühlssache. Aber FreeBSD kam mir nie ganz so flott vor.

Wenn man den Artikel liest, freu ich mich gleich noch mehr auf 2.0...
 
MrFixit schrieb:
Inwiefern ist der NetBSD-Kernel präemptiv? Durch das "fine-grained" locking in FreeBSD 5.x wird verdammt viel CPU mit sinnlosem locking verbraten. Wuerde mich nicht wundern, wenn NetBSD mit einem nicht-praemptiven Kernel und einem Scheduler, der unnoetige Context-Switches vermeidet, besser abschneidet als FreeBSD.
Zum Vergrößern anklicken....

sorry, aber alles käse. kein bock das hier zu begründen, aber vielleicht solltest du dich erstmal mal schlau machen, was begriffe wie context-switches, preemptive, locking und fine-grained bedeuten. :ugly:
 
Maledictus schrieb:
sorry, aber alles käse. kein bock das hier zu begründen, aber vielleicht solltest du dich erstmal mal schlau machen, was begriffe wie context-switches, preemptive, locking und fine-grained bedeuten. :ugly:
Zum Vergrößern anklicken....
Durchaus nicht alles Käse, und auch keine nette Art zu antworten.

1. "Durch das "fine-grained" locking in FreeBSD 5.x wird verdammt viel CPU mit sinnlosem locking verbraten."

Ohne das "sinnlose" macht dieser Satz durchaus Sinn - Locking kostet einfach Prozessorzyklen.

2. "Wuerde mich nicht wundern, wenn NetBSD mit einem nicht-praemptiven Kernel und einem Scheduler, der unnoetige Context-Switches vermeidet, besser abschneidet als FreeBSD."

Auch diese Aussage ist doch durchaus nachzuvollziehen - ein preemptiver Kernel hat vielleicht eine bessere Latenz, aber nicht notwendigerweise einen höheren Durchsatz. Wobei der Scheduler und die Präemption erstmal nichts miteinander zu tun haben. Vielleicht meint der Mr. auch den ULE-Scheduler, der dafür bekannt ist (war?) mehr Context-Switches durchzuführen als der 4BSD-Scheduler.

Vielleicht machst du dir doch einmal die Mühe uns zu sagen, wo deiner Meinung nach der Käse steckt?
 
Vor lauter "mutex", "struct ucred" undsoweiterundsofort blicke ich da auch nicht durch und kann auch nur in einer trüben Suppe stochern (wie Mr. Fixit schon sagte, es Kernel Hacker könnte das wohl "eben mal" erklären).
 
Da schreibt jemand auf Slashdot einen post, indem er ohne jeglichen Anschein eines Beweises, Benchmarks, whatever behauptet, daß NetBSD RC4 "schneller" sei als FreeBSD. Daraufhin entsteht hier eine wertfreie Diskussion um hypothetische Einflüsse unterschiedlicher Architekturen auf die Performance irgendwelcher BSD-Derivate, die keiner durch irgend etwas belegen/verifizieren kann. Bevor ihr hier alle Euch noch weiter in eurer Subjektivität ergeht, um Objektivität zu erreichen (sic!), wäre es vielleicht opportuner, wenn:

1. Man das Erscheinen von NetBSD 2.0 Release abwartet
2. Mann auf exakt der gleichen Maschine sowohl FreeBSD 5.3 als auch NetBSD 2.0 installiert.
3. Man exakt die gleichen Applikationen/whatever testet.
4. Die Ergebnisse und die Ausgangssituation genau dokumentiert.
5. Diese hier veröffentlicht.
6. Die Diskussion dann weiterführt.
7. Versucht die dabei auftretenden Unterschiede rational zu begründen.
8. Eine Güterabwägung durchführt und die Unterschiede in einem Gesamtkontext betrachtet. Das fine-grained Locking in FreeBSD ist vielleicht nicht grundlos eingeführt worden.

Ich nehme jetzt mal nur eine Aussage stellvertretend aus diesem thread heraus (no offense meant!): " ist das Gefühl, daß das System unglaublich viel gleichzeitig machen kann". Ich finde es sehr schön, wenn Leute Ihre subjektiven Gefühle für irgendwas ausdrücken, das mache ich bei Liebeserklärungen an meine Frau auch, aber mit Objektivität hat das rein gar nichts zu tun. Dieses Strickmuster an Diskussion finden wir bei esoterischen compilerflags in gentoo, Fefe's "benchmark" usw. immer wieder, das Ergebnis ist jedesmal das Gleiche. Ich konstatiere also eine Absenz von Erkentnisgewinn in all diesen Fällen.

Ich will hier niemand die Diskussion vermiesen, schliesslich sind die wahrhaftig nutzlosen Dispute diejenigen, die Spass machen, ich wollte es nur mal angemerkt haben...
 
Moin.

Daniel Seuffert schrieb:
Da schreibt jemand auf Slashdot einen post, indem er ohne jeglichen Anschein eines Beweises, Benchmarks, whatever behauptet, daß NetBSD RC4 "schneller" sei als FreeBSD. Daraufhin entsteht hier eine wertfreie Diskussion um hypothetische Einflüsse unterschiedlicher Architekturen auf die Performance irgendwelcher BSD-Derivate, die keiner durch irgend etwas belegen/verifizieren kann. Bevor ihr hier alle Euch noch weiter in eurer Subjektivität ergeht, um Objektivität zu erreichen (sic!),
[...]
Zum Vergrößern anklicken....

Warum soll man darüber nicht diskutieren? Aber gut, wohin ging denn die Diskussion eben?
Mr.Fixit vermutet etwas, Male "haut dagegen" und meint das es so nicht stimmt er aber gerad keine Lust hat es rauszusuchen, current erwidert darauf das das gesagte von Mr.Fixit nicht so falsch ist wie dargestellt. Ich für meinen Teil versuche mich eben schlau zu machen über mutex, locks und bla.
Soll einerseits heissen die Diskussion entwickelt sich eben erst, zum anderen abwarten was Male noch zu schreiben hat.
 
NetBSD 1.6.2 ist schon super schnell gegenüber meinem gestesteten Open- und FreeBSD (selbe Maschine). Ich habe leider keine Messdaten vorliegen aber den Geschwindigkeitsunterschied der OSe habe ich auf jeden Fall bemerkt. Ich bin sehr gespannt auf NetBSD 2.0. ;)
FreeBSD 5.x hat extrem viel overhead (ist aber auch gerechtfertigt) im Code der natührlich das System nicht gerade performanter macht.

Als Server-OS kann sich NetBSD durchaus sehen lassen.
 
Maledictus schrieb:
sorry, aber alles käse. kein bock das hier zu begründen, aber vielleicht solltest du dich erstmal mal schlau machen, was begriffe wie context-switches, preemptive, locking und fine-grained bedeuten.
Zum Vergrößern anklicken....

Irgendwie bist du jetzt derjenige, der dumm dasteht. Und nein, ich hab keinen Bock das zu begruenden...

:huth:
 
Kann man denn das fine-grained locking abstellen? Ursprünglich ist es doch für SMPng konzipiert und bringt auf einem UP nichts als overhead (oder??).
 
@Daniel Seuffert: Ich bin durchaus an subjektiven Eindrücken interessiert! Dass man darauf keine alles-erschlagende Diskussion zum Thema Geschwindigkeit aufbauen kann, ist klar, aber Benchmarks sind auch nicht der Weisheit letzter Schluss.

Ansonsten bezog sich der Kommentar auf slashdot auf NetBSD 2.0RC4, was schon existiert. Der Schreiber hat zwar keine Benchmarks angehängt, aber auf z.B. bonnie verwiesen - er war also anscheinend wenigstens davon überzeugt, dass jeder, der selbst solche Benchmarks durchführt, ähnliche Ergebnisse erzielen würde.

Da ich das ganze weder bestätigen, noch widerlegen kann, habe ich eben hier den Thread eröffnet. Macht das ganze jetzt mehr Sinn für Dich? :)

@Nakal: Ich hatte die Stabilität von NetBSD einfach mal vorausgesetzt. Wenn so ein System unter Last total einbricht oder gar abstürzt, ist es natürlich außer Konkurrenz - bei NetBSD scheint mir das aber weniger der Fall zu sein.

Vielleicht habe ich auch den Begriff des Konzepts in einer etwas zu schwammigen Form benutzt - ich meine grundlegende design-technische Entscheidungen, weniger die konkrete Implementierung. Solche Begriffe wie "fine-grained locking" würde ich (es ist zugebenermaßen ein wenig geraten) dazu zählen.

@MrFixit und Maledictus: Nanana, ihr werdet doch jetzt wohl nicht mit Hüt(h)en und Beleidungen um euch werfen :D

Ciao, Tobias
 
current schrieb:
Durchaus nicht alles Käse, und auch keine nette Art zu antworten.

1. "Durch das "fine-grained" locking in FreeBSD 5.x wird verdammt viel CPU mit sinnlosem locking verbraten."

Ohne das "sinnlose" macht dieser Satz durchaus Sinn - Locking kostet einfach Prozessorzyklen.
Zum Vergrößern anklicken....

Das "sinnlos" stört mich auch gewaltig, wenn es so sinnlos wäre, dann würde man es ja nicht machen.
Ich habs mir bei NetBSD nicht durchgelesen (von OpenBSD weiss ich es), dass die wahrscheinlich BigLock verwenden. Das macht FreeBSD seit 3.0 und versucht "Giant-Lock" seit 5.0 loszuwerden. Eine Technik die von BSD/OS kommt und dort schon gezeigt hat, dass sie wesentlich skalierfähiger ist als BigLock. Also nicht sinnlos das ganze!

2. "Wuerde mich nicht wundern, wenn NetBSD mit einem nicht-praemptiven Kernel und einem Scheduler, der unnoetige Context-Switches vermeidet, besser abschneidet als FreeBSD."

Auch diese Aussage ist doch durchaus nachzuvollziehen - ein preemptiver Kernel hat vielleicht eine bessere Latenz, aber nicht notwendigerweise einen höheren Durchsatz. Wobei der Scheduler und die Präemption erstmal nichts miteinander zu tun haben. Vielleicht meint der Mr. auch den ULE-Scheduler, der dafür bekannt ist (war?) mehr Context-Switches durchzuführen als der 4BSD-Scheduler.
Zum Vergrößern anklicken....
Reden wir hier von unterschiedlichen preemptives?
Ich meine das hier:
http://en.wikipedia.org/wiki/Pre-emptive_multitasking

Und das ist jeder BSD Kernel.

Kann sein, dass ich mich bei Context-switches irre, aber sie treten in folgenden Situationen auf:
- System call
- Hardware Interrupt (z.B. Netzwerkkarte)
- HZ mal pro Sekunde (eigentlich auch nen Hardware Interrupt)

Wo bitte ist da Spiel für mehr oder weniger? (Von Polling mal abgesehen, was FreeBSD sehr gut unterstützt) Ist ne echte Frage, würde mich wirklich interessieren, kann ja sein, dass ich da was verpasst habe unter meinem Stein :)

@MrFixit und Maledictus: Nanana, ihr werdet doch jetzt wohl nicht mit Hüt(h)en und Beleidungen um euch werfen
Zum Vergrößern anklicken....
Nun, ich habe MrFixit bewusst keinen Huth gegeben. Und wenn er meint, nur weil er ein bischen Rückendeckung von current bekommt, damit um sich werfen zu können ist das sein Problem. Er bekommt auch jetzt bewusst wieder keinen Huth von mir.
;)
 
Maledictus schrieb:
Reden wir hier von unterschiedlichen preemptives?
Ich meine das hier:
http://en.wikipedia.org/wiki/Pre-emptive_multitasking
Zum Vergrößern anklicken....
Ja, reden wir. Ein präemptiver Kernel macht das, was dort für das Userland beschrieben ist, auch für Kernelthreads. Und das ist weitaus komplizierter.

Maledictus schrieb:
- System call
- Hardware Interrupt (z.B. Netzwerkkarte)
- HZ mal pro Sekunde (eigentlich auch nen Hardware Interrupt)
Zum Vergrößern anklicken....
Vorsicht, nicht das du den Wechsel von User- in Kernelmode und zurück mit einem Contextswitch verwechselst. Ersterer ist relativ billig, da von der CPU direkt unterstützt (typischerweise verschiedene CPU levels). Unter einem Contextswitch wird normalerweise der Wechsel zwischen zwei Prozessen gesprochen, dazu müssen alle CPU Register gedumpt/geladen werden, der Stack geswitcht, MMU page tables gewechselt werden, CPU caches geflusht werden und so weiter. Das ist richtig teuer und liegt natürlich voll unter der Kontrolle des Schedulers.

Das erklärt auch, warum auf Interaktivität getrimmte Scheduler wie ULE häufig mehr Contextswitches machen als eben 4BSD.
 
current schrieb:
Ja, reden wir. Ein präemptiver Kernel macht das, was dort für das Userland beschrieben ist, auch für Kernelthreads. Und das ist weitaus komplizierter.
Zum Vergrößern anklicken....
afaik hat keines der BSDs bisher Kernelthreads. Auch hier besteht wieder Verwechslungsgefahr. Oft wird der Begriff Kernelthread als Gegenbegriff zu Threadunterstützung im Userland benutzt, aber ich glaube das meinen wir hier nicht, oder doch?

Vorsicht, nicht das du den Wechsel von User- in Kernelmode und zurück mit einem Contextswitch verwechselst. Ersterer ist relativ billig, da von der CPU direkt unterstützt (typischerweise verschiedene CPU levels). Unter einem Contextswitch wird normalerweise der Wechsel zwischen zwei Prozessen gesprochen, dazu müssen alle CPU Register gedumpt/geladen werden, der Stack geswitcht, MMU page tables gewechselt werden, CPU caches geflusht werden und so weiter. Das ist richtig teuer und liegt natürlich voll unter der Kontrolle des Schedulers.

Das erklärt auch, warum auf Interaktivität getrimmte Scheduler wie ULE häufig mehr Contextswitches machen als eben 4BSD.
Zum Vergrößern anklicken....
naja, es ist doch oft so, dass ein Systemcall nicht sofort zurückkommt, und deshalb erstmal der nächste lauffähige Prozess genommen wird, was dann wieder einen Contextswitch nach sich zieht. Aber du hast recht, nicht jeder Systemcall zieht einen Contextswitch nach sich, ABER es war ja auch nur eine Auflistung der Möglichkeiten für einen solchen.
 
Maledictus schrieb:
afaik hat keines der BSDs bisher Kernelthreads. Auch hier besteht wieder Verwechslungsgefahr. Oft wird der Begriff Kernelthread als Gegenbegriff zu Threadunterstützung im Userland benutzt, aber ich glaube das meinen wir hier nicht, oder doch?
Zum Vergrößern anklicken....
Dann knowst du not far enough, vielleicht führst du dir auf FreeBSD 5.x einfach mal 'man 9 kthread' und 'man 2 kse' zu Gemüte, dann wüsstest du, dass FreeBSD 5 sowohl echte Kernelthreads als auch Scheduler-Unterstützung für Userland Threads hat. Weiterhin würde dich 'man 3 pthread' darüber aufklären, dass es im Userland insgesamt drei Threadingmodelle gibt, neben dem alten libc_r Modell ein 1:1 (libthr) Modell und ein 1:n Modell (libpthread).
 
Ich sollte vielleicht noch das "sinnlos" erlaeutern, da es anscheinend einige Leute nicht verstehen:

Sinnlos ist alles was das OS tut, nur um es zu tun. Mit Context-Switches wird keine Arbeit verrichtet. Ein LOCK/UNLOCK Zyklus bearbeitet meine Workload um keine einzige Instruktion weiter. Wenn jede dritte Operation eine LOCK/UNLOCK ist, dann verbraet das System 33% Rechenkapazitaet sinnlos.

Natuerlich werden die Locks bei diesem System gebraucht um die Konsistenz zu wahren, aber es geht auch anders. Aber wir sollten vielleicht erstmal ueberlegen, ob wir auf guten Durchsatz oder niedrige Latenz aus sind. Oder ob wir den Mittelweg gehen wollen, bevor hier mit Halbwahrheiten und falschen Bezeichnungen um sich geworfen wird.
 
Also ich hab von kernel sachen nicht wirklich den plan, deshalb sag ich zu dem thema nix.

Aber ich hatte längere zeit auf meinem schwachem Gericom Laptop Windows 2000 Professionel drauf. DivX, XVid filmchen wurden egal mit welchem player nicht flüssig abgespielt. Auch ein umstieg auf Windows XP änderte daran nix.
Habe beide Windows systeme auch bis aufs letzte optimiert was nur geht.

Seit nem halben jahr hab ich nur noch FreeBSD drauf, angefangen mit 5.2.1 und jetzt bei 5.3. DivX, XVid filmchen ruckeln nicht mehr und so läuft alles besser :)
Unterstützung für nen zweiten Monitor oder beamer funzt auch besser unter BSD.

Was aber unter windows um einiges besser lief und vor allem flüssig waren so sachen wie: Quake 3, Visual Boy Advance, N64 Emu usw.

Unter BSD läuft Quake3 nur noch im Standbilder modus, VBA läuft leider auch viel viel langsamer, komme nicht auf 100%, max. 90% speed so trotz Framedrop und Sound stockt auch.

Noch dazu muss ich sagen, ich bin noch absoluter noob in BSD und habe nicht wirklich den Plan wie ich sachen optimieren kann.

Aber ich finde BSD was multimedia und netzwerk angeht ist es ein ganzes stück schneller als Windoof.
 
Geschwindigkeit-3d-Spiele

Also ich weiss ja nicht, was Du auf Deinem Gericom Notebook fuer einen Grafikchip drauf hast, aber wenn es einer von Nvidia ist, solltest Du auf jeden Fall dafuer sorgen, dass nicht der BSD-eigene AGP-Gart-Treiber geladen wird, sondern der von Nvidia. Das bringt einen erheblichen Performance-Schub!
Wenn du das gemacht hast, poste noch mal und berichte. :rolleyes:
 
@Finalspace: Subjektiv gesehen erscheinen Windows und Linux in einigen Situationen einfacher schneller. Zum Beispiel bei (in der Praxis unter BSD meist nicht durchgeführten) Spiele wie Quake3 oder auch bei Audiobearbeitung. Oft liegt dies aber gerade unter Windows an einer bedeutend besseren Unterstüzung der Hardware.
 
Genauso seh ich das auch so OOZE.
Die Hardware unterstützung ist bei BSD leider bei weitem nicht so ausgereift wie unter Windows.

Achja, und ich hab kein nvidia chip in meinem gericom notebook.
SiS 630 auf shared memory und 1100 MHz P3 :p
 
also die aussage das die hardware unterstüzung bei win besser ist als bei freebsd bezeichne ich hier mal als falsch, das alle grafickarten, billg drucker, winmodems usw rennen, hat imho nichts mit fbsd zu tun. wenn die treiber closed source sind, keine chance....
naja wie dem auch sei, ich finde die Hardware die FreeBSD unterstützt funktioneieren zu 90% auch sehr gut, wer mehr will soll imho entweder selber aktiv werden, warten oder wechseln ;)

Gruss, Flas!!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben