1 |
Alexander Skwar schrieb: |
2 |
|
3 |
> Arnold Krille schrieb: |
4 |
>> Am 06.08.05 schrieb Alexander Skwar <listen@×××××××××××××××.name>: |
5 |
>>> Mein Hauptsystem ist ein Athlon XP und damit "natürlich" |
6 |
>>> auch mit -march=athlon-xp kompiliert. Mein "low end" |
7 |
>>> (große Anführungszeichen *G*) System ist ein Notebook |
8 |
>>> mit Celeron M340, also (quasi) mit Pentium 4. Darum |
9 |
>>> werde ich da bei gcc 3.3.x mit -march=pentium-4 und |
10 |
>>> bei gcc 3.4.4 mit -march=pentium-m kompilieren. |
11 |
>> |
12 |
>> Mach aus dem march ein mcpu und schon laufen die Programme auf beiden |
13 |
>> System, zwar mit Optimierungen für die jeweilige Architektur, aber |
14 |
>> doch mit Abwärtskompatibilität... |
15 |
> |
16 |
> Klar. |
17 |
> Aber damit verschenke ich doch bestimmte *UNMENGEN* an |
18 |
> Performance, oder? :) Nicht auszumalen wie langsam dann |
19 |
> vlt. sowas wie perl wäre - Startzeiten von vlt. 0,5 Sekunden |
20 |
> vs. 0,48 Sekunden ;) |
21 |
|
22 |
Wenn das Programm 20000 Mal gestartet wird, summiert sich das auf |
23 |
400 Sekunden Differenz. Das sind gute 6 Minuten, die dabei mit |
24 |
Optimierung eingespart werden, bis alle 20000 Instanzen gleichzeitig |
25 |
laufen ;-) |
26 |
|
27 |
> Eigentlich hatte ich sogar vor, das "low end" System mit |
28 |
> icc zu kompilieren, um noch ein paar Promille mehr Performance |
29 |
> zu erhalten. Diese Performancevorteil würde ich doch |
30 |
> verschenken, wenn ich (bezogen auf das Zielsystem) unnötige |
31 |
> Kompatibilitätsschichten mit einbauen lasse. |
32 |
|
33 |
Ja und nein wenn für beide CPU compiliert wird, wird jede |
34 |
Optimierung unterlassen, die nur auf einer der beiden CPU läuft. |
35 |
- Dadurch wird das Programm etwas langsamer. |
36 |
|
37 |
Teilweise wird dann doch für beide Welten getrennt optimiert. Je |
38 |
nachdem, ob das Programm jetzt auf Athlon-XP oder P4 ausgeführt |
39 |
wird, linkt der Runtime-Linker einen anderen Codebereich. |
40 |
- Das verlangsamt den Programmstart (unmerklich), aber hält das |
41 |
ausgeführte Binary im Speicher schnell. |
42 |
|
43 |
> |
44 |
> Alexander Skwar |
45 |
|
46 |
-- |
47 |
Thomas |
48 |
|
49 |
-- |
50 |
gentoo-user-de@g.o mailing list |