CPU Optimierung?

cat1510

Well-Known Member
Hi Leutz

Wenn man einen makeworld laufen lässt kann man doch vorher in der make.conf Datei angeben für welchen CPU TYP man sein System optimieren möchte.

Folgendes Problem. Ich habe einen VIA Cyrix 800 CPU.

In den examples steht eine Option für nicht aufgeführte CPU Optionen.

# (?= allows to buildworld for a different CPUTYPE.)
#
#CPUTYPE?=i686
Also habe ich das mal ein meine make.conf mal eingebaut.

Er baut die Welt ohne Fehler zusammen. Bei der Installation steigt er mit einem fehler aus. Illegal.gz no such file or directory.
Wenn ich die World ohne die CPU Option baue kann ich Sie auch einwandfrei installieren.

Hat jemand eine Idee, woran das liegen könnte bzw ob ich eine Optimierung für VIA Cyrix einbauen kann? Oder sind die so schlecht? ;o)

mfg

CAT
 
Hmm ich habe doch schon reingeschrieben:

CPUTYPE?=i686

oder muss ich das ? Zeichen weglassen?
 
Für eine VIA CPU möchtest Du keine i686 Optimierung benutzen, die kann nämlich Code erzeugen, der auf dem Prozesser nicht läuft (i686 ist Pentium Pro oder höher). Für die VIA CPU's kannst Du CPUTYPE=k6-2 oder k6-3 verwenden, die sind von der Architektur vergleichbar (gleiche Features wie MMX, kein MMX2 oder SSE/SSE2, auch der 1st level Cache ist gleich gross IIRC).

Ich habe ein VIA EPIA-M 10000 Board mit einer 1 GHz VIA CPU, da compiliere ich mit CPUTYPE=k6-3.

@eLgino: So einfach geht das nicht, du musst einen gültigen CPUTYPE einsetzen, die findest Du in /etc/defaults/make.conf (4.X) bzw. /usr/share/examples/etc/make.conf (5.X).
 
Danke @ Current

Mein Problem hat sich dann gelöst und es gibt keinen Error mehr beim installieren.

Vielen Danke und einen schönen heißen Tag noch.

mfg

CAT
 
Morgen!

Hab da noch eine Frage zu den Prozessor Typen.

Ein AMD K7 1333Mhz ist ein Athlon-tbird oder ein Athlon4 in der CPU Optimierung?

Und welche CPU's sind denn welche von AMD?

Gibt es keinen Unterschied zwischen Thoughbrough und Barton?

Oder hat jemand nur einen Link zu den Info's?

Danke!

mfg

CAT
 
Wenn Du UTSL machen willst, schau mal in /usr/src/contrib/gcc/config/i386/i386.c...

Ich entnehme dem, das die Modelle "athlon" und "athlon-tbird" nur die SSE Prefetch-Instruktionen haben, während die anderen, neueren Athlons alle SSE Instruktionen beherrschen. SSE ist aber nur für FP-intensive Programme relevant (und wird vom gcc mehr schlecht als recht unterstützt).

Fazit: CPUTYPE=athlon sollte für alle Athlon reichen!
 
Original geschrieben von current
Für eine VIA CPU möchtest Du keine i686 Optimierung benutzen, die kann nämlich Code erzeugen, der auf dem Prozesser nicht läuft (i686 ist Pentium Pro oder höher). Für die VIA CPU's kannst Du CPUTYPE=k6-2 oder k6-3 verwenden, die sind von der Architektur vergleichbar (gleiche Features wie MMX, kein MMX2 oder SSE/SSE2, auch der 1st level Cache ist gleich gross IIRC).

Ich habe ein VIA EPIA-M 10000 Board mit einer 1 GHz VIA CPU, da compiliere ich mit CPUTYPE=k6-3.
Ähm, ich hab hier ein VIA EPIA-M 1000 (Rev.B) und dmesg sagt eindeutig, daß SSE als Prozessorfeature zur Verfügung steht.

Es wäre doch schade, wenn wir das nicht nutzen!?

Der k6-x hatte ja kein SSE und der k6-3 hatte ja auch 256 KB L2-Cache im Gegensatz zu den "luschigen" 64 KB L2 Cache beim VIA Nehemiah.

Ich würde also fast davon ausgehen, daß die Cache Größe nicht
wirklich wichtig ist, denn sonst würde es bei Dir sicher nicht laufen.

