# Dualcore Prozessoren

## flammenflitzer

Werden die Dualcore Prozessoren so unterstützt, das es Sinn macht, sich einen solchen zuzulegen? Oder steckt die Unterstützung noch in den Kinderschuhen? (Hatte mir vor Jahren auch einen der ersten 64bit prozessoren zugelegt, nur um dann nach 1,5 Jahren zufällig festzustellen, das ich performancemäßig in dieser ganzen Zeit mit einem 32bit system besser gefahren wäre.)

----------

## der.gecko

naja, zwei kerne machen schon sinn, da prozesse auf die kerne verteilt werden können. vor allem bei rechenintensiven anwendungen (seit einem jahr auch viele spiele) ist ein deutlicher performanceschub zu erwarten, da mehr instruktionen in der gleichen zeit ausgeführt werden können. in den "kinderschuhen" stekct die unterstützung nicht mehr, da praktisch alle desktop und server betriebssysteme mehrere cpus, bzw. cpukerne unterstützen.

zu deiner 64bit cpu, muss ich sagen, dass du auch nur dann eine bessere performance erwarten kannst, wenn du ein 64bit betriebssystem und entsprechende 64bit treiber und anwendungen verwendest...

solange du nicht von berufs wegen (z.b. video-bearbeitung oder mathematische berechnungen) einen schnellen rechner brauchst, der viele sachen gleichzeitig können muss, solltest du mit deiner jetzigten cpu sicher noch 1-2 jahre zurecht kommen. auch für aktuelle pc spiele ist deine cpu ausreichend (ich hab s.t.a.l.k.e.r. mit einem athlon xp 2400 gespielt  :Wink: )... mehr arbeitsspeicher und bessere grafikkarten haben da den grössten einfluss.

ein tipp zum schluss, verusche lieber ein paar onboard komponenten durch dedizierte karten zu ersetzen (z.b. raid oder audio). damit entlastest du deine cpu und kannst die karten bei einem pc neukauf "mitnehmen".

----------

## flammenflitzer

Ich hatte von Anfang an x86_64 Gentoo.

Ich habe einen SATA Hardware RAID. Bei Multimedia Anwendungen (Videobearbeitung, Slideshow erstellen) kommt die Kiste aber nicht so richtig aus der Hüfte.

----------

## _eckobar_

also ich bin mit der performance von meinem core2duo 2.4GHz durchwegs zufrieden. ich kann es nur empfehlen. hatte vorher einen p4 2.8GHz .... da liegen welten dazwischen.

PS: gleich im voraus ... bitte kein kindischen flames betreffend intel

----------

## UTgamer

 *flammenflitzer wrote:*   

> Werden die Dualcore Prozessoren so unterstützt, das es Sinn macht, sich einen solchen zuzulegen? 

  Ja und nein, jenachdem was du vorhast. Ich habe demletzt OpenOffice neu kompiliert und Portage nutzte nur eine CPU, eigentlich genau die großen Pakete wo man auf die Geschwindigkeit wartet, benutzen nur eine CPU.  Vor 1,5 Jahren wahren weit mehr Anwendungen von Portage mit 2 CPUs gebaut worden als heute.  :Sad:  Hier lohnt es sich nicht mehr.

Mein Hauptgrund damals für den Dualprozessor war das ich auf LAN-Parties auf dem einen Kern einen 24 Personen dedicated UT-Server fahre, um auf dem 2. Prozessor selbst zu spielen, und das klappt sogar sehr gut, mehr Personen währen noch drinn gewesen aber die Netzwerkverbindung hat nicht mehr geschafft gehabt.

 *flammenflitzer wrote:*   

> Ich hatte von Anfang an x86_64 Gentoo.
> 
> Ich habe einen SATA Hardware RAID. Bei Multimedia Anwendungen (Videobearbeitung, Slideshow erstellen) kommt die Kiste aber nicht so richtig aus der Hüfte.

 

Meinst du diese Onboard Fake-Raids? Dann brauchst du dich über weniger Geschwindigkeit kaum zu wundern. Die Aufgabe übernimmt trotzdem deine CPU, da fährst du selbst mit einem Linuxsoftwareraid noch schneller, falls es ein Fakeraid sein sollte.  :Wink: 

