[abs] 'good-&-safe flags' for an Arch Linux 32 on amd 64

kozaki · 2005-11-29 17:17:31

Finally got my hands on an AMD 3200, now with sound & network running fine with Arch (0.7.1)

I'm made room enough on the HDD for 2 others distros, one of them could well be an Arch test box (64?). So the main box stands for my production environment.

As I began to enjoy abs, makepkg & utilities arround them, may you tell me what would be the "good but safe" flags to enter /etc/makepkg.conf for an Arch Linux 32-bit on an AMD 64 bit CPU ?
Could the K7 flags (maybe with some sse2 option) be usefull in such a case ?
Am I loosing time and possibly stability in getting something like this ? :

# gcc like CARCH & CHOST to stay *standard*
export CARCH="i686"
export CHOST="i686-pc-linux-gnu"

export CFLAGS="-march=athlon -O2 -pipe -fomit-frame-pointer"
export CXXFLAGS="-march=athlon -O2 -pipe -fomit-frame-pointe

$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 47
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 0
cpu MHz         : 2000.048
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips        : 4003.16

paranoos · 2005-11-29 19:32:30

You're better off just using the standard Arch packages, and in the odd situation when you're compiling your own, to just use the standard i686.

Why? There are a few reasons. After some testing, I've come to the conclusion that compiling apps for an architecture different than your kernel results in a performance hit. The performance hit is greater than the ever-so-slight performance gain of compiling for Athlon.

If you plan on compiling everything of importance, then there are many distributions more suited to that. Gentoo isn't the only one, either. You may also consider trying a true 64bit distro. Members of the Arch community are developing one. Can somebody report on the progress?

You may find that the ease in maintaining a standard Arch distro is much easier than maintaining Gentoo (or any other source-based distro), especially considering the compile times, and the emphasis on using (what may or may not be) the best optimizations for your processor. You may also find that Arch is fast enough that you won't notice (much of) a difference in performance.

You mentioned trying out several distros. What else are you considering?

EDIT: By the way, I noticed you kept the CARCH variable, but then went and added an -march flag to your FLAGS. That's actually what CARCH is for. I don't know what the compiler would say if you gave it two -march flags heh

kozaki · 2005-11-29 19:50:55

Hey! Thank you for the advice paranoos

1st, I guessed what i could edit in my makepkg.conf, then kept the standard. Could you please detail a litle bit on the CARCH variable ? When i gave CARCH=athlon a try on a smaller computer, then gcc refused to compile itself

You may be right for most of it, especially the "Arch's way" > Gentoo for the user. One of the other distros could be Arch64, the other Mandriva x86_64 as I'm member & a long time user / traineer on this distro.
Still there's a point where I may need somme mmx & sse(2) (& whatsoever) flags : multimedia apps.
I use The Gimp, mplayer, mencoder, lame, folding (f@h) etc. more than the average, & I'm sure those apps would take an advantage on ssex / mmx compiled flags.
i686 stands for the Pentium Pro right ? Therefore no mmx, no sse with such a flag... Ain't it ?

paranoos · 2005-11-30 07:36:36

No, I suppose i686 does not include MMX or SSE or any of those extensions.

I can't speak for any of the other apps you mentioned, but I have lots of experience with mplayer and compile flags. mplayer actually detects your cpu capabilities on the fly - at least, that's the way Arch has it configured. I tested the standard Arch compile against my own compile with athlon optimization (I had a Duron 800 at the time). I tested it by playing a high resolution QuickTime movie that my computer was too slow to play. The sound was out of sync, and my benchmark was basically me listening for specific sounds, and how late they would appear. The Athlon compiled one was slightly slower, maybe a whole second. Perhaps I should try to duplicate this test somehow.

Really, with the speed of today's chips, I don't think these extensions make hardly a noticeable difference. MMX was developed when CPUs were running 233MHz, remember?

kozaki · 2005-11-30 10:48:32

well, back in the 90's, I also remember that a Pentium 200 (or was it 166MHz) with MMX played an audio file with Winamp (very 1st version) with about 4 times less CPU use than its counterpart withou MMX.
Other than that, yes you're right. & I'll keep standard i686 optimization for my production box.

the test box is a different case, so I'll go try different flags as this Gentoo x86 Install for Athlon 64 --> CFLAGS="-march=athlon-xp -msse2 -O3 -pipe" (compare to Gentoo x86-64 Install for Athlon 64 --> "-march=k8 -O2 -pipe")

Arch Linux

#1 2005-11-29 17:17:31

[abs] 'good-&-safe flags' for an Arch Linux 32 on amd 64

#2 2005-11-29 19:32:30

Re: [abs] 'good-&-safe flags' for an Arch Linux 32 on amd 64

#3 2005-11-29 19:50:55

Re: [abs] 'good-&-safe flags' for an Arch Linux 32 on amd 64

#4 2005-11-30 07:36:36

Re: [abs] 'good-&-safe flags' for an Arch Linux 32 on amd 64

#5 2005-11-30 10:48:32

Re: [abs] 'good-&-safe flags' for an Arch Linux 32 on amd 64

Board footer