cputype=p3 läuft natürlich nicht

i686 schon
 
Last edited:
welchen cputype

ne, Frage

dmesg gibt u.a. folgendes aus

CPU: AMD Athlon(tm) XP 2400+ (1999.66-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x681 Stepping = 1
Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE
36,MMX,FXSR,SSE>
AMD Features=0xc0400800<SYSCALL,MMX+,3DNow+,3DNow>


welcher CPUTYPE wäre nun für mich der richtige? einfach "atholon" oder was spezielleres...

attila
 
Vorsicht bei CPU-Optimierung bei ziemlich langsamen Systemen. Das kann nach hinten los gehen.

Denn viele bedenken nicht das durch scharfe Optimierung das Binary auch gut und gerne mal doppelt bis dreifach so groß werden kann. Das bedeutet mehr Zeug im RAM und es muss auch mehr Zeug von der Festplatte gelesen werden.

Bei Anwendungen die etwas berechnen mag es Performance-Vorteile geben. Aber bei normalen Sachen wie eine Desktop-Umgebung oder anderes kann die Performance auch locker mal extrem einbrechen, weil die Binaries einfach zu fett sind...

@attila

-march=athlon-xp -mcpu=athlon-xp
 
Danke für die schnelle Antwort


wenn du dich mit langsamen Systemen

auch auf meinen

AMD Athlon(tm) XP 2400+ (1999.66-MHz 686-class CPU)

beziehst, dann finde ich des etwas bedenklich.... (obwohl hab heute eh schon gemerkt, dass ich mit meinne Rechner v.a. graphikkarte nimmer recht aktuell bin [RivaTnt2])

aber des ist ein andere Thema
 
Hallo attila,

ich habe auch einen Athlon XP 2400+

folgendes habe ich dafür in der Kernel Konfiguration:
Code:
machine		i386
cpu		I686_CPU

options 	CPU_ATHLON_SSE_HACK	# wg. Athlon* 
options 	CPU_ENABLE_SSE 		# wg. Athlon*
(*Gefunden in /usr/src/sys/i386/conf/NOTES)


In der /etc/make.conf:
Code:
CPUTYPE?=athlon-xp
CFLAGS= -O2 -pipe

Läuft für mich prima. :)
Im Wiki steht noch mehr zum optimieren,
habe es aber noch nicht alles durch.

BSDForen Wiki:
http://wiki.bsdforen.de/index.php/FreeBSD_-_make.conf_optimieren


Gruß, Fusselbär
 
attila said:
Danke für die schnelle Antwort
wenn du dich mit langsamen Systemen auch auf meinen AMD Athlon(tm) XP 2400+ (1999.66-MHz 686-class CPU) beziehst, dann finde ich des etwas bedenklich....

Nein. Hab das alter des Threads nicht gesehen. ;) Bei deinem System brauchst du dir da nicht solche Gedanken machen. ;)
 
der thread ist etwas älter aber das thema immer aktuell....was mich interessieren würde....hat das mal jemand gemessen oder gibts irgendwie vergleiche mit und ohne kerneloptimierung was das real bringt
 
Flex6 said:
bitte mal aufs datum gucken
Oh, huch.

Um auf deine Frage trotzdem zu antworten: Es hängt unter anderem vom Prozessor und von der Art der Anwendung. Generell gilt für jede Optimierungsabsicht, dass man genau im Sinn haben sollte, weswegen man jene Optimierung wählt. Pauschal jeden Fetzen Code mit einer einzigen bestimmten Schalterkombination zu kompilieren, bringt nicht immer etwas. Der FreeBSD 6.0-Kernel ist beispielsweise bei meinem Dual Pentium III 733 bei der Ausführung von
Code:
dd if=/dev/urandom of=/dev/null bs=64k count=1k
gut 6% schneller, wenn der Kernel mit CPUTYPE=i386 und -Os anstatt CPUTYPE=pentium3 und -O2 kompiliert wurde. Wenn man aus Optimierung also wirklich einen Nutzen schlagen will, dann müsste man erstmal intensive Untersuchungen anstellen, inwieweit sich das auf das typische beabsichtigte Anwendungsszenario auswirkt.

Björn
 
Wie reproduzierbar sind denn diese "Benchmark" Ergbenisse ?

