# Umstieg von amd64 auf intel core duo

## flammenflitzer

Hallo

Ich will das Rad nicht noch einmal erfinden. Ich bin von amd64 auf intel core duo umgestiegen. Kann mir jemand sagen, was ich am system aendern muss. Habe gerade das erste Mal gebootet und noch die englische Tastatur. Das nervt.

----------

## Keruskerfuerst

Tastaturbelegung:

/etc/conf.d/keymaps

Prozessor:

In /etc/make.conf die CFLAGS an den neuen Prozessor anpassen.

----------

## Max Steel

und dann wird ja mit den nächsten Update nach und nach alles neu übersetzt und es ist alles an die neuen CFLAGS und damit an die CPU angepasst.

Allerdings system würde ich trotzdem neu bauen.

----------

## Keruskerfuerst

mit dem Befehl 

```
emerge -e  world
```

.Last edited by Keruskerfuerst on Wed Oct 10, 2007 5:54 pm; edited 3 times in total

----------

## flammenflitzer

Läuft erst mal. Was nehme ich den statt powernowd für dem amd64 nun für die CPU?

In der make.conf habe ich 

```
CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=nocona -O2 -pipe"

CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j2"

USE=" 3dnow 3dnowext 64bit a52 aac aalib ace -arts asf automount bzip2 cdb cddb cdparanoia cdrom colordiff cpudetection dbus de_tvtoday dhcp disk-partition divx dmi dolby-record-switch dvb dvbplayer dvdnav emovix -esd -evo exif fame ffmpeg flac fuse german gmedia -gnome gphoto2 -gstreamer hal ieee1394 java joystick jpeg2k kdeenablefinal kdehiddenvisibility libsamplerate lirc lm_sensors matroska mjpeg mmxext mng mplayer musepack musicbrainz nsplugin nvidia recode rtc shorten theora transcode usb v4l v4l2 vcd winbind x264 xanim Xaw3d xine xvid yv12 zvbi"
```

Ich glaube die use flags muß ich noch ändern.

Was kommt den da neu rein? 

```
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr lahf_lm
```

Und gibt es noch eine Optimierung für die CFLAGS?

----------

## Keruskerfuerst

Bei USE herausnehmen:

3dnow 3dnowext mmxext

hinzufügen:

mmx sse sse2 sse3 vielleicht auch noch sse4

CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer -s"

weitere CFLAGS kann info GCC entnehmen.

----------

## flammenflitzer

Ich habe jetzt 

```
CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer -s -mfpmath=sse -msse2 -mmmx"

CXXFLAGS="${CFLAGS}"
```

und in den useflags 

```
USE="-3dnow -3dnowext 64bit -mmxext mmx sse sse2 sse3 sse4
```

Sollte denn 

```
-fomit-frame-pointer -s
```

 nicht nur bei der x86 Architktur drin sein?

Außerdem habe ich verschiedene Aussagen zu den MAKEOPTS gefunden. Da wird teils 

```
MAKEOPTS="-j4"
```

 und auch 

```
MAKEOPTS="-j3"
```

 empfohlen.

----------

## schachti

 *flammenflitzer wrote:*   

> Außerdem habe ich verschiedene Aussagen zu den MAKEOPTS gefunden. Da wird teils 
> 
> ```
> MAKEOPTS="-j4"
> ```
> ...

 

Ich richte mich immer nach der Regel "Anzahl Prozessoren + 1", also 3 in Deinem Fall.

----------

## Keruskerfuerst

Makeopts="-j1 -s" setzen.

FORKS="=Anzahl der CPU Kerne"

USE="64bit 80387 mmx sse sse2 sse3 sse4"

passende CLFLAGS:

```
CFLAGS="-mtune=nocona"

CFLAGS="${CFLAGS} -march=nocona"

CFLAGS="${CFLAGS} -O2"

CFLAGS="${CFLAGS} -combine"

CFLAGS="${CFLAGS} -falign-functions=0"

CFLAGS="${CFLAGS} -falign-jumps=0"

CFLAGS="${CFLAGS} -falign-labels=0"

CFLAGS="${CFLAGS} -falign-loops=0"

CFLAGS="${CFLAGS} -fearly-inlining"

CFLAGS="${CFLAGS} -ffunction-cse"

CFLAGS="${CFLAGS} -fgcse-after-reload"

CFLAGS="${CFLAGS} -fgcse-lm"

CFLAGS="${CFLAGS} -fkeep-static-consts"

CFLAGS="${CFLAGS} -floop-optimize2"

CFLAGS="${CFLAGS} -fmerge-constants"

CFLAGS="${CFLAGS} -fno-ident"

CFLAGS="${CFLAGS} -fomit-frame-pointer"

CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

CFLAGS="${CFLAGS} -frename-registers"

CFLAGS="${CFLAGS} -fweb"

CFLAGS="${CFLAGS} -mmmx"

CFLAGS="${CFLAGS} -msse"

CFLAGS="${CFLAGS} -msse2"

CFLAGS="${CFLAGS} -msse3"

CFLAGS="${CFLAGS} -msse4"

CFLAGS="${CFLAGS} -m80387"

CFLAGS="${CFLAGS} -pipe"

CFLAGS="${CFLAGS} -s"

LDFLAGS="-Wl,-O4"

LDFLAGS="${LDFLAGS} -Wl,--as-needed"

LDFLAGS="${LDFLAGS} -Wl,--enable-new-dtags"

LDFLAGS="${LDFLAGS} -Wl,-s"

LDFLAGS="${LDFLAGS} -Wl,--sort-common"

LDFLAGS="${LDFLAGS} -Wl,-z"

LDFLAGS="${LDFLAGS} -Wl,now"
```

Native Unterstützung für den Core Duo 2 gibt es erst ab GCC 4.2.Last edited by Keruskerfuerst on Sat Oct 06, 2007 8:02 am; edited 1 time in total

----------

## schachti

 *Keruskerfuerst wrote:*   

> Ist es denn ein Zwei- oder Vierkernprozessor?

 

Soweit ich weiß gibt's Core 2 Duo nur als Dualcore, der Quadcore heißt Core 2 Quad.

 *Keruskerfuerst wrote:*   

> 
> 
> Makeopts="-j1 -s" setzen.
> 
> FORKS="=Anzahl der CPU Kerne"
> ...

 

Das kannte ich noch gar nicht... Was ist der Unterschied (Vor-/Nachteil) zu MAKEOPTS="-j3"?

