# Auf Leistung optimieren

## TMoS_uga

Hallo zusammen

Irgendwann demnächst mal sollte die Gentoo 2007.0 rauskommen.

Wenn die da ist wollte ich mein System neu aufsetzen und gleich mal richtig optimieren.

Da ich einen Core Duo Prozessor habe dachte ich an folgende make.conf Einstellungen:

 *Quote:*   

> 
> 
> CHOST="i686-pc-linux-gnu"
> 
> CFLAGS="-march=prescott -O3 -pipe -fomit-frame-pointer"
> ...

 

Swap = 2x Ram = 2GB.

Zudem würde ich initng anstatt sysvinit verwenden und hotplug-ng anstatt hotplug verwenden.

Nach der Installation des Systems würde ich ein "emerge -e system machen", um eine Stage 1 identische Installation zubekommen.

Anschliessend das ganze System prelinken.

Und natürlich werden nur notwendige Dienste gestartet.  :Smile: 

Jetzt noch fragen dazu.

Ist hdparm bei SATA Kontrollern notwendig oder gilt das nur bei IDE?

Gibt es weitere leistungsbezogene Optimierungsmöglichkeiten?

Thx

Gruss

Stefan

----------

## Keruskerfuerst

Ich würde eben nicht mit -O3 optimieren.

Siehe: https://forums.gentoo.org/viewtopic-t-547497.html

Dann eine bessere Partitionierung als im Handbuch angegeben:

/boot

/swap: am Besten auf einer anderen Festplatte

/

/home

/usr/portage

/var

Kernel optimieren: alles weglassen, was nicht unbedingt notwendig ist.

----------

## xraver

Vieleicht interessiert dich auch diese Möglichkeit;

https://forums.gentoo.org/viewtopic-t-549935-highlight-conrad.html

----------

## TMoS_uga

vielen dank erstmal für die antworten,

ich werde die beiden threads heute abend durchlesen..

----------

## a.forlorn

Ich bevorzuge -O3. Ich habe 3 Rechner damit laufen, verschiedenste Typen: 1x AMD Geode, 1x Intel DualCore, 1x Dual DualOpteron. Der Geode läuft schon so seit fast zwei Jahren, der Intel seit einem Jahr und der Opteron seit einem halben Jahr ohne irgendwelche Probleme. Warum also die Optimierung nicht nutzen? Die ebuilds blocken eh die cflags, die für dieses ebuild als unstable gelten.

```
CFLAGS="-march=opteron -O3 -pipe -fomit-frame-pointer"
```

----------

## Carlo

 *a.forlorn wrote:*   

> Warum also die Optimierung nicht nutzen? Die ebuilds blocken eh die cflags, die für dieses ebuild als unstable gelten.

 

Die Ebuilds filtern nicht alles. Und bei manchen Flags ist es ein Ärgernis, daß sie von einigen Ebuilds gefiltert werden, anstatt den vermeintlich Schlauen ins offene Messer laufen zu lassen.

Mit -O3 dauert die Kompiliererei länger und es bläht die Binaries auf, was sich durch langsamere Startzeiten der Anwendungen bemerkbar macht. -O2 ist definitiv die beste Wahl, wenn es nicht um besonders zu optimierende Code-Abschnitte geht.

----------

## Klaus Meier

Also meine Erfahrungen mit -O3 und dem gcc 4 sind: Finger weg. Habs vor kurzem mal wieder versucht und da war es Gnomebaker, welches seinen Dienst komplett verweigert hat.

Und zu allen, die sagen, bei mir gibt es keine Probleme. Einfachste Grundzüge der Beweisführung: Nehmen wir den Satz, alle Raben sind schwarz. Das Vorzeigen von einer Millionen schwarzer Raben beweist diesen Satz nicht, das Vorzeigen eines nichtschwarzen Rabens wiederliegt ihn.

Obwohl es wohl inzwischen so ausseiht, dass die meisten Anwendungen -O3 rausfiltern, die damit Probleme haben. Nur, einen Performancegewinn konnte ich bei meinem System mit -O3 nicht feststellen.

----------

## psyqil

 *a.forlorn wrote:*   

> Ich bevorzuge -O3.

 Das hältst Du für optimal auf 'nem Geode? Da würde ich höchstens -Os empfehlen.

----------

## Klaus Meier

 *a.forlorn wrote:*   

> Ich bevorzuge -O3. Ich habe 3 Rechner damit laufen, verschiedenste Typen: 1x AMD Geode, 1x Intel DualCore, 1x Dual DualOpteron. Der Geode läuft schon so seit fast zwei Jahren, der Intel seit einem Jahr und der Opteron seit einem halben Jahr ohne irgendwelche Probleme. Warum also die Optimierung nicht nutzen? Die ebuilds blocken eh die cflags, die für dieses ebuild als unstable gelten.
> 
> ```
> CFLAGS="-march=opteron -O3 -pipe -fomit-frame-pointer"
> ```
> ...

 

Was für Vorteile hast du denn gegenüber -O2 festgestellt?

----------

## ichbinsisyphos

ich hab auch einen yonah. meine make.conf sieht so aus.

```
CFLAGS="-march=prescott -Os -pipe -ftracer -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -s"

MAKEOPTS="-j3"

ACCEPT_KEYWORDS="~x86 x86"

FEATURES="ccache"

CCACHE_DIR="/root/.ccache"

CCACHE_SIZE="2G"

```

kann zu den optimierungen nicht wirklich viel sagen, ausser dass ich in den letzten monaten viele cflags und ldflags probiert hab und diese konfiguration bei mir absolut stabil ist.

----------

## Aldo

```
ACCEPT_KEYWORDS="~x86 x86"
```

Dazu sag ich jetzt mal nichts...

Ich denke mir nur meinen Teil.

----------

## blu3bird

Wenn du's wirklich schnell haben willst kompilier's nicht mit dem sys-devel/gcc sondern mit dev-lang/icc und nimm folgende cflags: 

```
-xP -ipo -O3 -Ob2 -fomit-frame-pointer -unroll -no-heap-arrays -pthread -parallel -complex-limited-range -fp-model fast=2 -no-fp-port -no-prec-div -no-prec-sqrt -static-libcxa -i-static -static -rcd
```

Aber nimm dir vorher 2 - 3 Wochen Urlaub...und wunder dich nicht wenn 2 + 2 auf einmal 5 ist  :Wink: 

----------

## ichbinsisyphos

 *Aldo wrote:*   

> 
> 
> ```
> ACCEPT_KEYWORDS="~x86 x86"
> ```
> ...

 

und ich antworte darauf nicht, bilde mir aber auch eine meinung über den poster, wahrscheinlich eine schlechte lol

----------

## a.forlorn

 *psyqil wrote:*   

>  *a.forlorn wrote:*   Ich bevorzuge -O3. Das hältst Du für optimal auf 'nem Geode? Da würde ich höchstens -Os empfehlen.

 

Das ist ein GeodeNX = -march=athlon-xp.  :Wink: 

----------

## a.forlorn

 *Klaus Meier wrote:*   

> Was für Vorteile hast du denn gegenüber -O2 festgestellt?

 

Der Pentium lief auf -O2 bei Installation, dann hab ich mal -O3 (nach so einer Diskussion) getestet, war alles stabil und mir kam es etwas schneller vor. Gemessen hab ich nichts, also ein rein subjektives Empfinden. Beim Opteron hab ich gleich -O3 genommen, ebenso beim Geode. Wie gesagt, Probleme wie ein Abbruch von emerge habe ich nicht, bis auf die üblichen verdächtigen (fehlerhafte ebuilds).  :Wink: 

edit: nur damit es klar wird... der Pentium war mein erstes 64er, da war ich vorsichtig.  :Wink:  Der Geode (bzw dessen Prozessorvorgänger) läuft trotzdem länger.  :Wink: 

----------

## Finswimmer

 *ichbinsisyphos wrote:*   

>  *Aldo wrote:*   
> 
> ```
> ACCEPT_KEYWORDS="~x86 x86"
> ```
> ...

 

Nur, dass ihr das nicht falsch auffasst.

Das ist die Ausgabe von emerge --info bei einem ~x86 System. Die Regel, dass der letzte Wert den neuesten überschreibt, darf man hier nicht anwenden.

Oder habe ich euch falsch verstanden?

Tobi

----------

## Aldo

Ich bezog mich eher darauf (bzw. wollte andeuten), daß '~x86', '-O3' und 'stabil' zusammen wohl _der_ Widerspruch schlechthin ist.

----------

## psyqil

 *a.forlorn wrote:*   

> Das ist ein GeodeNX = -march=athlon-xp. 

 Aber nicht vom Cache her...

----------

## a.forlorn

 *psyqil wrote:*   

>  *a.forlorn wrote:*   Das ist ein GeodeNX = -march=athlon-xp.  Aber nicht vom Cache her...

 

```
Geode NX

Codename: Thoroughbred B

L1-Cache: 64 + 64 KB (Daten + Instruktionen)

L2-Cache: 256 KB mit Prozessortakt
```

Soviel hatte mein XP2800+ auch.  :Wink: 

----------

## ichbinsisyphos

also vor ~x86 muss sich niemand fürchten. wie gesagt, mein system is völlig stabil. von zeit zu zeit muss ich aber das eine oder andere paket masken, weil eine abhängigkeit noch nicht in der letzten version vorliegt oder so ...

----------

## Inte

 *a.forlorn wrote:*   

> 
> 
> ```
> Geode NX
> 
> ...

 Ein Grund mehr -Os zu verwenden.

----------

## misterjack

Ne, -O2 ist besser bei dem Cache. -Os lohnt sich für Geode LX z.b.

----------

## Mr. Anderson

Zu -O2 setze ich inzwischen noch -fgcse-after-reload dazu. Das ist sonst bei -O3 mit dabei. Bringt nicht viel, verlängert dafür aber wohl die Übersetzungszeit messbar und sollte tendenziell eher kleineren Code erzeugen.

----------

## a.forlorn

Ja, -Os ist für P1-Generation. AMD empfiehlt eh für alle seine Prozessoren seit Athlon K7 -O3.

----------

## Keruskerfuerst

Ich habe alle Optimierungsstufen (-Os, -O1, -O2, -O3) auf einem System (AMD Athlon 64 3200, 1GB RAM, 128MB Grafikkarte) getestet.

Gentoo AMD64 Basissystem ohne grafische Oberfläche läuft am schnellsten, wenn -O2 verwendet wird.

-O3 führt zu einer Aufblähung des Codes und das System läuft langsamer. Genauso verhält es sich, wenn -Os verwendet wird. Nur bei CPUs mit kleinem Cache zu empfehlen.

P.S.: außerdem habe ich noch einige Compiler- und Linkeroptionen durch Tests herausgefunden, die zu einer wesentlichen Geschwindigkeitssteigerung führen: siehe hier (https://forums.gentoo.org/viewtopic-t-547497-postdays-0-postorder-asc-start-25.html)

----------

## STiGMaTa_ch

 *TMoS_uga wrote:*   

> Swap = 2x Ram = 2GB.

 

Vollkommen unnötig. 512MB reichen da ewig! die 2x RAM Regel machte noch Sinn als Leute 32MB RAM das höchste der Gefühle nannten.

Lieber Gruss

STiGMaTa

----------

## Inte

 *Keruskerfuerst wrote:*   

> Genauso verhält es sich, wenn -Os verwendet wird. Nur bei CPUs mit kleinem Cache zu empfehlen.

 Oder bei Notebooks mit langsamen Platten bzw. Flash-Medien. Irgendwo ist immer ein Flaschenhals.  :Wink: 

----------

## Anarcho

 *STiGMaTa_ch wrote:*   

>  *TMoS_uga wrote:*   Swap = 2x Ram = 2GB. 
> 
> Vollkommen unnötig. 512MB reichen da ewig! die 2x RAM Regel machte noch Sinn als Leute 32MB RAM das höchste der Gefühle nannten.
> 
> Lieber Gruss
> ...

 

Es sei denn man möchte Suspend-To-Disk nutzen. Dann sollte man schon 1x RAM als Grösse der Swap mindestens haben (allerdings braucht man nur sehr selten mehr, also genau 1xRAM würde ich in einem solchen Fall empfehlen).

Ausser natürlich man nimmt suspend to file ...

Auf meinem Server mit 1,5 GB RAM habe ich garkeine SWAP Partition mehr, sogar trotz /tmp als tmpfs.

----------

## TMoS_uga

erstmal danke.

und dann:

also das mir dem icc vergessen wir dann wohl  :Very Happy: 

Tragen wir mal zusammen:

-hdparm macht wohl kein Sinn für SATA Platten hab ich gelesen. (nicht hier)

-anstatt -O3 ist -O2 wohl besser geeignet.

-Swap reicht 1 GB vollkommen aus, wobei mir Suspend to RAM lieber währe  :Smile:  (auf eine andere Platte geht nicht -> Notebook)

-initng

-hotplug-ng

-kernel nur wirklich das was es braucht mit kompilieren.

-emerge -e system (damit ich mein stage1 system habe)

-prelinken

-nur notwendige Dienste starten

gibt es noch weitere tuning-möglichkeiten?

----------

## Vortex375

 *Quote:*   

> gibt es noch weitere tuning-möglichkeiten?

 

Nen kernel mit einem speziellen, auf Performance ausgerichtetem Patchset benutzen.

Zum Beispiel sowas (benutz ich auch): https://forums.gentoo.org/viewtopic-t-549328.html

----------

## Keruskerfuerst

 *Quote:*   

> -kernel nur wirklich das was es braucht mit kompilieren. 

 

Der Kernel sollte (komprimiert) nicht größer als 1,5MB sein

----------

## Klaus Meier

 *Vortex375 wrote:*   

>  *Quote:*   gibt es noch weitere tuning-möglichkeiten? 
> 
> Nen kernel mit einem speziellen, auf Performance ausgerichtetem Patchset benutzen.
> 
> Zum Beispiel sowas (benutz ich auch): https://forums.gentoo.org/viewtopic-t-549328.html

 

Wie fühlt sich denn der Unterschied an? Richtig spürbar?

----------

## Carlo

 *Klaus Meier wrote:*   

> Wie fühlt sich denn der Unterschied an? Richtig spürbar?

 

Ach was, das ist Einbildung. Produktiv setzt man ein, was stabil ist, kauft wenn nötig leistungsfähigere Hardware und/oder optimiert die Anwendung. Und auf dem Desktop ist der wesentliche Flaschenhals der Datenzugriff, also CPU-Cache->Ram->Festplatte. Die o.g. Patches haben überwiegend sowieso nichts mit Leistungssteigerung zu tun, sondern sind reine, experimentelle, Feature-Patches.

Wer meint, das -Os oder -O3 eine gute Wahl sind, kann ja mal

```
find  $(cat /usr/portage/profiles/categories) -mindepth 2 -maxdepth 2 -iname "*\.ebuild" -exec grep -H -- "replace-flags.*-O\(3\|s\)" {} \;
```

durchlaufen lassen.

----------

## Knieper

 *TMoS_uga wrote:*   

> 
> 
> -initng

 

Minit ist um einiges schneller.

 *Quote:*   

> -hotplug-ng

 

Hotplug kann man auch weglassen.

 *Quote:*   

> -prelinken

 

Hatte bei mir Null Effekt.

 *Quote:*   

> -nur notwendige Dienste starten

 

Macht man das nicht sowieso?

 *Quote:*   

> gibt es noch weitere tuning-möglichkeiten?

 

Dein "Tuning" ist mir immer noch suspekt. Was genau willst Du denn schneller/kleiner/bunter/sicherer machen?

----------

## Keruskerfuerst

Vielleicht solltest Du auch noch eine Metallpresse verwenden, um das Letzte aus dem Rechner herauszupressen...

----------

## musv

 *Carlo wrote:*   

> 
> 
> Wer meint, das -Os oder -O3 eine gute Wahl sind, kann ja mal
> 
> ```
> ...

 

