Browser benchmarks 2: even Wine beats Linux Firefox

Posted at 3:56pm on Thursday February 12th 2009

We posted yesterday about Firefox having very different JavaScript performance on Windows and Linux, despite being the same version of the software.

Some people have said that we should have used a stock build from Mozilla. (We disagree, because we'd argue that most Linux users use software from their package manager rather than downloading bits and pieces from the web.) Others have said that Opera should be tested. And some people have said that it's Nvidia/AMD/Intel drivers that are slowing down Linux.

Anyway, we thought we would conduct a couple more quick benchmarks to see whether we can eliminate some of these variants. We don't have time to run the full benchmark suite and fiddle around from scratch, so we ran just a few quick tests to see what we could find.

This time the information you need to know is:

These benchmarks were run on the same computer as before, running the same Fedora 10 install.
We tried Mozilla Firefox for Linux as downloaded straight from Mozilla.
We also tried Mozilla Firefox for Windows as downloaded from Mozilla, but running it using Wine on Fedora.
We installed and tested Opera 9.63 for Fedora 10, as downloaded from Opera.com. Note: we were only able to find i386 builds on the Opera site; this isn't optimal so if someone can point us towards an i686 build for Fedora 10 we will happily update the article.
We ran the Google V8 Benchmark suite V3, as before.

To be absolutely clear: we took the Windows Firefox and ran it on Fedora Linux using Wine 1.1.12 as provided by Fedora:

"Firefox Windows" is Firefox running on Windows.
"Firefox Fedora" is Firefox running on Fedora using the Fedora package.
"Firefox Mozilla" is Firefox running on Fedora using the Mozilla build.
"Firefox Wine" is Firefox as compiled for Windows running on Fedora using Wine.
"Opera" is, well, Opera 9.63 running on Fedora.

With all that in mind, here's how the results look now:

Firefox on Windows, Linux and Linux/Wine

Firefox running on Windows, Linux and Linux/Wine, plus Opera.

The end result: Firefox from Mozilla or from Fedora has almost nil speed difference, and Firefox running on Wine is faster than native Firefox. Opera lags behind, but we're inclined to believe that number would increase if a better build was used.

Is this the end of the story? Probably not - we expect some commenters will come up with some other reason why the slowdown is clearly Nvidia/ATI/someone else's fault. Go on, folks: try the benchmark yourself. If you're running Linux, install Wine and try Windows Firefox on Wine and make up your own mind.

You should follow us on Identi.ca or Twitter

Your comments

:-(

Javier, el pingüíno anónimo (not verified) - February 12, 2009 @ 4:46pm

This is amazing. I'd never thought that wine+firefox would be faster than the Linux version. This is getting silly.

And, have you thought about benchmarking wine+google chrome?

Javier
P.S. Congratulations for the distribution rise.

What wrong with Fedora?

Benoit (not verified) - February 12, 2009 @ 5:00pm

I ran the same experiment on my T7500 (Dell XPS) laptop with Arch Linux. Linux's Firefox vs Wine's Firefox and they get similar scores on the V8 benchmark, ranging from 170 to 180 when repeating the test.

Do other people get the same results as yours?
Is it a Fedora problem (kernel/libc version)?

Scandalous... O_o Someone

Psychok9 (not verified) - February 12, 2009 @ 5:21pm

Scandalous... O_o
Someone slowdown Linux?

On my Athlon 64 X2 5000+

Deggers (not verified) - February 12, 2009 @ 5:25pm

Running Kubuntu 8.10: Wine Firefox gets 161, Ubuntu Firefox gets 136. Lame!

Just shows how much Mozilla

Anonymous Penguin (not verified) - February 12, 2009 @ 6:48pm

Just shows how much Mozilla are bothering with optimization of the Linux build, I guess.

It's the compiler, stupid.

Anonymous Penguin (not verified) - February 12, 2009 @ 10:28pm

Recompile Firefox with the Intel ICC compiler and rerun the test.

Re: It's the compiler, stupid.

Anonymous Penguin (not verified) - February 13, 2009 @ 9:06am

NO! The whole *POINT* of this is that people *DON'T* recompile Firefox - the just use the one from their distro. If Linux performance is dragging behind because we use GCC, then this problem is much MUCH larger than just Firefox.

Re: It's the compiler, stupid.

Anonymous Penguin (not verified) - February 13, 2009 @ 12:49pm

I think he was just suggesting a likely cause of the effect and an experiment to investigate it.

My experience with other

Winter Knight (not verified) - February 13, 2009 @ 1:11pm

My experience with other programs has usually been the opposite. I am a free software developer, and the programs I make/help out with are somewhat faster on Linux than they are in Windows. However, I notice through casual observation that Firefox is slower and buggier in Linux than it is in Windows.

I'm pretty sure that this is just a consequence of the Mozilla devs creating a half-assed port in the first place. Firefox in Linux is bigger than the Windows equivalent, which is also somewhat unusual.

Compiler, Firefox Memory Manager, timer API

Lennie (not verified) - February 13, 2009 @ 2:04pm

I do remember at some point the Linux-build didn't have the same memory manager as the Windows version, I don't know what the differences are now. The compiler could also make a big difference. The windows timer API is quiet different from Linux/Unix, maybe Firefox works better with the Windows API.

compiler

Anonymous Penguin (not verified) - February 13, 2009 @ 2:14pm

MSVC is a better optimizing compiler than GCC. It's been that way for rather a while.

Please recompile it

Windbourne (not verified) - February 13, 2009 @ 2:16pm

I would like to see this ran with a re-compiled Firefox using different compilers. The reason is that Wine ultimately uses the same resources as firefox. For wine version to be faster, says it is compiler. If this is gcc, then it is time to revisit it and find out why the large difference.

Pointing to Mozilla

Anonymous Penguin III (not verified) - February 13, 2009 @ 2:20pm

This test makes me think that the difference IS a problem of the Firefox Linux code and not so much of Linux itself.
Looks like Mozilla doesn't really bother optimizing for Linux.
I've always been an avid Firefox user, but maybe I should review my options.

Graphics Drivers

Anonymous Penguin (not verified) - February 13, 2009 @ 2:27pm

Is it possible to try out the benchmarks on a windows machine with the default windows drivers installed instead the Graphics Card provider's one?

What Desktop?

Larry (not verified) - February 13, 2009 @ 2:27pm

What desktop are you guys using? Gnome, KDE4 or KDE3(unlikely since Fedora 10 doesn't ship with it)?

Why not try an older version like openSUSE 11.0 with KDE3?(11.1's KDE3 isn't as fully KDE3 as 11.0's).

So many are complaining about video drivers, and most are running KDE4. I have no video driver issues running openSUSE 11.0/KDE3 under nVidia, ATI, or Intel, so that would be a good test IMO.

Swiftfox

Oskar (not verified) - February 13, 2009 @ 2:32pm

Try swiftfox (if you'r lazy). It rox, i get almost same results on wine as on swiftfox, but, it should be better anyway. Take care.

Just to find the culprit: please try the Intel Compiler (ICC)

Anonymous Penguin (not verified) - February 13, 2009 @ 2:39pm

from http://www.intel.com/cd/software/products/asmo-na/eng/219771.htm

Please keep trying :)

Gen (not verified) - February 13, 2009 @ 2:48pm

Yes, please do blame anything & keep benchmarking!! I'll love to install the final, quicker, Linux Firefox solution once its discovered :)

I do hope the Mozilla chaps are reading this, maybe they can locate the problem!

Food For Developer Thought

Anonymous Penguin (not verified) - February 13, 2009 @ 2:49pm

Why do you dismiss this by saying to recompile?

Why should the user compile anything?

Why didn't Mozilla choose to compile their own crown jewel in the "proper" manner?

Why did Mozilla choose to compile it one way for Windows and another way for Linux?

Why don't you place blame where it belongs?

The issue here is not that the user should recompile what is now a standard issue piece of software. The issue is why didn't the software manufacturer do it correctly in the first place.

If you replaced the word Firefox with Internet Explorer in this story, who would you blame? The user or the developer?

"Food for Developer Thought": Dude you need a cookie.

Anonymous Penguin (not verified) - February 13, 2009 @ 3:14pm

Nobody is asking the end user to recompile anything. People are suggesting a recompilation in an effort to narrow down the source of this issue collaboratively. Once we know whom or what to blame maybe we can work together to fix it too. But we need to figure it out first and the developers have to do this. And developers recompile; a lot.

Where does this difference come from?

Anonymous Penguin (not verified) - February 13, 2009 @ 3:20pm

I think it makes sense to think about where this difference comes from. Some thoughts about possible and impossible reasons:
* Anything used both by native Firefor and Firefox on Wine can't be responsible (e.g. the slowness clearly isn't due to X, because X is used by Wine as well).
* If the slowdown is graphics related, maybe the used toolkit (GTK I think) is responsible for the slowdown. If this is the case, every app using gtk on Linux and native GUI on Windows should be slower on Linux than its Windows equivalent. If that is the case, optimizing GTK (or switching to another, faster toolkit) would be the solution.
* If the slowdown is compiler related, the solution is to get better compiled executables. Maybe the solution would be as simple as getting the vendors to use the appropriate options; I thing many GCC users don't know that if they don't give appropriate options, GCC still creates 80386 compatible code, and therefore won't take advantage of any of the great features newer processors offer. I don't think there are many Firefox users who still use an 80386. But maybe GCC just doesn't produce as fast code even with the right options. In that case, one solution would be to compile with another compiler (ICC, LLVM). Another solution would be to make GCC optimize better.
* Another possibility is that the standard library supplied with GCC/Linux is slower than the standard library supplied with MSVC/Windows (this of course only applies if Firefox makes noticeable use of the standard library). In that case, the solution of course would be to improve the standard library.
* Yet another possibility would be that the Linux calling conventions are inherently slower than the Windows calling conventions. If that is the case, the only solution would be to get better calling conventions for Linux. Probably those different calling conventions would be enabled only through options, or by function attributes, in order to not break backwards compatibility.
* There's also the possibility that the Linux related Firefox code is just not as well hand-optimized as the Windows related one. The correct solution to this is obvious.
* Related, but different is the possibility that the general code is better tuned for Windows. This need not be deliberate; it may just be that most profiling is done on Windows, and changes which improve the speed on Windows actually degrade Linux performance. The solution to that would, of course, be to have more Mozilla profiling done on Linux.

OK, that's all possibilities which come to my mind. There's most probably some possibility I've forgotten, though.

Request for testing Opera 10 Alpha

ruemere (not verified) - February 13, 2009 @ 3:20pm

Here is the link to Opera Desktop Team blog:
http://my.opera.com/desktopteam/blog/

And here is direct link to Unix/Linux builds:
http://snapshot.opera.com/unix/snapshot-4166/

Could you have a look at Opera with a new engine (10) and test it, too? If I am not mistaken, new versions should be significantly faster than 9.63.

Regards,
Ruemere

PGO

Anonymous Albatross (not verified) - February 13, 2009 @ 3:21pm

Try enable PGO (profiler-guided optimization https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization) in the SRPM build process. The vanilla Fedora RPM build has PGO disabled.

For the matter of benchmark, why not just use the benchmark suites for profile info collecting during the PGO build process? That will be interesting.

P.S In case you don't know, the "profile" we are talking about means the calling profile of functions (which function gets how many calls, spending how much time in it, etc.) and has nothing to do with Firefox's user profile management.

In other news: How does IE6/7/8 compare?

Anonymous Penguin (not verified) - February 13, 2009 @ 3:51pm

So, I understand that this might be a tangent. But I compared results of these benchmarks on Firefox with IE6 both running natively under Windows. The result was that IE6 sucks balls. Firefox score was above 200 and IE6 score was below 50. Is this the general experience?

It's the compiler, stupid. Pt II

Anonymous Penguin (not verified) - February 13, 2009 @ 5:03pm

I am not asking you to recompile it and try the test again because you are a USER, I am asking because you are the one running the BENCHMARKS.

You know, part of being a user of open source software is contributing back. These benchmarks may help us make Firefox faster, but you have to be less arrogant and obnoxious towards those of us trying to DO something about it. I am asking you to recompile and retest so that we can try to narrow down where the problem lies.

Of course, if you are simply doing this to attack Linux developers without consideration for anything else, then why are you posting these benchmarks?

Surprised ?

Anonymous Penguin (not verified) - February 13, 2009 @ 5:10pm

Hello,

Thanks for those tests confirming what I felt as a multi boot user very linux enthousiast.
I have used almost every Ubuntu version (5.04-9.10) and every Firefox that came with it. Same on my gentoo and debian boxes and iceweasel. And I have always felt firefox being slower on linux than on windows XP, no Vista at home, windows 7 beta shows same feeling.
I do not have the sufficient knowledge to guess where it comes from. I doubt it does from the driver, firefox code (which is pretty much the same as on windows)...
I want to say to the compiler mob : Stop blaming the build or the compiling options, they do not belong to firefox but to the distribution. And accross distribution it seems there ain't much difference.
I want to say to the IE mob : What is IE ? Are there really serious people still using this crap ?

Java

maccam94 (not verified) - February 13, 2009 @ 5:16pm

Aren't all of these tests based on Java? Shouldn't you check what versions of Java each browser is using? Maybe the Linux-native Firefox is using the OpenJDK JRE or something.

Fix the code

Anonymous Penguin (not verified) - February 13, 2009 @ 5:20pm

Here's a thought .. Instead of going off on why people should recompile with this flag, defending open source, or making excuses because a particular library is bad - Fix the code!

Re: Java

Anonymous Penguin (not verified) - February 13, 2009 @ 5:33pm

its Javascript not Java, too many people get the two confused.

I guess what most people

Anonymous Penguin (not verified) - February 13, 2009 @ 5:34pm

I guess what most people saying recompile really want is to answer this question:

-Why is Firefox in linux slower?

That's just it! Stop saying it is or it isn't firefox's fault, just try other compiler / other distro / whatever other bright idea to zoom in on the issue. Unless this post was just to generate flame wars.

So please, stop with the hypotheticals and just help figure the answer out.

RE: It's the compiler, stupid. Pt II

Anonymous Penguin (not verified) - February 13, 2009 @ 5:48pm

"You know, part of being a user of open source software is contributing back."

Thanks to the guys from tuxradar for an insightful look at my favorite browser. I think I'm switching to competition though. Opera maybe. But before I do that, I'm recompiling and will run the benchmarks later today. I will post it in my bulletin board so that I can contribute back to the linux community in my country. Oh, and a reminder, those of us who are actually DOING something about it are not asking __other__ people to recompile or run benchmarks. Of course everybody has to contribute something back because, otherwise, newbies might think that there's a Linux customer service!

Could the person who scans

Anonymous Penguin (not verified) - February 13, 2009 @ 5:49pm

Could the person who scans the firefox source for security holes also please make sure the code is optimized during todays pass?

All too slow...

Anonymous Penguin (not verified) - February 13, 2009 @ 5:54pm

Ok, this is serious and not a troll comment to pit one OS off of another, it is just meant to show that there is still quite a bit of work to do in Firefox. My system is a MacBook Pro from almost 3 years ago (2.16GHz Core Duo (not C2D) with 2G RAM (667MHz) on Mac OS X 10.5.6) and running the latest dev version of Safari (Webkit) I get a score of 1090. Yes, one thousand ninety. Consistently. Running an optimized build of FF3.1 beta (Shiretoko) using the new tracemonkey I get a consistent score of 109. Yes, one hundred nine. That is pitiful. Come on Mozilla team. Let's get this fixed.

Looking at the SwiftFox build of FireFox...

Stealth Penguin (not verified) - February 13, 2009 @ 5:57pm

I would tend to think it was some kind of optimization issues. While I have tried it, I notice that it is only at verion 3.0.4pre1, so any real comparison would require getting a "stock" build of FF 3.0.4pre1 (or waiting for SF to catch up).

other distro test

deant (not verified) - February 13, 2009 @ 6:07pm

pls test, mozila on diferent distros, fedora is know to be slow distro. diferent companies compile their distros diferent way. when you run such test dont put "fedora = linux" mark pls.

Everything got slower from Ubuntu 7.04 to 8.10

Anonymous Penguin (not verified) - February 13, 2009 @ 7:35pm

On my machine the newer Linux is obviously slower in all regards.

It's well documented here.

"Ubuntu 7.04 to 8.10 Benchmarks: Is Ubuntu Getting Slower?"

http://www.phoronix.com/scan.php?page=article&item=ubuntu_bench_2008&num=1

Compiler

Frank (not verified) - February 13, 2009 @ 8:23pm

Good afternoon,

All the gents asking for ICC and GCC -03 recompilizations are asking so that the results can be submitted back to Mozilla. Mozilla will fix their linux compilation guidelines, and distros will inherit the changes.

We're not saying that linux 'is' faster. We're trying to "make linux faster", and submit the methodology upstream. This is how free software works.

A warning against ICC. It's not a full drop in replacement for GCC. Expect thar to be dragons. For easy experimentation with GCC cflags, ping any gentoo-er to do the work for you.

Frank

MUHAHAHA

Anonymous Penguin (not verified) - February 13, 2009 @ 8:27pm

I want to see how Chrome performs if and when Google bothers to release it for *nix...

Funny thing is...

Silver Dream ! (not verified) - February 13, 2009 @ 8:33pm

My results:

Firefox Windows Parallels Desktop V4: 192
Firefox Windows VMWare Fusion V2: 188
Firefox Windows wine (Crossover V7.1): 162-189 (big run-to-run variation)
Firefox Linux (Ubuntu 8,10) VMWare Fusion V2: 172
Firefox OS X (10.5.6) native: 128

All on the same machine (2.4GHz C2D). All version 3.0.6. Will you still complain about Firefox performance under Linux? :-)

Oh, and BTW:

Safari OS X (10.5.6) native: 189

Other speed issues

Anonymous Penguin (not verified) - February 13, 2009 @ 8:48pm

I think the Mozilla team should focus in more serious speed issues (for example the *lame* scrolling).

A 20-30 points difference in JavaScript performance does not bother the end user so much, there are many more serious slowdowns/glitches I experience in Linux when comparing to Windows or even OS X.

Somebody benchmark Arora Browser.

Anonymous Penguin (not verified) - February 13, 2009 @ 8:55pm

I have no idea how this is possible but i am getting this result :-

Score: 1036
Richards: 2168
DeltaBlue: 1208
Crypto: 2005
RayTrace: 705
EarleyBoyer: 1954
RegExp: 171

Also slower on Gentoo AMD64

Anonymous Penguin (not verified) - February 13, 2009 @ 9:01pm

I get 288 with Wine and 251 with native Firefox in Gentoo AMD64, and on Gentoo everything is compiled from source on the user's machine.

Arora and that score...

Anonymous Penguin (not verified) - February 13, 2009 @ 9:10pm

If you had read my post above "All too slow..." you would see that I am getting that kind of score as well from WebKit (the dev version of Safari) on Mac OS X. Arora is based on WebKit. That is how much faster SquirrelFish (WebKit JavaScript engine) is than TraceMonkey. Really shows how much work Mozilla has to do on FF.

gentoo firefox: 205 wine

Anonymous Penguin (not verified) - February 13, 2009 @ 9:22pm

gentoo firefox: 205
wine firefox: 223

compiler (most likely) has nothing to do with it

Anonymous Penguin (not verified) - February 13, 2009 @ 9:42pm

I don't think the compiler can possibly have that huge of an effect. There is only so many ways you can write an optimizing compiler and gcc is already a very strong optimizing compiler. It has be something with the way Mozilla is optimizing their code on Windows.

Anyway to definitely rule out the compiler make sure you can compile with icc as others have said. Maybe also test Firefox 2 or Firefox 1.5, which are compiled with gcc on all platforms (including Windows).

What this test does that the other test didn't is mostly rule out the kernel. Very good. So lets get to the bottom of this.

Food for FanBoys

Anonymous Penguin (not verified) - February 13, 2009 @ 9:47pm

I hate these users. You guys make me want to take a shovel to your heads. You defend a brand as if it were a member of your family. DIE!!!

Fan boy bitches, get a life! You have no idea how damn annoying you guys are. I would love to meet one of you in real life and take my fist through your head.

One (very possible) reason

Sir Homer of Thistledown (not verified) - February 13, 2009 @ 9:53pm

This might explain why this is so (this was pointed in the comments of a previous test):

http://mozillalinks.org/wp/2008/02/firefox-3-ultimate-feature-performance/

Starting today, Firefox nightly Windows builds have the benefit of profile guided optimization (PGO). With PGO, after Firefox is compiled (written code is made ready for the computer as binary code), the just generated binary is ran while another application monitors how it behaves and creates a profile of what parts of Firefox are more used and in what order. Then the code is compiled again but this time guided by the produced profile generating a new optimized build.

The comment also pointed out that Firefox 3.1 / Linux build may be getting this optimization

compiler may have sth. to do with it

Anonymous Penguin (not verified) - February 13, 2009 @ 10:00pm

To the poster who said that "There is only so many ways you can write an optimizing compiler". It is exactly the opposite. It is actually a fun fact - it is proven that there are infinite number of ways to write an optimizing compiler.

is slower.. and.. what?

Anonymous Penguin (not verified) - February 13, 2009 @ 11:18pm

Considering the amount of resources used by firefox once you install 6 or 7 extensions.. do you really care about it?

Btw according to the topic it's a javascript performance issue, so what about slower linux calls, or worse compiler, or bad port, or.. .... ??
Mozilla people want better results, then focus on a native/optimized version for linux, upgrade the TK used by firefox (maybe you need to switch after all to QT, who knows), make a linux specific javascript engine, and stop using copy/paste from the windows-optimized version (of course it should work better on windows..)

Still slow? buy a better computer.. more ram, powerful cpu(s), raid0 disks,... that's it

Regards

It's easy to blame anyone...

Anonymous Penguin (not verified) - February 13, 2009 @ 11:26pm

What if the problem wasn't ATI/NVIDIA, but rather Linux/X/QT-GTK itself ?

... Think about it ...

Are you really suggesting

Anonymous Penguin (not verified) - February 13, 2009 @ 11:31pm

Are you really suggesting that one set of tests from Google is representative of Firefox's JS performance? Unless you also publish SunSpider and Dromaeo results, I'm gonna assume you cherrypicked the one set of results that gave you what you wanted and ignored the other two more credible test suites.

Would like someone to clarify..

Anonymous Penguin (not verified) - February 13, 2009 @ 11:45pm

.. where exactly is for sure, the point of failure in the performance drop between Firefox linux and Firefox Wine-on-linux.

Who cares? What does this

Anonymous Penguin (not verified) - February 13, 2009 @ 11:57pm

Who cares? What does this prove?

What are the units for the test?

konya chat

http://www.sohbetw.com (not verified) - February 14, 2009 @ 12:11am

http://www.sohbetw.com

architecture problems are obvious

Anonymous Penguin (not verified) - February 14, 2009 @ 12:12am

X server? lose it or stay in the 90s.

Linux has some really crap legacy architecture (some take pride in saying that the x11 server is as old and even more complex than the kernel.. wtf?) and every sane programmer knows windows development is just so much faster because the platform is mature.

MATURE. and yes a lot of linux architecture is really basic and some also plainly WRONG.

but the low level hacko coders just dont see it.

and does who do face strong opposition from the whackos.

linuxhater was/is right, but learn to take criticism and find something good in it.

The Browser war..

Anonymous Penguin (not verified) - February 14, 2009 @ 12:12am

that is going on now is all about speed.

Features across all the major browsers are pretty much in parity on a general level and apart from a few things speed is the final defining area of play left for browsers.

So when Mozilla release a browser for linux which renders content using linux system calls more slowly than emulating windows api calls in to linux system calls, then there is a big, big problem.

Opera Wine?

Anonymous Penguin (not verified) - February 14, 2009 @ 12:24am

What about trying to run Opera windows with Wine? If that is also faster than Opera for linux, then we have a trend...

PCLinuxOS 2008

Freddy (not verified) - February 14, 2009 @ 12:31am

I got 178 with pclinuxos 2008 seems it is not linux but Fedora is the culprit. My impression using Firefox in pclinux was always faster than in windows or other linuxes

Score: 178

Richards: 183
Deltablue: 221
Crypto: 153
RayTrace: 141
earlyBoyer: 234
RegExp: 156

some data points

Anonymous Penguin (not verified) - February 14, 2009 @ 12:36am

When I run the benchmarks in my FF on ubuntu (3.0.6 FF with plugins and other stuff running on the machine like VM's etc, so not a very clean test)

I get a result of 110.

When I preview the page inside aptana studio I get ~190
when I run the page serverside with jaxer I get ~190 also.

I think the results are skewed by the browser wrapper/chrome, and not indicative of the js engine per se (although still something i'd like looked at)

The tests themselves may be suspect for comparing an interpreted JS against a VM'd one, and could be skewed towards optimized features of the V8 engine like scope chain flattening.

but it clearly shows the linux FF is not well optimized vs the windows one.

PCLinuxOS 2008 Konqueror and Opera

Freddy (not verified) - February 14, 2009 @ 12:39am

Well Konqueror is fassst but it took much longer before the benchmark run the test???:

Score: 27.5
Richards: 16.6
DeltaBlue: 18.9
Crypto: 12.2
RayTrace: 56.6
EarleyBoyer: 35.8
RegExp: 55.9

Opera:

Score: 146
Richards: 104
DeltaBlue: 122
Crypto: 99.7
RayTrace: 334
EarleyBoyer: 544
RegExp: 42.5

gentoo amd64 wine vs native

Anonymous Penguin (not verified) - February 14, 2009 @ 12:42am

gentoo amd64; firefox:3.06; opera: 9.63; wine: 1.1.14

firefox-native: 205
firefox-wine: 223

opera-native: 190
opera-wine: 224

Timer API difference

Anonymous Penguin (not verified) - February 14, 2009 @ 12:44am

Does anyone thought about how the accuracy of timer api between wine and native linux can influence results?

Btw as far as I know google's test uses recursion heavily which is not much optimized by tracemonkey.

Oops

Freddy (not verified) - February 14, 2009 @ 12:51am

Thought lower results are better

What about 64 bit?

Anonymous Penguin (not verified) - February 14, 2009 @ 12:57am

What are the results when using a 64 bit OS?? with 64bit Firefox on linux, and Win Firefox 64 bit on WINE?

Also does this changes from Distro to distro?

what about opera lin, and opena win?

there are still too many questions not answered, how does the CPU affect in all this. Intel <> AMD

Will you get different results if you try different video cards?

wow

Anonymous Penguin (not verified) - February 14, 2009 @ 12:59am

wow

OMG I'm going to go home and

Anonymous Penguin (not verified) - February 14, 2009 @ 1:02am

OMG I'm going to go home and cut myself now. *sob*

Apportioning blame

Anonymous Penguin (not verified) - February 14, 2009 @ 1:10am

These numbers are particularly interesting because of what they suggest *isn't* the problem.

If ff+wine is almost as quick as ff+win, doesn't that mean that the linux kernel and X are off the hook here? Doesn't it also hold that gcc is quite capable of compiling linux, x and wine to be quick enough to run ff+wine at near-native speeds, and therefore gcc itself is not broken (as I saw suggested on slashdot), even if perhaps it is not being used optimally to compile ff+linux?

And most importantly, doesn't that also mean that the wine people have done a f**king amazing job if we can expect near native performance with a huge app like firefox in a clean-room reverse-engineered reimplementation of something as stupendously huge as the win32 api?

I have always felt that ff+linux was a bit too sluggish. It's kinda usable, but the full-page zooming feature is ridiculously slow and scrolling is a joke. It's imperative that the source of the problems here be identified and rectified, but it seems like the ff+wine vs ff+linux numbers do vindicate some components of our os of choice, and demand vociferous praise for others.

Chrome

Anonymous Penguin (not verified) - February 14, 2009 @ 1:29am

In Firefox I get 250, in Opera I get 262, in Chrome I get:

Score: 2446
Richards: 3182
DeltaBlue: 3729
Crypto: 2625
RayTrace: 4370
EarleyBoyer: 5448
RegExp: 288

wtf?

Linux and X have NOTHING to do with this

Anonymous Penguin (not verified) - February 14, 2009 @ 1:31am

Yeah it means the Linux kernel and X have nothing to do with it.

Why people are trolling X because of this article, I will not know. There are a lot of fucking clueless people who just sit and talk shit about MIT X architecture, and never even looked at a line of code in their lives. Just a bunch of fucking morons who hate Linux because they are too stupid to appreciate it.

about compiler optimization

jay (not verified) - February 14, 2009 @ 1:53am

---

Realistically, there is only so many ways you can statically optimize a piece of code. Ultimately a compiler is basically a translator, it takes like C or C++ code as input and outputs assembly or machine code. The problem is C or C++ is not very descriptive, it doesn't really tell the compiler what people will use this program for or how it will be used. So this limits the kind of optimizations that can be done. GCC does many optimizations already, maybe not ALL optimizations that are possible statically, but it does a hell of a lot of optimizations.

Don't blame Mozilla, distros compile their own packages

Coop (not verified) - February 14, 2009 @ 2:00am

Mozilla creates a vanilla linux version of the browser as a tarball with every release. In almost every single case, distros ignore this build and instead grab the source tarball (or directly from hg/CVS) and compile their own packages from scratch.

Yes, Mozilla concentrates more effort on improving the speed of Windows through compilation tweaks, but where's the incentive to do otherwise? Different distros have different (and sometimes contradictory) needs for building and packaging. There is not a one-size-fits-all answer for Linux builds.

Wow

Anonymous Penguin (not verified) - February 14, 2009 @ 2:06am

Dude that little penguin guy is soo cool!

RT
www.anon-tools.us.tc

firefox

Anonymous Penguin (not verified) - February 14, 2009 @ 2:12am

It's clear that this is a problem with Firefox, GG people trying to pass the blame to X or Linux like the previous article.

Anyway It looks to be fixed in Firefox 3.1 choobs

Any moron knows that Firefox Linux is a Pile of Sh*t

Anonymous Penguin (not verified) - February 14, 2009 @ 2:13am

And it's been that way forever. And it's gotten worse ever since the pre-1.0 builds.

It has nothing to do with compilers, drivers, blah blah. The native linux code just sucks. Simple.

If you really want to be blown away, try using Chrome for a couple weeks. Then use Linux Firefox. The slowness is hard to miss.

Logical Fallacy collection

Anonymous Penguin (not verified) - February 14, 2009 @ 2:14am

[some take pride in saying that the x11 server is as old ...]
Argumentum ad novitatem. something is 'bad' because it's old... (if the argument was really about complexity, why mention old?)

[every sane programmer knows ]
aka "No True Scotsman ..." fallacy

[so much faster because the platform is mature.]
ironically, the author use the contrary of it's first fallacy, in the same sentence. this time it is an "Argumentum ad antiquitatem". it is old(er) - or should I use the euphemism, 'mature' - hence it is better.

Benchmarks on OS X

Anonymous Penguin (not verified) - February 14, 2009 @ 2:19am

Firefox (Shiretoko 3.1b3pre w/ tracemonkey): 103

And just for kicks...
Safari 4 (5528.1): 327

Insane difference and from reading the posts, it seems like Firefox is just as slow on OS X.

All this babble...anyone have something technical to say?

Anonymous Penguin (not verified) - February 14, 2009 @ 2:40am

Man...this is such an interesting subject, and reading back I see 2 or 3 technical posts and the rest is just emotional crap.

I guess I'm contributing to the noise here because I also did not investigate, I'd just like to say shut up and do some investigating before posting shit.

Now taking my own advice....

Linux is bloated and slow

JOE W (not verified) - February 14, 2009 @ 2:43am

People should just stick to real world operating systems like OS X and Windows.

K-meleon is ten times a

Anonymous Penguin (not verified) - February 14, 2009 @ 2:51am

K-meleon is ten times a better browser than is firefox. I wonder how it would fare in such a comparison?

Congrats! You made it!

Anonymous Penguin (not verified) - February 14, 2009 @ 3:25am

If you've read the sodding drivel above, and are reading this line now, congrats.

Let me summarize for you as somebody with a B.S. in Computer Science who isn't a drooling mouth breather:

1. Clearly if the WINE version is faster this excludes X and Linux as possible sources of the problem since WINE also runs under X and Linux.

2. The WINE version is probably ALSO compiled with GCC, so GCC isn't the problem unless the distros are using a whole lot of stupid when they compile Firefox Linux.

3. The person who said that X is bad because it is "old" and Windows is good because it is "mature" in the same argument is a complete idiot who didn't realize they were contradicting themselves.

4. Sounds like the Linux-specific code for the Linux version of Firefox sucks, and the shoddy programmers who are to blame should be flogged. (Or left to fix it, which it sounds like they may have already done for Firefox 3.1)

Hope this helped.

well, one correction

Anonymous Penguin (not verified) - February 14, 2009 @ 3:26am

well... obviously windows firefox wasn't compiled with GCC, but WINE and X were.

It's more than likely not the compiler...

burito (not verified) - February 14, 2009 @ 3:30am

Having used all of these compilers, and more importantly *read their documentation*, I can tell you the only reason one would want to use ICC is for the extended instructions.

Things like SSE2, etc. Unless your doing a *lot* of FPU calculations, there will be 0 difference between GCC and ICC. Although, in reality, if you're needing that much performance, most people will hand write the SSE2 code in assembly, as generally you can squeeze out a lot more performance than any C compiler will.

In some circumstances GCC will outperform ICC and MSVC. ICC can only really shine for lots of FPU calcs. MSVC doesn't really shine at all, although for 99% of code there will be no difference between any of them.

Compiler optimisation is not a new science, and while new things are still being developed, no one lets their compiler lag behind the trends.

Cannot be X or Video driver.

Anonymous Penguin (not verified) - February 14, 2009 @ 3:45am

Wine also runs on X and the same video card, remember?

It's just that firefox don't care much of code quality on Linux because of the monopoly it enjoyed on the Linux platform. Now more and more Linux machines switch to webkit based browsers, firefox will get some real competition against it.

cool benchmark

lowell (not verified) - February 14, 2009 @ 4:26am

thanks for putting me up on that. here's what i got:

Firefox 3.0.6
Score: 81.8
Richards: 79.8
DeltaBlue: 98.2
Crypto: 83.2
RayTrace: 68.8
EarleyBoyer: 113
RegExp: 59.2

Webkit r40955
Score: 930
Richards: 1652
DeltaBlue: 1101
Crypto: 1443
RayTrace: 767
EarleyBoyer: 1767
RegExp: 182

Mac OS 10.5.6 running on a lowly but sexy MacBook Air.

javascript?

Anonymous Penguin (not verified) - February 14, 2009 @ 5:42am

Maybe don't do your time-intensive computing tasks with javascript then. I've heard java and C++ are popular.

kubuntu 8.1

Vanishing Penguin (not verified) - February 14, 2009 @ 6:45am

kubuntu 8.1 kde-4.2
2.6.27-11
ff 3.0.6 = 107
ff 3.1 = 90.1
ff 3.2 = 75.6
konqueror = 85.1
swiftfox = 109
opera = 88.8
flock2.0b3pre = 103
arora0.4 = 39.4
epiphany-gecko = 80.7
epiphany = 65.1
midbrowser0.3.0rc1 = 104

wine
opera 9.63 = 116
ff3.0.6 = 123

ff3.1&3.2 from fta ppa swiftfox and opera from repo on there sites
after each test with the tested browser open i ran ff3.0.7(left open for all tests) to ensure that no background process was skewing the result each time it came back with 107

Firefox is by default starting in offline mode in ubuntu

Bhaskar Chowdhury (not verified) - February 14, 2009 @ 7:30am

It's very annoying,although it's pretty easy to solve the problem manually within 5 min. But why? is this a fault of ubuntu or firefox??

Compiler?

Anonymous Penguin (not verified) - February 14, 2009 @ 8:08am

To rule GCC vs MSVC difference out, please recompile the Windows version with GCC and compare with the Linux version compiled with the same version of GCC.

numbers

Anonymous Penguin (not verified) - February 14, 2009 @ 9:48am

OSX 10.5.6 2.2GHz core 2 duo http://v8.googlecode.com/svn/data/benchmarks/v3/run.html

Safari 3.2.6 Opera 9.63 FF3.0.6 FF3.0.6.win.CO7.1 IE6 CO7.1
Score 180 127 165 161 36,6

Richards 93.1 91.9 180 182 33,9
DeltaBlue 137 109 187 213 29,7
Crypto 137 85.8 160 132 39,7
RayTrace 232 249 140 186 43,6
EarleyBoyer 354 447 208 129 28,0
RegExp 238 44.6 129 141 49,7

CO7.1: CrossOver 7.1 pro

So much for meaningful benchmarks

Penguin One (not verified) - February 14, 2009 @ 9:59am

Just ran the V8 benchmark for FF 3.0.6 and IE 7.0 with the following results:

IE 7.0 31
FF 3.06 115