----------

## Keruskerfuerst

MAKEOPTS=da werden beim Kompilieren mehrere Threads für einen Sourcecode gestartet.

FORKS=startet mehrere parallele Kompilervorgänge für verschiedene unterschiedliche Ebuilds.

----------

## schachti

Ich habe dazu noch nie was gelesen - seit wann gibt es dieses Feature denn in Portage?

----------

## franzf

 *Keruskerfuerst wrote:*   

> MAKEOPTS=da werden beim Kompilieren mehrere Threads für einen Sourcecode gestartet.
> 
> FORKS=startet mehrere parallele Kompilervorgänge für verschiedene unterschiedliche Ebuilds.

 

Wo hast du das her? Weder man make.conf noch /etc/make.conf.example sagen irgend etwas darüber...

Außerdem: So oft mach ich keine parallelen emerges, da ist es mir lieber wenn bei einem Paket parallel gearbeitet wird.

Drum lieber (wie man make.conf empfiehlt) num_cpus+1 für MAKEOPTS setzen, also für DUAL-Core -j3.

----------

## Keruskerfuerst

 *Quote:*   

> Ich habe dazu noch nie was gelesen - seit wann gibt es dieses Feature denn in Portage?

 

Dies ist nirgends in der Dokumentation enthalten. 

Seit einigen Monaten.

 *Quote:*   

> Außerdem: So oft mach ich keine parallelen emerges, da ist es mir lieber wenn bei einem Paket parallel gearbeitet wird.
> 
> Drum lieber (wie man make.conf empfiehlt) num_cpus+1 für MAKEOPTS setzen, also für DUAL-Core -j3.
> 
> 

 

Weil beim parallelen Kompilieren eines Pakets treten einfach Fehler auf.

Daher die andere Option wählen.Last edited by Keruskerfuerst on Mon Oct 08, 2007 6:41 am; edited 3 times in total

----------

## sirro

 *Keruskerfuerst wrote:*   

> MAKEOPTS=da werden beim Kompilieren mehrere Threads für einen Sourcecode gestartet.

 

Um genau zu sein: Prozesse.

Das merkt man "schön" wenn man hugin mit -j 3 kompiliert und der Rechner bei 2GB auf einmal anfängt zu swappen weil man 3 GCC-Prozesse mit je >500MB RAM-Verbrauch hat  :Smile: 

 *Quote:*   

> FORKS=startet mehrere parallele Kompilervorgänge für verschiedene unterschiedliche Ebuilds.

 

Ich fände das eher schlechter als -j. Zum einen müssen die Ebuilds ja dann unabhängig sein. Man kann ja z.B. nicht foo gleichzeitig mit seiner Abhängigkeit bar kompilieren. Bringt also nur was bei mehreren Paketen oder breiten Abhängigkeitsbäumen. Aber auch da läuft dann das letzte Paket immer nur auf einem Kern.

Könnte mir auch vorstellen, dass der Output unübersichtlich wird. Aber da rede ich als "Blinder von Farbe" da mein portage das anscheinend eh gar nicht kann.

 *Quote:*   

> Weil beim parallen Kompilieren eines Pakets treten einfach Fehler auf.

 

Die meisten Pakete bei denen das passiert filtern das doch eh. Ich hab zumindest bisher noch keine Probleme gehabt.Last edited by sirro on Sat Oct 06, 2007 8:38 am; edited 1 time in total

----------

## flammenflitzer

80387 in den useflags ? Oder ist das ein Tippfehler? Profuse kennt das nicht.

Geändert habe ich

```

CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=nocona -O2 -mmmx -msse -msse2 -msse3 -msse4 -pipe -s"

CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j1 -s"

FORKS="2"
```

----------

## sirro

see3 gibt es auch (noch) nicht als USE-Flag. Kann man natürlich trotzdem drin lassen falls es irgendwann mal jemand nutzt. Gibt aber ssse3 im mplayer.

nocona impliziert übrigens mmx und SSE1-3, die Flags kannst du dir also sparen wenn du willst.

```
           nocona

               Improved version of Intel Pentium4 CPU with 64-bit extensions,

               MMX, SSE, SSE2 and SSE3 instruction set support.
```

SSE4 gibt es eh noch gar nicht in Serien-CPUs und deiner hat es dann bestimmt auch noch nicht. Der GCC 4.2 kennt das Flag auch nicht.

```
cc1: error: unrecognized command line option "-msse4"
```

----------

## Keruskerfuerst

Man könnte die benötigte Rechenleistung eines Kompiliervorgangs wie beim Scheduling auf mehrere Kerne verteilen.

----------

## Stormkings

Vielleicht ist das hier einfach mal interessant:

Save CFLAGS (Gentoo wiki)

Bei MAKEOPTS hab ich übrigens -j5, aber da gibts unterschiedliche Vorschläge in man make.conf

dkLast edited by Stormkings on Sat Oct 06, 2007 12:23 pm; edited 1 time in total

----------

## flammenflitzer

Ja, das habe ich zuerst gelesen. Da geht doch aber immer noch etwas.

----------

## Stormkings

Das ist sicher richtig, dass da noch was geht. Fraglich ist nur, ob es etwas bringt. Außer längerer compile-Zeiten und Programmstartzeiten hab ich bisher wenig von Optimierungen bemerkt. Mplayer und Konsorten kann man ja über Useflags optimieren. Am schnellsten fühlt sich noch -Os an kombiniert mit den Safe Flags.

----------

## Keruskerfuerst

 *Stormkings wrote:*   

> Vielleicht ist das hier einfach mal interessant:
> 
> Save CFLAGS (Gentoo wiki)
> 
> Bei MAKEOPTS hab ich übrigens -j5, aber da gibts unterschiedliche Vorschläge in man make.conf
> ...

 

Wenn man ca. 30% Geschwindigkeitszuwachs verschenken will, dann kann man dies auch gerne tun.Last edited by Keruskerfuerst on Mon Oct 08, 2007 11:31 am; edited 2 times in total

----------

## flammenflitzer

Was?

-j5

oder 

Save CFLAGS (Gentoo wiki)

----------

## Keruskerfuerst

Ich meinte Save Cflags.

----------

## flammenflitzer

SchrottLast edited by flammenflitzer on Mon Oct 08, 2007 8:24 am; edited 1 time in total

----------

## flammenflitzer

wie sieht denn Deine make.conf aus?

Ich gehe mal davon aus, das Du nicht