```

find: app-accessibility: Datei oder Verzeichnis nicht gefunden

find: app-admin: Datei oder Verzeichnis nicht gefunden

find: app-antivirus: Datei oder Verzeichnis nicht gefunden

find: app-arch: Datei oder Verzeichnis nicht gefunden

find: app-backup: Datei oder Verzeichnis nicht gefunden

find: app-benchmarks: Datei oder Verzeichnis nicht gefunden

...

find: virtual: Datei oder Verzeichnis nicht gefunden

```

Die Zeilen dazwischen spar ich mir. Sind aber auch nicht grad anders.

Hab ich da was falsch gemacht bei copy + paste?

Erklär mal, warum -Os eine schlechte Wahl ist. Ich benutz das seit längerer Zeit. Ich hab nie einen Unterschied gemerkt zwischen O2, O3 und Os. Also hab ich mal irgendwo gelesen, daß Os kleinere Binaries produziert. Damit sinkt die Lade-/Startzeit der Programme. Außerdem nimmt das System weniger Speicher auf der Platte in Anspruch. Gibt's eigentlich irgendwo brauchbare Vergleichsdaten? Also nicht nur ein: "Das ist schneller, das ist langsamer". Also wieviel mb Speicher mehr / weniger benötigt ein Os-optimiertes System auf der Platte gegenüber einem vergleichbaren O2-System? Und wieviel Sekunden schneller / langsamer werden die Programme[/code] beim Starten?

Ok, nüchtern betrachtet ist das sowieso alles übertriebener Aufwand für wenig Optimierung.

----------

## Mr. Anderson

eben durch Zufall gefunden:

http://www.wikiservice.at/dse/wiki.cgi?CeeCompilerGcc

Na wenn das nicht ein paar Fragen aufwirft...  :Twisted Evil: 

----------

## Keruskerfuerst

Oder eben hier:

http://www.coyotegulch.com/products/acovea/

----------

## Carlo

 *musv wrote:*   

> Hab ich da was falsch gemacht bei copy + paste?

 

Nö. Ich habe nur cd /usr/portage stillschweigend vorausgesetzt.

 *musv wrote:*   

> Erklär mal, warum -Os eine schlechte Wahl ist.

 

Es gibt zwei Möglichkeiten: Code compiliert nicht oder Code compiliert, das Compilat aber ist fehlerhaft. Entweder liegt's an einem Compiler-Bug oder an fehlerhaftem Code, den der Compiler zwar anstandslos frißt, weil er syntaktisch korrekt ist, aber nicht der C/C++ Spezifikation entspricht. Und die Anzahl der Programmierer, die die Spezifikation(-en) genau gelesen und dann auch noch "im Blut" haben, dürfte im Vergleich zur Gesamtzahl derjenigen, die Code schreiben, minimal sein.

Wenn du sicher gehen willst, daß das Compilat keine durch den Compiler verursachten Seiteneffekte aufweist, wird dir jeder Compilerbauer sagen, keine Optimierungen zu verwenden.

 *musv wrote:*   

> Also hab ich mal irgendwo gelesen, daß Os kleinere Binaries produziert. Damit sinkt die Lade-/Startzeit der Programme.

 

Schon. So gewaltig ist der Unterschied zwischen -Os und -O2 aber nicht. Letzlich hängt der (Un-)Sinn der Optimiererei eben auch von der Hardware ab. Und wenn man schlau ist, schließt man ein Programm nicht gleich wieder, nur weil man zwischendurch ein anderes benutzen möchte...

 *musv wrote:*   

> Außerdem nimmt das System weniger Speicher auf der Platte in Anspruch. Gibt's eigentlich irgendwo brauchbare Vergleichsdaten? Also nicht nur ein: "Das ist schneller, das ist langsamer".

 

Irgenwelche Leute mit Vergleichsfimmel gibt es immer. Wie schon gesagt: Das ist Code- und Hardware-abhängig.

 *musv wrote:*   

> Also wieviel mb Speicher mehr / weniger benötigt ein Os-optimiertes System auf der Platte gegenüber einem vergleichbaren O2-System?

 

Kann man so pauschal nicht sagen. Aber es ist so wenig, daß es nur auf Embedded-Hardware sinnvoll ist, dies in seinen Überlegungen zu berücksichtigen.

 *musv wrote:*   

> Und wieviel Sekunden schneller / langsamer werden die Programme beim Starten?

 

Um Werte außerhalb des Subsekundenbereiches zu messen, muß es sich schon um sehr fette Anwendungen handeln. Dateien, die die jeweilige Anwendung beim Start lädt, werden durch ein anders optimiertes Binary auch nicht kleiner, d.h. im Normalfall ist es wesentlich sinnvoller, den Applikationscode zu optimieren, als an den Compiler-Optionen zu schrauben.

 *musv wrote:*   

> Ok, nüchtern betrachtet ist das sowieso alles übertriebener Aufwand für wenig Optimierung.

 

Genau. In den meisten Fällen liegt das irgendwo zwischen Spieltrieb und Zeitverschwendung. Ernsthafte, begründete Optimierung mal außen vor.

----------

## think4urs11

 *TMoS_uga wrote:*   

> gibt es noch weitere tuning-möglichkeiten?

 

wer unbedingt mit Compiler(optionen) herumspielen will: 1 2 3 4

aber auch vieles was mehr auf Anwendungsebene liegt

- adblocker verwenden, dadurch werden Seiten i.d.R. schneller geladen

- wenn du langsame DNS-Server hast lokal dnsmasq oder djbdns installieren

- rsync_exclude nutzen um nicht benötigtes aus portage rauszuschmeissen

- /tmp als tmpfs zum compilen mounten

- ....

----------

## Klaus Meier

 *Think4UrS11 wrote:*   

>  *TMoS_uga wrote:*   gibt es noch weitere tuning-möglichkeiten? 
> 
> wer unbedingt mit Compiler(optionen) herumspielen will: 1 2 3 4
> 
> aber auch vieles was mehr auf Anwendungsebene liegt
> ...

 

Ich denke auch, das beste Tuning ist: Gehirn einschalten. Bringt mehr als -Oirgendwas. Vor allem sollte man sich immer darüber im klaren sein, dass diese Optionen pauschal gelten. Und da gibt es halt Anwendungen, die vom schnellen Laden profitieren und andere von möglichst schnellen Code. Einfach mal den Mplayer übersetzen und schauen, was da für Optionen gesetzt werden. Wenn etwas außer -O2 oder -Os Vorteile bringt und keinerlei Probleme macht, dann wird es in den ebuilds doch meistens schon gesetzt. Wenn man dann aber wiederum sieht, was in den ebuilds alles an Optionen rausgefiltert wird, dann sollte das einem zu denken geben.

Wenn schon Tuning bei den Cflags, dann für jede Anwendung einzeln. Für ein ganzes System sind hoch komplexe Cflags Unfug.

----------

## misterjack

Wenn schon gepatchten Kernel, dann am ehesten sys-kernel/ck-sources

----------

## TMoS_uga

was ich will ist ein schnelles schlankes system.

schnell im booten, schnell im anwendungen starten.

wenn ich das hier so lese, dann lass ich das wohl mit den cflags und dem prelinken.

thx für die antworten

----------

## Keruskerfuerst

Und mit 

```
rc-update -s
```

 noch überprüfen, welche Dienst beim Booten gestartet werden.

----------

## a.forlorn

Wobei ich ja nicht verstehen kann, warum Du kein 64bit System basteln möchtest. Da könnte man ja dann auch das tolle Vista in 32bit draufmachen.  :Wink:  Echter Fortschritt!   :Laughing: 

----------

## TMoS_uga

thx Keruskerfuerst

@a.forlorn

Weil ich kein 64Bit System habe ^^

siehe hier: http://de.wikipedia.org/wiki/Yonah#Modelldaten_Core_Duo

Leider nix mit EM64T  :Sad: 

----------

## Knieper

 *TMoS_uga wrote:*   

> was ich will ist ein schnelles schlankes system.

 

Dann musst Du schlanke Software installieren und Bloedsinn deaktivieren. Nach dem Start sieht die Prozessliste bei mir so aus (ohne Initsystem und Kernel):

```

ash

fgetty

syslog-ng

udevd

```

Udev ist leider nicht das Gelbe vom Ei und fuer syslog-ng gibt es Alternativen, wie Multilog [1] und als ash-Ersatz kann man auch shish mal ausprobieren (hab ich bis jetzt nicht).

[1] http://cr.yp.to/daemontools/multilog.html

Oftmals bringt es mehr, seine Arbeitsgewohnheiten zu optimieren. ZB. schnelle Editorhandhabung (vim), bessere Fensterverwaltung (ion3), maechtige Shell (zsh) - je nachdem, was man macht.

----------

## a.forlorn

 *TMoS_uga wrote:*   

> thx Keruskerfuerst
> 
> @a.forlorn
> 
> Weil ich kein 64Bit System habe ^^
> ...

 

Kann der etwa nicht amd64?

----------

## Keruskerfuerst

Nein, ist eine 32Bit CPU.

----------

## Carlo

So Geschichten wie --as-needed, --hash-style=both, prelink und -Bdirect (letzteres leider von upstream abgelehnt) sind schon nicht schlecht, aber insbesondere bei den Linker Flags sollte man doch wissen was man tut.

----------

## Klaus Meier

Was mir in der letzten Zeit aufgefallen ist: Gentoo ist sehr schnell.

Ich hab da vor einiger Zeit ja selber einen Thread gestartet, weil da einige Sachen geklemmt haben und das Laden ewig dauerte. Da waren wohl einige Pakete nicht ganz optimal. Meinte auch mal was über ein Speicherleck im X-Server gelesen zu haben. Ich nutze keine agressive Optimierung, habe nichts weiter geändert und trotzdem fühlt es sich alles viel schneller an als noch vor ein paar Monaten.

Habs auch mal spaßeshalber mit den Startzeiten von Ubuntu und Arch verglichen. Und dann auf dem Desktop ein paar Anwendungen starten. Da liegt Gentoo vorne. Naja, nicht die Welt, aber so 10-20%. Und das, obwohl Ubuntu ja den Startvorgang für die neue Version beschleunigt haben soll. Und bei Arch liefen weniger Dienste. Also vor ein oder zwei Jahren lief Ubuntu bei mir mal deutlich flüssiger als Gentoo, da wollte ich mir unbedingt Ubuntu antun.

Hab zur Zeit so ein halbes Gnome 2.18 drauf, naja, die Pakete, die schon fertig sind. Vielleicht haben die auch noch mal Schub gebracht. Aber ich bekomme bei mir Startzeit bis zum gdm Login 30 Sekunden. Und mit einloggen ist das ganze dann in ca. 50 Sekunden fertig, werde da vielleicht mal Autologin aktivieren, um das besser stoppen zu können. Kann mich entsinnen, dass das schon mal 20 Sekunden mehr waren.

----------

## Mr. Anderson

So, ich habe eben einen Mini-Benchmark gemacht. Sehr viele Sprünge und sehr viele Integer-Operationen. Unter Anderem habe ich auch -fprofile-generate und -fprofile-use getestet:

Das Ergebnis kurz zusammengefasst, nach Platzierung:

```
-O2 -fomit-frame-pointer -fgcse-after-reload -fprofile-use

-O2 -fomit-frame-pointer -fgcse-after-reload -march=pentium4 -fprofile-use

-O2 -fomit-frame-pointer -fgcse-after-reload -march=pentium4

-O2 -fomit-frame-pointer -fgcse-after-reload -mtune=pentium4 -fprofile-use

-O2 -fomit-frame-pointer -fgcse-after-reload -mtune=pentium4

-O2 -fomit-frame-pointer -fgcse-after-reload
```

Wie man vermuten würde, brachte ein mtune=arch etwas Leistungsgewinn.

Ebenso noch einmal march=arch. Allerdings nur ohne profile-use.

Etwas überraschend fand ich, dass profile-use bis zu 20% Leistungsschub brachte.

Mit profile-use war das Ergebnis von mtune vernichtend. profile-use brachte rein gar nichts. Es gab sogar eher eine leichte Tendenz zu einer schlechteren Laufzeit.

Auch sehr enttäuschend war march. Diese aggressive Optimierung schnitt in Kombination mit profile-use zwar ein wenig besser ab als ohne profile-use, war aber immer noch schlechter als die Standardeinstellung i386 für march und mtune mit profile-use.

Ohne Prozessor-spezifische Optimierungen brachte profile-use hingegen etwa 20% Gewinn.

Bereits march=i486 bedeutete empfindliche Geschwindigkeitseinbußen.

Aber: -mmmx -msse -msse2 zusätzlich zu dem besten Ergebnis, das für den 386er optimiert war, gab noch einmal einen Gewinn von 5 bis 10%.

Sieger war also:

```
-O2 -fomit-frame-pointer -fgcse-after-reload -fprofile-use -mmmx -msse -msse2
```

mit march= oder mtune= schmierte das Ergebnis ab auf Werte, kaum besser als

```
-O2 -fomit-frame-pointer -fgcse-after-reload
```

-O1 brachte übrigens nur mittelmäßige Ergebnisse. Man könnte natürlich noch -O1 und einige Optionen von -O2 dazunehmen, aber das führt mir dann doch zu weit. ^^

Kurz: ein ziemlich ernüchterndes Ergebnis. Bereits ein march=i486 kann empfindliche Leistungseinbußen nach sich ziehen. Wirklich hochoptimieren lassen sich Binaries anscheinend mit -fprofile-generate, möglichst ausfühlicher Nutzung des Programms und anschließend -fprofile-use. Natürlich hängt das auch vom Code ab. Wenn da bereits in der Richtung optimiert wurde, lässt sich da natürlich nicht mehr viel rausholen.

