Pale Moon 12.0/Linux feedback thread

[Moonchild]

To keep things somewhat organized, I'd appreciate it if users of the experimental Pale Moon 12.0 for Linux build use this thread to post their comments/experiences.

UPDATE: The Linux build experiment has now been officially abandoned. Pale Moon will continue to be exclusively available for Windows.

[jumba]

My test run.

System Xubuntu 12.04 amd64
Processor amd apu E-450

Firefox 12 ( Detailed version information: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 )
Pale Moon 12 ( Detailed version information: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120502 Firefox/12.0 PaleMoon/12.0 )

Peacekeeper
firefox: 613
palemoon: 563
http://peacekeeper.futuremark.com/resul ... Id=2378296

SunSpider 0.9.1
firefox: 615.5ms +/- 0.4%
palemoon: 661.7ms +/- 0.5%

V8 Benchmark Suite - version 7
firefox: 1903
palemoon: 2268

Dromaeo
firefox: 150.07runs/s (Total)
palemoon: 146.49runs/s (Total)

Memory usage for blank tab:
Firefox 62mb
Pale moon 49mb
For 11 tabs same usage around 135-144mb

[Moonchild]

Thanks, about what I found in a VM as well comparing 32-bit of FF and PM against each other - unfortunately not significant enough of a difference so far.

[stravinsky]

is it because most distros ship x64 version of FF and arguably handles 64bit better than windows?

maybe its time to read the GCC 4.7 optimisation guide ?

how is cross-compiling PM in linux compared to windows ?

[Moonchild]

is it because most distros ship x64 version of FF and arguably handles 64bit better than windows?

I realize that I created a 32-bit binary, and would have been better off creating a 64-bit one as it's more common these days. Unfortunately to create both flavors, I realized I'd have to have 2 distinct Linux installs. Unlike on Windows.

maybe its time to read the GCC 4.7 optimisation guide ?

I already enabled the optimizations intended - results are simply not significant, apparently.

how is cross-compiling PM in linux compared to windows ?

Probably just as broken... It will still compile nsinstall and other tools from source and try to use them, even if the host OS won't support the created binaries.

[stravinsky]

I realize that I created a 32-bit binary, and would have been better off creating a 64-bit one as it's more common these days. Unfortunately to create both flavors, I realized I'd have to have 2 distinct Linux installs. Unlike on Windows.

i thnk 64bit binaries on linux of PM would be stable. no need really to build a 32bit version. most distros give 64 bit FF with 64 bit OS. so should be stable enough.

I already enabled the optimizations intended - results are simply not significant, apparently.

yeah, apparently. i think the optimisation switches are not even worth the effort it takes to type them. which linux distro did you install? during building/linking, how much did the CPU utilisation get? i mean, is building on linux faster and more multi-threaded than on windows? or did you still use a -j1 ? which vesion of GCC are you using?

Probably just as broken... It will still compile nsinstall and other tools from source and try to use them, even if the host OS won't support the created binaries.

i am mostly interested in the windows version of PM . i just want to find out if cross-compiling on linux with -OMGWTFAWESOME switch on GCC would make PM faster.
have you tried using LLVM/CLANG ? can FF even be built with LLVM?

how about the open-sourced "ekopath" compiler? that is supposed to build faster binaries than GCC.......
aww man, on linux the possibilities are enormous....


EDIT: all the building environment should be mentioned in the linux thread( like which distro, 32/64, compiler version, host CPU).

[Moonchild]

i think the optimisation switches are not even worth the effort it takes to type them.

Then this whole exercise is moot, if that's the case.. If there is no notable difference between using -O1 and -O2 -msse2 -mfpmath=sse -funroll_loops on gcc, then Pale Moon will never make a difference if developed/built for Linux...
Pale Moon, as stated on the website, gains its advantages by way of the build process, not by hacking code. If the build process can't be properly optimized on Linux/gcc, then it's pointless to spend more time on it.