kleine frage zu i686 optimierten Distri's

[Cold]

Ich wollte mir mal eine i686 optimierte Distri installieren, nur habe ich eine frage, diese optimiereung gilt für das installierte system, aber wie ist das dann bei programmen die ich so im nachhinein installiere? sind die dann auch optimiert für i686 oder sind die dann wieder normal und ich kann die optimierung vergessen :confused:

[sepp2k]

Kommt drauf an, wie du das Programm installierst. Wenn du selber kompilierst, kannst du selber einstellen, wodrauf es optimiert wird. Bei RPMs kommt's auf das RPM an. Ein i386.rpm oder ein x86.rpm ist für 386er oder gar nicht optimiert. Ein i686.rpm ist dementsprechend für 686er optimiert.

[TheGhost]

N`abend,
Stcihwort cpuflags !
Um architekturoptimiert Programme selber zu kompilieren müssen sog. cpuflags gesetzt werden.
Schau mal hier:
http://www.pro-linux.de/news/2002/0090.html
Ist aber mit Vorsicht zu genießen, zu viele Flags können auch bremsen. Dazu ist im Netz aber auch einiges an Info`s zu finden.

Gruß

[Cold]

N`abend,
Stcihwort cpuflags !
Um architekturoptimiert Programme selber zu kompilieren müssen sog. cpuflags gesetzt werden.
Schau mal hier:
http://www.pro-linux.de/news/2002/0090.html
Ist aber mit Vorsicht zu genießen, zu viele Flags können auch bremsen. Dazu ist im Netz aber auch einiges an Info`s zu finden.

Gruß

das heist also das ich auch ohne ein i686 optimiertes system, i686 optimierte programme kompilern kann? gilt das auch für denn kernel selber?

[sepp2k]

das heist also das ich auch ohne ein i686 optimiertes system, i686 optimierte programme kompilern kann? gilt das auch für denn kernel selber?
Ja und Ja.

[TheGhost]