Dies ist gesagt worden, so wird es auch kommentiert.  :Wink: 

 *flammenflitzer wrote:*   

> (Hatte mir vor Jahren auch einen der ersten 64bit prozessoren zugelegt, nur um dann nach 1,5 Jahren zufällig festzustellen, das ich performancemäßig in dieser ganzen Zeit mit einem 32bit system besser gefahren wäre.)

 

Ich habe einen AMD64 x2 mit 3GB-RAM und ich habe zusätzlich noch ein Debian zum testen und lernen drauf, damit habe ich die 32 Bitversion und 64 Bitversion getestet gehabt. Ich muß sagen die 32 Bitversion ist langsamer gewesen. Mein UT2004 (64Bitversion) läuft ebenfalls schneller auf dem 64 Bitsystem, der nVidia-Treiber(64) ist auch schneller und mein Quake 4 (32) unterstützt Multiprozessoren.

Die ersten Intel 64 Bitsysteme waren so schlecht, das sich selbst Microsoft bei Intel beschwerte auf AMD64 umzusteigen. In anderen Threads wurde ich häufiger gefragt warum meine Grafikleistung so hoch ist bei ~ gleichen Komponenten, ich nutze ja nur die CFLAGS aus meiner Signatur die auf Intel ebenfalls nicht problemlos laufen.  :Wink:  Sun und IBMs Flagschiffe sind bereits bei 128 bit. Der AMD MMX Chipsatz ist ebenfalls bereits bei 128 Bit in meinem schon 2 Jahre alten AMD64 3800+. Von Intel sind mir noch keine 128 Bitarchitekturen bekannt. Brauchst dich bei einem Intel nicht zu wundern wenn du die Performanceunterschiede nicht merkst. *g*

----------

## schachti

Ich bin vor ca. einem halben Jahr auf ein Dual Core System umgestiegen, und für meine Arbeitsumgebung macht es einen riesigen Unterschied. Alles läuft viel flüssiger, weil ein Prozeß mit hoher CPU-Last nicht gleich das komplette System lahmlegt, sondern nur einen der beiden Kerne - der andere kann sich dann um X-Server, Browser etc. kümmern. Ich habe oft Amarok nebenbei laufen, das ja auch ganz ordentlich CPU-Last zieht, und meine Home-Partition ist verschlüsselt, was sich bei Zugriffen in hoher CPU-Auslastung bemerkbar macht. Außerdem kodiere ich ab und zu mal einen Haufen Audiodateien als MP3 oder rippe mal eine DVD - in so einem Szenario ist eine Dual Core CPU ideal, weil die X-Oberfläche und Browser, Mail-Client etc. trotz der hohen Last noch flüssig laufen.

----------

## Treborius

ich denke, 

das es auch noch zeit braucht bis multi-cores wirklich gut unterstüzt werden,

ich schreibe gerade an einem project mit open-mp und erreiche gut 190% prozessorauslastung unter top,

aber der arbeitsaufwand ist selbst mit openmp eben erheblich grösser.

und bei den meisten programmen macht openmp garkeinen sinn, 

weil sie garnicht soviel power brauchen, 

aber die anderen projecte werden wohl irgendwann umsteigen ...

----------

## manuels

Jo, das meiste ist einfach nicht parallelisierbar. Da kann man nur die CPU(s) auslasten, wenn mehrere Programme gleichzeitig laufen.

Und alles nur weil niemand ne Idee hat, wie man CPUs baut, die weniger Abwärme liefern...

----------

## der.gecko

sieh es doch mal positiv.

ich benutze meine heizung schon seit jahren nicht mehr^^

----------

## flammenflitzer

Zum Raid 

```
00:13.0 RAID bus controller: 3ware Inc 7xxx/8xxx-series PATA/SATA-RAID (rev 01)
```

 Ein Hardwareraid. Ist allerdings für einen 64bit PCI Steckplatz gemacht. Ich habe nur einen 32bit Steckplatz.

----------

## Jinidog

Mein Upgrade von einem AthlonXP-2800+ auf einen AthlonX2-4400+ hat mein Gentoo kaum spürbar beschleunigt. Systemstart ist etwas schneller, hängt aber vermutlich mehr mit der etwas schnelleren Festplatte zusammen.

