Linux auf HPPA schneller machen ?

[Stefan307]

Hallo

Ich lese ja immer wieder hier wie abartig langsam Linux auf HPPA läuft! Jetzt frag ich mich woran das liegt bzw. was man dagegen tun könnte? Bevor jetzt wieder so ein Glaubenskrieg ausbricht ich hab nix gegen HP-UX aber Linux hat für mich 2 gewichtige Vorteile: Erstens ich hab das gleiche OS auf verschiedenen Rechnern( für mich ein Vorteil weil ich das Betriebssystem als Mittel zum Zweck sehe) und was noch viel wichtiger ist es gibt wesentlich mehr Treiber und damit mehr möglichkeiten bei PCI karten, auch wenn ja nicht alles auf HPPA Hardware läuft (z.b. Grafikkarten).

So jetzt frag ich mich wie man Linux auf die Sprünge helfen könnte? Hier wurde ja öfters über den schlechten Code den der gcc für HPPA erzeugt geschrieben, da frag ich mich natürlich ab man Linux nicht auch unter HPs Acc compilieren könnte? So wo könnte das noch dran liegen ? schlechte Hardwaretreiber ?

Ich hoffe das wir hier mal ohne Vorurteile darüber reden können ...

MFG S

[Fleedwood]

Ich muß gestehen, daß mir HPUX auch sind besonders schnell vorkommt, von daher kann ich das Argument abartig langsam nicht so recht nachvollziehen... solange wir UP sprechen
und uns über die Kernel Performance an sich unterhalten. Die letzten LM Bench Vergleichswerte die ich gesehen habe, hatten auch durchaus Punkte wo Linux schneller ist.

Wo Linux Defizite hat ist definitiv SMP und im Cache Management (das tut bei SMP dann nochmal mehr weh). Für die Cacheproblematik hab ich schon Patches gesehen, die da
Verbesserungen erbringen, die hatten aber noch Nebeneffekte, die erst noch gefixt werden müssen. Und da fehlts an Manpower... Warum SMP so schlecht skaliert hängt auch
mit Cache zusammen, aber wo es darüberhinaus noch im Argen liegt, weiß ich selber nicht (würde mich aber interessieren).

Ein guter Kernel profitiert relativ wenig von einem besseren Compiler, da er ja nach eh so wenig Zeit wie möglich verbraten soll und bei wirklichen Hotspots sowieso optimierte
Assemblerroutinen zum Einsatz kommen. Ein weiteres Problem ist, daß der aCC für 32bit nur SOM unterstützt, der Linux Kernel aber ELF braucht und zudem einige GCC
Erweiterungen verwendet. Und für Userspace wo ein gute Compiler deutlich mehr Effekte zeigt, ist der aCC wegen SOM auch nicht zu gebrauchen.

Thomas.

[karakal]

schlechte Hardwaretreiber ?

Du hast dir die Antwort schon selber gegeben. Es gibt einfach zuwenige Leute, die Linux auf HPPA einsetzen und noch weniger Entwickler, die das interessiert, da noch was zu machen.

IMHO ist die Qualität des Compilers einmal zweitrangig, solange es keine vernünftigen Treiber gibt.

Und zu dem Ding mit zwei Rechner und gleiches Betriebssystem: Wenn du Linux willst, dann ist das vernünftigste (und auch vom Preis/Leistungsverhältnis besser) einen x86-Rechner oder auch wenns unbedingt sein muss einen PowerPC (am besten von Apple) nehmen und da Linux drauf laufen lassen.

Ich hab Debian HPPA auch schon ausprobiert und im Gegensatz zu HP/UX 11v2 auf der gleichen Maschine kannst du Kinder kriegen...

Was kann man dagegen machen? Wenn man sehr gut drauf ist, die Treiber verbessern... In der Realität: Gar nix... HP/UX einsetzen...

[Fleedwood]

IMHO ist die Qualität des Compilers einmal zweitrangig, solange es keine vernünftigen Treiber gibt.

da die gleichen Chips auch auf x86 verwendet werden, somit auch die selben Treiber, müßten die auch unter x86 nicht taugen.

An den Treibern liegts nicht.

Thomas.

[karakal]

IMHO ist die Qualität des Compilers einmal zweitrangig, solange es keine vernünftigen Treiber gibt.

da die gleichen Chips auch auf x86 verwendet werden, somit auch die selben Treiber, müßten die auch unter x86 nicht taugen.

An den Treibern liegts nicht.

Ich will jetzt nicht päpstlicher sein als der Papst, aber ich nenne dir nur mal ein Beispiel:
Die "alten" Apple und PC... Beides AGP, bei beiden konnte man z.B. ATI Grafikkarten benutzen, nur im Apple funktionierten keine PC-Grafikkarten, weil das BIOS der Grafikkarte nicht gepasst hat...

Und klar liegts an den Treibern: Wenn es keine Treiber gibt, bzw. die Treiber nicht optimiert sind, kann man einen noch so toll optimierenden Compiler benutzen, es wird nix helfen...

Ich sags nochmal: Am Compiler liegts net....

[Fleedwood]