Wie dem auch sei: Das war ein Spezialfall. Sollte das halbwegs auf den allgemeinen Fall übertragbar sein, dürften sich die Distributoren freuen, da sie abwärstkompatiblen, eher kleinen Code mit hoher Leistung ausliefern können, ohne befürchten zu müssen, dass er langsamer läuft als mit aggressiven, abwärtsinkompatiblen Optimierungen. Konsequenterweise sollte dann sogar -mtune nicht verwendet werden. Insbesondere lohnt es sich bei Binaries von Distributionen, profile-generate und profile-use einzusetzen. Im Einzelfall ist der Aufwand unverhältnismäßig hoch.

----------

## think4urs11

Um 'optimale' CFlags zu finden gibt es auch noch app-benchmarks/acovea, siehe z.B. Acovea analysis results against real world programs

Und noch mehr zum Thema Optimieren z.B. hier: HOW TO OPTIMIZE AND ACCELERATE YOUR SYSTEM

----------

## teaser

 *Quote:*   

> blu3bird hat Folgendes geschrieben:
> 
> Wenn du's wirklich schnell haben willst kompilier's nicht mit dem sys-devel/gcc sondern mit dev-lang/icc

 

Das hört sich ja interessant an. Den icc find ich bei mir zwar unter /opt/intel/icc

Gibt es dazu Erfahrungen, man-pages, wiki ? 

[Edit: hat sich erledigt. Hab grad mal nach icc gesucht. Mehr als genug gefunden.]

Da ich z.zt. direkt hinter dem ersten magischen reboot bin, hatte ich schon damit spekuliert das 

System icc-optimiert zu kompilieren. 

 *Quote:*   

> TMoS_uga hat Folgendes geschrieben:
> 
> also das mir dem icc vergessen wir dann wohl

 

Entweder hab ich was überlesen....

Ich bin die ganze Zeit davon ausgegangen, Du benutzt gcc

Eine -O3 Einstellung ist für gcc experimentell/was zum testen.

Für icc aber Standard. 

icc-settings:

-O2 = optimal

-O3 = intel highspeed optimiertLast edited by teaser on Mon Apr 23, 2007 7:55 pm; edited 1 time in total

----------

## tost

Gibt es von diesem Howto flying with Gentoo keine Fortsetzung mehr in einem Wiki oder so ?

Weil da vieles noch als "coming soon" beschrieben wird. Ich fande da immer super Tipps und Ideen für Optimierungen auch wenn es ja schon 3 Jahre alt ist !

Zum optimieren selber:

Nutze was schmales vlt XFCE anstelle des kompletten KDE oder wie schon angesprochen mit den ganzen anderen Anwendungen oder Anwendungsgewohnheiten. 

Würde mich da nicht so in das Tuning mit dem ganzen CFlags Zeug verbeißen !

tost

----------

## Mr. Anderson

Sehr effektiv wäre es, dem gcc-Projekt zu helfen. Da mangelt es derzeit an Entwicklern, die Fehlerberichte abarbeiten und entsprechend ordentlich patchen. Der gcc 4 hat noch erhebliches Verbesserungspotenzial.

----------

## ichbinsisyphos

 *Mr. Anderson wrote:*   

> So, ich habe eben einen Mini-Benchmark gemacht. Sehr viele Sprünge und sehr viele Integer-Operationen. Unter Anderem habe ich auch -fprofile-generate und -fprofile-use getestet:
> 
> Das Ergebnis kurz zusammengefasst, nach Platzierung:
> 
> ```
> ...

 

wo kann man die cflags nachschlagen? google kennt davon kaum was. und -fprofile-generate macht bei mir sys-apps/sandbox unbrauchbar.

----------

## UTgamer

 *Think4UrS11 wrote:*   

>  *TMoS_uga wrote:*   gibt es noch weitere tuning-möglichkeiten? 
> 
> wer unbedingt mit Compiler(optionen) herumspielen will: 1 2 3 4
> 
> aber auch vieles was mehr auf Anwendungsebene liegt
> ...

 

Hier sind wirklich mit die besten Tuningtips vereint, super gesammelt Think4UrS11.   :Very Happy: 

Deinen 3. Link nochmal nach Jahren zu lesen war mal wieder sehr wertvoll.

- adblocker - auch hier im Einsatz  :Smile: 

- /tmp als tmpfs zum compilen mounten - auch hier im Einsatz  :Smile: 

Hier mein Script /usr/local/bin/temerge für Leute die sehr viel RAM im Rechner haben. Man kann gut mit 800MB RAM aufwärts für eine RAMDISK arbeiten:

```
#!/bin/bash

# http://de.gentoo-wiki.com/Arbeiten_mit_tmpfs

# http://forums.gentoo.org/viewtopic-t-352458-highlight-var+l%F6schen.html

file=/var/tmp/portage/.keep

if [[ -e $file ]]

then

      mount -t tmpfs tmpfs -o size=1438M /var/tmp/portage;

echo "Mounting 1438MB of physical RAM to /var/tmp/portage";

sleep 2;

echo -e "emerging ${*} ....\n";

emerge $*;

cd ;

umount /var/tmp/portage;

echo "/var/tmp/portage is unmounted";

fi

# x11-libs/wxGTK kommt mit 850MB nicht aus.
```

Also anstatt # "emerge foo" kann man obiges nutzen: # 'temerge foo' Und schon sind große Compilate in wenig Zeit erledigt. Das ist tuning pur.

----------

## think4urs11

 *UTgamer wrote:*   

> Hier sind wirklich mit die besten Tuningtips vereint, super gesammelt Think4UrS11.  
> 
> Deinen 3. Link nochmal nach Jahren zu lesen war mal wieder sehr wertvoll.

 

Um die Fahne ausnahmsweise mal für die (zu Recht[?] oft) gescholtene Forensuche hochzuhalten - dazu waren lediglich 5 Minuten mit 'ihr' nötig  :Wink: 

Dazu kommen natürlich noch Tips für jede einzelne Applikation

- Cachegröße bei dnsmasq

- das 'richtige' MPM für Apache bzw. einen leichteren httpd benutzen (im Extremfall fnord)

- Cachegrößen by Mysql, saubere Tabellen, Indexe, etc.

- in-memory/on-disk caching, max. Objektgrößen bei Squid

- ipv6 in Firefox abschalten (about:config network.dns.disableIPv6)

- .....

----------

## UTgamer

Ich möchte hier mal meine CFlags für AMD64 vorstellen, wirklich fast jede Anwendung läßt sich damit sauber und schnell kompilieren. Selbst das größte mir bekannte Softwarepaket OpenOffice startet damit innnerhalb von 2 Sekunden.  :Very Happy: 

Nur diese nicht, da sie nicht eine reine 64 Bit Anwendung ist.

```
sys-devel/gdb

      Latest version available: 6.6-r2

      Latest version installed: 6.6-r2

      Size of downloaded files: 14.535.755

      Homepage:    http://sources.redhat.com/gdb/

      Description: GNU debugger

      License:     GPL-2 LGPL-2
```

Hier sind sie:

```
CFLAGS="-march=athlon64 -O2 -mmmx -m3dnow -msse -msse2 -mfpmath=sse,387 -pipe -ffast-math -m64"
```

Ist wirklich absolut stabil.

Bei jedem emerge kommt zwar immer der Hinweis das man nicht "-ffast-math" und "-m64" verwenden soll, aber das ist unsinnig. 

-ffast-math, hat eine ~ zum Quadrat höhere Genauigkeit als unter 32 Bit. Also es kann bedenkenlos in 64 Bit eingesetzt werden. Ich habe keinerlei Probleme entdecken können. Und -m64 sorgt dafür das kein 32 Bitcode dabei ist, was wohl bei sys-devel/gdb nicht der Fall ist, ich frage mich warum das auf stable steht.

So einen stabilen schnellen Rechner wie meinen habe ich noch nirgends anderswo gesehen.

Allen AMD64 Nutzern viel Spaß beim nachmachen.   :Laughing: 

----------

## Mr. Anderson

 *UTgamer wrote:*   

> 
> 
> ```
> CFLAGS="-march=athlon64 -O2 -mmmx -m3dnow -msse -msse2 -mfpmath=sse,387 -pipe -ffast-math -m64"
> ```
> ...

 

Warum nur?  Es geht doch so viel einfacher. ^^

-march=athlon64 impliziert

-mmmx

-md3now

-msse

-msse2

das ist also haargenau das Gleiche wie:

```
CFLAGS="-march=athlon64 -O2 -mfpmath=sse,387 -pipe -ffast-math -m64"
```

btw: GCC 4.2.0 steht vor der Tür. Soll schnellere Ergebnisse liefern als der 4.1.0

----------

## UTgamer

 *Mr. Anderson wrote:*   

>  *UTgamer wrote:*   
> 
> ```
> CFLAGS="-march=athlon64 -O2 -mmmx -m3dnow -msse -msse2 -mfpmath=sse,387 -pipe -ffast-math -m64"
> ```
> ...

 

Nein ist nicht das gleiche!

Du hast man gcc noch nicht gelesen. Dort steht für diejenigen die nicht lesen wollen:

```
Options That Control Optimization

-O

-O1 Optimize.  Optimizing compilation takes somewhat more time, and a lot more memory for a large func-

    tion.

    With -O, the compiler tries to reduce code size and execution time, without performing any optimiza-

    tions that take a great deal of compilation time.

    -O turns on the following optimization flags: -fdefer-pop -fdelayed-branch -fguess-branch-probability

    -fcprop-registers -floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-domi-

    nator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename -ftree-fre -ftree-ch

    -fmerge-constants

    -O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging.

    -O doesn't turn on -ftree-sra for the Ada compiler.  This option must be explicitly specified on the

    command line to be enabled for the Ada compiler.

-O2 Optimize even more.  GCC performs nearly all supported optimizations that do not involve a space-

    speed tradeoff.  The compiler does not perform loop unrolling or function inlining when you specify

    -O2.  As compared to -O, this option increases both compilation time and the performance of the gen-

    erated code.

    -O2 turns on all optimization flags specified by -O.  It also turns on the following optimization

    flags: -fthread-jumps -fcrossjumping -foptimize-sibling-calls -fcse-follow-jumps  -fcse-skip-blocks

    -fgcse  -fgcse-lm -fexpensive-optimizations -fstrength-reduce -frerun-cse-after-loop  -fre-

    run-loop-opt -fcaller-saves -fpeephole2 -fschedule-insns  -fschedule-insns2 -fsched-interblock

    -fsched-spec -fregmove -fstrict-aliasing -fdelete-null-pointer-checks -freorder-blocks  -fre-

    order-functions -funit-at-a-time -falign-functions  -falign-jumps -falign-loops  -falign-labels

    -ftree-vrp -ftree-pre

    Please note the warning under -fgcse about invoking -O2 on programs that use computed gotos.

-O3 Optimize yet more.  -O3 turns on all optimizations specified by -O2 and also turns on the -fin-

    line-functions, -funswitch-loops and -fgcse-after-reload options.

-O0 Do not optimize.  This is the default.

-Os Optimize for size.  -Os enables all -O2 optimizations that do not typically increase code size.  It

    also performs further optimizations designed to reduce code size.
```

^^ Also hier finde ich meine gesetzten unter -O2 schon mal nicht, lassen wir mal weiter schauen:

```
[u]k8[/u], [u]opteron[/u], [u]athlon64[/u], [u]athlon-fx[/u]

AMD K8 core based CPUs with x86-64 instruction set support.  (This supersets MMX, SSE, SSE2,

3dNOW!, enhanced 3dNOW! and 64-bit instruction set extensions.)
```

Gut hier sind einige drinnen, wie diese hier: MMX, SSE, SSE2, 3dNOW.

Aber inspiriert durch diesen Text aus man gcc:

```
-mmmx

-mno-mmx

-msse

-mno-sse

-msse2

-mno-sse2

-msse3

-mno-sse3

-m3dnow

-mno-3dnow

    These switches enable or disable the use of instructions in the MMX, SSE, SSE2 or 3DNow! extended

    instruction sets.  These extensions are also available as built-in functions: see X86 Built-in Func-

    tions, for details of the functions enabled and disabled by these switches.

    To have SSE/SSE2 instructions generated automatically from floating-point code (as opposed to 387

    instructions), see -mfpmath=sse.

    These options will enable GCC to use these extended instructions in generated code, even without

    -mfpmath=sse.  Applications which perform runtime CPU detection must compile separate files for each

    supported architecture, using the appropriate flags.  In particular, the file containing the CPU

    detection code should be compiled without these options.
```

Zusammen mit:

```
-sse,387

    Attempt to utilize both instruction sets at once.  This effectively double the amount of avail-

    able registers and on chips with separate execution units for 387 and SSE the execution resources

    too.  Use this option with care, as it is still experimental, because the GCC register allocator

    does not model separate functional units well resulting in instable performance.
```

Liest sich heraus das er zwei (-sse,387) Co-Prozessoren gleichzeitig parallel verwenden soll. Nun oft sind die Anweisungen im Quelltext nur: fpu ..... , welchen Coprozessor der Kompiler nun verwendet ist ihm anscheinend selbst überlassen. Nun meist nimmt er i387, aber ich hatte woanders gelesen das sse und sse2 eine schnellere FPU-Einheit sein sollen als i387. Nun soll er also nicht extra spezifizierte FPU-Anweisungen bevorzugt als SSE(2) ausführen, und wenn deren Register ausgelastet sind noch zusätzlich parallel die von i387. Daher scheint es Sinn zu machen irgendwie die anderen Anweisungen noch hinzuzufügen. Ob nun wen SSE(2) + i387 gleichzeitig noch mmx oder 3DNow ausgeführt werden können ist mir hier nicht bekannt. Ich traue den in "athlon64" integrierten Anweisungen einfach nicht das gleiche zu. Speziel da ich nichts über die parallele Nutzung finden kann.  :Wink:  Als wichtig anzumerken ist noch das die allererste Athlon64 CPU auf dem Markt überhaupt noch keine SSE2 Einheit besaß, also wie behandelt das Flag die allererste Serie, woher weis der Compiler das es die CPU ohne SSE2 ist?

Nun gibt es noch diese beiden Flags. "-ffast-math" galt unter dem gcc3.x.x sogar mal als stabil.

```
-ffast-math

    Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -ffinite-math-only,

    -fno-rounding-math, -fno-signaling-nans and fcx-limited-range.

    This option causes the preprocessor macro "__FAST_MATH__" to be defined.

    This option should never be turned on by any -O option since it can result in incorrect output for

    programs which depend on an exact implementation of IEEE or ISO rules/specifications for math func-

    tions.
```

und

```
-m64

    Generate code for a 32-bit or 64-bit environment.  The 32-bit environment sets int, long and pointer

    to 32 bits and generates code that runs on any i386 system.  The 64-bit environment sets int to 32

    bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture.