Wo die beiden Kerne voll ausgenutzt werden, ist das System in der Tat doppelt so schnell. Das ist aber nur bei wenigen Anwendungen der Fall. Kompilieren kann entsprechend deutlich schneller gehen. (ein einzelner Kern ist dabei maximal 30% schneller als mein alter)

Das man mit Dualcores schneller zwischen Anwendungen umschalten kann, kann ich nicht bestätigen und halte das sowieso für ein Märchen. Da kommt es eher auf den Arbeitsspeicher an.

----------

## der.gecko

*zustimm*

mal von der technischen seite abgesehen, unterliegt der hardwaremarkt starken preisschwankungen... da kann es manchmal sogar sinnvoll sein eine woche mit dem kauf zu warten. ganz geduldige wie ich  :Embarassed:  sparen viel geld, wenn sie mit dem neukauf für einen bsetimmten rechner auch mal ein jahr oder so warten können^^

----------

## UTgamer

 *Jinidog wrote:*   

> Mein Upgrade von einem AthlonXP-2800+ auf einen AthlonX2-4400+ hat mein Gentoo kaum spürbar beschleunigt. Systemstart ist etwas schneller, hängt aber vermutlich mehr mit der etwas schnelleren Festplatte zusammen.
> 
> Wo die beiden Kerne voll ausgenutzt werden, ist das System in der Tat doppelt so schnell. Das ist aber nur bei wenigen Anwendungen der Fall. Kompilieren kann entsprechend deutlich schneller gehen. (ein einzelner Kern ist dabei maximal 30% schneller als mein alter)
> 
> Das man mit Dualcores schneller zwischen Anwendungen umschalten kann, kann ich nicht bestätigen und halte das sowieso für ein Märchen. Da kommt es eher auf den Arbeitsspeicher an.

 

Irgendetwas macht ihr aber falsch. Ich habe als 2. stärksten Rechner immer noch meinen Athlon 2400+ mit 1GB RAM, und der aktuelle AMD3800+ x2 ist auf einem Kern allein bereits doppelt so schnell wie der alte, selbst schon beim kompilieren. Was macht ihr das ihr die so langsam bekommt?

----------

## Max Steel

Wie schafft man das eig, 2 Kernel gleichzeitig laufen lassen?

Wenn man einen 2 Kern Prozessor hätte, ich nicht, es interresiert mich einfach.

----------

## UTgamer

Max Steel, das entscheidet die Anwendung, ob Programmierer es eingebaut haben oder nicht.

----------

## Jinidog

 *UTgamer wrote:*   

> 
> 
> Irgendetwas macht ihr aber falsch. Ich habe als 2. stärksten Rechner immer noch meinen Athlon 2400+ mit 1GB RAM, und der aktuelle AMD3800+ x2 ist auf einem Kern allein bereits doppelt so schnell wie der alte, selbst schon beim kompilieren. Was macht ihr das ihr die so langsam bekommt?

 

Die Gesamtperformance eines Systems hängt von weitaus mehr ab, als einem Prozessor. Beim Kompilieren spielt auch die Festplatte eine Rolle.

100% Leistungsgewinn von einem AthlonXP mit 2 GHz auf einen Athlon64 mit 2 GHz kann nicht an der CPU liegen. 

Der Athlon64 ist eine Fortentwicklung des XP, ist sicherlich schneller, aber mehr als 20% Performancegewinn ist (außer in Spezialfällen) nicht zu erwarten.

Dass der Geschwindigkeitsunterschied bei dir größer ist, wird aber sicherlich dadurch beeinflusst, dass du noch einen XP mit 266 MHz Frontsidebus hast, während meiner schon zur 333er Generation gehörte.

Ansonsten hatte ich bei mir nur einige wenige merges, die richtig zugelegt haben. Mplayer kompiliert nun drei Mal so schnell, ist aber auch Spitzenreiter. Von dem Geschwindigkeitsgewinn durch die beiden Kerne merke ich aber bei der normalen Nutzung kaum was. (sei angemerkt, dass auch der AthlonXP vom Surfen und Arbeiten ja sowieso nie ausgelastet wurde)

----------

## UTgamer

@Jinidog, da ist was drann, auch an den Bustackten. Ja mein 2400+ hat noch 266MHz.

Bis auf eine einzige Anwendung (OpenOffice) kompiliere ich ausschließlich alles im RAM.