```
CFLAGS="-mtune=nocona" 

CFLAGS="${CFLAGS} -march=nocona" 

CFLAGS="${CFLAGS} -O2" 

CFLAGS="${CFLAGS} -combine" 

CFLAGS="${CFLAGS} -falign-functions=0" 

CFLAGS="${CFLAGS} -falign-jumps=0" 

CFLAGS="${CFLAGS} -falign-labels=0" 

CFLAGS="${CFLAGS} -falign-loops=0" 

CFLAGS="${CFLAGS} -fearly-inlining" 

CFLAGS="${CFLAGS} -ffunction-cse" 

CFLAGS="${CFLAGS} -fgcse-after-reload" 

CFLAGS="${CFLAGS} -fgcse-lm" 

CFLAGS="${CFLAGS} -fkeep-static-consts" 

CFLAGS="${CFLAGS} -floop-optimize2" 

CFLAGS="${CFLAGS} -fmerge-constants" 

CFLAGS="${CFLAGS} -fno-ident" 

CFLAGS="${CFLAGS} -fomit-frame-pointer" 

CFLAGS="${CFLAGS} -fprefetch-loop-arrays" 

CFLAGS="${CFLAGS} -frename-registers" 

CFLAGS="${CFLAGS} -fweb" 

CFLAGS="${CFLAGS} -mmmx" 

CFLAGS="${CFLAGS} -msse" 

CFLAGS="${CFLAGS} -msse2" 

CFLAGS="${CFLAGS} -msse3" 

CFLAGS="${CFLAGS} -msse4" 

CFLAGS="${CFLAGS} -m80387" 

CFLAGS="${CFLAGS} -pipe" 

CFLAGS="${CFLAGS} -s" 

 

LDFLAGS="-Wl,-O4" 

LDFLAGS="${LDFLAGS} -Wl,--as-needed" 

LDFLAGS="${LDFLAGS} -Wl,--enable-new-dtags" 

LDFLAGS="${LDFLAGS} -Wl,-s" 

LDFLAGS="${LDFLAGS} -Wl,--sort-common" 

LDFLAGS="${LDFLAGS} -Wl,-z" 

LDFLAGS="${LDFLAGS} -Wl,now"
```

 so drin stehen hast.

----------

## Keruskerfuerst

Doch.

----------

## flammenflitzer

Also:

```
 CHOST="x86_64-pc-linux-gnu"

 CFLAGS="-mtune=nocona"

 CFLAGS="${CFLAGS} -march=nocona"

 CFLAGS="${CFLAGS} -O2"

 CFLAGS="${CFLAGS} -combine"

 CFLAGS="${CFLAGS} -falign-functions=0"

 CFLAGS="${CFLAGS} -falign-jumps=0"

 CFLAGS="${CFLAGS} -falign-labels=0"

 CFLAGS="${CFLAGS} -falign-loops=0"

 CFLAGS="${CFLAGS} -fearly-inlining"

 CFLAGS="${CFLAGS} -ffunction-cse"

 CFLAGS="${CFLAGS} -fgcse-after-reload"

 CFLAGS="${CFLAGS} -fgcse-lm"

 CFLAGS="${CFLAGS} -fkeep-static-consts"

 CFLAGS="${CFLAGS} -floop-optimize2"

 CFLAGS="${CFLAGS} -fmerge-constants"

 CFLAGS="${CFLAGS} -fno-ident"

 CFLAGS="${CFLAGS} -fomit-frame-pointer"

 CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

 CFLAGS="${CFLAGS} -frename-registers"

 CFLAGS="${CFLAGS} -fweb"

 CFLAGS="${CFLAGS} -mmmx"

 CFLAGS="${CFLAGS} -msse"

 CFLAGS="${CFLAGS} -msse2"

 CFLAGS="${CFLAGS} -msse3"

 CFLAGS="${CFLAGS} -msse4"

 CFLAGS="${CFLAGS} -m80387"

 CFLAGS="${CFLAGS} -pipe"

 CFLAGS="${CFLAGS} -s"

 LDFLAGS="-Wl,-O4"

 LDFLAGS="${LDFLAGS} -Wl,--as-needed"

 LDFLAGS="${LDFLAGS} -Wl,--enable-new-dtags"

 LDFLAGS="${LDFLAGS} -Wl,-s"

 LDFLAGS="${LDFLAGS} -Wl,--sort-common"

 LDFLAGS="${LDFLAGS} -Wl,-z"

 LDFLAGS="${LDFLAGS} -Wl,now"

 CXXFLAGS="${CFLAGS}"

 Makeopts="-j1 -s"

 FORKS="2"

 USE="-3dnow -3dnowext 64bit cpudetection 80387 mmx sse sse2 sse3 sse4" 
```

Und das läuft stabil?

----------

## Keruskerfuerst

Nein. Es gibt einige wenige Pakete, die mit diesen Flags nicht kompilieren wollen.

USE="-3dnow -3dnowext" kann man in diesem Fall weglassen.

----------

## UTgamer

Nicht übel, da hat Keruskerfuerst das für den Intel64 probiert was ich mit dem AMD64 mache, den nicht Standard aus der CPU zu quetchen.

 *Keruskerfuerst wrote:*   

> Nein. Es gibt einige wenige Pakete, die mit diesen Flags nicht kompilieren wollen.

 

Sind es bei dir auch app-emulation/wine, sys-devel/gdb und media-sound/audacity (falls in Benutzung)?

----------

## flammenflitzer

Ich habe damit emerge -e system ausgeführt. Kann das die Ursache sein, das amule jetzt unter kde mein System aufhängen läßt? 2GB Speicher und 3GB RAM sind für amule nach kurzer Zeit in Benutzung.

----------

## Keruskerfuerst

Bei mir kompiliert nur ffmpeg mit diesen Flags nicht.

----------

## UTgamer

flammenflitzer, so etwas habe ich unter AMD nie gehabt, auch amule läuft hier höchst optimiert sauber.

Das sollte eigentlich nicht die Ursache von amule sein.

Ich denke irgend eine Konfig ist beim Umstellen auf das andere System nicht mit aufgefrischt worden, oder aber du nutzt jetzt aufeinmal zu viele Threads gleichzeitig. Stichwort Hyperthreading?

Leg dir mal ein neues amule Profil an.

Keruskerfuerst danke, dann sind es andere Programme, mehr wollte ich nicht wissen. ffmpeg läuft bei mir sauber hochoptimiert mit den Co-Prozessoren. *g*

