Das kannst du dir jetzt schon ans Bein streichen...

Im gegensatz zu Graphikkartentreibern muss man fuer wlan ja auch keine "geheimen" algorithmen benutzen um die hardware ganz auszureitzen.

Und ob! Die Frequenzen der Centrino-Chips sind nämlich per Software frei einstellbar, was Big Brother den bösen Hackern natürlich nicht erlauben will. Schliesslich könnte man sonst in allen möglichen Frequenzbereichen (Polizei, Militär, NSA & Co) herumfunken.

Selbst wenn Intel den Source herausgeben möchte, werden da die Regierungen, allen voran die eines gewissen G. W. B., was vorhusten.

Jein. Die WLAN-Chips, für die es OpenSource Treiber gibt, haben entweder eine fest verdrahtete Kanaleinstellung, oder sie wird von der Firmware vorgenommen. Bei den meisten neuen Chips läuft die Kanaleinstellung aber über den Treiber, und in diesem Fall verbietet die FCC (US-Rundfunkbehörde) die vollständige Offenlegung der Quellen. Darum gibt es zum Beispiel für die Atheros-Chips bislang nur einen halboffenen Treiber (Ansteuerung ClosedSource, Rest OpenSource).

--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.

<frotzel>Ach, Hyperthreading bringt jetzt neben Marketingpunkten auch mehr Leistung?</frotzel>

Nee, im Ernst. Die unabhängigen Benchmarks, die ich bisher gesehen habe, zeichnen da ein deutliches Bild: HyperThreading hilft nur bei bestimmten Applikationen. Und zwar sollte die Applikation eine möglichst hohe Systemlast erzeugen, und zwei gleichmässig belastete Threads oder Prozesse haben, die möglichst verschiedene CPU-Funktionen nutzen. Ansonsten bremst HyperThreading eher, weil die bessere CPU-Ausnutzung durch den Aufwand des Registerswitchings wieder aufgefressen wird.

--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.

Hmmm... Also unter Registerswitching verstand ich eigentlich immer genau das, was bei HT gemacht wird: Den Registersatz umschalten. Wenn die Register neu geladen werden, ist hierzulande eigentlich eher die Rede vom Taskswitchung. Das ist natürlich noch langsamer, aber es wäre eine Illusion zu glauben, das Umschalten des Registersatzes brauche keine Zeit. Und der Registersatz muss umgeschaltet werden, denn die CPU hat nach wie vor nur einen Kern.

Weil die CPU nur einen Kern hat, laufen die Tasks auch weiterhing nur quasi-parallel. Beim Umschalten muss also der laufende Task unterbrochen, und der zweite Task gestartet werden. Dies muss aber vor der Software verborgen werden, um die Illusion von zwei vollwertigen CPUs aufrechtzuerhalten. Das wiederum ist nötig, um die Software daran zu hindern, selbst einen Taskwechsel vorzunehmen. Die von mir angesprochenen Benchmarkergebnisse lassen darauf schliessen, dass dieser Prozess sehr aufwändig, und ein HT-Taskwechsel trotz Register-Heimvorteil insgesamt langsamer als ein normaler Taskwechsel ist. Wenn das stimmt, so bringt HT nur etwas, wenn die gesamte CPU-Last nahe 100% steht. Dann kann die CPU die beiden virtuellen Maschinen nämlich so aufeinander abstimmen, dass die Rechenleistung optimal ausgenutzt wird.

Eine andere Möglichkeit wäre, dass die verschiedenen CPU-Teile parallel mit unterschiedlichen Registersätzen arbeiten können. Dass brächte eine noch bessere Ausnutzung der CPU, macht aber die Tasktrennung zu einer titanischen Aufgabe (welcher CPU-Teil arbeitet an welchem Task?), und würde zudem den internen Zugriff auf die Register verlangsamen. Auch hier würde sich der Vorteil von HT erst bei einer CPU-Last nahe 100% bemerkbar machen.

Was die Benchmarks betrifft, liegst du übrigens auf dem Holzweg. Es handelt sich um Applikationstests: Verschiedenen Programmen wurden komplexe Aufgaben gestellt, und die Zeit gemessen, die sie zur Erledigung benötigten. Die Tests habe ich in der c't gelesen. Falls gewünscht, kann ich die Ausgabe heraussuchen. Tom's Hardware hat meines Wissens auch mal Tests durchgeführt.

--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.

Wenn Intel den Treiber als Binary herausgibt, werden sie sich auf ein paar wenige weit verbreitete Kernel beschränken, oder (was zu hoffen ist) den selben Trick wie NVidia anwenden, nämlich einen Wrapper als Sourcecode veröffentlichen, der dann den Kernelversion-unabhängigen Binary-Treiber aufruft. (Ein solcher Wrapper ist allerdings effizienter als ein NDIS-Wrapper)