x86_64: poll for optional CFLAGS

kappa · 2007-03-28 11:00:48

I was trying to compile this but dies pretty much right away

Just a guess, but did you run makepkg twice in a row?
If so, delete the src directory and run it again. If it fails after emitting a number of creating "filename" messages, try uncommenting the
export MAKEFLAGS="-j1"
line in the PKGBUILD.

skottish · 2007-03-28 12:30:23

All I get is when trying to compile is:

[skottish@localhost downloads]$ makepkg
==> ERROR: install scriptlet (firefox.install) does not exist.

AndyRTR · 2007-03-28 12:43:14

you need to have a fresh cvs checkout ("abs") to have all files.

[vEX] · 2007-03-28 12:56:26

kappa wrote:

I was trying to compile this but dies pretty much right away
Just a guess, but did you run makepkg twice in a row?
If so, delete the src directory and run it again. If it fails after emitting a number of creating "filename" messages, try uncommenting the
export MAKEFLAGS="-j1"
line in the PKGBUILD.

You were correct, I was messing around with the old PKGBUILD earlier and got a failure before trying the new PKGBUILD, I had just assumed that the -c flag would clean up even when the build fails, guess I was wrong. Compiling fine now. :-)

skottish · 2007-03-29 01:32:38

This seems to speed up rendering significantly. Now I'm wondering about other programs...

fluke · 2007-03-29 05:25:25

i vote for enabling sse3

emphire · 2007-03-30 03:29:38

I'd like to have pni/sse3 in there... but I wouldn't want to isolate any x86_64 users. It's too bad we can't just make it an option. It would be nice if abs/pacman were more integrated and let us do a 'build world' with our own flags too.

-jon

iBertus · 2007-03-30 04:45:21

emphire wrote:

I'd like to have pni/sse3 in there... but I wouldn't want to isolate any x86_64 users. It's too bad we can't just make it an option. It would be nice if abs/pacman were more integrated and let us do a 'build world' with our own flags too.
-jon

Just change what is in /etc/makepkg.conf to the CFLAGS you wish to use.

emphire · 2007-03-30 07:54:38

iBertus wrote:

That is in /etc/makepkg.conf to the CFLAGS you wish to use.