----------

## Keruskerfuerst

Bei ffmpeg muß ich -combine entfernen.

App-emulation/wine, sys-devel/gdb und media-sound/audacity sind bei mir nicht installiert.

----------

## UTgamer

Kannst du ja mal ausprobieren wenn es nicht zuviele Umstände macht.

----------

## Keruskerfuerst

Ich habe auch ein paar spezielle USE-Flags verwendet:

```
USE="${USE} 64bit 80387"

USE="${USE} 3dnow 3dnowext"

USE="${USE} a52 aac -accessibility aiglx alsa -arts"

USE="${USE} bash-completion berkdb -bindist bzip2"

USE="${USE} cairo caps cdr cdparanoia cups -cracklib -crypt"

USE="${USE} dbus -debug dri dts dvd dvdr"

#USE="${USE} doc"

USE="${USE} -eds -emboss encode esd"

USE="${USE} -fam flac -fortran ftp"

USE="${USE} -gdbm gif glibc-omitfp -gnome -gpm gtk gtk2"

USE="${USE} hal"

USE="${USE} kde kdehiddenvisibility"

USE="${USE} ipv6 -isdnlog"

USE="${USE} java javascript jpeg"

USE="${USE} ldap"

USE="${USE} mad mpeg2 mikmod mmx mmxext mp3 mp4 mpeg"

USE="${USE} ncurses nls nptl nptlonly"

USE="${USE} ogg opengl -oss"

USE="${USE} pam pcre pdf perl posix png ppds profile python"

USE="${USE} quicktime qt3 qt4"

USE="${USE} readline"

USE="${USE} sdl -spell sse sse2 ssl svg"

USE="${USE} tcpd tiff truetype"

USE="${USE} unicode"

USE="${USE} vorbis"

USE="${USE} wxGTK"

USE="${USE} X x264 xine xml xorg xv xvid"

USE="${USE} zlib"
```

----------

## Anarcho

Also ich bezweifle jetzt einfach mal das man den Unterschied zu normalem -O2 merken wird, wenn man diese endlosliste an Parametern dranhängt. Höchstwahrscheinlich dauert es nur deutlich länger zu kompilieren.

Dazu sind diverse Flags völlig überflüssig (nur mal grob drüber geguckt):

```
 CHOST="x86_64-pc-linux-gnu"

 CFLAGS="-mtune=nocona" # ist schon in -march drin

 CFLAGS="${CFLAGS} -march=nocona"

 CFLAGS="${CFLAGS} -O2"

 CFLAGS="${CFLAGS} -combine"

 CFLAGS="${CFLAGS} -falign-functions=0"

 CFLAGS="${CFLAGS} -falign-jumps=0"

 CFLAGS="${CFLAGS} -falign-labels=0"

 CFLAGS="${CFLAGS} -falign-loops=0"

 CFLAGS="${CFLAGS} -fearly-inlining"

 CFLAGS="${CFLAGS} -ffunction-cse"

 CFLAGS="${CFLAGS} -fgcse-after-reload"

 CFLAGS="${CFLAGS} -fgcse-lm"

 CFLAGS="${CFLAGS} -fkeep-static-consts"

 CFLAGS="${CFLAGS} -floop-optimize2"

 CFLAGS="${CFLAGS} -fmerge-constants"

 CFLAGS="${CFLAGS} -fno-ident"

 CFLAGS="${CFLAGS} -fomit-frame-pointer" # ist schon in -O2 drin, ausser bei x86

 CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

 CFLAGS="${CFLAGS} -frename-registers"

 CFLAGS="${CFLAGS} -fweb"

 CFLAGS="${CFLAGS} -mmmx"   # -+

 CFLAGS="${CFLAGS} -msse"   #  | sollten in march = nocona drin sein

 CFLAGS="${CFLAGS} -msse2"  #  |

 CFLAGS="${CFLAGS} -msse3"  # -+

 CFLAGS="${CFLAGS} -msse4"

 CFLAGS="${CFLAGS} -m80387"

 CFLAGS="${CFLAGS} -pipe"

 CFLAGS="${CFLAGS} -s"

 LDFLAGS="-Wl,-O4" # seit wann gibt es -O4???

 LDFLAGS="${LDFLAGS} -Wl,--as-needed"

 LDFLAGS="${LDFLAGS} -Wl,--enable-new-dtags"

 LDFLAGS="${LDFLAGS} -Wl,-s"

 LDFLAGS="${LDFLAGS} -Wl,--sort-common"

 LDFLAGS="${LDFLAGS} -Wl,-z"

 LDFLAGS="${LDFLAGS} -Wl,now"

 CXXFLAGS="${CFLAGS}"

 Makeopts="-j1 -s"

 FORKS="2"

 USE="-3dnow -3dnowext 64bit cpudetection 80387 mmx sse sse2 sse3 sse4" 
```

----------

## Keruskerfuerst

```
CFLAGS="-mtune=nocona" # ist schon in -march drin 
```

In diesem Fall würde ich mir mal den Sourecode vom GCC ansehen. Da stimmt nämlich das Handbuch nicht.

Außerdem sind meine CFLAGS keine "Endlosliste".

LDFLAGS="-Wl,-O4": gibt es, seitdem ich bis 4 zählen kann.Last edited by Keruskerfuerst on Wed Oct 10, 2007 9:12 am; edited 2 times in total

----------

## UTgamer

 *Keruskerfuerst wrote:*   

> ...
> 
> In diesem Fall würde ich mir mal den Sourecode vom GCC ansehen. Da stimmt nämlich das Handbuch nicht.
> 
> Außerdem sind meine CFLAGS keine "Endlosliste"
> ...

 

Das habe ich auch schon festgestellt, wenn ich ein paar CFLAGS extra zusätzlich angebe die eigentlich included sein sollen arbeitet gcc auch anders als wenn ich die included Flags weglasse, wobei hier wohl Portage auch eine Rolle mitspielt.

----------

## Keruskerfuerst

Ich weiß, dieser GCC ist selbstoptimierend.   :Question: 

Gdb lies sich problemlos installieren.

P.S.: audacity und wine lassen sich problemlos kompilieren.

----------

## UTgamer

Danke fürs Antesten.

----------

## Keruskerfuerst

Kleine Aktualisierung der CFLAGS:

```
CFLAGS="-mtune=nocona"

CFLAGS="${CFLAGS} -march=nocona"

CFLAGS="${CFLAGS} -O2"

CFLAGS="${CFLAGS} -combine"

CFLAGS="${CFLAGS} -falign-functions=0"

CFLAGS="${CFLAGS} -falign-jumps=0"

CFLAGS="${CFLAGS} -falign-labels=0"

CFLAGS="${CFLAGS} -falign-loops=0"

CFLAGS="${CFLAGS} -fearly-inlining"

CFLAGS="${CFLAGS} -ffunction-cse"

CFLAGS="${CFLAGS} -fgcse-after-reload"

CFLAGS="${CFLAGS} -fgcse-lm"

CFLAGS="${CFLAGS} -fkeep-static-consts"

CFLAGS="${CFLAGS} -floop-optimize2"

CFLAGS="${CFLAGS} -fmerge-constants"

CFLAGS="${CFLAGS} -fno-ident"

CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

CFLAGS="${CFLAGS} -frename-registers"

CFLAGS="${CFLAGS} -fweb"

CFLAGS="${CFLAGS} -msse3"

CFLAGS="${CFLAGS} -m80387"

CFLAGS="${CFLAGS} -pipe"

CFLAGS="${CFLAGS} -s" 
```

und der LDFLAGS:

```
LDFLAGS="-Wl,-O4"

LDFLAGS="${LDFLAGS} -Wl,--as-needed"

LDFLAGS="${LDFLAGS} -Wl,--enable-new-dtags"

LDFLAGS="${LDFLAGS} -Wl,--hash-style=both"

LDFLAGS="${LDFLAGS} -Wl,--sort-common"

LDFLAGS="${LDFLAGS} -Wl,-z,now"

```

Dazu muß binutils 2.18-r1 verwendet werden (binutils-config -l).Last edited by Keruskerfuerst on Thu Oct 18, 2007 11:44 am; edited 3 times in total

----------

## flammenflitzer

Benutzt Du schon gcc-4.2.2 ?

----------

## Keruskerfuerst

Nein. Noch GCC 4.1.2.

----------

## UTgamer

Hatte GCC-4.2.0 angetestet und alles lief, die Performance gefiel mir aber nicht. Dann habe ich das ganze System mit GCC-4.2.1 neu gebaut und einige Teile von KDE ließen sich damit nicht bauen, danach hat es mich fast 4 Tage gekostet alles wieder auf GCC-4.1.2 zurückzubauen, da ich ständig GLIBC-3.4.x Fehlermeldungen bekam. Ich würde sagen 4.2.0 ist stable aber langsamer, und die darüber sind unstable zum jetzigen Softwarerepository. Vergiß diese Versionen vorerst lieber.

----------

## flammenflitzer

 *Keruskerfuerst wrote:*   

> Kleine Aktualisierung der CFLAGS:
> 
> ```
> CFLAGS="-mtune=nocona"
> 
> ...

 Warum die Änderung?

----------

## Keruskerfuerst

```
LDFLAGS="${LDFLAGS} -Wl,-s" 
```

Entfernt die Linkersymbole, die zur "Memoryrelocation" benötigt werden. War ein Fehler die Linkeroption zu verwenden.

```
LDFLAGS="${LDFLAGS} -Wl,-z,now" 
```

Schreibfehler. Ist auch in der Dokumentation nicht korrekt angegeben.

```
CFLAGS="${CFLAGS} -mmmx"   

CFLAGS="${CFLAGS} -msse"   

CFLAGS="${CFLAGS} -msse2"
```

wird durch -msse3 automatisch mit aktiviert.Last edited by Keruskerfuerst on Sat Oct 20, 2007 7:55 pm; edited 1 time in total

----------

## schachti

 *Keruskerfuerst wrote:*   

> 
> 
> ```
> CFLAGS="${CFLAGS} -floop-optimize2"
> ```
> ...

 

Habe ich in der man page vom gcc nicht gefunden. Was macht das Flag?

Warum hast Du -ftree-vectorize nicht dabei - macht das evtl. Probleme?

----------

## think4urs11

 *schachti wrote:*   

>  *Keruskerfuerst wrote:*   
> 
> ```
> CFLAGS="${CFLAGS} -floop-optimize2"
> ```
> ...

 

 *http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options wrote:*   

> -floop-optimize2
> 
> Perform loop optimizations using the new loop optimizer. The optimizations (loop unrolling, peeling and unswitching, loop invariant motion) are enabled by separate flags.

 

aber mit gcc-4.2.2 wird es eh wegfallen

 *http://gcc.gnu.org/ml/gcc/2007-03/msg00914.html wrote:*   

> 
> 
> 2006-02-10  Zdenek Dvorak <dvorakz@suse.cz>
> 
> (-floop-optimize2): Removed.

 

----------

## schachti

ok, dann kann ich es bei mir in der man page von gcc 4.2.2 auch nicht finden.   :Wink: 

----------

## Keruskerfuerst

 *Quote:*   

> Warum hast Du -ftree-vectorize nicht dabei - macht das evtl. Probleme?

 

Habe ich schon mal ausprobiert. Vergrößert den kompilierten Code ziemlich. Als Folge ist der erzeugte Code langsamer.

----------

## UTgamer

Ich nehme auch wieder Abstand von -ftree-vectorize; ausprobiert und war nicht zufrieden.

----------

## Keruskerfuerst

 *Quote:*   

> -floop-optimize2
> 
> Perform loop optimizations using the new loop optimizer. The optimizations (loop unrolling, peeling and unswitching, loop invariant motion) are enabled by separate flags.

 

Falsch. Dies ist der richtige Schleifenoptimierer.

----------

## Keruskerfuerst

```
CFLAGS="-mtune=nocona"

CFLAGS="${CFLAGS} -march=nocona"

CFLAGS="${CFLAGS} -O2"

CFLAGS="${CFLAGS} -combine"

CFLAGS="${CFLAGS} -falign-functions=0"

CFLAGS="${CFLAGS} -falign-jumps=0"

CFLAGS="${CFLAGS} -falign-labels=0"

CFLAGS="${CFLAGS} -falign-loops=0"

CFLAGS="${CFLAGS} -fearly-inlining"

CFLAGS="${CFLAGS} -ffunction-cse"

CFLAGS="${CFLAGS} -fgcse-after-reload"

CFLAGS="${CFLAGS} -fgcse-lm"

CFLAGS="${CFLAGS} -fkeep-static-consts"

CFLAGS="${CFLAGS} -floop-optimize2"

CFLAGS="${CFLAGS} -fmerge-constants"

