Hi hatt hatt jemand schonmal das Hurd debian system ausprobiert?
wie siehts da aus mit der geschindigkeit ist der schneller oder langsamer als der linux Kernel?
hurd performance
hmm, hier hat das mal jemand probiert, weiß nicht mehr wer. die sache ist aber: das ding ist noch unter "heavy" development. ich glaube nicht, dass man da verlässliche angaben machen kann, zumal kaum "potente" hardware unterstützt wird.
warten wir also bis nächste woche, da wird hurd fertig...
warten wir also bis nächste woche, da wird hurd fertig...
"In den reichen Ländern hat die Freiheit gesiegt - mit all den schrecklichen Folgen, die das für die anderen mit sich bringt und noch bringen wird. Die Demokratie ist auf andere Epochen verschoben." (L. Canfora)
Nen bissel steht hier: http://www4.informatik.uni-erlangen.de/ ... kernel.pdfNatas12 hat geschrieben:doofe frage: warum sind mikrokernel langsamer? (nicht-informatiker, nicht hauen!)
cu
ah, das pdf und dein post haben einiges geklärt... 
gibt es eigentlich einen statusreport oder eine roadmap zu gnu/hurd? die offiziellen seiten schweigen sich ja aus oder man findet informationen von 2002...
gibt es eigentlich einen statusreport oder eine roadmap zu gnu/hurd? die offiziellen seiten schweigen sich ja aus oder man findet informationen von 2002...
"In den reichen Ländern hat die Freiheit gesiegt - mit all den schrecklichen Folgen, die das für die anderen mit sich bringt und noch bringen wird. Die Demokratie ist auf andere Epochen verschoben." (L. Canfora)
könnte man jetzt z.B defekte hardware ohne denn rechenr auszuschalten wechsel?
Soweit ich weiss nutzt macosX den mach3 microkernel und der ist ja laut der pdf der langsamste. warum ist macosX trotzdem recht schnell?
Für den Heimbereich ist der Hurd als nicht so optimal oder? Ich hab z.B lieber ein schnellen Linux und dafür einmal im Jahr ein Absturts
So und wenn ich schonmal dabei bin endlos Fragen in den Raum zu streuen:
wie siehts eigendlich mit Linux (ohne xserver) vs Windows aus ?
Soweit ich weiss nutzt macosX den mach3 microkernel und der ist ja laut der pdf der langsamste. warum ist macosX trotzdem recht schnell?
Für den Heimbereich ist der Hurd als nicht so optimal oder? Ich hab z.B lieber ein schnellen Linux und dafür einmal im Jahr ein Absturts
So und wenn ich schonmal dabei bin endlos Fragen in den Raum zu streuen:
wie siehts eigendlich mit Linux (ohne xserver) vs Windows aus
?
Welche Hardware willst du denn wechseln? Steckkarten, Ram, Prozessor etc wirst du wohl kaum wechseln können.ZzLeCzZ hat geschrieben:könnte man jetzt z.B defekte hardware ohne denn rechenr auszuschalten wechsel?
Ich glaube, daß die geschwindigkeitsunterschiede bei einer finalen version des Hurds keine große Rolle mehr spielen. Da haben wir wahscheinlich auch alle ein paar Terrahertz-RechnerZzLeCzZ hat geschrieben:Für den Heimbereich ist der Hurd als nicht so optimal oder? Ich hab z.B lieber ein schnellen Linux und dafür einmal im Jahr ein Absturts
Ich glaube nicht, daß man pauschal die Geshcwindigkeit angeben kann.ZzLeCzZ hat geschrieben:So und wenn ich schonmal dabei bin endlos Fragen in den Raum zu streuen:
wie siehts eigendlich mit Linux (ohne xserver) vs Windows aus
Außerdem spielen da auch die treiber eine Rolle, sprich manche hardware wird von linux nicht gut unterstützt und läuft deswegen langsamer. Die Konfiguration von Linux spielt da auch ne Rolle.
Nachdem zu Urteilen was ich bisher so gelesen habe, gelten Micro-Kernel deshalb als langsam, weil die meißten von ihnen aus monolithischen Kerneln entwickelt wurden. Diese Dinger waren/sind nicht so schnell und dann hat sich der Mythos des langsamen Micro-Kernels verbreitet.
Aber letztendlich hängt's wohl eher von der Implementation des Micro-/Mono-Kernels ab und davon wofür er benutzt werden soll. Interessantes dazu gibt es u.a. auf den Seiten von L4 bzw. Fiasco zu lesen.
Aber letztendlich hängt's wohl eher von der Implementation des Micro-/Mono-Kernels ab und davon wofür er benutzt werden soll. Interessantes dazu gibt es u.a. auf den Seiten von L4 bzw. Fiasco zu lesen.
Ist denke ich mal auch ein Architekturproblem. Um so mehr Abstraktionsschichten und Modularität eingebaut werden desto langsamer muß es nun mal weden. Sind gegensätzliche Ziele. Jedoch glaube ich, dass das von den immer schnelleren Geräten aufgefangen wird und sich irgendwann die Architekturvorteile mehr lohnen als die Geschwindigkeit. Ob das heute schon der Fall ist, ist eine andere Frage.DavidJ hat geschrieben:Nachdem zu Urteilen was ich bisher so gelesen habe, gelten Micro-Kernel deshalb als langsam, weil die meißten von ihnen aus monolithischen Kerneln entwickelt wurden.
cu
Jepp, hinzuzufügen wäre evtl. noch, dass man sich die Frage stellen kann, "langsamer worin?". Performance technisch gesehen ist ein monolithischer Kernel zumindest theoretisch schneller als ein Micro-Kernel, aber für z.B. ein Echtzeitsystem wäre ein monolithischer Kernel wiederum zu "langsam". Aber ich habe keine Ahnung worum es da dann im speziellen genau geht.
Muß mal wieder nen bissel klugscheißen:DavidJ hat geschrieben:aber für z.B. ein Echtzeitsystem wäre ein monolithischer Kernel wiederum zu "langsam".
Ein Echtzeitbs hat erst mal gar nichts mit Schnelligkeit zu tun. Ein Echtzeitbs ist daduch definiert das es garantierte Antwortzeiten liefern kann. Das heißt wenn von einem System gefordet wird das einmal am Tag von einer Wetterstation 3 Meßdaten entgegengenommen werden muss, kann das für unser Verständniss ein recht langsames System sein. Schwieriger wird es schon bei einem Banktransaktionssystem, welches auf viele gleichzeitige Anfragen innerhalb einer gewissen Zeit (meinetwegen 1ms) reagieren muß. Ein Echtzeitbs zeichnet aus, das man die Anzahl, für welche die Anwortzeiten garantiert werden kann, bestimmen kann, also das zum Beispiel für 10000 gleichzeitige Anfragen welche in einem Intervall von 1 Sekunde reinkommen eine Antwortzeit von 1ms garantiert werden kann.
cu
Dass es bei einem Echtzeitbetriebssystem theoretischnicht um Geschwindigkeit geht ist mir auch klar, nur ist das in der Realität aber dann meißt doch der Fall. Denn wie du in deinem Beispiel mit dem Banktransaktionssystem gezeigt hast, geht es eben meißt um die Sicherstellung von _sehr_ niedrigen Antwort-/Reaktionszeiten, was sich wieder in Geschwindigkeit niederschlägt.tylerD hat geschrieben:Muß mal wieder nen bissel klugscheißen:DavidJ hat geschrieben:aber für z.B. ein Echtzeitsystem wäre ein monolithischer Kernel wiederum zu "langsam".
Ein Echtzeitbs hat erst mal gar nichts mit Schnelligkeit zu tun. Ein Echtzeitbs ist daduch definiert das es garantierte Antwortzeiten liefern kann. Das heißt wenn von einem System gefordet wird das einmal am Tag von einer Wetterstation 3 Meßdaten entgegengenommen werden muss, kann das für unser Verständniss ein recht langsames System sein. Schwieriger wird es schon bei einem Banktransaktionssystem, welches auf viele gleichzeitige Anfragen innerhalb einer gewissen Zeit (meinetwegen 1ms) reagieren muß. Ein Echtzeitbs zeichnet aus, das man die Anzahl, für welche die Anwortzeiten garantiert werden kann, bestimmen kann, also das zum Beispiel für 10000 gleichzeitige Anfragen welche in einem Intervall von 1 Sekunde reinkommen eine Antwortzeit von 1ms garantiert werden kann.
cu
Nur braucht man eben, je nach Anforderungsprofil, verschiedene "Arten" von Geschwindigkeit. Bringt dir ja nix wenn dein System Antwortzeiten von bspw. max. 3 ms garantieren kann aber dafür die Performance als Fileserver schrottig ist und du gerade einen Fileserver damit betreiben möchtest. Womit wir eigentlich auch schon wieder beim Punkt der Implementierung sind: Ich habe schon von Entwicklungen gelesen, die die Anforderungen sowohl eines RTOS als auch eines "general computing OS" (angeblich) ohne Abstriche erfüllen.
Wobei ich dazu leider keine weitergehenden Infos habe. Aber über google läßt sich vielleicht was finden, wollte schon was raussuchen aber ohne genauen Suchbegriff wirst du nur mit unmegen an Links zugeschüttet.