I know. I was thinking I would have to go through every installed package and copy it from /var/abs/* to /var/abs/local and makepkg on each of them manually (and then constantly check for updates to the package manually and do it over again when there's a new version). Now that I've come across srcpac and yaourt it sounds like it should be easy though.

Still it would be nice to have a quick ready-to-go up-todate binary with pni for everything (even if it's just to use until a re-compile completes). Especially for things that take a long time to build (like Xorg, gnome, etc). I wonder if it would be hard to arrange a separate x86_64-pni repository.

AndyRTR · 2007-03-30 09:34:58

-mtune=nocona will add additional SSE3 instruction support on system where available without breaking backward compatibility. it's planned for a while now. sadly noone gave me some benachmark results that i asked for to see if it is really worth it. i guess binaries will become a bit larger but on most systems it should give a boost on (certainly multimedia) packages.

i will bring this topic up for the devs to discuss.

skottish · 2007-03-30 15:58:09

This post is pointless now. See below.

Last edited by skottish (2007-03-31 23:50:37)

skottish · 2007-03-31 23:26:20

I wanted to see some benchmarks on how well the CFLAGS in post #1 worked. I decided to try first by transcoding a video with x264. The test file is a 398.7MB MPEG2 video, with AC3, 48000 audio. I'm controlling x264 using FFMPEG-r8317. My current version of x264 is r636 built today for these test. The x264 PKGBUILD was provided by Predatorfreak, and is available through AUR. I'm on an AMD X2 5200+ processor with 4GB PC4200 RAM.

Warning about this test: I don't know shit about CFLAGS, so I may have tainted the results.

The FFMPEG command used:

ffmpeg -benchmark -i in.mpg -acodec aac -ab 512k -vcodec h264 -b 5000k -coder 1 -r 29.97002997 out.mp4

I probably should have left the audio intact, but I don't think that it really matters for this test.

The original CFLAGS:

-O3 -ffast-math -fomit-frame-pointer -ftree-vectorize

FFMPEG's benchmark:

bench: utime=1490.577s

Second test CFLAGS:

-march=x86-64 -O2 -msse3 -pipe -ffast-math -fomit-frame-pointer -ftree-vectorize

FFMPEG's benchmark:

bench: utime=1620.386s

Third test CFLAGS:

-march=x86-64 -O3 -msse3 -pipe -ffast-math -fomit-frame-pointer -ftree-vectorize

FFMPEG's benchmark:

bench: utime=1495.515s

Last edited by skottish (2007-04-01 01:17:12)

AndyRTR · 2007-04-01 05:45:07

ok, it's a start. but what we need are the pkg size and bench for these flags:

CFLAGS="-march=x86-64 -O2 -pipe"
CXXFLAGS="-march=x86-64 -O2 -pipe"

CFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe"
CXXFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe"

CFLAGS="-march=x86-64 -msse3 -O2 -pipe"
CXXFLAGS="-march=x86-64 -msse3 -O2 -pipe"

skottish · 2007-04-01 18:02:25

Same test as above with x264 built with:

No CFLAGS explicitly called:

bench: utime=1612.807s

package size: 799.9KB

(note: "gcc -O4 -ffast-math -march=x86-64 -O2 -pipe" from GCC's output)

-------------------------------------------------

CFLAGS="-march=x86-64 -O2 -pipe"
CXXFLAGS="-march=x86-64 -O2 -pipe"

bench: utime=1620.050s

package size: 799.6KB

-------------------------------------------------

CFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe"
CXXFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe"

bench: utime=1683.224s

package size: 772.1KB

------------------------------------------------

CFLAGS="-march=x86-64 -msse3 -O2 -pipe"
CXXFLAGS="-march=x86-64 -msse3 -O2 -pipe"

bench: utime=1644.512s

800.0KB

Pierre · 2007-04-01 20:39:29

Quite interesting. So you saved about a minute when not using sse3? I did several tests with nexuiz and I did not notice any difference in performance.

Stalwart · 2007-04-02 18:47:08

fast-math breaks many programs

AndyRTR · 2007-04-02 21:43:55

hm. i cannot trust in skottish's benchmarks. with additional SSE3 support it cannot be slower. i have to doubt that results.

iBertus · 2007-04-02 22:25:07

AndyRTR wrote:

hm. i cannot trust in skottish's benchmarks. with additional SSE3 support it cannot be slower. i have to doubt that results.

It is dangerous to expect a uniform result from all code compiled with SSE3 enabled. This would not be the only example of optimizations slowing down code. The ability of any piece of code to take proper advantage of SSE3 is limited by the programmer that wrote said piece of code. The benchmarks posted here could be in error but could also be valid. Someone else needs to rerun a benchmark to compare.

@skottish: please do not vary from the default Arch64 CFLAGS except for SSE3 support when you are doing this benchmark.

Last edited by iBertus (2007-04-02 22:27:34)

skottish · 2007-04-02 22:36:03

iBertus, in the last test I only used AndyRTR's CFLAGS except in the first case.

EDIT--> I see what you mean. x264 is internally passing flags that it wants from configure. So my tests were a combination of AndyRTR and their CFLAGS.

Last edited by skottish (2007-04-03 12:40:55)

daltocli · 2007-04-10 21:19:43

AndyRTR wrote:

I can already see that we have more user running old athlon64 cpus than I expected. So we really need to keep compatibility.
But I still want to play with -mtune=xxx to get optional SSE3 support. Only old 130µm athlon64 and sempron miss that feature. I think a good test will be to transcode(mencoder, lxdvdrip,...) some dvd movies. Somebody wants to do that? A Core2Duo would be nice but also athlon64 or PIV would be good.

I'm running a Core 2 Duo 1.66GHz "Centrino Duo" with 2Gb RAM, I'd be willing to test SSSE3 And -march=core2 CFLAGS. How'd I go about it? (anything that optimises my lappy even further can't be bad!). My cpu supports pni and ssse3.

AndyRTR · 2007-04-10 21:53:34

daltocli wrote:

I'm running a Core 2 Duo 1.66GHz "Centrino Duo" with 2Gb RAM, I'd be willing to test SSSE3 And -march=core2 CFLAGS. How'd I go about it? (anything that optimises my lappy even further can't be bad!). My cpu supports pni and ssse3.

for -march=core2 you will need to wait for gcc4.3

ekerazha · 2007-04-14 08:41:38

AndyRTR wrote:

I think about adding SSE3 support to the default and developers CFLAGS/CXXFLAGS. I have found -mtune=nocona to get optional SSE3 support.

Not really.

From: http://gcc.gnu.org/onlinedocs/gcc-4.1.2 … tions.html

-mtune=cpu-type
Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions.

I have a Turion64 (k8 -*not* nocona- arch with SSE3 -*not* SSSE3/SSE4- support), however I think that flags shouldn't be touched imho: if you really need SSE3/SSSE3 or "nocona" or "k8" optimizations for a specific package, then manually recompile that single package.

Last edited by ekerazha (2007-04-14 08:57:58)

AndyRTR · 2007-04-16 06:02:31

http://www.spec.org/cpu2006/flags/CPU20 … er_F-mtune

...If both are specified, the code generated will use the architecture, registers, and mnemonics set by -mcpu, but the scheduling parameters set by -mtune.

So only the scheduling parameters would benefit from -mtune=nocona and SSE3 wouldn't be enabled We still have too many users running cpus without PNI support. So changing -march is no option at the moment.

Is it still worth to think about using some -mtune switch? I doubt.

ahaslam · 2007-05-21 16:55:59

Having a Core 2 Duo I was intrigued by this. I have added '-msse3' to my otherwise standard CFLAGS.
I recompiled lame & tested it by transcoding an album. The package weighed in at 354KB (not much difference there) and transcoding time was reduced from 227s to 220s. I've included pastebins of the output should anyone want to see the differences (too long for here): Lame standard / Lame SSE3.

lloeki · 2007-05-21 17:24:18

It would be nice if abs/pacman were more integrated and let us do a 'build world' with our own flags too.

oh god please no, I don't want arch to become gentoo. and this thread feels just like it...

back in gentoo, in the early days of core/core2 we did some benchmarking of whether prescott|pentiumm were better and if nocona was appropriate. benchmarks werer run, incl. sse1|sse2|sse3. search gentoo forums/wiki('proper cflags' page should still have the link to forum thread) for it. results were that compiling with sse2|3 was of ~/dev/zero interest.

this is especially true given the fact that some cpus don't have pni. I don't feel like ruling out <3yrs old computers from 64bit (we're forcing them to i686...) is good.

Arch Linux

#26 2007-03-28 11:00:48

Re: x86_64: poll for optional CFLAGS

#27 2007-03-28 12:30:23

Re: x86_64: poll for optional CFLAGS

#28 2007-03-28 12:43:14

Re: x86_64: poll for optional CFLAGS

#29 2007-03-28 12:56:26

Re: x86_64: poll for optional CFLAGS

#30 2007-03-29 01:32:38

Re: x86_64: poll for optional CFLAGS

#31 2007-03-29 05:25:25

Re: x86_64: poll for optional CFLAGS

#32 2007-03-30 03:29:38

Re: x86_64: poll for optional CFLAGS

#33 2007-03-30 04:45:21

Re: x86_64: poll for optional CFLAGS

#34 2007-03-30 07:54:38

Re: x86_64: poll for optional CFLAGS

#35 2007-03-30 09:34:58

Re: x86_64: poll for optional CFLAGS

#36 2007-03-30 15:58:09

Re: x86_64: poll for optional CFLAGS

#37 2007-03-31 23:26:20

Re: x86_64: poll for optional CFLAGS

#38 2007-04-01 05:45:07

Re: x86_64: poll for optional CFLAGS

#39 2007-04-01 18:02:25

Re: x86_64: poll for optional CFLAGS

#40 2007-04-01 20:39:29

Re: x86_64: poll for optional CFLAGS

#41 2007-04-02 18:47:08

Re: x86_64: poll for optional CFLAGS

#42 2007-04-02 21:43:55

Re: x86_64: poll for optional CFLAGS

#43 2007-04-02 22:25:07

Re: x86_64: poll for optional CFLAGS

#44 2007-04-02 22:36:03

Re: x86_64: poll for optional CFLAGS

#45 2007-04-10 21:19:43

Re: x86_64: poll for optional CFLAGS

#46 2007-04-10 21:53:34

Re: x86_64: poll for optional CFLAGS

#47 2007-04-14 08:41:38

Re: x86_64: poll for optional CFLAGS

#48 2007-04-16 06:02:31

Re: x86_64: poll for optional CFLAGS

#49 2007-05-21 16:55:59

Re: x86_64: poll for optional CFLAGS

#50 2007-05-21 17:24:18

Re: x86_64: poll for optional CFLAGS

Board footer