CFLAGS="${CFLAGS} -fno-ident"

CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

CFLAGS="${CFLAGS} -frename-registers"

CFLAGS="${CFLAGS} -fweb"

CFLAGS="${CFLAGS} -msse3"

CFLAGS="${CFLAGS} -m80387"

CFLAGS="${CFLAGS} -pipe"

CFLAGS="${CFLAGS} -s"

und der LDFLAGS:

LDFLAGS="-Wl,-O4"

LDFLAGS="${LDFLAGS} -Wl,--as-needed"

LDFLAGS="${LDFLAGS} -Wl,--enable-new-dtags"

LDFLAGS="${LDFLAGS} -Wl,--hash-style=both"

LDFLAGS="${LDFLAGS} -Wl,--sort-common"

LDFLAGS="${LDFLAGS} -Wl,-z,now"
```

Kennt jemand eine Verbesserung der obigen Einstellungen?

----------

## kernelOfTruth

Marker / Reminder

verrückte liste an cflags ^_^, die muss ich mir mal genauer anschauen   :Smile: 

also ich hatte standardmäßig:

-fforce-addr -Wno-error -fivopts -fmodulo-sched -ftree-loop-im -ftree-loop-ivcanon

zu meinen hardened specs drin, vielleicht bringen die was ...

----------

## Genone

 *Keruskerfuerst wrote:*   

>  *Quote:*   Ich habe dazu noch nie was gelesen - seit wann gibt es dieses Feature denn in Portage? 
> 
> Dies ist nirgends in der Dokumentation enthalten. 
> 
> Seit einigen Monaten.

 

K.A. wo du das herhast:

```
$ grep -r FORK /usr/lib/portage/

$ 
```

(gleiches gilt für trunk/ aka portage-2.2)

Und USE=80387 sieht mir auch irgendwie nach Hirngespinst aus. Um die *FLAGS durchzugehen ist mir meine Zeit zu schade.Last edited by Genone on Sun Oct 28, 2007 2:53 am; edited 1 time in total

----------

## Keruskerfuerst

 *Quote:*   

> K.A. wo du das herhast:
> 
> ```
> $ grep -r FORK /usr/lib/portage/
> 
> ...

 

Portage ist eben eine Wundertüte...

Weiß ich, seitdem ich bei einem Entwickler nachgefragt habe.

----------

## Genone

 *Keruskerfuerst wrote:*   

