Official firefox-pgo thread

harryNID · 2010-02-25 23:47:37

Marcel
When building with CFLAGS="-march=atom -mfpmath=sse -fexcess-precision=fast", Firefox segfaults again on startup. Only using "-march=atom -fexcess-precision=fast" results in an executable that runs stable for several hours now. So one of the causes of my problem has something to do with -mfpmath=sse.

Why are you setting sse? -march=atom implies sse already. There might be a probable case if you were still using -march=i686 but not here I think. Just wondering though.

From gcc guide:

atom
Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support.

as to why -mfpmath=sse is not working check here:
http://gcc.gnu.org/onlinedocs/gcc/i386- … 64-Options

Summary pertinent to you:

-mfpmath=unit
Generate floating point arithmetics for selected unit unit. The choices for unit are:
`sse'
Use scalar floating point instructions present in the SSE instruction set. This instruction set is supported by Pentium3 and newer chips, in the AMD line by Athlon-4, Athlon-xp and Athlon-mp chips. The earlier version of SSE instruction set supports only single precision arithmetics, thus the double and extended precision arithmetics is still done using 387. Later version, present only in Pentium4 and the future AMD x86-64 chips supports double precision arithmetics too.
For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default.

Just loaded gcc-snapshot 4.5. I've already built a couple programs against it. I will try a firefox compile and let everybody know the results.

Marcel- · 2010-02-26 02:54:38

harryNID wrote:

Why are you setting sse? -march=atom implies sse already.

I was not sure about that. But if -march=atom implies sse, why do I get a segfault when using -mfpmath=sse, but not without? This implies that -march=atom does not activate the sse-flag. Moreover, why does gcccpuopt output

Warning: Your compiler supports the -march=native option which you may prefer
-march=atom -mfpmath=sse

If -mfpmath=sse is implied by -march=atom, why is it explicitly stated here?

I (re)read the documentation you linked to, and it says (as you already quoted):

For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default.

As the Atom N270 isn't a 64-bit processor, I have to explicitly activate sse to take advantage of this. A look at 'gcc-4.5 -O2 -Q --help=target -march=atom' confirms this:

  -mfpmath=
[...]
  -msse                                 [disabled]
  -msse2                                [disabled]
  -msse2avx                             [disabled]
  -msse3                                [disabled]
  -msse4                                [disabled]
  -msse4.1                              [disabled]
  -msse4.2                              [disabled]
  -msse4a                               [disabled]
  -msseregparm                          [disabled]
  -mssse3                               [disabled]

Strangely enough, the output of some random test code says:

options enabled:  [...] -msse -msse2 -msse3 -mssse3

That said, the processor should not have problems with -mfpmath=sse, so why Firefox crashes, I don't know...

harryNID wrote:

Just loaded gcc-snapshot 4.5. I've already built a couple programs against it. I will try a firefox compile and let everybody know the results.

Nice, I'll try that too. With which CFLAGS did you build those programs?

And has someone already tried to build this package with ICC, as it tends to give CPU intensive applications a performance boost on Atom processors.

EDIT: I just found this article about compiling Firefox with ICC (automatically translated from Chinese), might be useful (for correct sources, look at this original post, as Google Translate sporadically mangles the options). Of course, Google is also your friend).

Last edited by Marcel- (2010-02-26 04:10:44)

harryNID · 2010-02-27 18:42:55

I was not sure about that. But if -march=atom implies sse, why do I get a segfault when using -mfpmath=sse, but not without? This implies that -march=atom does not activate the sse-flag. Moreover, why does gcccpuopt output

I really wish they were (gcc-devs) a bit more precise with the manual. Neat script (gcccpuopt) by the way. I hadn't seen that before.

Also:

gcc-4.5 -O2 -Q --help=target -march=atom

is a command I didn't know about till now so thanks for the tip.

I was going to say you only had to specify -mfpmath=sse if you were trying to force it on (which apparently you do indeed need).

What if you tried -mfpmath=-mssse3 which is the latest floating-point you can use for your processor. I'm taking that this line for i386 or i686:

For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective.

means (IMO) -mfpmath=sse should look like this -mfpmath=-msse and so on up to 3. I would try -mssse3 as I said because it's the latest and probably the fastest version of the instruction set. Let me know if that works I'm really interested in your results. I'm just getting into compiling and I'm learning how to use gcc myself.

On a sour note my computer went South yesterday so I had to reinstall. It's going to be awhile before I get to be able to play with that gcc-4.5 compile of Firefox.

A word of caution about -fexcess-precision=fast. Before my computer went down I was able to compile a few programs with gcc-4-5. That option wouldn't work for some programs I was trying to compile. They kept erroring out until I took it out of my CFLAGS(S) line. It could be causing an issue for you as well.

Marcel- · 2010-02-28 14:38:56

harryNID wrote:

gcc-4.5 -O2 -Q --help=target -march=atom
is a command I didn't know about till now so thanks for the tip.

Honour to whom honour is due, I just found it on the Gentoo forums when looking for Atom optimization. But you should really notice the (strange) difference in flags between this command (posted in my previous message) and the output of

echo 'int main(){return 0;}' > test.c && gcc-4.5 -v -Q -march=native -O2 test.c -o test && rm test.c test

(found in the same topic on the Gentoo forums) where "-msse -msse2 -msse3 -mssse3" are magically enabled.

I was going to say you only had to specify -mfpmath=sse if you were trying to force it on (which apparently you do indeed need).

Yes, but when doing so, Firefox segfaults on startup.

For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective.
means (IMO) -mfpmath=sse should look like this -mfpmath=-msse and so on up to 3. I would try -mssse3 as I said because it's the latest and probably the fastest version of the instruction set.

No, they are separate flags. According to the documentation the possible values for -mfpmath are '387', 'sse', 'sse,387', 'sse+387' and 'both'. The -ms[s]se# flags enable "the use of instructions in the MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, AVX, AES, PCLMUL, SSE4A, SSE5, ABM or 3DNow! extended instruction sets."

So I tried compiling firefox-pgo again with CFLAGS="-march=atom -mssse3 -fexcess-precision=fast" and now it doesn't crash on startup.

A word of caution about -fexcess-precision=fast. Before my computer went down I was able to compile a few programs with gcc-4-5. That option wouldn't work for some programs I was trying to compile. They kept erroring out until I took it out of my CFLAGS(S) line. It could be causing an issue for you as well.

That's strange, because, according to this message on gcc-bugs, that flag only activates floating point handling like with GCC 4.4. On a side note, I have to admit that when using CFLAGS="-march=atom -fexcess-precision=fast", Firefox segfaulted every now and then, especially when my Firefox window got focus. But that could also have been caused by a bug in my window manager IceWM, which spat several messages out on my console about a possible bug in itself. Unfortunately, I didn't write them down.

Marcel- · 2010-03-03 04:16:38

Just for the record, the custom built ff-pgo using GCC 4.5 and CFLAGS="-march=atom -mssse3 -fexcess-precision=fast" rarely crashes, only a few times. But when it does, it always gives this error:

firefox-bin: Fatal IO error 10 (No child processes) on X server :0.0.

(the messages above this one were printed much earlier and seem to be unrelated)

toxygen · 2010-03-04 20:36:03

firefox-pgo-minefield - 3.7a3 - built 2010/03/04, from mozilla-central revision c4169105a5d4
working great, had to mess around with my add-ons to get them to work
in safe mode:
sunspider test 883ms (approaching my holy grail of 2009/11/15 score of 878!)
with add-ons, i'm getting around 917ms.

===/ end transmission /===

harryNID · 2010-03-06 14:05:17

Marcel-
No, they are separate flags. According to the documentation the possible values for -mfpmath are '387', 'sse', 'sse,387', 'sse+387' and 'both'. The -ms[s]se# flags enable "the use of instructions in the MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, AVX, AES, PCLMUL, SSE4A, SSE5, ABM or 3DNow! extended instruction sets."

Your absolutely right! My bad. Good thing your here to keep me on my toes!!

Now after getting back up and running. I tried another build (using gcc 4.4.3-1) and FF3.6 and using the settings from my post in #545 p22. I changed the CFLAGS in the PKGBUILD to this.

export CFLAGS="-march=pentium4 -mfpmath=sse -funroll-loops"
export CXXFLAGS="-march=pentium4 -mfpmath=sse -funroll-loops"

To my amazement it built stable and it's the fastest version I've compiled yet. With this build I scored under 1800 for the first time on a sunspider test (1785 to be exact, 55 ms faster than my previous build). That's not bad considering this is a P4 from 2001. Running the stock version of FF from the repo I'm getting in the 3000 range. I read somewhere that "-funroll-loops" works pretty good for FF so I decided to try it. I guess they weren't lying (although I'm sure -mfpmath=sse helped out too).

When I get a chance I still wouldn't mind trying a gcc4.5 version to see if it might be slightly faster. I still have other stuff to install so it might be awhile.

Gen2ly · 2010-03-06 17:47:25

harryNID wrote:

If you are using a P4 you could try my CFLAGS which [were] in the PKGBUILD. Using those I have yet to run into any more seg faults.
export CFLAGS="-march=i686 -mtune=pentium4 -O2 -pipe -fomit-frame-pointer"
export CXXFLAGS="-march=i686 -mtune=pentium4 -O2 -pipe -fomit-frame-pointer"
Just comment out -march=native lines and uncomment the two above. If that indeed is your problem then no matter which version of firefox-pgo you use you will have the same issue irregardless because something in mozilla's code is not picking up -march=native correctly for our processor type. If you decide to test this theory and compile again let us know if it worked for you.

Yep, worked for me, thank for the tip, Harry.

harryNID wrote:

BTW, I just had to use the stock version of firefox here during the lib updates for a short while and the difference between these two packages is like night and day for me. PGO is is much faster on my computer so it might be worth a recompile just in case that is your problem.

Agreed. Had a faster computer before this and didn't really notice PGO much, but on the P4 I definitely can tell a difference.

Majki · 2010-03-16 10:41:12

Does anybody else has this weird problem - qucik opening tabs /sometimes just opening "wrong tab" causes crash?

/usr/lib/firefox-3.6/run-mozilla.sh: line 131: 24845 memory access violation "$prog" ${1+"$@"}

blasse · 2010-03-16 10:43:50

Majki wrote:

Does anybody else has this weird problem - qucik opening tabs /sometimes just opening "wrong tab" causes crash?
/usr/lib/firefox-3.6/run-mozilla.sh: line 131: 24845 memory access violation "$prog" ${1+"$@"}

WFM. Did you encounter this problem with regular FF build too (Arch official)?

Majki · 2010-03-16 10:44:38

Nop. Only pgo version.

dcc24 · 2010-03-23 20:09:43

Finally got it to compile with commenting the RC line and using the following CFLAGS with a Core i3 CPU.

    export CFLAGS="-march=i686 -mtune=core2 -O2 -pipe -fomit-frame-pointer"
    export CXXFLAGS="-march=i686 -mtune=core2 -O2 -pipe -fomit-frame-pointer"

Ranguvar · 2010-03-24 17:29:19

dcc24, please try this:

Ranguvar wrote:

After extensive testing, it appears that '-march=core2' breaks 32-bit compiles, but not 64-bit ones. '-march=core2 -mno-ssse3' also breaks. For optimization options very similar to '-march=core2' that should not break, I advise those that are having problems to try '-march=nocona -mssse3'.

Last edited by Ranguvar (2010-03-24 17:29:28)

toxygen · 2010-03-24 17:33:03

Ranguvar wrote:

...

hey, you're back. what's the status on updating the pgo-minefield stuff? I tried the nightly packages and those work well, but building pgo-minefield is giving libpng errors (the comment used to be in AUR til allan broke it(tm). i just finished pgo-beta with blasses' PKGBUILD in the comments and that went fine..

blasse · 2010-03-24 17:38:59

My pkgbuild has disabled system png - I've got errors since libpng-1.4.1 and cannot find any patch, so I've disabled use of system libpng

toxygen · 2010-03-24 18:48:53

sneaky, i just saw that line, dunno how i missed it, no wonder it works

    sed -i 's/--with-system-png/--without-system-png/'

so far it's working great, thanks for the update

Majki · 2010-03-29 10:47:24

I have mentioned crashes. The problem was with

march=native

Changed to:

march=i686

fixed problem. FF works great. Why mozilla don't compile firefox that way?

My CPU is AMD Turion(tm) 64 X2 Mobile Technology TL-52

Last edited by Majki (2010-03-29 13:42:03)

Marcel- · 2010-03-29 13:40:07

About -march=native causing problems that seem to be fixed using -march=i686: it's mentioned earlier here, it affects at least 32-bit Intel Atoms as well as P4s and Core2s (confirmed by harryNID and me. Unfortunately, mentioned AUR comments got deleted).

This issue is present since FF 3.6.

BTW, what do you exactly mean by

Majki wrote:

Why mozilla don't compile firefox that way?

Last edited by Marcel- (2010-03-29 13:41:37)

Majki · 2010-03-29 13:45:13

@Marcel
https://bugs.launchpad.net/ubuntu/+sour … bug/213708

I mean, if pgo-optimization makes FF faster, why it's not done by default that way?

ngoonee · 2010-03-29 13:48:19

Majki wrote:

@Marcel
https://bugs.launchpad.net/ubuntu/+sour … bug/213708
I mean, if pgo-optimization makes FF faster, why it's not done by default that way?

Because PGO optimizes for YOUR machine.

Marcel- · 2010-03-29 13:53:55

I don't know, but perhaps someone else? There's already a feature request about this filed upstream. Sorry, don't have the time to read all those comments there at the moment.

EDIT: @ngoonee: yes, of course, you're right.

Last edited by Marcel- (2010-03-29 13:55:01)

bangkok_manouel · 2010-03-29 15:12:51

well, not really. all tests that are run are the same for everyone, I'm not quite sure this is machine-dependant. IIRC, windows binaries are all built with PGO.

blasse · 2010-03-29 18:58:53

PGO is considered unstable in linux build, but maybe enabled in future. The optimizations are machine-dependant

broch · 2010-03-29 21:04:32

Because PGO optimizes for YOUR machine.

no
PGO - profile guided optimization is set per program tested. It optimizes areas of program less and more used.

@Majki
GCC based PGO is till far from being worth of general use as it generates mixed results.
this would be highly inefficient if PGO would generate per machine optimizations. After Intel removed anti AMD code ICC should compile code equal in quality on AMD and Intel CPUs. However FF compilation with ICC fails (FF compiles but segfaults).

@bangkok_manouel
I think that windows is using IPO considered more efficient than PGO.
It would be nice to get IPO as efficient as in windows.

Anyway I don't see anything improvement over default FF.

Marcel- · 2010-03-30 20:59:28

broch wrote:

After Intel removed anti AMD code ICC should compile code equal in quality on AMD and Intel CPUs. However FF compilation with ICC fails (FF compiles but segfaults).

This is not entirely true (at least not on an Intel Atom processor).

Last edited by Marcel- (2010-03-30 20:59:58)

Arch Linux

#551 2010-02-25 23:47:37

Re: Official firefox-pgo thread

#552 2010-02-26 02:54:38

Re: Official firefox-pgo thread

#553 2010-02-27 18:42:55

Re: Official firefox-pgo thread

#554 2010-02-28 14:38:56

Re: Official firefox-pgo thread

#555 2010-03-03 04:16:38

Re: Official firefox-pgo thread

#556 2010-03-04 20:36:03

Re: Official firefox-pgo thread

#557 2010-03-06 14:05:17

Re: Official firefox-pgo thread

#558 2010-03-06 17:47:25

Re: Official firefox-pgo thread

#559 2010-03-16 10:41:12

Re: Official firefox-pgo thread

#560 2010-03-16 10:43:50

Re: Official firefox-pgo thread

#561 2010-03-16 10:44:38

Re: Official firefox-pgo thread

#562 2010-03-23 20:09:43

Re: Official firefox-pgo thread

#563 2010-03-24 17:29:19

Re: Official firefox-pgo thread

#564 2010-03-24 17:33:03

Re: Official firefox-pgo thread

#565 2010-03-24 17:38:59

Re: Official firefox-pgo thread

#566 2010-03-24 18:48:53

Re: Official firefox-pgo thread

#567 2010-03-29 10:47:24

Re: Official firefox-pgo thread

#568 2010-03-29 13:40:07

Re: Official firefox-pgo thread

#569 2010-03-29 13:45:13

Re: Official firefox-pgo thread

#570 2010-03-29 13:48:19

Re: Official firefox-pgo thread

#571 2010-03-29 13:53:55

Re: Official firefox-pgo thread

#572 2010-03-29 15:12:51

Re: Official firefox-pgo thread

#573 2010-03-29 18:58:53

Re: Official firefox-pgo thread

#574 2010-03-29 21:04:32

Re: Official firefox-pgo thread

#575 2010-03-30 20:59:28

Re: Official firefox-pgo thread

Board footer