Dies kann ich absolut nicht nachvollziehen, denn auf 2 Dual-core Xeons läuft ein nicht optimiertes Freebsd 7.0 etwa 2 GFlops schneller als wie unter Linux, wo schon einige Paramter angepasst und getuned sind. Und 14 Gflops gegenüber 12 finde ich schon ohne jegliches Tuning mit einer einfachen Standardinstallation (nur Scheduler getauscht) schon enorm.
Entweder liegt bei dir eine Fehlkonfiguration vor, oder du hast eine merkwürdige Hardwarekombination, die sich da nicht verträgt. Anders kann ich mir das nicht erklären.
Nun habe ich einige Zeit damit verbracht Informationen zu sammeln, die Deine Aussage der 2 GFLOPS Differenz unterfüttern könnten und habe nichts Vernünftiges finden können. Bislang nur belangloses Gerede, unsaubere 'Tests' oder schlichtweg nur Lippenbekenntnisse einiger Fanboys.
Kannst Du mir sagen woher Deine Information stammt oder mir Näheres zur Konfiguration mitteilen?
Eine 'Fehlkonfiguration', wie Du sie vielleicht gerne sehen möchtest, liegt mit hoher Wahrscheinlichkeit nicht vor. Zumindest nicht in dem Sinne, daß ein eklatanter Fehler vorliegen könnte. Das Problem des 'stehenden Systems' trat mit Wechsel von FBSD 6 nach FBSD 7 auf. Und nochmals: für den X11-Anwender waren die beschriebenen Probleme offensichtlich, weil das 'haptische' System stockte. Nähere Betrachtungen bei headless-Servern aber zeigten ganz ähnliche Einbrüche bei hoher SATA-I/O und Einbrüchen im Bereich Netzwerk.
Das betrifft vor allem UP-Systeme unter 64Bit! Auf der gleichen Hardware unter 32Bit (AMD 3500+ bei 2,2 GHz und 2 oder 4 GB RAM) sind diese massiven Aussetzer zwar auch spürbar, allerdings nicht derart massiv und einschränkend wie unter 64Bit. Selbiges gilt für meine Dual- und Quad-Coresysteme, da tritt allerdings das Problem nicht nicht so empfindlich auf, Dank SMP. Eine P4-CPU mit SMT unter 32 Bit verhält sich noch flüssiger, wobei ich hier nicht wirklich ausreichend Tests durchgeführt habe, da 32Bit Systeme für mich mitlerweile außerhalb des Fokusses sind.
Während unter 6.2 ein 'build world' ca. 90 Minuten dauerte, nimmt es jetzt auf der gleichen Hardware (unverändert) 120 Minuten in Anspruch (AMD64, 2,2 GHz). Da sich mit 7.0 Compiler und System geändert haben, ist das natürlich kaum ein 'echtes' Maß, wohl aber der Umstand, daß ich vor 7.0 problemlos ein System UND einen Port bzw. Updates dieser ohne Störungen fahren konnte - das ist nicht mehr möglich, mit den bislang hier breitgewalzten Problemen.
Eine Vermutung ist, daß vielleicht der Compiler aggressiver arbeitet.
Wenn man unter FreeBSD 7.0-STABLE, der zu diesem Zeitpunkt aktuellen Xorg-Version, Windowmaker und mplayer (die Software ist auf dem aktuellsten Stand!) ein Musikstück hört oder einen Film schaut und mit dem Mauszeiger (USB und/oder PS/2 Maus) ein Fenster anfaßt und es größer oder kleiner macht und dann bei gedrückter Maustaste inne hält, hört die Musik einfach auf zu spielen oder der Film bleibt stehen. Und das bleibt nicht dabei, Platten I/O sowie Netzwerk-Verkehr brechen auch einfach ein! Und das kann ich auf zwei Maschinen reproduzieren, einem Quadcore und einer UP Maschine, beide 64Bit, SCHED_ULE, PREEMPTION. System gleicher Stand, Software (Ports) ebenfalls aktuell. Lustig, nicht ... In einem Fall ist es eine M-Audio PCI-Karte mit entsprechendem Treiber, im anderen Falle der HD-Audio Chip auf einem P35 basierten Board. eigentlich ist diese Info irrelevant, da auf unterschiedlichen Architekturen das Problem auftritt und damit als Betriebssystemproblem identifiziert werden kann.
Vielleicht kann jemand von euch diesen Fall nachvollziehen und darüberhinaus mir Informationen/Quellen über die interessanten GFLOPS-Diskrepanzen nennen.
Danke