>  *Quote:*   K.A. wo du das herhast:
> 
> ```
> $ grep -r FORK /usr/lib/portage/
> 
> ...

 

Und wer soll das bitte gewesen sein? Weil der hätte dir ziemlichen Blödsinn erzählt.

----------

## Keruskerfuerst

Zu FORKS="<Anzahl der Cpukerne>" gibt es im Entwicklerforum einen Thread.

----------

## Genone

 *Keruskerfuerst wrote:*   

> Zu FORKS="<Anzahl der Cpukerne>" gibt es im Entwicklerforum einen Thread.

 

Ah, so langsam dämmert mir woher der ganze Quatsch kommt. Aber der Reihe nach:

1) ich nehme mal an, du meinst das "Portage + Programming" Forum, denn im "Developers" Forum gibt es keinen auch nur entfernt relevanten Thread (mal davon abgesehen dass du da auch keinen Zugriff hast)

2) schätze mal, du meinst diesen Thread: https://forums.gentoo.org/viewtopic-t-484842.html Dann sollte dir aber auch klar sein dass da kein Entwickler (im Sinne von Gentoo bzw. Portage Developer) direkt dran beteiligt ist, und das ganze ein inoffizieller Patch ist der in keinem offiziellem Release vorhanden ist.

Insofern sind deine Aussagen bestenfalls ungenau, aber für die meisten Leute wohl eher direkte Fehlinformation.

----------

## Keruskerfuerst

 *Quote:*   

> 1) ich nehme mal an, du meinst das "Portage + Programming" Forum, denn im "Developers" Forum gibt es keinen auch nur entfernt relevanten Thread (mal davon abgesehen dass du da auch keinen Zugriff hast) 
> 
> 

 

Ich habe auf dieses Forum auch noch Zugriff. Es gibt für den Eintrag FORKS="<Anzahl der Cpukerne>" einen Thread im Entwicklerforum. Kann man auch leicht ausprobieren, indem man den entsprechenden Eintrag in /etc/make.conf hinzufügt.

 *Quote:*   

> 2) schätze mal, du meinst diesen Thread: https://forums.gentoo.org/viewtopic-t-484842.html Dann sollte dir aber auch klar sein dass da kein Entwickler (im Sinne von Gentoo bzw. Portage Developer) direkt dran beteiligt ist, und das ganze ein inoffizieller Patch ist der in keinem offiziellem Release vorhanden ist. 
> 
> 

 

Nein.

 *Quote:*   

> Insofern sind deine Aussagen bestenfalls ungenau, aber für die meisten Leute wohl eher direkte Fehlinformation.

 

Vielleicht solltest Du dich mal besser informieren.

----------

## Genone

 *Keruskerfuerst wrote:*   

>  *Quote:*   Insofern sind deine Aussagen bestenfalls ungenau, aber für die meisten Leute wohl eher direkte Fehlinformation. 
> 
> Vielleicht solltest Du dich mal besser informieren.

 

Vielleicht solltest du deine Behauptungen mal belegen.

----------

## think4urs11

 *Genone wrote:*   

>  *Keruskerfuerst wrote:*    *Quote:*   Insofern sind deine Aussagen bestenfalls ungenau, aber für die meisten Leute wohl eher direkte Fehlinformation. Vielleicht solltest Du dich mal besser informieren. Vielleicht solltest du deine Behauptungen mal belegen.

 

++ Ich schließe mich Genone an - verifizierbare Fakten bitte.

Die Gruppen die meines Wissens nach Zugriff auf 'das Developer-Forum' (auf forums.gentoo.org) haben weisen deinen Nick jedenfalls schon mal nicht aus.

----------

## kernelOfTruth

 *Keruskerfuerst wrote:*   

>  *Quote:*   Warum hast Du -ftree-vectorize nicht dabei - macht das evtl. Probleme? 
> 
> Habe ich schon mal ausprobiert. Vergrößert den kompilierten Code ziemlich. Als Folge ist der erzeugte Code langsamer.

 

außerdem scheint das ungenau zu sein   :Confused: 

openssl fliegt beim test immer raus ohne das läuft der test durch (auch mit ffast-math !)

----------

## Keruskerfuerst

An dieser Diskussion scheinen sich Personen zu beteiligen, die 

a) sich noch nie den GCC Sourcecode angesehen haben

b) Ebuilds noch nie mit anderen als den Standartcompilerflags kompiliert haben

----------

## schachti

 *Keruskerfuerst wrote:*   

> An dieser Diskussion scheinen sich Personen zu beteiligen, die 
> 
> a) sich noch nie den GCC Sourcecode angesehen haben
> 
> b) Ebuilds noch nie mit anderen als den Standartcompilerflags kompiliert haben

 

Welche Forenregel verbietet das denn?

----------

## Anarcho

 *Keruskerfuerst wrote:*   

> An dieser Diskussion scheinen sich Personen zu beteiligen, die 
> 
> a) sich noch nie den GCC Sourcecode angesehen haben
> 
> b) Ebuilds noch nie mit anderen als den Standartcompilerflags kompiliert haben

 

Da wir leider alle unfähig sind den GCC-Sourcecode durchzulesen (oder sollte ich viel mehr sagen unwillent, denn ich kann meine Zeit sinnvoller nutzen, dazu gibt es man-pages...) zeig uns doch bitte die entsprechenden Stellen. Dann kannst du uns das ganz einfach belegen und wir geben alle ruhe.

Auch den Code mit -O4 bitte, denn, ich weiss nicht ob du das gelesen hast, aber es geht auch -O128, -O1024 usw. nur kommt dabei nichts anderes raus als mit -O3.

----------

## Keruskerfuerst

 *schachti wrote:*   

>  *Keruskerfuerst wrote:*   An dieser Diskussion scheinen sich Personen zu beteiligen, die 
> 
> a) sich noch nie den GCC Sourcecode angesehen haben
> 
> b) Ebuilds noch nie mit anderen als den Standartcompilerflags kompiliert haben 
> ...

 

Keine. 

Überaus interessante Signatur, nebenbei bemerkt.

 *Quote:*   

> Da wir leider alle unfähig sind den GCC-Sourcecode durchzulesen (oder sollte ich viel mehr sagen *unwillend*, denn ich kann meine Zeit sinnvoller nutzen, dazu gibt es man-pages...) zeig uns doch bitte die entsprechenden Stellen. Dann kannst du uns das ganz einfach belegen und wir geben alle ruhe.
> 
> Auch den Code mit -O4 bitte, denn, ich weiss nicht ob du das gelesen hast, aber es geht auch -O128, -O1024 usw. nur kommt dabei nichts anderes raus als mit -O3.

 

Ausschnitt aus gcc 4.2.2/gcc/opts.c

```
if (!optimize)

    {

      flag_merge_constants = 0;

    }

  if (optimize >= 1)

    {

      flag_defer_pop = 1;

#ifdef DELAY_SLOTS

      flag_delayed_branch = 1;

#endif

#ifdef CAN_DEBUG_WITHOUT_FP

      flag_omit_frame_pointer = 1;

#endif

      flag_guess_branch_prob = 1;

      flag_cprop_registers = 1;

      flag_if_conversion = 1;

      flag_if_conversion2 = 1;

      flag_ipa_pure_const = 1;

      flag_ipa_reference = 1;

      flag_tree_ccp = 1;

      flag_tree_dce = 1;

      flag_tree_dom = 1;

      flag_tree_dse = 1;

      flag_tree_ter = 1;

      flag_tree_live_range_split = 1;

      flag_tree_sra = 1;

      flag_tree_copyrename = 1;

      flag_tree_fre = 1;

      flag_tree_copy_prop = 1;

      flag_tree_sink = 1;

      flag_tree_salias = 1;

      if (!no_unit_at_a_time_default)

        flag_unit_at_a_time = 1;

      if (!optimize_size)

   {

     /* Loop header copying usually increases size of the code.  This used

        not to be true, since quite often it is possible to verify that

        the condition is satisfied in the first iteration and therefore

        to eliminate it.  Jump threading handles these cases now.  */

     flag_tree_ch = 1;

   }

    }

  if (optimize >= 2)

    {

      flag_thread_jumps = 1;

      flag_crossjumping = 1;

      flag_optimize_sibling_calls = 1;

      flag_cse_follow_jumps = 1;

      flag_cse_skip_blocks = 1;

      flag_gcse = 1;

      flag_expensive_optimizations = 1;

      flag_ipa_type_escape = 1;

      flag_rerun_cse_after_loop = 1;

      flag_caller_saves = 1;

      flag_peephole2 = 1;

#ifdef INSN_SCHEDULING

      flag_schedule_insns = 1;

      flag_schedule_insns_after_reload = 1;

#endif

      flag_regmove = 1;

      flag_strict_aliasing = 1;

      flag_strict_overflow = 1;

      flag_delete_null_pointer_checks = 1;

      flag_reorder_blocks = 1;

      flag_reorder_functions = 1;

      flag_tree_store_ccp = 1;

      flag_tree_store_copy_prop = 1;

      flag_tree_vrp = 1;

      if (!optimize_size)

   {

          /* PRE tends to generate bigger code.  */

          flag_tree_pre = 1;

   }

    }

  if (optimize >= 3)

    {

      flag_inline_functions = 1;

      flag_unswitch_loops = 1;

      flag_gcse_after_reload = 1;

    }

  if (optimize < 2 || optimize_size)

    {

      align_loops = 1;

      align_jumps = 1;

      align_labels = 1;

      align_functions = 1;

      /* Don't reorder blocks when optimizing for size because extra

    jump insns may be created; also barrier may create extra padding.

    More correctly we should have a block reordering mode that tried

    to minimize the combined size of all the jumps.  This would more

    or less automatically remove extra jumps, but would also try to

    use more short jumps instead of long jumps.  */

      flag_reorder_blocks = 0;

      flag_reorder_blocks_and_partition = 0;

    }

  if (optimize_size)

    {

      /* Inlining of very small functions usually reduces total size.  */

      set_param_value ("max-inline-insns-single", 5);

      set_param_value ("max-inline-insns-auto", 5);

      flag_inline_functions = 1;

      /* We want to crossjump as much as possible.  */

      set_param_value ("min-crossjump-insns", 1);

    }