Ich habe 3 GB RAM die sich für Gentoo beim Kompilieren wirklich lohnen.

Dazu verwende ich nicht den Standard emerge Befehl sondern einen getunten, also emerge im Script.

Mein Script /usr/bin/temerge:

```
#!/bin/bash

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

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

# Wenn die Datei .keep nicht existiert, noch erstellen

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.
```

Mein Athlon 2400+ (32) hat 1 GB RAM, trotzdem lasse ich auch dort fast alle emerges mit einer 850MB temerge RAM-Disk laufen, und der 3800+(64)  ist trotzdem mehr als doppelt so schnell beim kompilieren.

Firefox (je nach Version) benötigt auf dem 64 Bitrechner rund 20 Minuten, und auf dem 32 Bitrechner rund 50 Minuten. Beides auf einer RAM-Disk. (Werte aus dem Gedächtniss).

----------

## Jinidog

mit genlop -t mozilla-firefox kannst du abrufen, wieviel Zeit ein merge gebracht hat.

Dass eine RAM-Disk viel Geschwindigkeit bringt, bezweifle ich. Wenn genug RAM da ist, bleiben die Dateien eh im FileCache, also im Arbeitsspeicher genauso wie bei einer RAM-Disk.

----------

## UTgamer

Nein, ich mußte ja wegen den neuen Updates um OpenOffice und weitere Pakete emergen zu können auch Perl neubauen.

```
genlop -t mozilla-firefox

Can't locate Date/Manip.pm in @INC (@INC contains: /etc/perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux /usr/lib64/perl5/vendor_perl/5.8.8 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux /usr/lib64/perl5/site_perl/5.8.8 /usr/lib64/perl5/site_perl /usr/lib64/perl5/5.8.8/x86_64-linux /usr/lib64/perl5/5.8.8 /usr/local/lib/site_perl .) at /usr/bin/genlop line 24.

BEGIN failed--compilation aborted at /usr/bin/genlop line 24.
```

Klappt nicht mehr. Genloop wurde nochmal neu gebaut ändert aber nichts an der Ausgabe.

----------

## dertobi123

 *UTgamer wrote:*   

> 
> 
> ```
> genlop -t mozilla-firefox
> 
> ...

 

emerge dev-perl/DateManip

----------

## UTgamer

Danke Tobi  :Very Happy: 

```
genlop -t mozilla-firefox

 * www-client/mozilla-firefox

     Fri Jun  8 03:24:35 2007 >>> www-client/mozilla-firefox-1.5.0.12

       merge time: 30 minutes and 17 seconds.
```

War in der Version wohl etwas länger. Die neueren FF setze ich nicht mehr ein und mein Overlay für 1.5.0.12 muß ich erst noch umbenennen da die Version von Portage gemasked wurde, wir können ja ein anderes Beispiel nehmen. Z.B. den aktuellen Seamonkey.

Athlon64 3800x2 bei 3GB RAM

```
genlop -t seamonkey

 * www-client/seamonkey

     Fri Jun  8 03:57:59 2007 >>> www-client/seamonkey-1.1.2

       merge time: 30 minutes and 47 seconds.

     Sun Jul 22 16:44:12 2007 >>> www-client/seamonkey-1.1.3

       merge time: 20 minutes and 57 seconds.

     Mon Aug  6 14:14:54 2007 >>> www-client/seamonkey-1.1.4

       merge time: 20 minutes and 24 seconds.
```

Athlon 2400+ bei 1GB RAM

```
genlop -t seamonkey

 * www-client/seamonkey

     Wed Dec 20 16:05:07 2006 >>> www-client/seamonkey-1.0.6

       merge time: 1 hour, 14 minutes and 3 seconds.

     Thu Jan  4 19:12:49 2007 >>> www-client/seamonkey-1.0.7

       merge time: 50 minutes and 43 seconds.

     Fri Mar  2 16:27:54 2007 >>> www-client/seamonkey-1.1.1

       merge time: 1 hour, 21 minutes and 14 seconds.

     Tue Jun 19 05:00:16 2007 >>> www-client/seamonkey-1.1.2

       merge time: 1 hour, 19 minutes and 41 seconds.

     Tue Aug  7 13:26:53 2007 >>> www-client/seamonkey-1.1.3

       merge time: 1 hour, 16 minutes and 12 seconds.

     Tue Aug  7 17:45:24 2007 >>> www-client/seamonkey-1.1.4

       merge time: 1 hour, 16 minutes and 18 seconds.