```

Bei wirklich jedem emerge Vorgang wird vor beiden Flags unnötiger Weise gewarnt. Nun wenn sie deiner Meinung nach das gleiche sind, warum warnt den emerge davor?

Da -ffast-math auf einem 64 Bit Prozessor ~ zum Quadrat genauer ist als auf einem 32 bittigen, und ich es hier ohne Probleme als default im System laufen habe, zeigt auch dies eine wirklich höhere Performance. Ich habe wirklich 0 Probleme gefunden.  :Very Happy: 

-m64, alle Zeiger werden auf 64 bittige Register umgelengt, nun es resultiert wohl daraus so wie ich es verstanden habe wohl ein etwas höherer Speicherverbrauch wegen der Pointer. Auch hier merkte ich einen geringen Performancevorteil.  :Wink: 

---------

Ich gedenke auch noch weiter zu optimieren, und spiele mit dem Gedanken auch dieses weniger bekante Flag mal auszutesten. 

```
-malign-double

-mno-align-double

    Control whether GCC aligns "double", "long double", and "long long" variables on a two word boundary

    or a one word boundary.  Aligning "double" variables on a two word boundary will produce code that

    runs somewhat faster on a Pentium at the expense of more memory.

    Warning: if you use the -malign-double switch, structures containing the above types will be aligned

    differently than the published application binary interface specifications for the 386 and will not

    be binary compatible with structures in code compiled without that switch.
```

Bei weiteren Flags bin ich noch am Überlegen, aber das letzte klingt echt wie der Überhammer.

PS:

Ich habe mir die Tage noch ein Debian - Etch - 4.0 - 64, auf die Platte installiert gehabt. Und einige Anwendungen wie z.B. Worker und weitere aus der KDE-Gruppe funktionieren selbst auf dem mit dem -Os optimierten Debian 64 ohne irgendwelche Probleme.

Und es wird stabil sicher noch schneller gehen können.   :Laughing: 

[Hinweis] Dieser Text ist sehr lesenswert für alle die am Optimieren Interresse haben.

http://www.wikiservice.at/dse/wiki.cgi?CeeCompilerGcc

----------

## Keruskerfuerst

Bevor Du (das darf ich doch sagen), so schlau daherredest, solltest Du Dir

a) entweder den Sourcecode selbst

b) oder das richtige Compilermanual (dies ist nicht die Onlineversion)

durchlesen

 :Idea: Last edited by Keruskerfuerst on Mon Apr 30, 2007 8:00 pm; edited 1 time in total

----------

## UTgamer

Du Keruskerfuerst (ja duzen ist ok), wenn ich irgendwo hängen bleibe weil etwas nach dem kompilieren mal nicht mehr funktionieren sollte, werde ich auch aus eigenem Interresse dort nachlesen. Aber bisher läuft das ganze System ja sauber und stabil, also zur Überschrift: "Auf Leistung optimieren" passen meine Erfahrungen doch ganz gut.

Ich habe damals zu meinen Amiga Zeiten (88-95) Assembler auf dem m68k programmiert gehabt, leider ist die Intel-Architektur durch Big-Endian zu Little-Endian so miese in Assembler zu programmieren das ich es wieder aufgegeben habe. Aber was Befehls-und Datenregister sowie deren Ansteuerung sind weis ich nun  wohl noch sehr genau.  :Wink:  C/C++ hatte ich kurz in meiner Netzwerkadminausbildung (CNE), hatte mir aber garnicht gelegen. Programmierung auf der i386 Architektur liegt mir nicht.

PS: Neige aber manchmal dazu übers Ziel hinaus zu laufen (bin manschmal recht ehrgeizig und jemand muß mich bremsen). *g*

Ja bezüglich paralleler Verarbeitungen sollte ich wirklich mal die C Dokus lesen, weil woanders werde ich sicher kaum fündig.

----------

## Mr. Anderson

 *UTgamer wrote:*   

> Nein ist nicht das gleiche!

 

Doch  :Razz: 

 *Quote:*   

> Du hast man gcc noch nicht gelesen.

 

Schon des Öfteren.  :Wink: 

 *Quote:*   

> Also hier finde ich meine gesetzten unter -O2 schon mal nicht

 

Hab ich auch nicht behauptet.

 *Quote:*   

> lassen wir mal weiter schauen:
> 
> ```
> [u]k8[/u], [u]opteron[/u], [u]athlon64[/u], [u]athlon-fx[/u]
> 
> ...

 

Genau das habe ich geschrieben. Mehr nicht.

Der Rest mag ja stimmen, ändert aber an Obigem nichts  :Wink: 

----------

## slick

 *Keruskerfuerst wrote:*   

> Der Kernel sollte (komprimiert) nicht größer als 1,5MB sein

 

Warum eigentlich? Ich dachte immer die Kernelgröße ist nur von Bedeutung auf historischen Rechnern. Da ich gern den Kernel ohne Modulsupport baue wird der schonmal sehr groß. Daher würde mich gern mal interessieren ob das auf aktuellen Rechnergenerationen auch noch zutrifft und wenn ja "warum?".

btw, hier die passende Umfrage zu euren CFLAGS: https://forums.gentoo.org/viewtopic-t-557167.html

----------

## obrut<-

@utgamer:

alle, ja alle, athlon64 haben sse2 an bord. alle.

sse3 haben nur die "neueren".

mfpmath=i387,sse macht nicht sonderlich viel sinn, da alle cpus mit amd64 befehlssatz, auch die von intel, im 64 bit modus 16 sse-register haben, statt wie bisher nur 8. der vorteil durch die höhere registerzehl bei verwenung der i387-register dürfte daher in der praxis gegen null gehen. bringen würde es nur was, wenn für klassische fpu-befehle und sse-befehle separate schaltkreise vorhanden wären, was beim k8 nicht der fall ist. der inhalt der 128 bit breiten sse-register wird daher in happen zu 64 bit durch die fpu geschoben und verarbeitet.

ob p4 und core cpus separate sse- und i387-einheiten haben, weiß ich nicht. der pentium m machts jedenfalls so wie der k8 und verarbeitet immer nur 64 bit große happen.

----------

## energyman76b

 *TMoS_uga wrote:*   

> was ich will ist ein schnelles schlankes system.
> 
> schnell im booten, schnell im anwendungen starten.
> 
> wenn ich das hier so lese, dann lass ich das wohl mit den cflags und dem prelinken.
> ...

 

wieso prelinken weglassen? Gerade das bringt richtig viel! Es macht die Dateien nicht kleiner, es macht die Programme auch nicht schneller - aber die Startzeiten werden deutlichst reduziert.

----------

## UTgamer

@obrut, thx, deinen Beitrag werde ich mir mal auf die Platte legen und weiterverarbeiten. Es klingt nicht nur logisch, nein es erklärt auch warum mein System noch immer stabil ist trotz einer Beschleunigung.  :Wink: 

Als ich meine Flags so umgestellt hatte liefen wirklich fast alle Anwendungen schneller, erst recht die bildverarbeitenden Progs, gqview ist nun enorm beschleunigt auch in den Previefenstern die immer eine Ewigkeit brauchten.

Bezüglich -malign-double, hierfür müßte ich mein System von Anfang an neubauen.

Nun da wären ein paar 32 Bit Anwendungen wie Teamspeak und Quake4 die nur als Binaries erhältlich sind, jetzt frage ich mich ob die in der 32 Bit-Emulation noch laufen.

Bei Turboprint64 oder der Unreal2004-64-Bit-Binary von iculus bin ich mir sicher das die nicht mehr laufen, sollten die 32bit Bins im Emumodus aber noch funktionieren, würde ich UT2004 downgraden auf 32 Bit.

Höchstwahrscheinlich würde aber auch die 32-Bit Emulation keine Bins ohne -malign-double mehr schlucken.

Weiss da jemand etwas zu? 

Habe gerade nicht soviel Zeit mich durch englische Dokumente zu wühlen, wobei ich diese Kombi sowieso wieder nirgends finden werde. Evtl. bin ich ja auch komplett aufm Holzweg.

----------

## energyman76b

 *UTgamer wrote:*   

> @obrut, thx, deinen Beitrag werde ich mir mal auf die Platte legen und weiterverarbeiten. Es klingt nicht nur logisch, nein es erklärt auch warum mein System noch immer stabil ist trotz einer Beschleunigung. 
> 
> Als ich meine Flags so umgestellt hatte liefen wirklich fast alle Anwendungen schneller, erst recht die bildverarbeitenden Progs, gqview ist nun enorm beschleunigt auch in den Previefenstern die immer eine Ewigkeit brauchten.
> 
> Bezüglich -malign-double, hierfür müßte ich mein System von Anfang an neubauen.
> ...

 

laß malign-double.

Es wird wahrscheinlich außer viel Ärger nichts bringen - und der Hinweis, daß es schneller laufen könnte bezog sich auf Pentium - nicht Pentium II, III oder IV.

Also laß die Finger davon. Es wird dir nur Probleme bringen und nichts verbessern.

----------

## mv

 *UTgamer wrote:*   

> Nun gibt es noch diese beiden Flags. "-ffast-math" galt unter dem gcc3.x.x sogar mal als stabil.
> 
> ```
> -ffast-math [...] since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.
> ```
> ...

 

Du zitierst hier Deine eigene Widerlegung (IIRC stand das auch schon bei gcc3* so oder so ähnlich in der manpage - und mit Recht). Sicherlich, die meisten Programme brauchen z.B. keine korrekte Behandlung von Zahlenüberläufen u.ä., aber der Ausgabe eines Spreadsheet oder ein wissenschaftlichen Programms würde ich nicht trauen, wenn auch nur eine seiner Bibliotheken damit kompiliert würde. Klar, "stabil" läuft das Programm vermutlich trotzdem noch - was aber nicht heißen muss, dass das Ergebnis das richtige ist...

 *Quote:*   

> 
> 
> ```
> -m64 [...]  The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture.
> ```
> ...

 

[Loriot] Mit Deinem Gefühl stimmt etwas nicht. [/Loriot]

Es ist zwar richtig: Mit -m64 wird "long" 64 Bit lang, ebenso wie Pointer. Aber die Kompilation eines kleinen Testprogramms wird Dir zeigen, wie lange diese beiden Datentypen auf einem 64-Bit-System ohne diese Option sind (Hint: -m64 ist dort default).

 *Quote:*   

> Bei wirklich jedem emerge Vorgang wird vor beiden Flags unnötiger Weise gewarnt.

 

Vollkommen zu recht. Das einzige, was -m64 in den CFLAGS bewirkt, ist, dass bei den Programmen, bei denen das ebuild/configure ausdrücklich ein -m32 zu den CFLAGS hinzufügt (normalerweise, weil der Paketautor/-maintainer weiß, dass dies für das Funktionieren des Codes notwendig ist) dieses möglicherweise wirkungslos wird, falls das ebuild nicht auch das vollkommen unnötige und nur störende -m64 filtert...

----------

## UTgamer

@ energyman76b, gesunder Ratschlag, wenn der Emu-Modus nicht klappt, war das ganze nur reine Zeitverschwendung, einmal hin und wieder zurück gekompiliere.  :Wink: 

@ mv, 

"-ffast-math", ja der Hinweis auf wissenschaftliche Verarbeitungsprogramme ist mir bekannt, ich nutze sie nicht. 

Da ich aber auch auf meinem alten 32 bit-Rechner (siehe Signatur) schon seit 2004 dieses Flag nutze und über die Jahre kaum Probleme hatte, werde ich auf 64 Bit noch viel weniger Probleme haben und habe sie auch nicht.

-m64, der Start von z.B. OpenOffice hat sich beschleunigt, sogar PHP (ich nutze die Opensource SugarCRM-Suite) aufm Apache hat sich verbessert - Formularfelder hacken nun nicht mehr beim Anklicken. Also da hat sich geringfügig einfach etwas getan.

Nun, um allen gerecht zu werden muß die Distrie sich an Standarts halten, solte ja verständlich sein (siehe mögl. Fehler bei wissenschaftl. Berechnungen). Aber einzelne Performance Freaks unterhalten sich auch darüber, und ich kann denen die es nicht beruflich brauchen nur sagen, das ganze System ließ sich stabil bis auf eine einzelne Anwendung sauber installieren und es läuft stabil.  :Wink: 

----------

## energyman76b

 *UTgamer wrote:*   

> @ energyman76b, gesunder Ratschlag, wenn der Emu-Modus nicht klappt, war das ganze nur reine Zeitverschwendung, einmal hin und wieder zurück gekompiliere. 
> 
> @ mv, 
> 
> "-ffast-math", ja der Hinweis auf wissenschaftliche Verarbeitungsprogramme ist mir bekannt, ich nutze sie nicht. 
> ...

 

was ist denn das für eine kaputte Logik?

Außerdem - einer der Gründe, warum du kaum Probleme hattest, ist, daß die meisten ebuilds mit BEKANNTEN Problemen es rausfiltern. Wenn deine Spreadsheet-App irgendwo Rundungsfehler hat, wie bemerkst du das? Oder wenn sich kcalc leicht verrechnet?

----------

## misterjack

 *UTgamer wrote:*   

> -m64, der Start von z.B. OpenOffice hat sich beschleunigt, sogar PHP (ich nutze die Opensource SugarCRM-Suite) aufm Apache hat sich verbessert - Formularfelder hacken nun nicht mehr beim Anklicken. Also da hat sich geringfügig einfach etwas getan.

 

Seit wann hat das Anklicken von Formularfeldern (client-seitig) was mit PHP oder Apache (server-seitig) zu tun? Ich kann mich meinen Vorredner anschließen, kaputte Logik   :Rolling Eyes: 

----------

## UTgamer

 *misterjack wrote:*   

> Seit wann hat das Anklicken von Formularfeldern (client-seitig) was mit PHP oder Apache (server-seitig) zu tun? Ich kann mich meinen Vorredner anschließen, kaputte Logik  

 

Ah, ihr konntet nicht wissen das der PHP/Apache-Server auf dem Client läuft, zuhause ist mein Arbeitsrechner gleichzeitig mein Privatrechner und Server mit verschiedenen User-Profiles, mobile Daten werden ab & zu von einem Laptop eingespeist, Backups auf extra Backupplatten im Rechner, die HW verträgt noch sehr viel mehr, plane seit langem noch einen Sqid aufzuspielen.  :Wink:  Dann ist die Logik nicht mehr kaputt.

 *energyman76b wrote:*   

> ...
> 
> Außerdem - einer der Gründe, warum du kaum Probleme hattest, ist, daß die meisten ebuilds mit BEKANNTEN Problemen es rausfiltern. Wenn deine Spreadsheet-App irgendwo Rundungsfehler hat, wie bemerkst du das? Oder wenn sich kcalc leicht verrechnet?

 Ich nutze keine Anwendungen die bei (64 Bit) Größenordnungen wohl so bei 30 Stellen hinter dem Komma liegen.  

Kcalc, ja ich weiß das es ein minimales Risiko gibt, daher bin ich auch immer Vorsichtig bei Ergebissen aus irgendwelchen Kalkulationsprogs (wie z.B. Steuerabrechnung), hier habe ich dann einen höheren Arbeitsaufwand. Bei Multimedia (Hauptnutzung des Rechners) habe ich hingegen nur große Vorteile.