```

Den Ausschnitt aus ld (binutils) suche ich noch heraus.

----------

## Anarcho

Wie ich schon sagte, hier macht -O4 keinen Sinn, es läuft aufs gleiche hinaus wie -O3. Oder was wolltest du zeigen?

Ich bin dann mal auf den Linker gespannt.

Es fehlt aber noch der Beweis das -mtune nicht in -march drin ist (bedenke: es geht um die x86(_64) Architektur).

----------

## Keruskerfuerst

Wobei soll -O4 denn Sinn oder keinen Sinn machen?

----------

## Max Steel

beim compilieren.

-O4 ist dasselbe wie -O3

----------

## Keruskerfuerst

Ich verwende beim Kompilieren das Flag -O2.

----------

## flammenflitzer

Ich habe jetzt

```
CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer -s -mfpmath=sse -msse2 -mmmx"

CXXFLAGS="${CFLAGS}"

Makeopts="-j1 -s"

FORKS="2"
```

 Schon mit meinem alten Prozessor hatte ich eine ellenlange Liste mit CFLAGS. Am besten lief das System damals, als ich wieder die Standard "Safe" CFLAGS eingetragen habe.

----------

## Anarcho

 *flammenflitzer wrote:*   

> Ich habe jetzt
> 
> ```
> CHOST="x86_64-pc-linux-gnu"
> 
> ...

 

Wobei wohl immer noch offen ist ob FORKS überhaupt existiert in einem ungepatchen Portage.

 *Genone wrote:*   

> 
> 
> ```
> grep -r FORK /usr/lib/portage/
> ```
> ...

 

----------

## Klaus Meier

Zu den ganzen Compilerflags kann ich nur sagen:

1. Ich hab auch mal so nen Trieb gehabt und tausende Kombinationen durch irgendwelche Benchmarks gejagt. Vorteil für das ganze System: Null.

2. Solche Aussagen wie bei mir läuft fast-math oder ähnliches ohne Probleme sind ohne Wert. Dieses flag macht definitiv Probleme. Wer es für sich selber nutzt ok, aber bitte nicht anderen empfehlen. 

3. Es geht hier um einen Eintrag in der make.conf. Damit wird das ganze System übersetzt. Ich habe stellenweise den Eindruck, dass manche glauben, je mehr Flags, um so schneller der Code. Nur ist es so, dass bei 90% aller Anwendungen auf einem Desktopsystem nicht die Geschwindigkeit des Codes sondern die Ladezeit entscheidend für die Performance ist. Wenn ich ein Terminal starte, dann will ich es möglichst schnell, die Arbeitsgeschwindigkeit des Terminals ist immer hoch genug.

4. Für das ganze System kommt deshalb nichts anderes als -O2 oder -Os in Frage. Etwas anderes ist es für spezielle Anwendungen. Da sollte man einfach mal zusehen, was passiert, wenn man den mplayer installiert. Da wird hoch optimiert, sogar mit fast-math, weil es da was bringt und bei dem begrenzten Zahlenbereich der Pixel fast-math genau genug ist. Also, viele Anwendungen, bei denen eine spezielle Optimierung etwas bringt, haben dies schon in den ebuilds eingebaut.

5. Spezielle Flags, die eine Anwendung beschleunigen, können eine andere verlangsamen.

Sollte mir jemand beweisen, das es irgendwelche Flags gibt, die über die in den Save CFlags empfohlenen hinausgehen und als Eintrag in der make.conf etwas bringen, dann würde es mich sehr freuen, mich geirrt zu haben.

Es steht in allen Beiträgen nur, welche CFlags derjenige benutzt. Irgend einen Hinweis darauf, was es denn nun bringt oder warum genau diese Einstellungen habe ich nicht gelesen.

----------

## Genone

 *Anarcho wrote:*   

> Wobei wohl immer noch offen ist ob FORKS überhaupt existiert in einem ungepatchen Portage.

 

Ich denke mal keine Antwort ist auch ne Antwort   :Wink: 

(und die Frage war eh nicht offen, als "Chefentwickler" sollte ich wohl wissen ob es sowas gibt oder nicht)

----------

## Keruskerfuerst

Neue CFLAGS:

CFLAGS="-mtune=k8"

CFLAGS="${CFLAGS} -march=k8"

CFLAGS="${CFLAGS} -O2"

CFLAGS="${CFLAGS} -combine"

CFLAGS="${CFLAGS} -falign-functions=0"

CFLAGS="${CFLAGS} -falign-jumps=0"

CFLAGS="${CFLAGS} -falign-labels=0"

CFLAGS="${CFLAGS} -falign-loops=0"

CFLAGS="${CFLAGS} -fearly-inlining"

CFLAGS="${CFLAGS} -ffunction-cse"

CFLAGS="${CFLAGS} -fgcse-after-reload"

CFLAGS="${CFLAGS} -fgcse-lm"

CFLAGS="${CFLAGS} -fkeep-static-consts"

CFLAGS="${CFLAGS} -floop-optimize2"

CFLAGS="${CFLAGS} -fmerge-constants"

CFLAGS="${CFLAGS} -fno-ident"

CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

CFLAGS="${CFLAGS} -frename-registers"

CFLAGS="${CFLAGS} -msse2"

CFLAGS="${CFLAGS} -m80387"

CFLAGS="${CFLAGS} -fweb"

CFLAGS="${CFLAGS} -pipe"

Neue LDFLAGS:

LDFLAGS="-Wl,-O4"

LDFLAGS="${LDFLAGS} -Wl,--as-needed"

LDFLAGS="${LDFLAGS} -Wl,--enable-new-dtags"

LDFLAGS="${LDFLAGS} -Wl,--hash-style=both"

LDFLAGS="${LDFLAGS} -Wl,--sort-common"

LDFLAGS="${LDFLAGS} -Wl,-S"

LDFLAGS="${LDFLAGS} -Wl,-z,now"

----------

## buggybunny

@Keruskerfürst, 

bist du ein Troll?

Machst erst ein Riesenfass auf von wegen wie doof alle sind außer dir, stellst Behauptungen auf und postest dann zum Beleg sourcecode der nichts mit der Behauptung zu tun hat.

Abgesehen davon, das du dir auch zu schade bist auf Gegenargumente einzugehen.

Was war jetzt nochmal damit:

```
grep -irsI fork /usr/lib/portage/

/usr/lib/portage/pym/portage_exec.py:   pid = os.fork()

```

?

----------

## think4urs11

locked bevor die Diskussion noch weiter in die Sinnlosigkeit abdriftet; ein Bezug zum Thema ist eh nur noch gelegentlich erkennbar.

----------