Hmm, ich würde nie auf die Idee kommen ein HP Maschine als Grafikworkstation unter Linux einzusetzen. Da das für mich
nicht in Frage kommt, habe ich die Aussage "abartig langsam" auf so Sachen wie Netzwerk und Platten-IO bezogen. Und genau
da kommen PCI Chips zum Einsatz die auch auf x86 laufen. Und dementsprechend kommen auch die gleichen Treiber zum Einsatz.

Ich finds schon sehr komisch, wenn man OS Performance rein an Grafik-IO festmachen will. Ein HP Server ohne Graka hääte demnach
wohl keine Performance....

BTW, ich hab mich in meinen ersten Beitrag exakt auf Kernelperformance bezogen und die Kerneltreiber spielen da eben keine Rolle.
Da macht das etwas schlechtere Cache-Flushing unter Linux den Unterschied zu HP-UX aus. Und je größer der Cache desto
ungünstiger wirds.

Thomas.

[Ebbi]

Tja, ohne Grafik sind die Admins heutzutage eben blind.

[Fleedwood]

Tja, ohne Grafik sind die Admins heutzutage eben blind.

auweia

Thomas.

[llothar]

Ich sags nochmal: Am Compiler liegts net....

Doch am Compiler liegts deutlich. Dieses Porting Archive für PA-RISC hat ja den acc Compiler geschenkt bekommen und kompiliert damit und die sagen dir einfach das 50% Leistungssteigerung ausschliesslich aus gcc<->acc zurückzuführen ist. Okay der gcc hat da einiges geschenkt bekommen in der letzten Zeit.

Dann kommt nochmal die unterschiedliche Architektur dazu. Das kann immer seltsame Effekte haben.

Dagegen kannste SCSI Treiber etc. in die Tonne tretten die machen gar nichts aus. Hatte mal 1992 in Forth so einen Treiber gehackt. Da ist nicht wirklich was was ein Treiber falsch oder gar langsam machen kann.

Bei Netzwerkkarten wenn die Hardware da nicht alles super unterstützt ist auch einiges zu machen. Eine schlechte CRC Checksumme und schon gehts runter und die Luzie bleibt sitzen und geht nicht mehr ab.

[karakal]

Hmm, ich würde nie auf die Idee kommen ein HP Maschine als Grafikworkstation unter Linux einzusetzen. Da das für mich
nicht in Frage kommt, habe ich die Aussage "abartig langsam" auf so Sachen wie Netzwerk und Platten-IO bezogen. Und genau
da kommen PCI Chips zum Einsatz die auch auf x86 laufen. Und dementsprechend kommen auch die gleichen Treiber zum Einsatz.

Ich finds schon sehr komisch, wenn man OS Performance rein an Grafik-IO festmachen will. Ein HP Server ohne Graka hääte demnach
wohl keine Performance....

BTW, ich hab mich in meinen ersten Beitrag exakt auf Kernelperformance bezogen und die Kerneltreiber spielen da eben keine Rolle.
Da macht das etwas schlechtere Cache-Flushing unter Linux den Unterschied zu HP-UX aus. Und je größer der Cache desto
ungünstiger wirds.

Thomas.

*seufz* Das war ein BEISPIEL! Und es macht einen Unterschied, ob ich einen Treiber schreiben muss, der auf HPPA oder auf x86 läuft....
Und ich hab nie von der Grafikperformance geschwafelt... egal....

[Fleedwood]

*seufz* Das war ein BEISPIEL! Und es macht einen Unterschied, ob ich einen Treiber schreiben muss, der auf HPPA oder auf x86 läuft....
Und ich hab nie von der Grafikperformance geschwafelt... egal....

du hast ATI Grafikkarten erwähnt ... verwende es halt nicht als Beispiel wenns schlecht ist ...

Für einen SCSI Hostadapter oder eine Netzwerkkarte ist es egal, ob x86 oder HPPA aus Linux Sicht.

Nur um den Punkt den ich machen will nicht aus dem Auge zu verlieren: Mir geht es darum, daß die Linuxtreiber unter HPPA und x86 gleich sind sofern
die gleiche Hardware bedient wird. Wenn diese also unter x86 von der Perfomance gut sind, dann sind sie das auch unter HPPA. Deshalb liegen die
Perfomanceprobleme eben nicht in den Treibern.

Thomas.

[Fleedwood]

Ich sags nochmal: Am Compiler liegts net....

Doch am Compiler liegts deutlich. Dieses Porting Archive für PA-RISC hat ja den acc Compiler geschenkt bekommen und kompiliert damit und die sagen dir einfach das 50% Leistungssteigerung ausschliesslich aus gcc<->acc zurückzuführen ist. Okay der gcc hat da einiges geschenkt bekommen in der letzten Zeit.

für einen guten Kernel ist der Compiler nicht kriegsentscheidend. Da spielen gute Algorithmen eine deutlich größere Rolle. Was leider so an aktuellen Userlandcode rumfliegt, tendiert oft
genau in die andere Richtung (Quick and Dirty halt) und schon spielt ein Compiler eine größere Rolle.

Thomas.