----------

## mv

 *UTgamer wrote:*   

> "-ffast-math", ja der Hinweis auf wissenschaftliche Verarbeitungsprogramme ist mir bekannt, ich nutze sie nicht.

 

Mir würde es auch genügen, wenn eine für mich wichtige Video-/Soundaufnahme kaputtkodiert würde. Klar, wenn man den Rechner nur zum Abspielen oder Zocken benutzt, ist es egal - da würde ja selbst ein (seltener) Absturz nicht wirklich Probleme bereiten. Ob dann allerdings der geringfügige Geschwindigkeitsvorteil ins Gewicht fällt?

 *Quote:*   

> Da ich aber auch auf meinem alten 32 bit-Rechner (siehe Signatur) schon seit 2004 dieses Flag nutze und über die Jahre kaum Probleme hatte, werde ich auf 64 Bit noch viel weniger Probleme haben und habe sie auch nicht.

 

Das dürfte wohl nichts mit 32/64 Bit zu tun haben. Oder hat float/double auf 64Bit eine andere Länge?

 *Quote:*   

> -m64, der Start von z.B. OpenOffice hat sich beschleunigt, sogar PHP

 

Möglicherweise, weil es nach der Rekompilation an einer günstigeren Stelle der Platte liegt o.ä. - mit -m64 hat das jedenfalls nichts zu tun, weil das eben nichts am erzeugten Code ändert.

----------

## UTgamer

 *mv wrote:*   

>  *UTgamer wrote:*   "-ffast-math", ja der Hinweis auf wissenschaftliche Verarbeitungsprogramme ist mir bekannt, ich nutze sie nicht. 
> 
> Mir würde es auch genügen, wenn eine für mich wichtige Video-/Soundaufnahme kaputtkodiert würde. Klar, wenn man den Rechner nur zum Abspielen oder Zocken benutzt, ist es egal - da würde ja selbst ein (seltener) Absturz nicht wirklich Probleme bereiten. Ob dann allerdings der geringfügige Geschwindigkeitsvorteil ins Gewicht fällt?

 

Ich habe mir die Tage mehrere Landkarten (Maßstab 1:20000) erstellt, von der Größe 7000*7000 Pixel und arbeite darin ohne irgendwelche Probleme, flink im Scrollen und alles, 2-3 Grafikfenster + Browser auf und zwischen denen wird munter umkopiert. Der /tmp-Ordner liegt in einer 256 MB großen Ramdisk, nicht ein Absturz, nicht einmal eine der riesigen Grafiken beschädigt, live beim copy&paste wird von 24-Bit-Grafiken auf 8-Bit Grafiken herunter gerechnet zwischen den Grafiktools. Browser ist 24 Bit, Irfanview im wine laufend ist 24 bittig für die Schneidarbeiten, xv für screenshoots ist 24 bittig, und für meine Zwischenablagen für fertig geschnittene Teile dient kolourpaint vom KDE im 8-Bitmodus.

Gepackt im PNG-Format auf der Platte sind sie allein rund 8,8 MB groß. Das einzige wo ein Fenster mal für rund 5 Sek. blockiert ist wenn ich abspeichere.

Ich habe sie mal gerade aus interresse extra im BMP-Format abgespeichert, das dauerte dafür dann auch nur 1 Sekunde über wine ausm IrfanView, also ungepackt (BMP) ist eine 35 MB groß!

Probleme beim konvertieren von 35MB großen Daten in verschiedene Formate (BMP/GIF/PNG/JPG)  :Question: 

Keine Ahnung was ihr habt, ich finde keine Probleme mit "-ffast-math" oder den anderen Flags. 

Wie sagt man in Mel Brooks - Spaceballs so schön: "Colonel - Wahnsinnige Geschwindigkeit"   :Laughing: 

-----------------

PS - Offtopic:

Das einzige was mir im Linus noch fehlen würde wäre das alte "Deluxe Paint" vom Amiga, ein Tool für alles. Ich würde ja nur das benutzen wenn der scheiß UAE-Emulator unter Linux nicht so beschießen zu konfigurieren und zum Laufen zu bewegen wäre. Unter Windows funktioniert die ein oder andere WinUAE-Version wenigstens sauber.

Kommt mir nicht mit Gimp, a) muß ich dafür Gnome installieren (niemals) und b) habe ich mir das unter Debian mal angesehen, keine richtige deutsche Menüführung und überhaupt überall kann man dran drehen aber wofür die ganzen Sachen sind - ka, einfach mal mehrere Layer einrichten und transparent durchscheinen lassen um sie schön gegeneinander zu verschieben wie das in Deluxe Paint geht, habe ich nicht gefunden, ebenso habe ich die progamminternen Clipboards (schiebe Clipboard 3 auf Layer 4, dann mixe Layer 1 + 4 miteinander damit ich die richtige Position finden kann, dann schalte Layer 2 gegen Layer 4, wobei ich die beiden Grafiken dann merge) nicht gefunden. Hallo Markt&Technik legt das Amiga-Deluxe-Paint wieder neu auf für Linux. Animierte Grafiken (IFF-Format) konnte man damit auch bereits in den 80ern herstellen (Grafikstandart unter Amiga). Wo stelle ich hier unter X und wie kompliziert animierte Desktophintergründe oder Dateimanager-Hintergründe her? Ging alles mit Deluxe-Paint  Linux hat noch einen langen Weg auf dem Desktop vor sich um selbst Desktoptechniken der 80er Jahre irgendwan mal zu erreichen. Windows ist wirklich keine Alternative für Amigaanhänger, hat ja noch nichtmal eine einzige RAM-Disk  :Razz:   Mit Linux-DBUS kommt so ganz ganz langsam mal eine Alternative für das alte Arex, einer DCOP/DBUS Programmiersprache, abgewandelt und kompatibel zum IBM-REX.

Ich bin einfach besseres gewohnt oder auch verwöhnt und muß zusehen wie ich mit den beschränkten Mitteln hier zurecht komme. 

Langsame Amigas gab es nie, ich hätte gerne den gleichen Komfort, und "-ffast-math", tmpfs und viel RAM kommen solangsam auf die 28 MHz Geschwindigkeit die ich auf meinem Motorolla 68030er mit 4 MB RAM und einer Bootgeschwindigkeit von 7 Sekunden nach Powerbuttondrücken bis zum annimierten Desktop hatte. Heute habe ich die 258 fache CPU-Geschwindigkeit, 40 fache RAM-Größe und 37 fache Busgeschwindigkeit, und das System ist immer noch lahmer als früher. (Heul) Die Sprach-Ein/Ausgabe zum Programme starten vermisse ich ebenfalls. Früher einfach ein Alias auf eine Ramdisk gelegt in dem die meist benötigten CLI-Befehle gelegen hatten und das war Geschwindigkeit pur. Heute weiß man ja während eines Arbeitstages ja noch nichtmal wie oft irgend eine der Bins aus /usr/bin wie oft den Tag über gestartet wurden, und alle in eine RAM-Disk legen, geht auch nicht, zur Zeit habe ich in /usr/bin 320 MB drinn, zudem sind die meistbenutzten sowieso nur Scripte die auf irgendwelche Libs verweisen. Also das war früher auch besser gelöst. Die Anwendungsprogramme hatten nichts im Commando-Ordner zu suchen, die packte man als Verknüpfung in die Desktopleiste oder als Icon. Wieviele bins im /usr/bin Verzeichnis habe ich eigentlich noch nie seit Installation gestartet? Hab leider die atime abgeschaltet sonst würde ich direkt mal nachschauen. Weil geil währe ein Initscript welches eine RAM-Disk erstellt und die meist benötigten Befehle darein schiebt (wie ich damals Standart eingerichtet hatte), dann ein Script welches alle anderen nur als Symlink mit dareinlegt. Beim dem Projekt wäre ich sofort mit dabei.

 :Crying or Very sad: 

----------

## mv

 *UTgamer wrote:*   

> Keine Ahnung was ihr habt, ich finde keine Probleme mit "-ffast-math" oder den anderen Flags.

 

Bei den beschriebenen Aktionen dürfte -ffast-math weitestgehend keinen Einfluss haben; der entscheidende Faktor bei der Geschwindigkeit dürfte wohl eher der Festplatten-IO bzw. -Caching sein. Höchstens bei Konvertierung von/zu jpg könnte etwas Fließkommaarithmetik in Benutzung sein. Von daher ist es auch nicht überraschend, dass dabei mit -ffast-math keine Probleme auftreten.

 *Quote:*   

> Kommt mir nicht mit Gimp, a) muß ich dafür Gnome installieren (niemals) und b) habe ich mir das unter Debian mal angesehen

 

a) ist sicherlich falsch. Ich habe Gimp installiert, aber kein Gnome und auch keine Gnome-Libraries.

b) Jedes mächtige Graphikprogramm ist einarbeitungsbedürftig. Es ist natürlich verständlich, dass Du nicht ein neues lernen willst, wenn Du bereits in eines eingearbeitet bist.

 *Quote:*   

> Windows ist wirklich keine Alternative für Amigaanhänger, hat ja noch nichtmal eine einzige RAM-Disk 

 

Was ist tmpfs Deiner Meinung nach?

 *Quote:*   

> Die Sprach-Ein/Ausgabe zum Programme starten vermisse ich ebenfalls.

 

Ich würde erwarten, dass Du in app-accessibility etwas dafür findest (sphinx?)

 *Quote:*   

> Weil geil währe ein Initscript welches eine RAM-Disk erstellt und die meist benötigten Befehle darein schiebt

 

Ziemlich blödsinnig wäre das, weil der Fesplatten-Cache des Betriebssystems das Ram viel efffizienter nutzt (indem eben automatisch die selten benutzten Sachen herausfliegen und für das häufig benutzte Platz machen) - sowas gab es unter dem Amiga natürlich nicht, deswegen musste man sich mit Ramdisk behelfen. Wenn es Dir nur um das schnelle Starten beim ersten Aufruf geht (und Du dafür beim Booten länger warten willst) kannst Du ja ein Script schreiben, das die betreffenden Programme lädt (und ggf. unmittelbar darauf wieder killt). Was vielleicht sinnvoll wäre, wäre eine Möglichkeit, gezielter auf die Cache-Strategie Einfluß zu nehmen (etwa indem man bestimmte Teile angeben kann, die bevorzugt im Cache gehalten werden sollen; sinnvoll wäre es, wenn man das dann über Neubooten hinweg speichern können) - dazu solltest Du Dich allerdings an die Filesystem-Maintainer wenden.

----------

## UTgamer

 *mv wrote:*   

>  *UTgamer wrote:*   Keine Ahnung was ihr habt, ich finde keine Probleme mit "-ffast-math" oder den anderen Flags. 
> 
> Bei den beschriebenen Aktionen dürfte -ffast-math weitestgehend keinen Einfluss haben; der entscheidende Faktor bei der Geschwindigkeit dürfte wohl eher der Festplatten-IO bzw. -Caching sein. Höchstens bei Konvertierung von/zu jpg könnte etwas Fließkommaarithmetik in Benutzung sein. Von daher ist es auch nicht überraschend, dass dabei mit -ffast-math keine Probleme auftreten.

 

Jetzt bin ich aber überrascht, Photobearbeitung in JPG steht gerade nicht auf meiner todo-Liste, ich werde meine Ohren mal offenhalten, weil meine Frau auf dem anderen Rechner ebenfall mit "-ffast-math" dieser Tage einige Photos bearbeiten will, ich werde sie mal fragen ob sie auf dem Athlon XP irgend etwas negatives bei der Photobearbeitung auszusetzen hat. 

(Seltsam, als ich noch Assembler auf dem Amiga programmierte habe ich jeden Co-Prozezzor mit eingebunden gehabt den es gab, um jedwede Geschwindigkeit auszureizen, die FPU hatte einen nicht unbeachtlichen Anteil daran, ich schrieb CPU-Instructions zur Anweisung die gefüllten FPU-Register Päckchenweise nummeriert auf vordefinierte Arrays zu schieben, die FPU-Datenpäckchen in Registergröße im Array vorzuhalten war eine sehr schnelle Methode sie von CPU und Grafikchips direkt  wieder in die Register schieben zu können zur Weiterverarbeitung. Es war etwas kniffelig, aber brachte die schnellsten Programme hervor. Ich habe das Programmieren wegen der Little-/Big-Endian Umstellung vor Jahren aufgegeben.) 

Zudem gerade bei JPGs wie du auch erwähntest fällt es doch mal nicht auf, ob ein einzelnes Pixel statt dem Helligkeitswert 255*255*255 durch einen Rundungsfehler mal 255*254*255 zu erhalten. Ich dachte aber mit der mittlerweile gegen früher viel höheren Nachkommastelle würde es für alle Grafikdaten einfach unnötig werden noch Integer als (Bild-/Audio-)Daten zu verwenden. Bei jedem CD-Brennvorgang mit höherer Geschwindigkeit werden zwar die Daten nach dem Brennen meist mit dem Original verglichen, aber auf jedem anderem lesendem Laufwerk ist die Fehlerrate und damit Korrektur durch Spur- , Staub, Kratzer, Fett und Herstellungsfehlern die Fehlerwarscheinlichkeit höher als bei einem FPU-Rundungsfehler. 

https://forums.gentoo.org/viewtopic-p-4054106.html#4054106

PS - Offtopic:

 *mv wrote:*   

>  *Quote:*   Kommt mir nicht mit Gimp, a) muß ich dafür Gnome installieren (niemals) und b) habe ich mir das unter Debian mal angesehen 
> 
> a) ist sicherlich falsch. Ich habe Gimp installiert, aber kein Gnome und auch keine Gnome-Libraries.
> 
> b) Jedes mächtige Graphikprogramm ist einarbeitungsbedürftig. Es ist natürlich verständlich, dass Du nicht ein neues lernen willst, wenn Du bereits in eines eingearbeitet bist.

 

Ich habe einen WOW-Effekt, vor längerer Zeit wollte das Ebuild noch Gnometeile mitinstallieren. Schön das du mich darauf aufmerksam gemacht hast das dies nicht mehr der Fall ist, kann ich ja jetzt nochmal schauen ob es meine Wünsche erfüllen kann (die Entwicklung steht ja nicht).

 *mv wrote:*   

>  *Quote:*   Windows ist wirklich keine Alternative für Amigaanhänger, hat ja noch nichtmal eine einzige RAM-Disk  
> 
> Was ist tmpfs Deiner Meinung nach?

 

Aneinander vorbei geredet, ich meinte MS-Windows, das hat nämlich 0 (außer dem internen Cache). Hier auf meinem Linux nutze ich mehrere tmpfs (RAM-Disks), selbst für den Browsercache von 128 MB.

 *mv wrote:*   

>  *Quote:*   Die Sprach-Ein/Ausgabe zum Programme starten vermisse ich ebenfalls. 
> 
> Ich würde erwarten, dass Du in app-accessibility etwas dafür findest (sphinx?)

 