Bei mehrmaligen Lauf auf meinem System (6.1-prerelease, amd64) erhalte ich folgende Ergebnisse :

67108864 bytes transferred in 1.419678 secs (47270483 bytes/sec)
67108864 bytes transferred in 1.477740 secs (45413173 bytes/sec)
67108864 bytes transferred in 1.352252 secs (49627483 bytes/sec)
67108864 bytes transferred in 1.511934 secs (44386113 bytes/sec)
67108864 bytes transferred in 1.654982 secs (40549607 bytes/sec)
67108864 bytes transferred in 1.588217 secs (42254215 bytes/sec)
67108864 bytes transferred in 1.402124 secs (47862283 bytes/sec)
67108864 bytes transferred in 1.421471 secs (47210861 bytes/sec)

Als CPUTYPE steht bei mir athlon64 :) .



Björn König said:
Oh, huch.

Um auf deine Frage trotzdem zu antworten: Es hängt unter anderem vom Prozessor und von der Art der Anwendung. Generell gilt für jede Optimierungsabsicht, dass man genau im Sinn haben sollte, weswegen man jene Optimierung wählt. Pauschal jeden Fetzen Code mit einer einzigen bestimmten Schalterkombination zu kompilieren, bringt nicht immer etwas. Der FreeBSD 6.0-Kernel ist beispielsweise bei meinem Dual Pentium III 733 bei der Ausführung von
Code:
dd if=/dev/urandom of=/dev/null bs=64k count=1k
gut 6% schneller, wenn der Kernel mit CPUTYPE=i386 und -Os anstatt CPUTYPE=pentium3 und -O2 kompiliert wurde. Wenn man aus Optimierung also wirklich einen Nutzen schlagen will, dann müsste man erstmal intensive Untersuchungen anstellen, inwieweit sich das auf das typische beabsichtigte Anwendungsszenario auswirkt.

Björn
 
JonSvenJonsson said:
Wie reproduzierbar sind denn diese "Benchmark" Ergbenisse ?
Bei mir sind die Zahlen sehr reproduzierbar, jede Spalte repräsentiert eine Messung mit einem bestimmten Kernel.

Code:
von Links nach rechts
-O2 -march=i386
-Os -march=i386
-O2 -march=pentium3
-Os -march=pentium3

6,91	6,69	6,97	6,6
6,91	6,69	6,96	6,6
6,91	6,69	6,96	6,57
6,91	6,69	6,96	6,57
6,91	6,69	6,96	6,57
6,91	6,69	6,96	6,57
6,91	6,69	6,96	6,57
6,91	6,69	6,96	6,57
6,91	6,69	6,96	6,58
6,91	6,69	6,96	6,6
6,91	6,69	6,96	6,59
6,91	6,69	6,96	6,58
6,91	6,69	6,96	6,57
6,91	6,69	6,96	6,58
6,91	6,69	6,96	6,58
 
Vorhin wurde gesagt, das CPU-Optimierungen auf langsamen Systemen langsamer machen, weil sie das Binary vergrössern.
DAS IST FALSCH!!
CPU-Optimierungen machen im schlimmsten Fall nichts, im besten für eine Funktion, die vorher 5 Befehle gebraucht hat nun einen eigenen Befehl -> Der Code wird kleiner und meistens auch schneller!!
GRÖSSER wird er nur, wenn man die (ohnehin bösen) -O2, -O3 Schalter benutzt, da er hier z.B. Schleifen in normalen Code umwandelt, der dann 20x untereinander steht, um die Sprünge/Vergleiche zu sparen. Subjektiv haben die -O-Schalter mir nichts gebracht, ausser Instabilität im System. CPU-Optimierungen nehme ich aber immer mit rein.
 
Und, um nochmal auf die Hauptfrage in diesem Thema zurück zu kommen:
Der C3-Prozessor hat einen bis auf den cmov-Befehl kompletten i686-Befehlssatz.

Da FreeBSD aber offensichtlich diesen Befehl braucht, kannst du i686-Optimierungen nicht verwenden...
 
Da ich früher auch mal ein Epia-Board hatte, und mir sicher war, CPU-Optimierungen genutzt zu haben, habe ich gerade nochmal nachgeschaut. Warum nimmst du nicht einfach 'c3' als CPUTYPE? Das ist doch genau das, was du suchst und das Thema ist geges... äh... beantwortet! :-)
 
Back
Top