```

Es hatte beim 2400+ sogar noch länger gedauert als ich gedacht hatte.  :Wink: 

Jaja, das 64er System habe ich nicht bereut.

----------

## xraver

 *Jinidog wrote:*   

> 
> 
> Dass eine RAM-Disk viel Geschwindigkeit bringt, bezweifle ich. Wenn genug RAM da ist, bleiben die Dateien eh im FileCache, also im Arbeitsspeicher genauso wie bei einer RAM-Disk.

 

Hm, bei mir schaut es aber so aus.

Ohne tmpfs

```
Sat Aug 18 14:17:30 2007 >>> www-client/mozilla-firefox-2.0.0.6

merge time: 8 minutes and 36 seconds.

```

mit tmpfs

```
Sat Aug 18 14:26:16 2007 >>> www-client/mozilla-firefox-2.0.0.6

merge time: 5 minutes and 48 seconds.
```

Ein Unterschied von 3min. Bei meheren Paketen wie z.b emerge -e world ist es dann ein gewaltiger Unterschied ob ich mit tmps merge oder ohne.

Zum Thema;

Ich finde es macht sich schon bemerkbar ob man nur 1Kern oder mehere hat.

Zwar sind nicht immer alle Kerne ausgelastet, aber wenn  ich zum beispiel 1 Anwendung habe die 1Kern voll auslastet, dann hab ich immer noch genug Power für andere Aktivitäten. Es macht einfach Spass wenn man über 500 Pakete innerhalb weniger Stunden emergen kann.

----------

## UTgamer

Ähm xraver deine Werte sind ja der Hammer, haben wir sonst noch etwas gemeinsames das wir vergleichen könnten? Immerhin ist jetzt meine HW bald 2 Jahre alt.  :Wink: 

```
genlop -t xorg-server

 * x11-base/xorg-server

     Fri Jun  8 01:13:19 2007 >>> x11-base/xorg-server-1.2.0-r3

       merge time: 12 minutes and 41 seconds.
```

----------

## xraver

Was wollen wir den vergleichen?

Meine HW ist noch nicht so alt. Aber wenn ich schon wieder die neuen CPUś sehe - lecker.

Das hab ich zur zeit drinen stecken;

Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz, 1600 MHz

4GB Ram (laufen zur Zeit nur mit 667Mhz)

2 Maxtor SATA Platten (noch kein RAID)

ASUS P5N-E SLI Mainboard

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

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

Mit der Leistung bin ich sehr zufrieden.

Das Einzige was mit ein wenig stört und was ich dem nächst angehen möchte - der Stromverbrauch.

Ob nun der Xserver mit oder ohne tmpfs compiliert wurde weiss ich nicht.

```
Sat Jun  9 15:49:17 2007 >>> x11-base/xorg-server-1.2.0-r3

merge time: 6 minutes and 2 seconds.
```

----------

## Jinidog

Diese Vergleiche sind mit Vorsicht zu genießen. Unterschiedliche Compiler-Flags und unterschiedliche Compiler Versionen führen zu völlig unterschiedlichen Ergebnissen.

(damit meine ich die Vergleiche zwischen verschiedenen Maschinen.)

----------

## UTgamer

Thx

 *xraver wrote:*   

> Mit der Leistung bin ich sehr zufrieden.
> 
> Das Einzige was mit ein wenig stört und was ich dem nächst angehen möchte - der Stromverbrauch.
> 
> Ob nun der Xserver mit oder ohne tmpfs compiliert wurde weiss ich nicht.
> ...

 

Der Stromverbrauch hatte mich auch damals (knapp 2 Jahren) bereits davon abgehalten statt dem 3800+ den erhältlichen 4400+ zu nehmen.

Bei mir weiß ich auch nicht mehr ob der X-Server mit oder ohne tmpfs gebaut wurde.

Deiner ist also so rund doppelt so schnell. Nicht schlecht aber verständlich bei der GHz Zahl und dem höheren Bustackt.

2* 200 GB SATA-Platten und sehr zufrieden (SAMSUNG SP2004C)

MSI K8N SLI Platinum Hauptplatine (nForce4) mit 400 MHz Bustackt und FireWire Onboard.  :Very Happy: 

[Edit]

Jinidog, ja hast recht mit den Kompilern und Flags, lassen sich nicht sonderlich vergleichen.

----------

## xraver

 *Jinidog wrote:*   

> Diese Vergleiche sind mit Vorsicht zu genießen.

 

Ja.

 *Jinidog wrote:*   

> 
> 
>  Unterschiedliche Compiler-Flags und unterschiedliche Compiler Versionen führen zu völlig unterschiedlichen Ergebnissen.
> 
> (damit meine ich die Vergleiche zwischen verschiedenen Maschinen.)

 

Unterschiedliche Compiler-Versionen? Ich denke mal das 90% der Leute den Compiler verwenden der gerade im Portage-Tree aktuell ist.

Dem Argument mit dem CFLAGS stimm ich wiederum zu.

Aber wie es schon im Wiki beschreiben wurde. tmpfs wirkt sich nicht bei allen Usern postiv aus.

----------

## manuels

[quote="xraver"][quote="Jinidog"]

Ohne tmpfs

```
Sat Aug 18 14:17:30 2007 >>> www-client/mozilla-firefox-2.0.0.6