Werde ich mir mal ansehen, ich hatte noch nicht für alles Zeit.

(Sprachsynthese zum Vorlesen von Texten war bereits ins System integriert, mußte man nur Entsprechungen für Deutsch selbst definieren wie er z.B. ein ö aussgeben soll). Eingabe ja ging auch nur über Zusatztools, meist war bei 40-80 Worten Schluß. Stand jetzt bei mir mal hinten an, vermisse ich aber so langsam. Kommt auch bald drann, jetzt wo das System meinen Vorstellungen langsam entspricht (lange Jahre Arbeit war das).

 *mv wrote:*   

>  *Quote:*   Weil geil währe ein Initscript welches eine RAM-Disk erstellt und die meist benötigten Befehle darein schiebt 
> 
> Ziemlich blödsinnig wäre das, weil der Fesplatten-Cache des Betriebssystems das Ram viel efffizienter nutzt (indem eben automatisch die selten benutzten Sachen herausfliegen und für das häufig benutzte Platz machen) - sowas gab es unter dem Amiga natürlich nicht, deswegen musste man sich mit Ramdisk behelfen. Wenn es Dir nur um das schnelle Starten beim ersten Aufruf geht (und Du dafür beim Booten länger warten willst) kannst Du ja ein Script schreiben, das die betreffenden Programme lädt (und ggf. unmittelbar darauf wieder killt). Was vielleicht sinnvoll wäre, wäre eine Möglichkeit, gezielter auf die Cache-Strategie Einfluß zu nehmen (etwa indem man bestimmte Teile angeben kann, die bevorzugt im Cache gehalten werden sollen; sinnvoll wäre es, wenn man das dann über Neubooten hinweg speichern können) - dazu solltest Du Dich allerdings an die Filesystem-Maintainer wenden.

 

Ja demnächst werde ich meine Augen für alles aus diesem Thema "Cache-Strategie Einfluß" offen halten.

Das über einen Reboot festgehalten werden wäre echt nützlich (damals gab es dafür die resetfeste RAM-Disk, ok aber das war eine MMU-HW-Sache, und ermöglichte einen Reboot nach dem Resetknopf drücken innerhalb von 2 Sekunden).

So jetzt muß ich aber mal los, Heute ist Muttertag  :Wink: 

----------

## mv

 *UTgamer wrote:*   

> Zudem gerade bei JPGs wie du auch erwähntest fällt es doch mal nicht auf, ob ein einzelnes Pixel statt dem Helligkeitswert 255*255*255 durch einen Rundungsfehler mal 255*254*255 zu erhalten.

 

Ich vermute nicht, dass -fast-math Einfluss auf die Rundungsfehler hat. Es geht dabei eher um so Fragen wie, ob z.B. im Falle eines NaN-Zwischenergebnisses (not-a-number, etwa bei Division durch 0, die leicht bei Division durch Differenzen auftreten kann) auch als Endergebnis NaN herauskommt, oder ob der Compilercode das NaN-Flag aus Geschwindigkeitsgründen ignoriert, und man dafür ein "zufälliges" Ergebnis erhält. Ob und ggf. wie sehr sich das auswirkt, hängt natürlich stark von der Anwendung ab, und inwieweit sich deren Implementierung auf das (eigentlich dokumentierte) Verhalten verlässt.

 *Quote:*   

> Sprachsynthese zum Vorlesen von Texten war bereits ins System integriert

 

Kannst Du haben: app-accessibility/speechd

Es gibt aber auch noch app-accessibility/festival und sicher noch weitere.

 *Quote:*   

> damals gab es dafür die resetfeste RAM-Disk

 

Das will man gar nicht mehr brauchen müssen, denn ein Reset ist ja inzwischen höchstens notwendig, wenn irgendeine Hardware oder Kernel/Treiber massive Bugs hat (oder bei einer Kernel-Neukompilation).

 *Quote:*   

> habe ich jeden Co-Prozezzor mit eingebunden gehabt den es gab, um jedwede Geschwindigkeit auszureizen

 

Zwar habe ich mich mit modernen Prozessoren nicht viel beschäftigt, aber so etwas bringt dort vermutlich nicht viel: Die parallelisieren soweit wie möglich ohnehin schon selbständig - es ist da eher wichtig, dass man den Code so schreibt, dass sie die parallel berechneten Ergebnisse auch nutzen können und nicht ganze Queues wegschmeißen müssen (Stichwort: branch-prediction). Wenn man sich dann noch "händisch" (sprich: unter Zuhilfenahme von Code) mit dem Co-Prozessor synchronisieren müsste, hätte man jedweden Vorteil verspielt.

----------

## UTgamer

 *mv wrote:*   

>  *UTgamer wrote:*   Zudem gerade bei JPGs wie du auch erwähntest fällt es doch mal nicht auf, ob ein einzelnes Pixel statt dem Helligkeitswert 255*255*255 durch einen Rundungsfehler mal 255*254*255 zu erhalten. 
> 
> Ich vermute nicht, dass -fast-math Einfluss auf die Rundungsfehler hat. Es geht dabei eher um so Fragen wie, ob z.B. im Falle eines NaN-Zwischenergebnisses (not-a-number, etwa bei Division durch 0, die leicht bei Division durch Differenzen auftreten kann) auch als Endergebnis NaN herauskommt, oder ob der Compilercode das NaN-Flag aus Geschwindigkeitsgründen ignoriert, und man dafür ein "zufälliges" Ergebnis erhält. Ob und ggf. wie sehr sich das auswirkt, hängt natürlich stark von der Anwendung ab, und inwieweit sich deren Implementierung auf das (eigentlich dokumentierte) Verhalten verlässt.

 

Das war das Stichwort NaN-Flag (not-a-number) (damals auf den kleineren 16(32) Bitrechnern auch noch Rundungsfehler).

Ich übersehe immer aus eigener ASM-Erfahrung das C und Nachfollger ja Hochsprachen sind.

Klar jetzt fällt es mir wieder wie Schuppen von den Augen, die Compilerprogrammierer von fast jeder Hochsprache haben dieses Problem. Unter Assembler und einigen negativen Erfahrungen am Anfang kriegte man das recht schnell in den Griff, und wenn es perse nicht hinhauen wollte hat man eben doch wieder auf Integer umgestellt, je nach Programmzweck. (So ungefähr hatte ich das Problem angegangen.) Man definierte den Inhalt von Arrays als int oder float und mußte um Vermischungen vorzubeugen z.B. die Register am besten fest reservieren, reg 15-31 z.B. für float, so konnte man z.B. dem NaN-Problem einfach entgehen, weil Vermischungen ausgeschlossen waren am Ende für den Assembler nicht vergessen Stack und Register wieder als float/raw und nicht int zu markieren. Und die RAW-Daten konnten direkt als Datenstream der Grafikausgabe übergeben werden.

(Sind schon ein paar Jahre her, das ich das das letze mal gemacht hatte). 

Früher hatte "C" den Manko das man ja die Register nicht fest reservieren konnte (von bis) wie in Assembler, daß das Heute intern immer noch ein Problem ist hätte ich jetzt so nicht erwartet und einfach vergessen. Zudem spielt Multi-tasking/-threading auch noch mit zur erschwerenden Problematik.

Ich sehe es ja ein, Hochsprachenkompiler haben ihre Probleme damit.

Am Beispiel Xara Xtreme: *Quote:*   

> Xara Xtreme bietet eine hohe Verarbeitungsgeschwindigkeit, die durch die Programmierung in Assembler in Xara Xtremes Renderer erreicht wird. Laut Angaben des Herstellers gilt Xara Xtreme derzeit als das mit Abstand schnellste Illustrationsprogramm auf dem Markt

  sieht man immer wieder was alles in ASM machbar ist. Der SVG Grafikstandard demnächst in KDE 4, sollte am besten auch in float über ASM programmiert werden, dann ist a) die CPU frei für andere Dinge und b) Float ist wesentlich schneller abgearbeitet.. *g*

Eines fällt mir aber noch dazu ein, warum merke ich eigentl. das wenn die gesammte Software auf dem Rechner so mit meinen jetzt gesetzen Flags kompiliert wurde das sie flotter läuft, als wenn ich sie unter Standart -O2 kompiliere?

 *mv wrote:*   

> Zwar habe ich mich mit modernen Prozessoren nicht viel beschäftigt, aber so etwas bringt dort vermutlich nicht viel: Die parallelisieren soweit wie möglich ohnehin schon selbständig - es ist da eher wichtig, dass man den Code so schreibt, dass sie die parallel berechneten Ergebnisse auch nutzen können und nicht ganze Queues wegschmeißen müssen (Stichwort: branch-prediction). Wenn man sich dann noch "händisch" (sprich: unter Zuhilfenahme von Code) mit dem Co-Prozessor synchronisieren müsste, hätte man jedweden Vorteil verspielt.

 

Die FPU-Geschwindigkeit eines Athlon ist zumindest enorm, sie soll rund dopplt so schnell sein wie auf Intelsystemen.

branch-prediction - damit habe ich leider keine Erfahrung. 

Es mag Geschwindigkeitsvorteile bringen, aber belastet doch sicher den Energieverbrauch einer CPU (Stichwort: Ruhestrom). Ob das der richtige Weg ist wage ich einfach mal ohne höheres Wissen zu bezweifeln. Irgendo las ich diesen Monat das die IT-Systeme in D schon 2% der CO2 Emissionen ausmachen. Nun bei branch-prediction kann ich mich als Ruhestromkiller auch täuschen. 

Es bringt zumindest etwas Leistungsvorteil. Zudem ist branch-prediction für die Co-Prozessoren auch garnicht nötig, ich bin froh wenn diese Einheiten überhaupt etwas zu tun haben, meist unter Integer schlummern sie ja doch nur rum außer bei z.B. großartigen 3D-Spielen (sse/mmx/i368). Ich finde sogar die Renderausgabe der Mozilla-Browser (Gecko) solle es am besten auch nutzen (scrollen, Seitenaufbau (Tabellen/CSS), etc). Dann kann die CPU im Hintergrund z.B. noch schneller emergen weil sie dann zu 99% frei wäre. *g*

----------

## obrut<-

branch prediction macht einen erheblichen anteil der performance heutiger cpus aus, da die pipelines länger sind als früher und daher ein abwarten des ergebnisses einer operation um den nächsten befehl ausführen zu können einfach zu lange dauert.

selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können.

----------

## UTgamer

 *obrut<- wrote:*   

> branch prediction macht einen erheblichen anteil der performance heutiger cpus aus, da die pipelines länger sind als früher und daher ein abwarten des ergebnisses einer operation um den nächsten befehl ausführen zu können einfach zu lange dauert.
> 
> selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können.

 

Zu branch prediction, thx hat mir weiter geholfen, und nicht schlecht ins Detail gegangen.  :Wink: 

Aber deine Werte scheinen doch etwas älter zu sein.

Ich habe hier mal ein paar Textpassagen (mit Quellenangaben) herausgesucht was wirklich in einem modernen Pentium 7+ oder Athlon (XP, 64 oder 64 x2) abgeht; bei der Benutzung von nicht Integer also 3D Now, MMX, SSE, SSE2.

###################################

#### http://www.cpushack.net/CPU/cpu3.html ####

 The P7 extended the pipeline even further to over 20 stages (or 30 during cache misses), stressing clock speed over execution speed (for marketing reasons) - this led to some questionable design decisions. The three decoders are replaced by single decoder and a trace cache - similar in concept to the decoded instruction cache of the AT&T Hobbit, but 80x86 instructions often decode into multiple micro-ops, so mapping the micro-ops to memory is more complex, and instructions are loaded ahead of time using branch prediction. This speeds execution within the cache, but the single decoder limits the external instruction stream to one at a time. Long micro-op sequences are stored in microcode ROM and fed to the dispatch unit without being stored in the cache.

There are seven execution units, one FPU/MMX/SSE, one FP register load/store unit, two add/subtract integer units, one logic (shift and rotate) unit, one load and one store unit. The add/subtract units run at double the clock rate, basically as a two stage pipe, allowing two results within a single clock cycle, meaning up to nine micro-ops could be dispatched each cycle to the seven units, but in practice the trace cache is limited to three per cycle. A slower logic unit replaces two faster address units in the P6, slowing most code. Since the stack-oriented FPU registers are difficult to use for superscalar or out-of-order execution, Intel added floating-point SSE instructions (called SSE2), so that floating point operations can use the flat SSE registers which will make future designs easier, and the old FPU design becomes less important. 

...

...

...

When moving from the 80286 to the 80386 (IA-32), Intel took the opportunity to fix some of the least liked features remaining in the previous design. Moving to x86-64, AMD decided to further modernize the design, adding a cleaner 64-bit mode (selected by Code Segment Descriptor (CSD) register bits).

It's based on sixteen 64-bit integer and sixteen 128-bit vector/floating point (XMM) registers (the lower eight registers of each map to the original x86 integer and SSE/SSE2 registers) and the 8087 FPU/MMX registers, with a 64-bit program counter. In 64-bit mode, integer registers are uniform and can be 8-, 16-, 32-, or 64-bit. Address spece is changed from mainly segmented to a flat space (keeping data segment registers in 32- or 16-bit sub-modes) with PC relative addressing, although code segments (within the address space) are still used to define the modes for each segment. Older 8086 modes are supported in a separate "legacy" mode. These changes give compilers a larger, more regular register set to use making optimizations easier.

Rumours persisted that Intel was developing a CPU codenamed "Yamhill", originally based on original 64-bit P7 plans dusted off, but then switching to the x86-64 architecture and instruction set (apparently under pressure from Microsoft to avoid creating yet another instruction set to support - ironically making Intel a follower of AMD, after driving 80x86 development from the beginning). Originally it was an unofficial project, then official when performance of the first Itanium disappointed, and K8 popularity exceeded expectations. It was finally released as an "enhanced" Pentium 4 Xeon (March 2004), despite being a new design. The 64-bit capability is designed as a 32-bit add-on (like old bit-slice processors) and is disabled in lower end versions, (much like the low-cost 80486SX FPU was disabled). When enabled, the extended 32 bit pipeline operates 1/2 clock cycle later than the main pipeline.

It has the same registers, addressing modes and extensions as the AMD K8, but is otherwise similar to the 64-bit P7, with the same pipeline, including double-clocked add/subtract units, though fixing the bottlenecks and using larger caches, buffers, etc. In addition, there are separate SSE2 functional units, rather than using the older FPU units for SSE operations as the P7 did. 

###################################

Optimizing Performance on Modern HPC Systems: Learning From Simple Kernel Benchmarks 

http://www10.informatik.uni-erlangen.de/~jan/download/rgw05.ps

(Den HTML-Link kann das Forum irgendwie nicht, muß das PS-Dokument dafür herhalten)

---------

3.2 Handcoded optimizations

While the achievable sustained memory performance of former x86 cpu generations

was far below peak, latest generation CPUs as the AMD Athlon 64 and Intel Pentium

