Official firefox-pgo thread

broch · 2010-03-31 00:21:54

what icc optimization flags have you used? Maybe different that I used. Why would you use ICC with PGO if IPO is better (dont know about FF though)?
I have i686, so is another difference.
I have same icc version
sunspider results for FF and FF-PGO are identical = 1408 vs 1368.

Marcel- · 2010-03-31 12:43:33

broch wrote:

what icc optimization flags have you used?

Just those I put in my .mozconfig (showed in mentioned topic).

broch wrote:

Why would you use ICC with PGO if IPO is better (dont know about FF though)?

I didn't. As you can see in my .mozconfig, I disabled PGO. I will try compiling with IPO later.

broch wrote:

I have i686, so is another difference.

My Atom (I didn't specify which one) is also 32-bit.

broch · 2010-04-02 01:55:20

I tweaked ICC settings (that I used before) and I was able to compile firefox-icc with optimized flags. Unfortunately on 32-bit system I was not able to go to the max (memory issues on 32-bit systems).
Anyway
firefox-icc (1257.2ms) 32-bit is faster than firefox-pgo (1354.8ms). Both are faster than firefox compiled with GCC without PGO (1408ms).

In all three cases, I used exactly the same mozconfig with exception of compiler optimization.

64-bit systems should get better results, so bold firefox-icc testers can try hoping for better results.

Last edited by broch (2010-04-02 01:56:19)

Gary13579 · 2010-04-02 12:36:35

Hey all, I've been struggling with firefox-pgo and firefox-pgo-beta for a few days now. Originally, it worked great. That lasted all of 30 minutes before I started getting random segfaults. I built it again, and it has segfaulted on start up ever since.

My processor is a 1.4GHz Pentium M, which means to rebuild takes 2 hours, so I'm getting incredibly frustrated.

Has anyone else had problems building on a Pentium M before? I'm trying to use "-march=i686 -mtune=pentium-m -O2 -pipe" now, if it still segfaults I'll post an strace..

Fackamato · 2010-04-02 12:41:22

Gary13579 wrote:

Hey all, I've been struggling with firefox-pgo and firefox-pgo-beta for a few days now. Originally, it worked great. That lasted all of 30 minutes before I started getting random segfaults. I built it again, and it has segfaulted on start up ever since.
My processor is a 1.4GHz Pentium M, which means to rebuild takes 2 hours, so I'm getting incredibly frustrated.
Has anyone else had problems building on a Pentium M before? I'm trying to use "-march=i686 -mtune=pentium-m -O2 -pipe" now, if it still segfaults I'll post an strace..

What if you use -march=native ?

Gary13579 · 2010-04-02 12:48:47

-march=native is the default in the PKGBUILD, and was segfaulting. -march=pentium-m didn't seem to fix it. Still building... *contemplates setting up distcc while this is going on...*.

Marcel- · 2010-04-02 12:54:34

-march=native will probably set -march to pentium-m, so that wouldn't make a difference. It sounds you suffer from the aforementioned issue. It's highly possible that using -march=i686 will solve your segfaults.

Gary13579 · 2010-04-02 15:23:55

"-march=i686 -mtune=pentium-m -O2 -pipe" worked for me, no segfaults so far. I was under the impression that -mtune would override -march, but apparently not?

Ah well, I'll use it throughout the day and pray for stability . Still amazingly fast.

Marcel- · 2010-04-02 16:24:06

No, exactly the opposite: by default, -march sets -mtune to the same setting. From the GCC docs:

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

-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.

harryNID · 2010-04-03 01:51:59

Here is something else to try. So far for the last few builds it seems to work as well for my P4 and it allows me to use "march=native". It also seems to be somewhat speedier (at least according to sunspider). I'm currently using gcc 4-5 to compile without any issues.

First in mozconfig add/change:
ac_add_options --enable-optimize="-O2 -fomit-frame-pointer"

Example from mozconfig:
 ## Optimize
ac_add_options --disable-pedantic --enable-jemalloc --enable-xterm-updates
### Reverse these lines (enable vs disable) for a debug build
ac_add_options --enable-optimize="-O2 -fomit-frame-pointer" --disable-debug --disable-tests
ac_add_options --enable-profile-guided-optimization
ac_add_options --enable-strip --enable-install-strip
###

Add any other changes you like (like getting rid of libgnomeui as an example). After you make the changes update the PKGBUILD to reflect those changes (sha256sums,dependencies, etc.).

Change in PKGBUILD:

unset CFLAGS
unset CXXFLAGS
export CFLAGS="-march=native -funroll-loops"
export CXXFLAGS="-march=native -funroll-loops"

Note: -funroll-loops is optional but I haven't had any issues with it and it seems to work really well with firefox. It will however make your binary slightly bigger so you have been warned.

One thing I think needs to be looked at by someone more professional than I is whether setting "-O2" in the PKGBUILD (using the original export command supplied) could be causing our problems. Notice that I set "ac_add_options --enable-optimize" to use "-O2" but I only set the export command in the PKGBUILD to "-march=native". That is because every time I added "-O2" to the "export CFLAGS="-march=native" command in the PKGBUILD it would cause segfaults after it built. This is only me theorizing though so if anybody wants to comment or experiment with the above changes to see what they get then that would be cool.

Last edited by harryNID (2010-04-03 01:53:46)

blasse · 2010-04-03 09:38:20

harryNID wrote:

Here is something else to try. So far for the last few builds it seems to work as well for my P4 and it allows me to use "march=native". It also seems to be somewhat speedier (at least according to sunspider). I'm currently using gcc 4-5 to compile without any issues.

First in mozconfig add/change:
ac_add_options --enable-optimize="-O2 -fomit-frame-pointer"
Example from mozconfig:
 ## Optimize
ac_add_options --disable-pedantic --enable-jemalloc --enable-xterm-updates
### Reverse these lines (enable vs disable) for a debug build
ac_add_options --enable-optimize="-O2 -fomit-frame-pointer" --disable-debug --disable-tests
ac_add_options --enable-profile-guided-optimization
ac_add_options --enable-strip --enable-install-strip
###

DO NOT DO THIS!
passing optimize flags directly into mozconfig overwrites mozilla default optimization (which is very good). It may result in better sunspider, but overall feel and usage of firefox will be worse (some parts of code are compiled with -Os, -O1, and other flags, and that is better than forcing -O2).

btw.
And if you must, instead of editing mozconfig, add this lines to PKGBUILD:

    sed -i 's/--enable-optimize/--enable-optimize="-O2 -fomit-frame-pointer"/' \
        .mozconfig || return 1

Should work and generating new checksums is unneeded

Last edited by blasse (2010-04-03 09:41:37)

harryNID · 2010-04-03 14:06:42

blasse, my above post is meant to be taken strictly as an experiment for those few of us that are having issues compiling a stable version of firefox-pgo with the stock PKGBUILD. It has already been established that using "i686" works for those suffering from it but I offered this an another possible route to take. I could have been more clear about my intentions in the previous post I suppose. I was just seeking somebody with the same issues as I to give it a try to see what results they get with it.

DO NOT DO THIS!
passing optimize flags directly into mozconfig overwrites mozilla default optimization (which is very good). It may result in better sunspider, but overall feel and usage of firefox will be worse (some parts of code are compiled with -Os, -O1, and other flags, and that is better than forcing -O2).

I understand and agree with you (and I know it overwrites the default optimizations) but again this is an experiment that I have had success with concerning my issues. As far as I can tell the issues we are having, have to do with the default optimization parameters firefox uses and those set in the PKGBUILD. As stated in my previous post setting "march=native -O2" in the PKGBUILD seems to be conflicting with firefox's optimizations causing segfaults for people with certain processors. By forcing "-O2" throughout the build via mozconfig and setting "march=native" in the PKGBUILD I have not had one segfault yet. As far as "feel and usage" firefox is running like a dream for me (as far as firefox can anyway lol!). It might very well be worse in certain situations but I have not encountered any more so than a regular install of firefox. It might be fairer to say "mileage may very according to the driver".

btw.
And if you must, instead of editing mozconfig, add this lines to PKGBUILD:
sed -i 's/--enable-optimize/--enable-optimize="-O2 -fomit-frame-pointer"/' \
.mozconfig || return 1

Again you are absolutely correct. To be quite honest I forgot about doing it that way for the standard user. I change some other things with mozconfig and the PKGBUILD so I have it set up that way for personal reasons.

blasse · 2010-04-03 20:42:15

To be honest, long time ago when I've started firefox-pgo package, I've used optimizations passed in mozconfig and I were happy with it I've dropped this form after some discussions with better coders than me
Maybe dropping -O2 code at all would help? Most of ff native optimizations is based on it by default, so this may give better result

Ranguvar · 2010-04-05 20:30:08

As blasse aluded to, Firefox does this handy thing where it passes different flags to the compiler depending on the source code currently being compiled.
If my memory serves correctly, changing options in mozconfig will force Firefox to obey particular settings, and may impact your speed.
Flags set as variables in the PKGBUILD, though, merely serve as guidlines which Firefox may (seems to in all cases) or may not override.

Of course, if you can't get the package compiled, do what's necessary by all means
In that case though, it may be a true bug, though Mozilla doesn't support GNU/Linux PGO.
It means optimization flags are being auto-set which break the software, (IMO) something that should absolutely never happen -- auto-set settings should default to very safe, with an override option.

This is probably related to certain instruction sets, if "-march=i686" works for most people. What I would recommend is trying other -march values below your CPU's capabilities, and also playing with that lower -march and -msse3 (for example, try whatever instruction sets you have but your -march does not enable), AND the appropriate -march with some -mno[instructionsethere] additions.

For example, if my Pentium 4 Prescott isn't working, I'd try both with "-march=prescott -mnosse3", "-march=pentium4 -msse3", etc.

Last edited by Ranguvar (2010-04-05 20:32:15)

Gen2ly · 2010-04-07 20:44:10

Thanks again for testing, harry. Using

unset CFLAGS
unset CXXFLAGS
export CFLAGS="-march=native -funroll-loops"
export CXXFLAGS="-march=native -funroll-loops"

appears to work pretty good so far on my Pentium 4. Thanks for the testing.

Edit:

Oop, looks like I spoke too soon. When I choose NoScript to allow a site, I got a crash. Reverting back to previous where I had no problems:

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

Last edited by Gen2ly (2010-04-07 22:31:54)

toxygen · 2010-04-08 22:09:35

firefox-pgo-minefield (3.7a5pre) build 4/8/10, from my average sunspider score ~890-950ms now at 817ms, the lowest score yet!

youri · 2010-04-08 22:23:30

Hi, my firefox-pgo-beta randomly crashes too. Is there anything I can try? It's x86_64. Also, most flash stuff crashes too.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a3) Gecko/20100329 Firefox/3.7a3

davidm · 2010-04-08 23:30:23

toxygen wrote:

firefox-pgo-minefield (3.7a5pre) build 4/8/10, from my average sunspider score ~890-950ms now at 817ms, the lowest score yet!

Niiice. Looks like I'm due for recompiling a new nightly....

koeleck · 2010-04-22 15:24:40

Looks like the problem with broken pgo-builds was found:
https://bugzilla.mozilla.org/show_bug.cgi?id=560897

Hund · 2010-04-22 16:24:02

Xlib: extension "RANDR" missing on display ":99.0".

I cant compile. Always stops with that message.

Marcel- · 2010-04-22 18:48:45

I experienced this too. It's because Firefox segfaults during the tests, causing these error messages. As I said earlier to you, this is due to -march=native or something like that (mcore2, prescott, atom, etc.). Just compile with -march=i686 and everything should be fine.

Last edited by Marcel- (2010-04-22 18:49:56)

Hund · 2010-04-22 20:26:04

Marcel- wrote:

I experienced this too. It's because Firefox segfaults during the tests, causing these error messages. As I said earlier to you, this is due to -march=native or something like that (mcore2, prescott, atom, etc.). Just compile with -march=i686 and everything should be fine.

I've already tested that, but as I said before, it didnt help.

Marcel- · 2010-04-22 22:34:19

Oh, sorry, I didn't read your posts after that, now. Which packages are you building now? On what processor/architecture? Can you post your CFLAGS?

Hund · 2010-04-22 22:52:13

Marcel- wrote:

Oh, sorry, I didn't read your posts after that, now. Which packages are you building now? On what processor/architecture? Can you post your CFLAGS?

Np. I've tried firefox-pgo and firefox-pgo-beta, same message with both of em.

export CFLAGS="-march=nocona -O2 -pipe"

I've also tried core2, i686 and native.

As you can tell, I'm a bit newbie with this.

Marcel- · 2010-04-22 22:57:27

And what processor/architecture do you have? Can you post the output of gcccpuopt? And your current mozconfig?

Last edited by Marcel- (2010-04-22 22:58:23)

Arch Linux

#576 2010-03-31 00:21:54

Re: Official firefox-pgo thread

#577 2010-03-31 12:43:33

Re: Official firefox-pgo thread

#578 2010-04-02 01:55:20

Re: Official firefox-pgo thread

#579 2010-04-02 12:36:35

Re: Official firefox-pgo thread

#580 2010-04-02 12:41:22

Re: Official firefox-pgo thread

#581 2010-04-02 12:48:47

Re: Official firefox-pgo thread

#582 2010-04-02 12:54:34

Re: Official firefox-pgo thread

#583 2010-04-02 15:23:55

Re: Official firefox-pgo thread

#584 2010-04-02 16:24:06

Re: Official firefox-pgo thread

#585 2010-04-03 01:51:59

Re: Official firefox-pgo thread

#586 2010-04-03 09:38:20

Re: Official firefox-pgo thread

#587 2010-04-03 14:06:42

Re: Official firefox-pgo thread

#588 2010-04-03 20:42:15

Re: Official firefox-pgo thread

#589 2010-04-05 20:30:08

Re: Official firefox-pgo thread

#590 2010-04-07 20:44:10

Re: Official firefox-pgo thread

#591 2010-04-08 22:09:35

Re: Official firefox-pgo thread

#592 2010-04-08 22:23:30

Re: Official firefox-pgo thread

#593 2010-04-08 23:30:23

Re: Official firefox-pgo thread

#594 2010-04-22 15:24:40

Re: Official firefox-pgo thread

#595 2010-04-22 16:24:02

Re: Official firefox-pgo thread

#596 2010-04-22 18:48:45

Re: Official firefox-pgo thread

#597 2010-04-22 20:26:04

Re: Official firefox-pgo thread

#598 2010-04-22 22:34:19

Re: Official firefox-pgo thread

#599 2010-04-22 22:52:13

Re: Official firefox-pgo thread

#600 2010-04-22 22:57:27

Re: Official firefox-pgo thread

Board footer