merge time: 8 minutes and 36 seconds.

```

mit tmpfs

```
Sat Aug 18 14:26:16 2007 >>> www-client/mozilla-firefox-2.0.0.6

merge time: 5 minutes and 48 seconds.
```

Zum Vergleich: Hast du den Ccache aktiviert? Das würde das Ergebnis natürlich verfälschen

----------

## Jinidog

Also, ich nutze gcc-4.2.0 und nach meinem Eindruck kompiliert der langsamer als der 4.1.2er

----------

## xraver

 *manuels wrote:*   

> 
> 
> Zum Vergleich: Hast du den Ccache aktiviert? Das würde das Ergebnis natürlich verfälschen

 

Mh, der ccache haut ja richtig rein.

FEATURES=-ccache emerge mozilla-firefox

```
Sat Aug 18 16:02:28 2007 >>> www-client/mozilla-firefox-2.0.0.6

merge time: 12 minutes and 12 seconds.
```

----------

## _eckobar_

 *xraver wrote:*   

> ...
> 
> CFLAGS="-march=nocona -O2 -pipe -msse3 -fomit-frame-pointer"
> 
> CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
> ...

 

ich finde deine compilerflags sehr interessant, weil im gentoo wiki habe ich gefunden, dass folgende flags für einen core2duo safe sind:

```
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"
```

kann mir bitte jemand folgendes erklären:

 vorteile nocona architektur gegenüber prescott

 was bewirkt -msse3?

 was bewirkt visibility-inlines-hidden?

 holen die compiler flags vom xraver mehr aus der maschine? wie stabil läuft die kiste ... hinsichtlich der als safe markierten flags aus dem wiki

bitte aber einfach erklären, hab mich mit der thematik noch nicht wirklich auseinander gesetzt ... und möchte jetzt auch nicht gcc manual durchkauen.

----------

## UTgamer

@ _eckobar_, bezüglich -msse3 habe ich mal eine genaue Zusammenfassung erstellt.

Die anderen sind Intel Vergleiche unter sich, zu denen ich keine Erfahrungswerte habe.

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

Zu meinen CFLAGS, die habe ich bereits hinreichend definiert und erklärt gehabt:  :Wink: 

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

----------

## xraver

@_eckobar_

Ich hab es so verstanden das man -march=prescott für 32Bit verwendet und -mach=nocona für 64Bit.

----------

## UTgamer

 *xraver wrote:*   

> @_eckobar_
> 
> Ich hab es so verstanden das man -march=prescott für 32Bit verwendet und -mach=nocona für 64Bit.

 

So habe ich es auch verstanden.

----------

## _eckobar_

danke für die erklärung an UTgamer / xraver.

merkt ihr eigentlich einen unterschied zwischen 32bit und 64bit modus? hab mal auf einem AMD Turion verglichen und da ist mir eigentlich überhaupt kein unterschied in der performance aufgefallen. openoffice / firefox / kernel compiles haben alle gleich lange gedauert egal ob 64bit oder 32bit.

mal abgesehen von der tatsache, dass man mit 64bit teilweise probleme mit programmen (z.b.: java plugin) bzw. man mehr speicher adressieren kann .... bringt es wirklich was für den heimanwender (serverbereich anderes thema, da hier sehr wohl größerer speicherraum von relevanz sein kann)?

----------

## UTgamer

Auf meiner HW hatte ich mal kurz zum Testen ein Debian in 32 Bit drauf und danach in 64 Bit, also allein der 64 Bit nVidia-Treiber ist es meiner Meinung nach schon Wert. Ich hatte grob UT2004 angetestet und auf dem 32er hatte es mich enttäuscht, aber das ist jetzt schon recht lange her, mehr als 1 Jahr. Aktuelle Vergleichswerte auf der gleichen HW habe ich nicht mehr.

----------

## Ampheus

Also ich habe aus irgendeinem Thread hier im Forum voll extreme flags, welche hier aber noch nie Probleme gemacht haben:

```
COREFLAGS="-frename-registers -fweb -pipe -fomit-frame-pointer -funit-at-a-time -fre$