4 Prescott can nearly reach their theoretical peak memory bandwidth. However,

this can only be done using the SSE/SSE2 instruction set extensions and special

optimizations that have not found their way into standard compilers yet. We have

explored the potential of these new instructions with handcoded assembly language

versions of the vector triad.

SSE/SSE2

SSE and SSE2, available on Intel Pentium 4 as well as AMD Athlon64 and Opteron

processors, not only provide a completely new set of SIMD registers that has sig-

nificant advantages over the traditional FPU register stack, but also add special

instructions for explicit memory subsystem control:

 Nontemporal stores can bypass the cache hierarchy by using the write-combine

buffers (WCBs) which are available on all modern CPUs. This not only enables

more efficient burst operations on main memory, but also avoids cache pollu-

tion by data which is exclusively stored, i. e. for which temporal locality is not

applicable.

Prefetch instructions, being hints to the cache controller, are provided in order

to give programmers more control over when and which cachelines are brought

into the cache. While the built-in hardware prefetch logic does a reasonable job

identifying access patterns, it has some significant limitations [7] that might be

circumvented by manual prefetch.

 Explicit cache line flush instructions also allow explicit control over cache use,

making cache based optimizations more effective. These special instructions were

not used in the benchmarks described below.

...

In order to get an impression of cache behavior we ran plain FPU and SSE2 versions

of the vector triad (Fig. 3). An important general observation on all Pentium 4

revisions is that cache bandwidth scales with the register width used in load/store

instructions, i. e. the CPU reaches its full potential only when using the 16-byte

SSE registers. On the other hand, the AMD Athlon 64 bandwidth almost stays the

same when going from FPU to SSE2. Moreover, this CPU shows a mediocre L2

bandwidth when compared to the Pentium 4. The AMD design clearly does not

favor vector streaming applications as much as the Pentium 4 which is trimmed

to SIMD performance. As a side note, the cache bandwidths on a Pentium 4 are

asymmetric, meaning that read bandwidth is much higher than write bandwidth,

the latter being 4 bytes/cycle on all cache levels. The Athlon64 does not show this

asymmetry at all.

One must still keep in mind that the Pentium 4 CPUs derive much of their

superior cache performance from a very high clock rate. Memory bandwidth, on the

other hand, depends on completely different factors like the number of outstanding

memory references or the effectivity of hardware prefetch.

###################################

####### CodingForSpeedInDelphi.doc ##########

http://dennishomepage.gugs-cats.dk/CodingForSpeedInDelphi.doc

Aus einem Delphi Speedoptimisation Manual:

  14.  Memory Copy

         1. Integer

         2. Floating Point

Copying floating point data can basically be done in two ways. Either by using CPU registers as temporary storage or by using the FPU stack. Using SSE on P3 or SSE/SSE2 on P4 can also do it.

As an example this chapter uses functions for copying complex numbers in rectangular format. Just think about the records used in a general way. Any record with floating point numbers would suffice. The basic function looks like this

###################################

Naja,  die Funktion -fast-math scheint außer den möglichen Risiken eines NaN (und evtl. wissenschaftl.  Rundungsfehlern) bei Compiler-/Programmierfehlern wohl doch sehr viele Vorteile zu haben.

Mich kriegt man auf Desktoprechnern, ja sogar einfachen Web- oder Storage-Servern nicht davon überzeugt das die RAW-Datentechnik für diese von Nachteil ist. 

Auf Hochverfügbarkeitsmachinen Wissenschaft/Forschung/Finanzzentren (Cluster, etc.) und in Datenzentren ist es natürlich unmöglich sich auf solche Risiken einzulassen.

Nebenbei bemerkt für reines Numbercrunching. 

Ich fand eine Unmenge an Diskussionen über Floatoptimizations für die Projecte unter Boinc, wie z.B. die Suche nach außerirdischem - Seti. Dort wurde von vielen gesagt das die Berechnungen unter SSE2 rund 7 mal schneller vonstatten gehen als auf dem Standart Boinc in Integer. Unter SSE3 wurden Wertsteigerungen gegenüber SSE2 vom nochmal 0,5-1 fachen angegeben, also rund 7,5 - 8 mal schneller.

---

Ich kann mir auch nicht vorstellen das eine Co-Unit mit ihrer ALU-Ausnutzung die ganze Main-Unit ausbremsen soll, die müssen doch eigene ALUs besitzen um das verarbeiten zu können und auf einem DualCore erst überhaupt nicht. Berechne ich die 128 Bit Float-Werte auch auf den 64 Bit Int-ALUs des Main-Core und wie soll ich damit z.B. beim NumberCrunching die 7-8 fache Geschwindigkeit erreichen? Zudem kann es auch garnicht übereinstimmen, da ich mehrmals gelesen hatte das die SSE-Einheit einem RISK-Prozessorsatz ähnelt. *obrut<- wrote:*   

> Selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können.

 ^ Diese Aussage paßt zum ersten Auszug oben für Intel-FPU instructions, jedoch nur mehr bedingt für SSE, wobei AMD diese Einheiten ja wieder besser geregelt hat. Letztendlich hat Intel ja seinen Murks zu Gunsten der AMD-Architektur auf drängen Microsofts aufgegeben, also wer sich einen älteren Pentium 4 gekauft hat ist selbst schuld, er hat sich vorher nicht richtig informiert, und hat hier eben eine Geschwindigkeitsbremse bei der Main-Unit (ist aber im Gesammten gesehen immer noch performanter als ganz ohne float).  *Quote:*   

> It's based on sixteen 64-bit integer and sixteen 128-bit vector/floating point (XMM) registers

  *Quote:*   

> Copying floating point data can basically be done in two ways. Either by using CPU registers as temporary storage or by using the FPU stack. Using SSE on P3 or SSE/SSE2 on P4 can also do it.

 

Treffe ich zudem hierbei den Nagel auf den Kopf wenn ich vom Compilerflag -m64 rede, das Optimierung dann einfacher von statten geht?

"Older 8086 modes are supported in a separate "legacy" mode. These changes give compilers a larger, more regular register set to use making optimizations easier."

Kleine Notiz am Rande für nicht Techniker: *Quote:*   

> Arithmetic Logic Unit
> 
> Die ALU ist der eigentliche Rechner. In ihr werden alle arithmetische und logische
> 
> Funktionen und Berechnungen ausgeführt. Zur ALU gehören auch der Akku(Speicher) und die Flags(Ereignisspeicher).
> ...

 

Kleiner Aufruf an alle Programmierer, bitte nutz zur Multimediaprogrammierung Bild,Audio,Video mehr die 128 Bit- und Burstvorteile der SSE Technologie, für ältere CPUs und AMD einzeln auch gerne MMX und 3D Now.  Den diese Befehlssätze sind extra für Multimedia entwickelt worden.  :Very Happy: 

----------

## UTgamer

 :Cool:   Damit der Thread nicht einschläft fiel mir gerade ein das wir eine kleine Benchmarksammlung zu unserer Diskussion einfügen könnten. 

============================================================

Test A

Also ich habe da diesen Benchmark http://www.cs.virginia.edu/stream/ ausfindig gemacht und ohne an irgendwelchen Parametern zu schrauben diese Werte erhalten:

```

Function      Rate (MB/s)   Avg time     Min time     Max time

Copy:        1447.4347       0.0222       0.0221       0.0225

Scale:       1458.1276       0.0220       0.0219       0.0221

Add:         1619.4354       0.0299       0.0296       0.0305

Triad:       1617.6918       0.0299       0.0297       0.0301

-------------------------------------------------------------

Solution Validates

-------------------------------------------------------------
```

Die Kompilierung ist auf einfachster Stufe, herunterladen von:

http://www.cs.virginia.edu/stream/FTP/Code/stream.c

und

http://www.cs.virginia.edu/stream/FTP/Code/mysecond.c

, dann einfach mit gcc -O stream.c -o stream kompilieren, das dauert keine Sekunde  :Wink: 

Bitte nicht optimieren auf irgendwas, es wäre schön wenn wir gleiche Ergebnisse bekämen, ich habe auch nicht auf den DualCore eingestellt.   :Very Happy: 

============================================================

Test B

Jetzt habe ich hier den 2. Benchmark: http://r-goetz.de/RGBench/

Die Seite hat auch sehr viele aktuelle Vergleichswerte.  :Wink: 

Den habe ich folgendermaßen mit meinen Standart USE-Flags eingestellt (wie nach Anleitung): 

CC= gcc -march=athlon64 -O2 -msse3 -mfpmath=sse,387 -pipe -ffast-math -m64

Das Kompilieren hat rund 3 Sekunden gedauert  :Wink: 

Dies sind meine Werte unter X:

```

   Task    : estim.|  absoulte | relative |   Speed   |

           : memory|   speed   |   speed  | relative  |

           : usage |  absoulte | relative | to PM7500 |

-------------------+-----------+----------+-----------|

MC -   250 :   0.5 |     14.09 |   100.00 |   2988.10 |

MC -   500 :   2.0 |     13.34 |    94.66 |   4362.91 |

MC -  1000 :   8.0 |     11.28 |    80.01 |   3894.43 |

MD -   500 :   0.5 |    216.09 |   100.00 |   3709.60 |

MD -  1000 :   2.0 |    207.52 |    96.03 |   4347.55 |

MD -  2000 :   8.0 |    209.75 |    97.07 |   4432.79 |

MCI- 12500 :   0.5 |   3029.85 |   100.00 |   4580.12 |

MCI- 60000 :   2.0 |   1669.69 |    55.11 |   2782.81 |

MCI-200000 :   8.0 |   1491.20 |    49.22 |   2788.54 |

-------------------+-----------+----------+-----------|

Averages:

       by task              by size          speed loss

                                          with mem size

   MD  :  4163.31       0.5MB :  3759.27         0.00

   MC  :  3748.48       2.0MB :  3831.09       -18.07

   MCI :  3383.82       8.0MB :  3705.25       -24.57

                 single Core  Throughput

float   Average :  3955.90      3955.90

integer Average :  3383.82      3383.82

total   Average :  3727.07      3727.07
```

Dies sind meine Werte auf der Konsole:

```

   Task    : estim.|  absoulte | relative |   Speed   |

           : memory|   speed   |   speed  | relative  |

           : usage |  absoulte | relative | to PM7500 |

-------------------+-----------+----------+-----------|

MC -   250 :   0.5 |     14.22 |   100.00 |   3015.01 |

MC -   500 :   2.0 |     13.44 |    94.50 |   4394.83 |

MC -  1000 :   8.0 |     11.39 |    80.10 |   3933.87 |

MD -   500 :   0.5 |    217.74 |   100.00 |   3737.87 |

MD -  1000 :   2.0 |    209.18 |    96.07 |   4382.22 |

MD -  2000 :   8.0 |    211.04 |    96.92 |   4459.97 |

MCI- 12500 :   0.5 |   2923.62 |   100.00 |   4419.54 |

MCI- 60000 :   2.0 |   1662.46 |    56.86 |   2770.76 |

MCI-200000 :   8.0 |   1408.73 |    48.18 |   2634.32 |

-------------------+-----------+----------+-----------|

Averages:

       by task              by size          speed loss

                                          with mem size

   MD  :  4193.35       0.5MB :  3724.14         0.00

   MC  :  3781.23       2.0MB :  3849.27       -17.52

   MCI :  3274.87       8.0MB :  3676.05       -24.93

                 single Core  Throughput

float   Average :  3987.29      3987.29

integer Average :  3274.87      3274.87

total   Average :  3702.33      3702.33
```

Meine Werte sind teils um einiges langsamer als die Werte auf seiner Webseite. Naja wenn einige kaum Dienste am laufen haben.

============================================================

Laßt mal bitte eure Werte vergleichen.

Für die Diskussion interresieren mich ja ganz besonders die fast-math Werte. Bei ähnlichen Proßessorgeschwindigkeiten (meine 3,8 GHz Athlon64).

Jetzt bitte nicht jeder wenn bereits mit ähnlichen HW-/Softwareprofilen gepostet wurde.

----------

## firefly

Da die x86 Architektur auf der "von neumann maschine" beruht, ist die CPU komplett "blockiert", wenn eine der subeinheiten der CPU Daten liest oder schreibt (von Register zu Register, Register zu RAM oder RAM zu Register). Denn die "von neumann maschine" ist eine ein-bus architektur, sprich ein Datenbus, ein Addressbus und ein Steuerbus.

Es kann gut sein das in modernen CPUs intern mehrere Datenbusse gibt aber spätestens wenn es nach ausen geht existiert nur ein Daten-, Address und ein Steuerbus.

Druch pipelining kann man etwas performance heraushohlen da dann subeinheiten eventuell über einen eigenen bus daten austauschen können. Aber je länger die pipeline wird desto geringer wird der performance schub ausfallen,bei höhren Tagtraten, da die CPU "länger" auf das ergebniss warten muss.

Soweit ich weis, ist Intel dadurch mal ganz schön auf die Schnauze gefallen. Denn Intel hat bis vor kurzen den weg verfolgt, eine höhere Performance durch reine Taktraten Steigerung zu erreichen. Da die pipeline in Intel Cpus schon zum teil "extrem" lang war, wurden die CPUs, meines wissen nach, sehr instabil bei Taktraten über 3 Ghz.

----------

## firefly

 *UTgamer wrote:*   

> 
> 
> Für die Diskussion interresieren mich ja ganz besonders die fast-math Werte. Bei ähnlichen Proßessorgeschwindigkeiten (meine 3,8 GHz Athlon64).

 

ähm du hast kein 3.8Ghz Athlon 64. Die 3800+ angabe spiegelt nicht den realtakt wieder. Der Athlon64 3800+ ist hat einen realtakt von 2.4 GHz

----------

## UTgamer

 *firefly wrote:*   

> Da die x86 Architektur auf der "von neumann maschine" beruht, ist die CPU komplett "blockiert", wenn eine der subeinheiten der CPU Daten liest oder schreibt (von Register zu Register, Register zu RAM oder RAM zu Register). Denn die "von neumann maschine" ist eine ein-bus architektur, sprich ein Datenbus, ein Addressbus und ein Steuerbus.
> 
> Es kann gut sein das in modernen CPUs intern mehrere Datenbusse gibt aber spätestens wenn es nach ausen geht existiert nur ein Daten-, Address und ein Steuerbus.

 

Ja stimmt für den "alten" Intel Weg, aber AMD hat mit dieser Bremse gebrochen, und nun läuft auch die AMD64 Optimierung auf den Intel 64ern.

 *firefly wrote:*   

> Druch pipelining kann man etwas performance heraushohlen da dann subeinheiten eventuell über einen eigenen bus daten austauschen können. Aber je länger die pipeline wird desto geringer wird der performance schub ausfallen,bei höhren Tagtraten, da die CPU "länger" auf das ergebniss warten muss.
> 
> Soweit ich weis, ist Intel dadurch mal ganz schön auf die Schnauze gefallen. Denn Intel hat bis vor kurzen den weg verfolgt, eine höhere Performance durch reine Taktraten Steigerung zu erreichen. Da die pipeline in Intel Cpus schon zum teil "extrem" lang war, wurden die CPUs, meines wissen nach, sehr instabil bei Taktraten über 3 Ghz.

 