Hi,
also das Ganze ist so eine Sache für sich, ich bin da mal im Slackforum sehr gut beraten worden.
Vorweg soviel: Versprech` Dir nicht zuviel davon, das bringt bei einzelnen Programmen nicht sehr viel, also zumindest wirst Du nicht viel davon merken.
Anders sieht das aus wenn sowohl der Kernel als auch Dein WM und X mittels solcher Flags kompiliert werden.
Und das macht viel Arbeit und dauert recht lange.
Ich habe mir den Spaß mal gegönnt und das unter Slack so durchgezogen.
Also erst eigenen Kernel gebaut, dann Xorg und dann KDE. Alles zusammen macht die Kiste schneller (also Programme werden schneller gestartet, insgesamt fluppt das alles etwas flotter) aber unterm Strich denke ich das der Aufwand schon recht enorm ist für etwas mehr Performance.
Nun gut, wenn man Spaß am kompilieren hat dann ist es schon O.K., mir macht das Spaß und mit der Zeit werden es mehr und mehr selbst gebastelte Pakete.
Ich hoffe das hilft Dir etwas.
Gruß

[derguteweka]

Moin,

wie TheGhost schon geschrieben hat; versprech' dir nicht zu viel davon. Der Unterschied ist marginal. Nochdazu kommt, dass die jeweils brandneuesten gcc Versionen nicht immer unter allen Umstaenden mit allen Optimierungen auch immer fehlerfreien code liefern....
Die Unterschiede zwischen nicht auf CPU optimiert oder optimiert mit allen Faxen kommen auf uralten, schwachbruestigen Systemen imho auch viel mehr zum
Tragen, als auf halbwegs modernen Kisten (z.b. >=1GHz)

Gruss
WK

[crazygeek]

stichwort gentoo, da hast eine sourcen-basierte distro und kannst das komplette system über compiler flags auf deine "gesamte" hardware optimieren...

[Hun]

allerdings brauchst du 2^X reboots um den Mehraufwand an Zeit wieder reinzubekommen...

[Skipper]

stichwort gentoo, da hast eine sourcen-basierte distro und kannst das komplette system über compiler flags auf deine "gesamte" hardware optimieren...
Das ist alles nur Hype.

Ich konnte zwischen einem i386-Slackware und einem optimal angepassten Gentoo auf einem Athlon Thunderbird KEINEN spürbaren Geschwindigkeitsunterschied feststellen.

Die Geschwindigkeitsunterschiede zwischen den Distributionen liegen eher im mehr oder weniger aufgeblasenen Drumherum begründet, wie Startscripte und ähnliches.

[K4L]

mhh soweit ich weiss bringt eine optimierte distri nur was mit einem compiler was, der für diene prozessorarchitektur optimiert ist. soweit ich nämlich weiss ist der gc damals unter dem apsect entwikelt worden, dass code für viele plattformen genererieren kann. daher ist des ganze optimiererei meines wissen nach, wie meine vorsprecher schon gesagt haben ein hype. richtige optimierung erhält man nur dann mit dem entsprechenden compiler wie zb bei intel prozessoren mit dem intel c compiler.

ein optmirter kernel macht sich schon bemerkbar, da auch viel blödisnnige module rausgeworfen könne ,die gar nciht für die machine bennötigt werden. also nach meiner ansicht lohnt sihc optimierter cod enur für den kernel, aber ansonsten ist das übertrieben

meine informationen über das thema habe ich nr a sum netz und können vollkommen falsch sein, deshalb nicht völlig zerreisen

[Skipper]

ein optmirter kernel macht sich schon bemerkbar, da auch viel blödisnnige module rausgeworfen könne ,die gar nciht für die machine bennötigt werden.
Stimmt nach meiner Erfahrung auch nicht. Bei einem modularisierten Kernel liegen die Module schliesslich auf der Festplatte, wo sie niemand stören. Selbst wenn unnötige Sachen fest im Kernel drin sind, belegen sie höchstens ein par KB mehr RAM, bremsen sonst aber auch nicht.

Kernel kompilieren ist eigentlich nur sinnvoll, wenn der fertig mitgelieferte irgendwelche Probleme macht.

[derguteweka]

Moin,


ein optmirter kernel macht sich schon bemerkbar, da auch viel blödisnnige module rausgeworfen könne ,die gar nciht für die machine bennötigt werden. also nach meiner ansicht lohnt sihc optimierter cod enur für den kernel, aber ansonsten ist das übertrieben

meine informationen über das thema habe ich nr a sum netz und können vollkommen falsch sein, deshalb nicht völlig zerreisen

Das Geruecht haelt sich hartnaeckig, ist aber trotzdem genau falsch. Die Rechenzeit des Computers wird doch nicht im Kernel verbraten, sondern in den Anwendungen. Der Kernel macht doch "nur" solche sachen wie Systemaufrufe; Speicherverwaltung und HW-Zugriffe. Das braucht im Normalfall nur einen ganz kleinen Teil der Rechenzeit. Da bringts doch ueberhaupt nix, das jetzt von z.b. 1% auf 0.9% zu optimieren. Viel mehr bringts, die Applikationen zu optimieren. Bei Distributionen von der Stange bringts auch viel, eben alle nicht benoetigten Dienste rauszuschmeissen. Mir wird immer ganz schlecht, wenn ich seh' wie lange sich so ne frischinstallierte Distri duch alle init-scripte quaelt.

Gruss
WK

[K4L]

mhjh aber was ich dann nciht versteh, die hardwre wrid dann ja bessa angesproche, und der cpu wird besser ausgereizt, warum sollte das keinen performance vorteil bringen?

[Tomek]

mhjh aber was ich dann nciht versteh, die hardwre wrid dann ja bessa angesproche, und der cpu wird besser ausgereizt, warum sollte das keinen performance vorteil bringen?

Bei normalen Programmen bringt das eben keinen nennenswerten Vorteil. Erst wenn es um komplexe Berechnungen geht, spielt das eine Rolle. Und bei normalen Desktopanwendungen oder Serverdiensten finden eben in den seltensten Fällen solche Berechnungen statt.

[derguteweka]

Moin,


mhjh aber was ich dann nciht versteh, die hardwre wrid dann ja bessa angesproche, und der cpu wird besser ausgereizt, warum sollte das keinen performance vorteil bringen?

Nee, Hardware kannst du nicht besser oder schlechter ansprechen; du liest oder schreibst in ein Register, das wars; die Geschwindigkeit haengt massgeblich vom Bus ab, ueber den das ganze geht...
Und wie man eine CPU besser ausreizen kann ist mir nicht so richtig klar ;-)
Klaro vielleicht gehen die Systemaufrufe in einem masscompilierten Kernel ein bisschen schneller, aber in der Gesamtperformance bringt das fast nix, denn 99% der Rechenzeit verbringt die CPU (hoffentlich) in den Applikationen und nicht im Kernel. Deshalb sind die Applikationen das Entscheidende fuer die Performance.

Gruss
WK

[HEMIcuda]

mhjh aber was ich dann nciht versteh, die hardwre wrid dann ja bessa angesproche, und der cpu wird besser ausgereizt, warum sollte das keinen performance vorteil bringen?
Wir sind hier in einem Forum und nicht auf der Flucht. Waere schoen, wenn Du
nochmal durchlesen wuerdest, was Du zusammen"schreibst".

[fs111]

Nur weil ein Paket foo.bar.baz.8.3.6.i385.rpm heißt, heißt das noch lange nicht, dass es keine Optimierungen enthält. Wer sowas behauptet hat keine Ahnung, und wer glaubt mehr als ein paar % Geschwindigkeit aus harten Compilerflags herauszuholen leidet an Halluzinationen. Fedoar bspw. kompiliert die Programme für den i686 optimiert, bezeichnet sie aber als i386, da sie auf diesem auch laufen würden, würde man sie dort benutzen wollen. D.h. also, dass die Distributionen ohnehin schon optimiert sind.

fs111