CPUFLAGS="-msse3"

CFLAGS="-Os -mtune=prescott ${CPUFLAGS} ${COREFLAGS}"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

LDFLAGS="-Wl,-O1"

MAKEOPTS="-j3"
```

Das Ganze ist für nen CoreDuo 1,83 Ghz.

----------

## UTgamer

Ampheus, na dann schau mal ob du etwas auf den GCC Manualseiten finden kannst:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Was du darin nicht findest sollte keine zusätzliche Option für deine CPU sein, oder du suchst die anderen Seiten des Manuals ab:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/

 :Wink: 

----------

## Ampheus

Ich seh grad, da hat mir nano nen Streich gespielt  :Smile:  Richtig lautet es:

```
COREFLAGS="-frename-registers -fweb -pipe -fomit-frame-pointer -funit-at-a-time -freorder-blocks -fno-ident -freorder-blocks-and-partition -fmerge-all-constants -mno-tls-direct-seg-refs"

CPUFLAGS="-msse3"

CFLAGS="-Os -mtune=prescott ${CPUFLAGS} ${COREFLAGS}"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

LDFLAGS="-Wl,-O1"

MAKEOPTS="-j3"
```

@UTGamer: Was soll ich denn auf den Seiten suchen? Ich bin mir schon bewusst, was die flags bewirken, falls du das meinst  :Smile: 

----------

## snIP3r

hi leute!

ich will mal auch meinen kommentar zu dual-core cpu's abgeben. ich bin erst vor kurzem von meinem alten athlon xp 1100 mit 1,125 gb ram mit nem 32 bit gentoo auf diese kiste umgestiegen:

AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

ASUS M2N-SLI Deluxe

2GB Corsair DDR800 CL5 Ram

3Ware 9650SE-4LP mit 4x320GB WD3200YS RE Festplatten mit ICY Dock HotSwap Rahmen

HL-DT-ST DVD-ROM GDRH10N

S3 Trio64 PCI VGA-Karte (alt ber lafft und ist passiv gekuehlt

mit diesen CFLAGS: CFLAGS="-O2 -march=k8 -pipe"

und diesem CHOST setting: CHOST="x86_64-pc-linux-gnu"

ich muss sagen dass ich hierbei nen krassen performance unterschied merke. aber ich denke bei vergleich der beiden cpu's ist das klar  :Wink: 

vor allem das kernel kompilieren geht schon verdammt schnell, auch das updaten des systems inkl. installieren neuer packages. was mich aber stoert ist, dass unabhaengig von der leistung der cpu und des ram, das alte io problem immer noch bleibt, auch nach dem umstieg von pci auf pci-express. sobald was auf platte geht, bringt dir die hohe cpu performance nichts mehr. vielleicht liegt es auch am 3ware controller, was ich aber nicht so recht glauben mag (siehe diesen thread https://forums.gentoo.org/viewtopic.php?p=4194996). mit tmpfs geht das emergen wirklich schneller (ist ja auch klar, wegen der ramdisk), aber leider fehlt mir hierzu das entsprechende mehr an ram  :Sad: 

ein schoener nebeneffekt ist auch noch, dass der stromverbrauch um 1/3 weniger ist als vorher  :Very Happy: 

just my 2 cents

gruss

snIP3r

----------