Das Bündeln von CPU und MMU soll heissen, das sogar neuerdings die IOMMU/Northbridge

 zusammen auf dem einen CPU-Chip gebündelt werden, wegen der Pipelineschwäche des alten Intel Architekturerbes. Und wieder mal ist AMD vorraus.

Die IOMMU-Einheit in Athlons ist auch nicht neu, die gab es bereits seit 2002 in einem anderen Athlon Modell: *Quote:*   

> Alle Hammer haben einen integrierten Memory-Controller, der beim Opteron als Zweikanal-DDR-Interface mit einer theoretischen Bandbreite von 8,4 GByte/s mit PC2100- und 10,8 GByte/s mit PC2700-Modulen ausgelegt ist.

  Sie wird jetzt nur verbessert.

 *firefly wrote:*   

>  *UTgamer wrote:*   
> 
> Für die Diskussion interresieren mich ja ganz besonders die fast-math Werte. Bei ähnlichen Proßessorgeschwindigkeiten (meine 3,8 GHz Athlon64). 
> 
> ähm du hast kein 3.8Ghz Athlon 64. Die 3800+ angabe spiegelt nicht den realtakt wieder. Der Athlon64 3800+ ist hat einen realtakt von 2.4 GHz

 

Ja weiss ich, es fehlte das + Zeichen dabei. Genau dies ist es ja warum seit dem Aufkommen der Athlons Intel mit ihrer "Von Neumann Architektur" nicht mehr die Innovationsliste von den Beiden anführt.

Ich denke da AMD mit IBM zusammen in der Prozessorentwicklung tätig ist, hat AMD das Wissen um die Änderungen von IBM erhalten. Das die Coprozessoren auf den Athlons nicht mehr die CPU blockieren hatte IBM bereits in seiner 68000 Reihe, wie auch damals Motorola (Amiga/Apple/Atari).

Das habe ich woanders bereits häufiger gelesen, das IBM Know-How hinzusteuert, die IO-MMU Geschichte die in der nächsten Generation kommt hatte bereits auch mein 68030 Amiga vor 16 Jahren.  :Wink: 

Es ist heute auf allen Athlons und auf den von Intel eingekauften "Core 2 Duos" einfach nicht mehr der Fall das eine SSE(x) oder MMX Einheit die CPU blockiert. Bis zur Intel Pentium D Reihe stimmt deine Aussage noch mit der "Von Neumann Architektur".  :Wink: 

AMD/IBM mischen gerade Intel auf. *g*

Ich als alter 68000er Fan, war schon immer gegen Intel eingestellt, damals prangte noch auf meinem Amiga-Desktop ein riesiges Intel Outside Logo; Intel ist heute noch nicht so weit wie Motorolla/IBM es vor 20 Jahren waren. Mit Taktraten kann Intel allerdings am besten von allen umgehen, das Geld für die kleinere Dye-Technik haben sie ja.

Dieser Artikel verdeutlicht auch nochmal die Struckturänderung die AMD 1999 in seinen Athlon hat einfließen lassen:  http://www.heise.de/ct/99/16/088/

 *Quote:*   

> Athlon ist mit einem neuen Prozessor-Bus ausgestattet, dessen Protokoll AMD von dem Hersteller eines der schnellsten Mikroprozessoren überhaupt, Digital, übernommen hat. Den Versuch eines eigenständigen Prozessorbusses hat seinerzeit mal die Prozessorschmiede NexGen unternommen - der Versuch scheiterte kläglich: NexGen wurde schließlich von AMD aufgekauft und ihr Design floss in den K6 ein, den AMD wieder in kompatibles Sockel-7-Format presste.

 

 *Quote:*   

>  Wie unsere Benchmarkergebnisse belegen, schlägt er den Pentium III bei gleichem Takt in nahezu allen Belangen. Zum Teil, etwa im Gleitkomma-Bereich, düpiert er den Herausgeforderten geradezu. Ja, es gibt sogar einen Benchmark bei SPECfp95 (fpppp), wo Athlon sensationell um den Faktor drei schneller ist. Als i-Tüpfelchen kommt dabei noch hinzu, dass die Benchmarks mit den Intel- C++- und Fortran-Compilern übersetzt wurden, die wohl kaum im Ruf stehen, speziell für Athlon zu optimieren.
> 
> Benchmarks wie SPECfp95 oder die BAPCo-Suite mied AMD früher wie der Teufel das Weihwasser - nun sind sie auf einmal AMDs Lieblinge - und ganz zufällig mag Intel auf einmal die BAPCo-Suite gar nicht mehr. Und auch typische Benchmarks aus Intels Drei-Welten-Theorie (Integer, MMX, FPU) wie der hauseigene Media Bench stehen nun in einem gänzlich anderen Lichte da. Wissenschaftler, die sich die SPECfp95-Ergebnisse anschauen, müssen einfach in Scharen zum Athlon überlaufen, was dessen Ruf sicherlich gut tut. 

 

Das macht der Athlon eben bereits seit 8 Jahren. Schöne Integergrüße an die Intelfraktion.   :Laughing: 

Jeder der ein Athlondesign ohne "-ffast-math" nutzt verschenkt sehr viel Leistung. Sollte eine einzelne schlecht programmierte Anwendung mal Probleme haben, kann genau für diese das "-ffast-math" ja abgeschaltet werden. Solch eine Anwendung ist z.B. sys-devel/gdb, eine weitere ist mir zur Zeit nicht bekannt.

----------

## mv

 *UTgamer wrote:*   

> Jeder der ein Athlondesign ohne "-ffast-math" nutzt verschenkt sehr viel Leistung.

 

Wie kommst Du denn auf diese Aussage? -ffast-math hat nichts mit Athlon vs. Intel zu tun. Schau Dir doch nochmal in der manpage an, welche Schalter -ffast-math genau umlegt, und was das bewirkt: Es geht jeweils nur um die Frage, ob ein paar zusätzliche Code-Befehle für Exceptions u.ä. eingebaut werden, falls sich Programme auf die dokumentierte Behandlung dafür verlassen.

----------

## UTgamer

 *mv wrote:*   

>  *UTgamer wrote:*   Jeder der ein Athlondesign ohne "-ffast-math" nutzt verschenkt sehr viel Leistung. 
> 
> Wie kommst Du denn auf diese Aussage? -ffast-math hat nichts mit Athlon vs. Intel zu tun. Schau Dir doch nochmal in der manpage an, welche Schalter -ffast-math genau umlegt, und was das bewirkt: Es geht jeweils nur um die Frage, ob ein paar zusätzliche Code-Befehle für Exceptions u.ä. eingebaut werden, falls sich Programme auf die dokumentierte Behandlung dafür verlassen.

 

Diese Diskussion pro/kontra fast-math führte 2001 bereits dewar (von  http://www.adacore.com/home/company/) mit Linus Torvalds.  :Wink: 

Das Englisch ist nicht ganz einfach: http://gcc.gnu.org/ml/gcc/2001-07/msg02151.html

Dort ging es auch um noch von Hand aufgebesserte Assembleroptimierung um den Punkt den Obrut ansprach zu verhindern. *obrut<- wrote:*   

> ... selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können.

 

Wieder bezog sich dies einzig um die "Von Neuman Architektur" von Intel. Als Beispiel nannte Torvalds Quake3 mit seiner Handoptimierung bei Laufzeiten. Da der Athlon jedoch einen eigenständigen CPU-Buss besitzt hätte sich ID-Software an Q3 jede Menge Arbeit sparen können. Aber Q3 ist ja leider noch älter, und war auch das schnellste Spiel was ich damals kannte.

Nun ein kleines Zitat einer deutschen Seite (2005), http://www.heise.de/newsticker/meldung/print/58863 *Quote:*   

> Die 64-Bit-Welle hat auch vor der GCC nicht Halt gemacht: Ein Reihe mathematischer Funktionen wie asin, acos oder log10 sind nun als Intrinsics für die AMD64-Befehlssatzerweiterung verfügbar, sofern man seinen Code mit dem GCC-Schalter -ffast-math übersetzt. Vergleichbares gibt es auch für die Itanium-Plattform (IA-64), wo Gleitkomma- und Ganzzahl-Divisionen sowie Quadratwurzelberechnungen nun inline stattfinden.

  Anmerkend weiß ja jeder das Intel-Itanium eine Totgeburt war.

Die Beschreibung im man zu -ffast-math ist sehr eingeschrängt. Ich zitiere einmal die Funktionen die der GCC für -ffast-math nur für "inline x87" bereithält direkt von http://gcc.gnu.org/, und worauf man verzichten muß ohne.

Also nach http://gcc.gnu.org/gcc-4.0/changes.html *Quote:*   

> New Targets and Target Specific Improvements
> 
> ...
> 
> IA-32/x86-64 (AMD64)
> ...

 

Der man Eintrag nochmal aktuell für 4.1.2 aus dieser Doku http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Floating-point-implementation.html#Floating-point-implementation

 *Quote:*   

> # Whether and how floating expressions are contracted when not disallowed by the FP_CONTRACT pragma (C99 6.5).
> 
> Expressions are currently only contracted if -funsafe-math-optimizations or -ffast-math are used. This is subject to change. 

 

Zu SSE- oder MMX-Befehlen habe ich jetzt erstmal auf die Schnelle leider nichts gefunden.

Weitere Markierungen in dem Text sagen auch das einige Optimierungen nicht in GCC selbst sondern in der C Biblithek hinterlegt sind. (Das geht mir aber zu tief in C, komme nur aus der ASM-Ecke.)

Also warum sollten "inline x87", SSE(x) und MMX bei mathematischen und Multimediaoperationen nicht das System beschleunigen? Das die CPU blockiert wird (Register-/Stackcharing) von den floats findet nur auf Intel und nicht AMD Prozessoren statt.

Ich mische ja auch noch die Register mit -sse,387  :Smile: 

 *Quote:*   

> -sse,387
> 
> Attempt to utilize both instruction sets at once.  This effectively double the amount of available registers and on chips with separate execution units for 387 and SSE the execution resources too.  Use this option with care, as it is still experimental, because the GCC register allocator does not model separate functional units well resulting in instable performance.

  Aber instabil wie erwähnt ist hier überhaupt nichts, scheint wohl wieder mal nur für Intels zu gelten. *g*

Hier noch ein Artikel von Intel selbst http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/itanium/275924.htm?page=3 *Quote:*   

> 
> 
> The current version of the GNU Compiler Collection (GCC) by the Free Software Foundation is a minor release of 4.0. In moving to GCC 4.0, the GCC team adopted a new optimization framework called Tree-SSA7. This has enabled them to perform more optimizations, and improve the performance of existing optimizations.
> 
> Fluent, working with Intel, tested the quality of the code produced by GCC and the Intel compiler by benchmarking their solver on a 3.4 GHz Intel Xeon dual-processor system with 16 GB of memory. They tested a serial version of FLUENT, using only one processor. This prevented interconnect and communication library performance from affecting the results.
> ...

 

Selbst Intel gibt zu das die Performance gesteigert wird.

----------

## mv

 *UTgamer wrote:*   

>  *Quote:*       * The acos, asin, drem, exp10, exp2, expm1, fmod, ilogb, log10, log1p, log2, logb and tan mathematical builtins (and their float and long double variants) are now implemented as inline x87 intrinsics when using -ffast-math.
> 
>     * The ceil, floor, nearbyint, rint and trunc mathematical builtins (and their float and long double variants) are now implemented as inline x87 intrinsics when using -ffast-math.
> 
>     * The x87's fsincos instruction is now used automatically with -ffast-math when calculating both the sin and cos of the same argument.
> ...

 

Ich bin baff: Das scheint in der Tat zu stimmen und auch noch für 4.1.2 gültig zu sein. Es ist mir vollkommen schleierhaft, wieso dies nicht automatisch sondern nur bei Benutzung von -fast-math geschieht. Die man-/infopage gibt offensichtlich Falschinformationen, denn mit der dortigen Beschreibung, dass -fast-math nur ein paar andere Flags setzt (die offensichtlich nichts damit zu tun haben) hat das überhaupt nichts zu tun.

----------

## UTgamer

Ich bin froh das du das meist brach liegende Potenzial erkannt hast.  :Smile: 

Es gibt noch eine Erweiterung die bereits längst in AMD64 eingeflossen ist.

Eine ältere Diskussion darüber ist hier zu finden http://gcc.gnu.org/ml/gcc/2005-08/msg00270.html

Wobei die dort erwähnte crtfastmath.c kein i386 Code ist sondern z.B. von IA64.

Früher gab man z.B. :

"CFLAGS="-march=athlon64 -O2 -pipe -frename-registers -fweb -ffast-math -mfpmath=sse -ftracer -funroll-loops -fstack-protector " 

als seine CFlags an. 

Aber das ist überhohlt:

-mfpmath=sse is the default choice for the x86-64 compiler.

SSE bietet noch weit mehr Funktionen und Geschwindigkeit als float.   :Laughing: 

----------

## schachti

Du hast mich ja fast ueberzeugt, auf meinem (32-bittigen) Athlon64 X2 System mal -ffast-math auszuprobieren...   :Wink: 

----------

## UTgamer

@ schachti, keine Sorge das System bleibt weiterhin genauso stabil wie vorher. 

Du merkst die Beschleunigung am allermeisten beim GQview, weitere Anwendungen bei denen man richtig was spürt hatte ich im Verlauf auch genannt. 

Ich bin mir nicht ganz sicher ob es mit diesen Compilerflags zusammenhängt aber das Abspeichern auf Festplatte unter reiserfs 3.6  geht auch flotter, bei ext3 habe ich jedoch nichts gemerkt, daher habe ich vor rund 2 Monaten von Mischfilesystemen auf den gleichen Platten (Debian Kernel 2.6.18.x/Gentoo) alles auf reiserfs umgestellt, und nicht einmal einen Fehler in den 1,5 Jahren auf dem 64er bekommen, kann aber auch eine Inlinekernelverbesserung sein. Oder die CPU hat doch soviel mehr Freiraum bekommen das die Flags sich auswirken. Ich habe ja das gesammte System damit erstellt icl. aller Treiber, eine Optimierung mehr oder weniger kann sich schon merkbar auswirken.

----------

## Keruskerfuerst

```
emerge boost
```

 erhöht die Leistungsfähigkeit des System auch.

----------

## Storm.Xapek.de

 *Keruskerfuerst wrote:*   

> 
> 
> ```
> emerge boost
> ```
> ...

 

??

Warum sollte das die "Leistungsfähigkeit des Systems" erhöhen?

Klas boost ist ne feine Sache wenn mans plattformunabhängig will,

aber was hat boost mit Leistungsfähigkeit zu tun?

----------

