Firefox 3.5RC2 Performance In Windows Vs. Linux

pizzutz writes "Andy Lawrence has posted a Javascript speed comparison for the recently released Firefox 3.5RC2 between Linux (Ubuntu 9.04) and Windows(XP SP3) using the SunSpider benchmark test. Firefox 3.5 will include the new Tracemonkey Javascript engine. The Windows build edges out Linux by just under 15%, though the Linux build is still twice as fast as the current 3.0.11 version which ships with Jaunty."

Comments

Don't benchmark it on Ubuntu

[petrus4]

Ubuntu typically has everything but the kitchen sink running in the background; it's even worse than XP for frivolous defaults.

Get Slackware, or something else minimalistic, where you're likely to have a marginal amount of memory left after the operating system and residents are loaded in. ;)

Re:Don't benchmark it on Ubuntu

[larry bagina]

Firefox isn't slower because of ubuntu, it's slower because the microsoft's C compiler is better than gcc.

Re:Don't benchmark it on Ubuntu

[Freetardo Jones]

It has nothing to do with Ubuntu. Here are benchmarks from Firefox on Fedora: The issue is just as bad on Fedora: http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-firefox. That's only from a few months

Re:Don't benchmark it on Ubuntu

[Anonymous Coward]

It's because it's an interesting post, while your previous one was flamebait.

Re:Don't benchmark it on Ubuntu

[K. S. Kyosuke]

Surprising? Because your post *did* smell of something burning, while the MSVC claim has at least some merit - MSVC really got better. I guess it had to, it would be a shame if MS threw a couple of megabucks on it with no results at all.

Re:Don't benchmark it on Ubuntu

[K. S. Kyosuke]

No one is claiming that it hasn't, either - that's why we have no Microsoft Visual Bob 2008. :)

Re:Don't benchmark it on Ubuntu

[Locke2005]

I am SHOCKED and AMAZED that a compiler specifically implemented for x86 (with assistance from Intel) produces more efficient x86 machine code than a compiler that is based on a general purpose architecture with just a back-end code generator for x86. Next you'll be telling me that a Swiss army knife isn't as good for skinning animals as a Bowie knife and that an amphibious vehicle is neither as fast on land as a Ferrari nor as fast in the water as a cigarette boat!

Re:Don't benchmark it on Ubuntu

[mR.bRiGhTsId3]

You know all that stuff that's running in the background. Well, it's running in the background, which means that most of it should be swapped out and it shouldn't wake up very often to do stuff.

Re:Don't benchmark it on Ubuntu

[Anonymous Coward]

So how hard is this to test? Anyone want to run firefox win32 binaries on linux with WINE? Since the executable code will be faithfully executed by the CPU we can eliminate the compiler differences from the equation.

Somebody else do it. :) I'm busy.

Re:Don't benchmark it on Ubuntu

[Anonymous Coward]

Visual C is not "compiler specifically implemented for x86". It supports (and supported in the past) lots of architectures -- x86, x64, Itanium, Alpha, MIPS (and MIPS16), PowerPC, ARM (and Thumb), Hitachi SuperH, Infineon TriCore, several other embedded CPUs as well.

Of course x86/x64 are main targets, but my guess it is so for GCC as well :-)

Re:Don't benchmark it on Ubuntu

[R2.0]

"Next you'll be telling me that a Swiss army knife isn't as good for skinning animals as a Bowie knife "

Actually, in most cases one would be better off with a Swiss Army type knife than a Bowie knife. Even on a large animal, parts of the skinning process are delicate and take a light touch, and the smaller blades are better at that. And then get to smaller animals - may as well just beat that rabbit with a rock as use a Ka-Bar. In addition, the saw blade of a SA knife is handy for cutting cartilage, etc.

A Bowie knife is a fighting knife, made more for killing and rough work. It will do other things, but not that well. That being said, when the meteor hits because DOD "blocked" the satellite information, and I have to choose 1 knife, it would be the Ka-Bar or similar. Why? Because I want to stay alive to have the opportunity to skin rabbits with my poor tool, and whipping out a Swiss Army knife will only make a zombie laugh.

Re:Don't benchmark it on Ubuntu

[SilverEyes]

More interesting modding :P

Re:Don't benchmark it on Ubuntu

[rbanffy]

They also have an easier job. MSVC doesn't need to address as many architectures as GCC does. IIRC, there is no MSVC for s/390

Re:Don't benchmark it on Ubuntu

[Anonymous Coward]

I am shocked and amazed that the company which destroyed all competing commercial compilers by hiring their best developers away now has a really good compiler.

Re:Don't benchmark it on Ubuntu

[selven]

Just because you can justify Linux's inferiority in this one area doesn't mean that we don't need to improve it.

Re:Don't benchmark it on Ubuntu

[cbhacking]

What's your point? Both are presented as general-purpose desktop operating systems (Slackware has some proponents who will try and claim that status for it too, but most of them wouldn't get very far). At the very least, try it on another "user-friendly" desktop-oriented distro.

Of course, they're also benchmarking on a 2-month-old build of Ubuntu (designed for the capabilities of modern hardware, and the features of a modern OS) vs. on a 92-month-old build of Windows. When XP came out, it said that its minimum requirements were 128MB of RAM (on which it runs little better than Vista on 512MB) and people thought that was a lot! This is a ridiculous comparison.

Re:Don't benchmark it on Ubuntu

[msclrhd]

A while back, I ran some tests on Firefox 3 with Wine vs Linux native (http://spreadsheets.google.com/pub?key=pCaFy3jQwNj5XFrxvcYJxPA&gid=3). Results: Firefox 3 Windows executable with wine built using the -O3 compiler setting was the winner (although, on average there wasn't much difference between the different wine versions).

This was with the V8 tests. I haven't tested FF 3.5rc2 yet, nor have I experimented with the build options.

Re:Don't benchmark it on Ubuntu

[msclrhd]

It will depend on what compiler settings were used to build the glibc library, what architecture it was tuned for, whether or not the glibc library is targeted to the specific version of the kernel you are using. It also depends on what options were used to build the companion libraries, as well.

Also, the last time this was discussed on slashdot, I seem to remember that it was Profile Guided Optimisation (PGO) that helped FF on Windows. This would allow the compiler to better structure the machine code to keep as much of the program running in the CPU cache as possible (by pre-loading branches in conditional statements that are executed more frequently).

Re:Don't benchmark it on Ubuntu

[Skye16]

Wait, is it a zombie meteor?

I'm confused.

Re:Don't benchmark it on Ubuntu

[tyrione]

Firefox isn't slower because of ubuntu, it's slower because the microsoft's C compiler is better than gcc.

Very soon they can leveraged LLVM where it makes sense.

Re:Don't benchmark it on Ubuntu

[Locke2005]

It is a Gnu inferiority, not a Linux inferiority. And yes, we do need to improve it.

Re:Don't benchmark it on Ubuntu

[harish.babu]

Well, M$ did throw 'a couple of mega bucks' to come up with Windows Vista. And everyone knows what 'merit' it had!

Re:Don't benchmark it on Ubuntu

[True Grit]

improving performance on its most popular platforms if they want to remain relevant...

You don't understand, GCC's portability is the reason for its very existence. Thats not optional. GCC has got more than 20 backends (architectures) and 8-10 frontends (languages) for goodness sake, no freakin' wonder its a little slower than MSVC/ICC, those latter guys only have to worry about 2 backends (x86/x86_64) and 2 frontends (C/C++).

GCC's wide portability is what currently guaranttees its relevancy. The minute GCC starts chasing clock cycles on the x86 platform (at the expense of the others), that will be its curtain-call...

Re:Don't benchmark it on Ubuntu

[harish.babu]

Folks over at tuxradar did this comparison a while ago. Here (http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-firefox) are the results. No surprise that FF running under Wine beats native FF on linux

Re:Don't benchmark it on Ubuntu

[xtracto]

Get Slackware, or something else minimalistic, where you're likely to have a marginal amount of memory left after the operating system and residents are loaded in. ;)

I do not agree with this, testing on Windows XP vs Ubuntu is good if you want to compare the "standard" out of the box performance. A test when you do a fresh install of BOTH systems and on top of that install the testing app.

What is wrong here IMHO is the title of the story, as it should be "Firefox 3.5RC2 Performance in Windows Vs. Ubuntu" because as you implied, saying tested on "Linux" is a very general claim. That could refer to testing it on the Kernel+GNutils + X.org and nothing else... surely that would improve its performance a bit.

Re:Don't benchmark it on Ubuntu

[xtracto]

Maybe it would be an interesting experiment to benchmark a Firefox release compiled with icc?

Re:Don't benchmark it on Ubuntu

[Bert64]

It's not the background apps, the windows version running under wine actually outperforms the native linux version too.

Re:Don't benchmark it on Ubuntu

[Bert64]

What if you compile the linux version using intel's compiler?

Re:Don't benchmark it on Ubuntu

[Bert64]

The problem is that mainstream distributions are trying to cater to as many users as possible, so they supply binaries which are targeted at a generic 686 (pentium pro) or even a 386... This is part of the reason why 64bit distros seem so much faster, because the lowest possible 64bit machine is still a lot closer to today's tech.
The mainstream distros should define a cutoff point, and not support anything older... There will always be someone else to do that, with specific lightweight distributions.

Re:Don't benchmark it on Ubuntu

[Bert64]

How about on a gentoo system, where firefox has been compiled to target the particular cpu?
How about a 64bit system?

Re:Don't benchmark it on Ubuntu

[mqduck]

With space being so cheap these days, I wonder why distributions don't offer precompiled binaries for each separate --march flag.

Re:Don't benchmark it on Ubuntu

[donaldm]

This is part of the reason why 64bit distros seem so much faster, because the lowest possible 64bit machine is still a lot closer to today's tech.

I agree with you but to be sure I tried running the benchmark on my laptop (1.8GHz Intel Centrino dual core 64 bit with 2GB memory) running the 64 bit Fedora 11 and Firefox 3.5 beta 4 and got a really abysmal result on my machine. The first is my results:

RESULTS (means and 95% confidence intervals)
Total: 3848.4ms +/- 1.3%
3d: 482.2ms +/- 10.1%
cube: 157.8ms +/- 21.5%
morph: 150.0ms +/- 11.8%
raytrace: 174.4ms +/- 15.9%

The next is the 32 bit Win XP version.

RESULTS (means and 95% confidence intervals)
Total: 2076.4ms +/- 5.2%
3d: 243.2ms +/- 8.9%
cube: 61.6ms +/- 20.1%
morph: 70.8ms +/- 7.8%
raytrace: 110.8ms +/- 15.5%

I won't bore you with the rest but needless to say Firefox 3.5 RC 2 running the SunSpider javaScript test on MS Windows XP SP3 32 bit and Ubuntu 9.04 32-bit appears to be a better performer than Firefox 3.5 Beta 4 64 bit on Fefora 11 64 bit. Still this only means that this benchmark is slower but going from Firefox 3 to 3.5 definitely appeared faster although this is a bit subjective and not a statistical proof.

Re:Don't benchmark it on Ubuntu

[donaldm]

It has nothing to do with Ubuntu. Here are benchmarks from Firefox on Fedora: The issue is just as bad on Fedora: http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-firefox. That's only from a few months

I tried the V8 benchmark on my laptop (1.8GHz Centrino dual core, 2 GB memory) with Firefox 3.5 Beta 4 64 bit on Fedoral 11 64 bit and got 150 first and 142 second. Not that good, but then again is this really a problem since getting Firefox 3.5 subjectively my web browsing appears much faster and for the majority of users quicker browsing is more important.

Re:Don't benchmark it on Ubuntu

[TheLink]

Because what you said was incorrect, and what he said was true.

Even though ubuntu has stuff loaded up, they're not running using 10% of the cpu. Just go do a top and see how much cpu is in use when you're not doing anything.

My ubuntu machine has two vmware virtual machines running on it and they only use about 3-4% of CPU total when not doing much - the machine is 96-97% idle with these running. If I suspend them, the machine would be 99-100% idle.

If using ubuntu and not slackware could cause the 15% difference in speed then something is wrong with the linux scheduler. Or someone in ubuntu has screwed up big time.

Re:Don't benchmark it on Ubuntu

[MikeBabcock]

It would be nice to do a comparison of both compiled with ICC instead (assuming the Firefox source code is compatible).

Re:Don't benchmark it on Ubuntu

[James Skarzinskas]

I don't mean to rain on your parade, but Microsoft's compiler targets multiple architectures as well.

Re:Don't benchmark it on Ubuntu

[Just Some Guy]

With space being so cheap these days, I wonder why distributions don't offer precompiled binaries for each separate --march flag.

Probably because it multiplies the load on their build servers by the number of supported platforms.

Re:Don't benchmark it on Ubuntu

[larry bagina]

TraceMonkey compiles javascript to native code. It most likely generates better x86 code than x64 code. They're using some of adobe's tamariz, Actionscript is also compiled to native code which is why adobe took forever to get flash on x64.

Re:Don't benchmark it on Ubuntu

[mqduck]

Sure, but that's a one-time (-per-package-per-version) thing. It's not like compiling a package is such a colossal task.

Re:Don't benchmark it on Ubuntu

[Just Some Guy]

As of this instant, apt-cache search '' | wc -l returns 28,308 packages. It may be infeasible for them to compile that many packages multiple times.

But why?

[Anonymous Coward]

Is there any explanation as to why there is the difference?

Re:But why?

[Freetardo Jones]

The Windows version is compiled with PGO (profile guided optimization) while Linux versions aren't.

Re:But why?

[moon3]

The problem is that GCC is pretty much the only compiler on Linux used these days and while the code is very nice C++ compilers on Windows produce a bit better code still.

But when I mention Watcom C++ or other aspiring open source compiler here, a compiler that could possibly interest Linux community and spawn some competition for GCC then I get modded down often by people citing GCC is good enough for everybody and everything.

Re:But why?

[asa]

In addition to a compiling process called profile guided optimization, or PGO, it's also a safe bet that the Windows compiler just spits out better (faster and smaller) results than the Linux compiler.

Re:But why?

[larry bagina]

also worth mentioning is llvm. gcc-llvm has an llvm backend doing code generation (which sometimes beats standard gcc, sometimes doesn't). There's also a non-gcc c/objective c/c++ compiler, clang, in development, though it may be a couple years before c++ support is complete.

Re:But why?

[Locke2005]

Didn't gcc 4.0 strip out all the processor-specific optimizations? I don't think it has ever been put back in. Sure, optimizing for x86 and not other processors shows a certain bias, but I'll take x86 bias over poorly optimized code any day.

Re:But why?

[guyniraxn]

What if we threw SwiftFox in to the comparison?

Re:But why?

[Locutus]

in the 90s, the Watcom compiler produced some of the fastest code out there. I know it was open source and is still used but it would be interesting to see what it could do in cases like this. If it's as good as it used to be, showing a 15% improvement and eliminating any speed advantage MS compilers might have would be eye opening for many who might consider gcc the only compiler for GNU/Linux software.
 

LoB
 

Re:But why?

[Rockoon]

Watcom isnt even top-3 anymore.

The king of C compilers is now ICC, with both MSVC and GCC way behind.

Re:But why?

[Prune]

One can always use the Intel compiler on Linux. The performance of compiled code is comparable to that the Intel compiler produces with its Windows version.

Re:But why?

[joib]

Didn't gcc 4.0 strip out all the processor-specific optimizations?

No.

Re:But why?

[pseudonomous]

Isn't there also an Intel compiler available for Linux?

Re:But why?

[pz]

The problem is that GCC is pretty much the only compiler on Linux used these days and while the code is very nice C++ compilers on Windows produce a bit better code still.

In my experience, MS's VC++ produces not just a bit better code than gcc, but whole hocking meeses better code. VC++ is a damned good compiler, no matter what one might think about the company that generated it, while gcc is a merely decent one, no matter how much one might want to promote FOSS.

Re:But why?

[David Gerard]

The OpenWatcom license is OSI-approved, but I don't see why. It failed DFSG, and I asked the FSF about it and they can't make head nor tail of it either.

Re:But why?

[Lennie]

I guess it's still available, here:

http://www.openwatcom.org/index.php/Main_Page

Re:But why?

[flyingfsck]

The Microsoft C compiler generates very well optimized code. It has beat out GCC by 10% or more since time immemorial.

Re:But why?

[rbanffy]

GCC _is_ good enough for a lot of stuff.

I would consider other compiler if it can compile all of my current distro to all architectures it supports. I find the x86 world remarkably boring,

Re:But why?

[tao]

The reason is that OSI approves pretty much every license on earth. The FSF has nothing to do with OSI (if they did, I would lose all respect for the FSF, considering the crap licenses accepted by OSI)...

Re:But why?

[David Gerard]

I was surprised because the OSI rules are based on the DFSG, and the OpenWatcom license fails those laughably.

Re:But why?

[electrosoccertux]

It feels just as slow. It's not just Gnome, it's slow in KDE and XFCE, too.
It is currently faster to run Firefox.exe under Wine than it is to run it native in Linux. (Yes I have tried this, the difference is night and day; it's just as fast in Wine as it is in windows).

Re:But why?

[asa]

Many of the rendering engine parameters can be set in Firefox's preferences. Firefox prefs are stored as a js file. Swiftfox makes a different set of trade-offs in these parameters than the Mozilla engineers. You're free to take your pick, but I'm goin' with the Mozilla engineers.

Re:But why?

[msclrhd]

If it is the Microsoft compiler that is causing the performance gain, how do you explain the performance increase on running Firefox through Wine. Surely, since Wine and the Linux system that it is running on are built with gcc, you'd expect it to run slower, or have marginal difference to native Linux.

That's not to say that the Microsoft compiler isn't any good. It's more likely that the Windows binary has had profile guided optimisation enabled and is better organised for branch prediction and the other insane things that CPUs do nowadays to keep things in the CPU cache longer.

Re:But why?

[tao]

Things like foundation documents, constitutions, etc., seems to be generally ignored these days. Consider the FRA-law in Sweden, the PATRIOT act in the US... The examples are numerous. These days I'm generally more surprised if people keep to their ideals. Then again, I'm a cynic.

Re:But why?

[amdpox]

Wine runs the code almost raw - the only difference to running on windows is that Win32 API calls are handled by Wine rather than Windows. All the computation that Firefox itself does is run exactly as it is on windows, ad thus the optimisations MSVC makes to the machine code are still there when it's run under Wine.

Re:But why?

[Trelane]

It's also free for on Linux non-commercial use: http://software.intel.com/en-us/articles/non-commercial-software-download. The Fortran and C as well as vtune and a bunch of other software (e.g. the Math Kernel Library) are all available for free, non-commercial use on Linux. Of course, AMD's software doesn't even have that restriction. :)

Re:But why?

[Bert64]

Other architectures also have their own specific compilers... MIPSPro, Sun Studio, CCC....
The problem is that a lot of software is tied to gcc extensions, which is effectively a form of embrace and extend.

Re:But why?

[RightSaidFred99]

I know. I much prefer all those much faster CPUs out there to boring old x86.

Wait, there aren't any that are faster. Doh!

So what shall one use now?

[lordmetroid]

When Firefox on Linux is getting the crap treatment from its developers, what shall one use now?

Re:So what shall one use now?

[mister_playboy]

This is nothing new. Running Windows FF in WINE is faster than using Linux native FF.

Re:So what shall one use now?

[illiter4te]

Why not just use XP? -.- -- All Heil Microsoft!

Re:So what shall one use now?

[asa]

A very large chunk of Firefox's developers have Linux as their primary platform. Linux Firefox absolutely doesn't get crap treatment from Firefox developers. You're obviously not familiar with the comparative qualities of the compilers on different platforms or you would asking "why do the Linux compilers get beat so badly by the Windows compilers."

Re:So what shall one use now?

[westlake]

A very large chunk of Firefox's developers have Linux as their primary platform. You're obviously not familiar with the comparative qualities of the compilers on different platforms or you would asking "why do the Linux compilers get beat so badly by the Windows compilers."

So why isn't the Moz Foundation investing in a better compiler?

---and what does this say about the performance of any app running under Linux compared to the Windows version?
 

Re:So what shall one use now?

[BZ]

> So why isn't the Moz Foundation investing in a better compiler?

This is a good question; I believe it's largely a matter of not having found anyone to pay to do the work, but I'm not privy to details on this stuff...

> what does this say about the performance of any app running under Linux compared to the
> Windows version?

That if performance is gated on computation and codesize, and the code identical, it'll tend to be faster on Windows....

Thing is, for most apps performance is gated on I/O or display (if gated at all) more than on computation and codesize.

Re:There! You have it!

[Anonymous Coward]

This proves that, um, Windows,er, Linux is....um...what the fuck does this prove again?

And why the fuck should I care if there's a 15% difference in performance of Firefox between those two OSes? I use my particular OS for reason that have nothing to do with how well Firefox runs on it.

That 15% could very well be measured in hours when the Slashtard coders get through with their Web 2.0 abominization of Slashdot.

Speaking of Bloat

[Junior Samples]

How well does it perform on Vista?

Re:Speaking of Bloat

[otaker]

How well does it perform on Vista?

Firefox does even better on Vista then on Linux machines...

Re:Speaking of Bloat

[CannonballHead]

This is a strange question. "Ok, so it's slow on mainstream Linux distros. I bet its slow on Vista, too!" I don't think it IS as slow on Vista, but I fail to see how that question does anything but try to say "Vista is just as bad as Linux."

Which, considering the fact that most geeks are more of the opinion that "Vista is a garbage can in comparison to the Taj Mahal/Buckingham Palace/[Insert Expensive Cool Place] that we call Linux," seems to be rather fruitless. Unless, of course, you're willing to admit that Linux isn't necessarily better in everything than Windows. :) Which is fine with me, who uses both quite extensively.

Re:Speaking of Bloat

[cyber-vandal]

It does seem weird however to compare the performance of an app on the latest version of Ubuntu versus that of the previous (and now 8 year old) version of Windows. I'm sure it's even quicker on Windows 2000.

Re:Speaking of Bloat

[msclrhd]

Vista even looks like Gnome:

* compact 'save as' dialog -- check;
* expand/collapse arrows on treeviews without any grid lines -- check;
* buttons as folders for directory navigation as the default for and alternative to the address bar -- check;
* user prompted for password when doing admin stuff -- check;
* an XML-based GUI markup -- check.

Re:Speaking of Bloat

[adolf]

I'm sure that they'd have loved to make a more fair comparison, say, between XP and an 8-year-old version of Linux.

But: Firefox 3.5 RC2 won't run on 8-year-old versions of Linux.

So, there. :P

Re:Speaking of Bloat

[cyber-vandal]

I'm sure there's someone out there prepared to prove you wrong. But that person is not me. ;-)

Re:Speaking of Bloat

[zoips]

Vista doesn't use WPF. That ended up being one the huge schisms between DevDiv and the Windows group, that .NET and WPF was shifting too much during the buildup of Vista for the Windows group to actually use, so Vista using WPF was scrapped. Obviously WPF ships with .NET 3.0, and many new .NET based apps use it (it's sure as shit better than Windows Forms).

I'm not sure about this

[mail2345]

But I think the speed difference was due to the Windows binary having profiling based optimizations, vs the Linux bin.

Re:I'm not sure about this

[Benanov]

That and Ubuntu does its own recompile...they make changes. It's not Mozilla's build.

Re:I'm not sure about this

[atomic-penguin]

That and Ubuntu does its own recompile...they make changes. It's not Mozilla's build.

I doubt that Ubuntu has an official 3.5 RC package built, as of yet. The benchmark article, even suggests, they are still shipping Firefox 3.0.11 with Ubuntu 9.04. No matter how bleeding edge Ubuntu may seem, it is very unlikely that Canonical would ship a Beta version or Release Candidate of Firefox.

Re:I'm not sure about this

[Teun]

Hmm, Adept says: Firefox Version 3.5~b4~hg20090330r24021+nobinonly-Oubuntu1 Package is maintained by Ubuntu Mozilla Team

I run it and it works.

Re:I'm not sure about this

[butalearner]

Very untrue, considering they shipped Hardy (a long-term support release no less!) with Firefox 3 Beta 5 as the default browser.

Re:I'm not sure about this

[asa]

That and Ubuntu does its own recompile...they make changes. It's not Mozilla's build.

I doubt that Ubuntu has an official 3.5 RC package built, as of yet. The benchmark article, even suggests, they are still shipping Firefox 3.0.11 with Ubuntu 9.04. No matter how bleeding edge Ubuntu may seem, it is very unlikely that Canonical would ship a Beta version or Release Candidate of Firefox.

The Ubuntu guys that maintain Ubuntu's build of Firefox are pretty quick to get new versions compiled. That doesn't mean it shows up in the primary Ubuntu repo, but I'd bet that they've built it already.

Re:I'm not sure about this

[atomic-penguin]

I was not questioning whether the Beta software works or not. The grandparent poster suggested that the benchmarked Firefox Release Candidate in this article was in fact, an official Ubuntu build as opposed to a Mozilla build. The article suggests that Ubuntu 9.04 still ships with Firefox 3.0.11 by default. More than likely, the package benchmarked was a Mozilla build.

Re:I'm not sure about this

[maglor_83]

No matter how bleeding edge Ubuntu may seem, it is very unlikely that Canonical would ship a Beta version or Release Candidate of Firefox

8.04 shipped with Firefox 3 beta 5.

Re:My problem with Firefox is this

[pablomme]

But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.

Widgets and dialogs, ok, that's your aesthetic preference. But fonts? After a couple of years using Ubuntu I hate how Windows fonts look pixelated even with Cleartype on. Freetype is much better at its job than Cleartype. If only because of that, I prefer the looks of Firefox on linux than on Windows.

maybe linux carries some of this blame

[asa]

Putting the blame all on Firefox when there's no doubt a certain amount of performance penalty that comes with a Linux's less good compiler is just lame. How about telling the linux tool makers to build tools that output faster and smaller code instead of demanding that app developers solve those problems? Finally, what "linux" build was this? Did it use profile guided optimization and other performance features of Mozilla's official Windows build system? If not, you're comparing apples to oranges.

Re:maybe linux carries some of this blame

[gilesjuk]

Indeed, GCC just isn't as good at producing fast code as Microsoft or Intels compilers. This is probably the price you pay for having a fairly portable compiler such as GCC.

Re:maybe linux carries some of this blame

[user317]

Putting the blame all on Firefox when there's no doubt a certain amount of performance penalty that comes with a Linux's less good compiler is just lame. How about telling the linux tool makers to build tools that output faster and smaller code instead of demanding that app developers solve those problems? Finally, what "linux" build was this? Did it use profile guided optimization and other performance features of Mozilla's official Windows build system? If not, you're comparing apples to oranges.

its an exponentially harder problem to do performance analysis at the compiler level then at the application level. Plus firefox + wine runs over 10% faster then firefox on linux, so very likely its not the tools. My guess its just because there are more windows hackers working on firefox since its a more important platform (to mozilla) then linux, so more optimizations are done.

Re:maybe linux carries some of this blame

[BikeHelmet]

Usually they profile the windows versions, and don't profile the linux ones.

Why? No clue.

Re:maybe linux carries some of this blame

[loufoque]

This is a myth.
I have barely ever noticed a performance increase when comparing code compiled with equivalent options on GCC, ICC and MSVC.

Quite the contrary, GCC is faster more often than you'd think.

Re:maybe linux carries some of this blame

[sjames]

And for not surrendering your first-born in order to have as many copies of it as you like.

Re:maybe linux carries some of this blame

[RebelWebmaster]

See bug 418866 for some guidance.

Re:maybe linux carries some of this blame

[YokoZar]

Usually they profile the windows versions, and don't profile the linux ones.

Why? No clue.

Because GCC is throwing weird errors when we try to enable PGO building on Linux https://bugzilla.mozilla.org/show_bug.cgi?id=418866

Re:maybe linux carries some of this blame

[0xABADC0DA]

My guess is Mozilla uses /GL option for visual c++ to do whole program optimization (if not, they should). Afaik this is currently not possible in gcc for C++ code except by cat'ing or #including all your files together into one.

In something huge like firefox there are probably a bunch of accessors and small functions that can be inlined to make a smaller *and* faster binary, if only the compiler can see the method implementation.

Re:maybe linux carries some of this blame

[multipartmixed]

Why don't you compile Tracemonkey with MSVC, GCC, and ICC, then run the sunspider benchmark. Make sure you have PGO turned on for the MSVC build.

Then you can go eat your hat.

Re:maybe linux carries some of this blame

[asa]

Got links? I'd love to see some support for this. Until I get those, I'm going to take the large number of anecdotal accounts from the people who actually compile popular apps like Firefox on Windows and Linux as having a bit more weight than your lone voice without any supporting evidence or even specif anecdotes.

Re:maybe linux carries some of this blame

[asa]

Mozilla doesn't compile the Linux builds in widespread use. If you're wondering why Firefox wasn't compiled with profile guided optimizations, ask your Linux distros. They're ultimately responsible for it since they cut Mozilla out of the process years ago. Your vendor relationship for Firefox is with Ubuntu or Red Hat, not with Mozilla. That's what the Linux distros demand and so that's the way it's probably going to stay.

Re:maybe linux carries some of this blame

[bloodhawk]

It is not a Myth, GCC is a good compiler, MSVC and ICC are fantastic compilers. This doesn't make GCC bad by any means, but it is gonna be a very rare occurance that GCC produces faster code, more work and effort has been spent on the other 2 to make them that much better.

Re:maybe linux carries some of this blame

[dhavleak]

Why is it important to use equivalent options?

If, for argument's sake, MSVC has a feature that's missing from GCC and this feature results in 5% faster code for some app -- well, more power to MSVC.

Re:maybe linux carries some of this blame

[asa]

And I believe it's the case today. Firefox on Windows can be compiled with PGO but the tools are busted on Linux so it can't be compiled with PGO there. That probably accounts for most of the performance difference. Fix the tools.

Re:maybe linux carries some of this blame

[bsmedberg]

Mozilla does comparative performance testing for the best GCC compiler flags constantly. There are several reasons why our Linux builds are slower than Windows:

1. The Windows ABI is cheaper: every relocated symbol in Linux is resolved at runtime by loading the PIC register and going a GOT lookup. Windows avoids PIC code by loading the code at a "known" address and relocating it at startup only if it conflicts with another DLL.
2. Mozilla code runs fastest when 99% of it is compiled for space savings, not "speed". Because of the sheer amount of code involved in a web browser, most of the code will be "cold". Tests have shown that at least on x86, processor caches perform much better if we compile 99% of our code optimizing for codesize and not raw execution time: this is very different than most compiler benchmarks. The MSVC profile-guided optimization system allows us to optimize that important 1% at very high optimization levels; the GCC profile-guided optimization system only really works within the confines of a particular optimization level such as -Os or -O3. In many cases using PGO with Linux produced much *worse* code!
3. The GCC register allocator sucks, at least on register-starved x86: we've examined many cases where GCC does loads and saves that are entirely unnecessary, thus causing slowdowns.

Believe me, we'd really love to make Linux perform as well as Windows! We spent a lot of time in Firefox 3 with libxul reducing startup time by making symbols hidden and reducing the number of runtime relocations...

Re:maybe linux carries some of this blame

[BZ]

> Why? No clue.

Because gcc falls down and dies if you try to actually use its profile-guided optimization feature with Firefox. See https://bugzilla.mozilla.org/show_bug.cgi?id=418866

I'd love to be able to enable this and get some profiles of things like sunspider and DOM-heavy pages with it, but I'm blocked on the gcc suckage. If you happen to know some gcc developers who could help here, that would be very nice.

Re:maybe linux carries some of this blame

[BZ]

> its an exponentially harder problem to do performance analysis at the compiler level then
> at the application level.

While true, the fact remains that MSVC++ produces smaller and faster code than gcc on this particular set of code, even ignoring things like profile-guided optimization.

But in any case, the 15% difference listed here is precisely what Sunspider on Windows picked up from profile-guided optimization.

> Plus firefox + wine runs over 10% faster then firefox on linux, so very likely its not
> the tools.

firefox+wine is running a binary compiled with MSVC++, so it likely _is_ the tools. If you think otherwise, care to explain your reasoning? Because what you said looks like a false deduction to me.

> My guess its just because there are more windows hackers working on firefox

I can guarantee that there are more Linux hackers than Windows hackers working on Firefox. I can also guarantee that a lot of the profiling is done on Mac (because Shark is far and away better than anything else freely available out there). I can further guarantee that per-platform optimization only happens on the level of compiler flags, not on the level of code. Largely because most of the code is the same on all platforms, and not hand-tweaked for maximum performance (because there area bigger performance fish to fry).

Re:maybe linux carries some of this blame

[loufoque]

The Windows ABI is cheaper: every relocated symbol in Linux is resolved at runtime by loading the PIC register and going a GOT lookup. Windows avoids PIC code by loading the code at a "known" address and relocating it at startup only if it conflicts with another DLL.

If you find the shared object system slow, you could simply choose not to use it.

Mozilla code runs fastest when 99% of it is compiled for space savings, not "speed". Because of the sheer amount of code involved in a web browser, most of the code will be "cold".

I have never developed applications where codebases are huge enough that optimization ends up causing more cache misses than anything else, to put in perspective what I said earlier. PGO is however supposed to undo such optimizations.

Interestingly, while Mozilla advocates compiling its javascript engine with -Os, Google compiles V8 with -O3 -fomit-frame-pointer (i.e. the usual recommended flags for performance for i386).

The GCC register allocator sucks, at least on register-starved x86

It seems to do better with -fomit-frame-pointer.

We spent a lot of time in Firefox 3 with libxul reducing startup time by making symbols hidden and reducing the number of runtime relocations...

You mean you spent a lot of time duplicating what the "prelink" program does?

Re:maybe linux carries some of this blame

[bsmedberg]

We could not choose to not use shared objects without destroying the Firefox extensibility model.

Sure, PGO is supposed to solve that problem. Measurements have shown that GCC's PGO does not actually work that well: it either turns on optimizations too aggressively, increasing codesize and slowing the program, or it doesn't turn on enough optimizations in the code that truly matters.

Mozilla makefiles manually choose special optimization settings for certain files within the JS engine such as jsinterp.cpp (which is compiled with -O3). We're working on being able to support -fomit-frame-pointer but currently the crash reporting system would break if we did that, and at least for the Mozilla binaries crash reporting is more important.

The prelink program does not affect code generation. Declared hidden symbols actually change code generation to avoid PIC loads and GOT lookups.

Re:Proving yet again

[asa]

Actually, it probably does say something about the superiority of the Windows compiler and potentially other Windows tools.

It's not only Javascript

[Anonymous Coward]

that matters when it comes to browser speed. I am running 3.5 beta on Ubuntu right now, with TraceMonkey turned on, and it really does well in terms of javascript performance.

But this doesn't change almost anything. GUI is still horribly sloooow. I have to reboot Firefox every few hours to keep it running somehow.

When I'm listening to online radio in one tab, and try to upload large file in other tab, my music is gone, Compiz marks firefox in grey as "not responding" and 2 of my 2GHz cores get 100% CPU usage for 10 mins. This is horrible.

The situation with Linux flash isn't any better. I really wish I could live without it, but as a web developer I cannot yet.

Watched documentary about beginning of Mozilla, a guy was given a job, maybe still on Netscape then, and he wanted "to make Mozilla run faster on Linux". Yeah, right. How many years have passed? 5? 10? crap.

Re:My problem with Firefox is this

[WarwickRyan]

>Ask Apple or even Windows folks.

You have seen Safari, haven't you?

It puts the 'f' in fugly.

Re:My problem with Firefox is this

[jdgeorge]

Firefox on Windows looks great/awesome/beautiful....name it. But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.

Folks, I am not trolling so have a look for yourselves and compare....

I'm running Windows XP and Ubuntu 9/04 side by side on similar laptops. Just to test, I looked at the main pages for Slashdot, Wikipedia (English), and Amazon, side-by-side.

My eyeball result of looking for differences between pages rendered with Firefox on Ubuntu 9.04 vs Windows XP:

• Slashdot (slashdot.org): indistinguishable
• Wikipedia (en.wikipedia.org/wiki/Main_Page): indistinguishable
• Amazon (www.amazon.com): Bold fonts in the "Shop All Departments" navigation menu appear too big on Ubuntu; they don't quite seem to fit properly.

Other than the issue for Amazon, the pages rendered look identical to me. The fonts for the menus look identical. I still disagree with the choice the mozilla team made to have the preferences/options menus with different titles in different locations for Linux versus Windows, but other than that, the UI seems consistent to me. The default GNOME theme for Firefox isn't as pretty as the new Firefox theme on Windows, but that's a minor aesthetic thing, and it's not ugly, it just isn't pretty.

Re:My problem with Firefox is this

[asa]

"But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse." What do you mean "on Linux"? On Ubuntu? on Fedora? Some other distro? The OS is responsible for the fonts, not Firefox and the distros almost all make changes to the default look and feel of Firefox.

Harm of looking good: opportunity cost

[jonaskoelker]

Or even then...How would a good looking Firefox harm Firefox?

If the time spent making firefox look good could be spent on other things, the harm of a good-looking firefox is that said other things are missing; they could be performance, stability, bug fixes, new features.

Now, I said "if". I'm not certain the condition is satisfied: if I'm working on performance-optimizing some application I run a lot, I'm not going to work on making it look pretty if I think it looks just fine. I figure people who like the performance just fine isn't going to move away from working on the pretty either. (As long as they're volunteer developers).

The size of the opportunity cost also depends on how big the return on investment is, in looks and performance, comparatively. If one mythical man-month can make firefox look 200% better or be 50% more performant, well... 200 > 50. Though I'm not sure how you quantify pretty ;-) user approval rating, maybe?

So in short: how would a good looking firefox harm firefox? I have no clue! ;) But I know that the answer "none" is something you arrive at only after some consideration.

Re:Harm of looking good: opportunity cost

[valinor89]

Thet would make sense if FF was a comercial product with limited resources (money) but beeig opensource anyone can make contributions. What is someone has no idea of what to do to optimize FF but still can improve it's looks? There would be no harm at all.

Re:My problem with Firefox is this

[TodLiebeck]

Firefox on Windows looks great/awesome/beautiful....name it. But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.

In Ubuntu 9.04 here, and I personally think the stock DejaVu fonts on Linux look quite nice. Actually prefer the traditional toolbar on Linux with Tango icons (tango.freedesktop.org) rather than the "enlarged back button" version found on Windows and OSX.

The only problem I see is the topic of this thread, i.e., performance. It's slow enough to feel slow, and the fact that most Linux distros run so well on old hardware makes the problem worse.

The bigger problem for the "Linux browsing experience" still seems to be Flash. Visiting a Flash-heavy site (like the horrible items produced by any given automaker) is a painful experience...it's bad enough that I'll typically crack open the MacBook. I find Flash sites consume an order of magnitude more CPU running natively in a Linux browser than they do running in a Windows XP VirtualBox instance hosted by the same Linux OS.

AdBlockPlus and FlashBlock are the only things that enable me to continue to use this computer for web browsing. It's somewhat of a sad state of affairs, given that it's more than quick enough to run multiple VirtualBox instances, Eclipse instances, and a GIMP instance with dozens of files open at the same time. But give it one web page with a few Flash advertisements, and you'll think you're on a Pentium 60.

Re:My problem with Firefox is this

[gbarules2999]

Firefox on Windows looks great/awesome/beautiful....name it. But on Linux, it is inherently ugly. The beast looks ancient and the fonts and dialogs make matters worse.

Not really. It fits in with the rest of Gnome fairly well, and if you throw on the Linux equivalent of "Cleartype" the fonts are actually quite nice. Installing the "mscorefonts" that most distros have these days makes Firefox rendering between the two practically indistinguishable, aside from, again, that Clear/Freetype rendering beauty.

Where's the proof that GCC is solely to blame?

[pembo13]

I keep hearing people saying that it's all GCC's fault, but I have seen no real proof of that. Nor why a profit making company such as Mozilla can't throw devs at GCC to fix the underlying problem.

Re:Where's the proof that GCC is solely to blame?

[characterZer0]

Why can't they just use Intel's compiler?

Re:Where's the proof that GCC is solely to blame?

[hattig]

Compilers aren't a simple problem that you can 'throw devs at'.

Maybe the Intel compiler could be used, but it breaks on anything non-trivial.

Or we can suck up the 15% performance degradation, especially if it is due to profiled optimisations on Windows, and just be happy that it is twice as fast in terms of Javascript, that might make Slashdot usable on a netbook again. It's certainly going to be faster than IE8 on Windows, and that is what most Windows users will be using in the end.

I only hope that Canonical make it available for 8.10, because we can't all upgrade to 9.04 because some companies (looks at VIA) take 6 months to get their drivers updated.

Re:Where's the proof that GCC is solely to blame?

[Peepsalot]

Is there a reason that Mozilla should spend considerable resources making the Linux version of their product faster than the Windows version of their product? I don't really see how it's their problem.

Re:Where's the proof that GCC is solely to blame?

[Dr. Spork]

I also wondered this! For one thing, it would make Stallman's head explode, but we might as well get the sad and inevitable event behind us and all use the best compiler we can get for all Linux projects.

Re:Where's the proof that GCC is solely to blame?

[loufoque]

Maybe the Intel compiler could be used, but it breaks on anything non-trivial.

No it doesn't.
Also, Mozilla uses a subset of C++ that only contains trivial features. (not that it would be a problem, ICC uses the most standard conforming C++ frontend there is)

Re:Where's the proof that GCC is solely to blame?

[mR.bRiGhTsId3]

Its my understanding that a bunch of the firefox core is written in C++. ICC uses a different name mangling scheme that GCC, so you can't link C++ code compiled with ICC with code compiled by GCC.

Re:Where's the proof that GCC is solely to blame?

[Freetardo Jones]

That stopped being true back in 2007 when they released version 10.0.

Re:Where's the proof that GCC is solely to blame?

[asa]

Mozilla's expertise is in Web browsers and the Internet, not in code compilers. Your suggestion makes about as much sense as telling Mozilla it should be funding development of faster hard drives or better LCDs. They'd all improve the Firefox experience, but don't really make a lot of sense for a browser vendor to be doing. As for GCC being inferior to other compilers, I'd recommend you ask that team directly. I'm sure they'll give you an honest answer.

Re:Where's the proof that GCC is solely to blame?

[mR.bRiGhTsId3]

Well, I guess the only reason to not compile with ICC is that "0h N0es! iNtel is t3h unfr33!" because every piece of literature I'v ever read suggests ICC produces slightly larger binaries which are greatly faster when compared to GCCs output. In fact, for this reason I seem to remember a whole bunch of guides from the olden days on Gentoo for how to install ICC.
And thus, the lesson we have learned is that when you have the engineers who designed the architecture on hand, you can write a kickass compiler.

Re:Where's the proof that GCC is solely to blame?

[asa]

Why can't they just use Intel's compiler?

Who is "they"?

Builds created by Mozilla get used but very few people compared to builds made by Ubuntu and other Linux distros. Perhaps you should contact them and as them why they're not using the Intel compiler.

Re:Where's the proof that GCC is solely to blame?

[BZ]

Last we tried it couldn't manage to compile the whole app (Firefox, that is). It's been a while since I checked on this, though.

There's been some serious thought put into just compiling the JS engine with ICC as a first step, but using two different compilers for different parts of the build process is a bit of a hassle, of course.

Re:makes sense

[ianare]

... and anonymous users are dyslexic (tub onyl midly).

Re:My problem with Firefox is this

[atomic-penguin]

The bigger problem for the "Linux browsing experience" still seems to be Flash.

So what is the problem Flash, or Linux?

Re:My problem with Firefox is this

[Anonymous Coward]

Fix your eyes!

  I'm a peer reviewed, 5 year at university 4 years at work designer and I say firefox on winows is *not* better looking that Firefox on Linux (gnome).

7 years of college, down the drain!

Re:My problem with Firefox is this

[Anonymous Coward]

skin your ff and you wont tell the difference between the windows and linux version. And calling it ugly just shows that you don't bother taking a minute or two to find a theme that doesn't give you an eye sore. *very windows like*

Here, I'll even help you out. https://addons.mozilla.org/en-US/firefox/browse/type:2/cat:all?sort=popular
Some of the themes can blow your "beautiful" windows theme out of the H2O.

Does gcc "do" Windows?

[Anonymous Coward]

Can gcc compile Firefox for Windows, so that we can more confidently apportion blame?

Re:Does gcc "do" Windows?

[Mad Merlin]

Can gcc compile Firefox for Windows, so that we can more confidently apportion blame?

Yes.

Re:Does gcc "do" Windows?

[BZ]

Yes, and Windows builds compiled with GCC are much slower than the MSVC++ ones.

Re:There! You have it!

[Colonel Korn]

This proves that, um, Windows,er, Linux is....um...what the fuck does this prove again?

And why the fuck should I care if there's a 15% difference in performance of Firefox between those two OSes? I use my particular OS for reason that have nothing to do with how well Firefox runs on it.

That 15% could very well be measured in hours when the Slashtard coders get through with their Web 2.0 abominization of Slashdot.

People have been complaining or quite some time about poor performance on slashdot. What is it that shows this poor performance? I don't recall doing anything that isn't instantaneous here.

Intel compiler

[Prune]

Then release binaries made with the Intel compiler. It's a better optimizer than MSVC (and gcc) whether on Windows or Linux.

Re:Intel compiler

[BZ]

The Intel compiler can't actually (correctly) compile the code in question, last I checked. See https://bugzilla.mozilla.org/show_bug.cgi?id=386840 for an example. Also https://bugzilla.mozilla.org/show_bug.cgi?id=412829 and https://bugzilla.mozilla.org/show_bug.cgi?id=483283 and https://bugzilla.mozilla.org/show_bug.cgi?id=403224

So people really are working on it; it's just not there yet.

real world vs testbench

[Werrismys]

Everything in these kind of tests usually makes MS and Intel compilers stand out vs gcc. On the desktop, the Wintel platform is shit slow all the time. I care for the latter. no 27 different systray update services for different crapware, the crapware, antivirus, etc running - just the apps and system services I have actually opted for,

What about other common cross platform software ?

[godrik]

Are there around some tests about other open source software that could help us understand the problem ? We can find some on open office : http://www.oooninja.com/2009/03/multiplatform-benchmark-30.html Or Tomcat : http://mediakey.dk/~cc/tomcat-performance-linux-faster-than-windows/ But that does not seem to gie a clear understanding of what's happening.

Re:There! You have it!

[jalefkowit]

The lag when posting a comment between hitting the "Preview" button and actually seeing the preview is downright painful.

On Linux 57% slower

[r45d15]

I just did my benchmarks, dual booting, Ubuntu 9.04 x64 and Windows XP x32: XP: 1586.6ms Ubuntu: 2739.2ms Specs: Intel Pentium D 3.4Ghz, 4GB RAM.

A Good Test would be Slashdot

[ackthpt]

When did Slashdot become such a COW?

Seriously, I try to scroll and the delay is very noticable to the point of annoying. I can load other large pages and scroll no problem. Is it a javascript performance issue or Firefox?

Re:A Good Test would be Slashdot

[rts008]

It's /. and it's sorry assed javascript, not firefox.
I went to preferences and chose 'classic view' to end this assclown behavior. That also ended the funny bars showing up in the middle of replies, the friend/foe icons plastered on top of comments, and other asshattery that was going on here also.

Re:A Good Test would be Slashdot

[pohl]

Yes, I'm certain that javascript is the problem. Slashdot has been unusable for me in mobile Safari on my 1st generation iPhone running version 2.0 of the software. The recent 3.0 upgrade made it usable, but still sluggish and with wierd random behaviour.

Re:A Good Test would be Slashdot

[vigilology]

For me it was the div on the left hand side that contains some weird counts of posts that I never managed to figure out. It's only in the new dynamic comment system they're using (IIRC). I got rid of it by using a stylesheet just for Slashdot:

#d2out {
        display: none;
}

Re:A Good Test would be Slashdot

[IsoRashi]

The layout has been bothering me too, but I had no idea we could revert to the our view. Thanks!

Why not normal x86_64?

[short]

i686 is now for about 6 years a dead horse. GNU/Linux world keeps i686 ABI compatible, that means:

• cdecl calling convention - the stack passed arguments - terribly slow, MS-Windows world is using their stdcall/fastcall mess which is faster but not compatible with former cdecl. x86_64 uses registers passed arguments by default.
• PIC - position independent code. GNU/Linux requires all the shared libraries (=that is all the Firefox code) to be position independent which is very expensive on i686 and as it also costs even one register. Vs. MS-Windows relocate libraries at kernel so they do not use PIC. On x86_64 the new PC-relative addressing makes PIC the same cheap as normal code.
• 64bit data for free - 32bit code had to handle all 64bit values expensively in two registers
• Probably other x86_64 arch improvements I forgot about. (guaranteed SSE/SSE2/SSE3/others? I do not remember.)

Other points making x86_64 the only choice at the same time making more favors to F/OSS / GNU/Linux:

• address space - Applications today already face the 1GB/2GB limit of i686 32-bit addressing. x86_64 has no such limits in any way. There are no reasons to run F/OSS (GNU/Linux) code in 32-bit mode. Contrary to MS-Windows with everything distributed proprietary where no 64-bit alternatives commonly exist.
• Compiler tools development concentrates on x86_64, as proprietary code has more financial investments in the past this advantage whould vanish with x86_64 as F/OSS code has enough financial backing nowadays.

Re:My problem with Firefox is this

[Nutria]

So what is the problem Flash, or Linux?

Neither. Probably X Windows. (Yes, I know the correct name is "X Window System", but I don't care!)

Re:My problem with Firefox is this

[FooBarWidget]

Unlikely to be X. I can play normal videos just fine at full speed. It's only Flash that eats CPU and is slow.

Re:Proving yet again

[rbanffy]

I think GCC is not known for generating very optimized code. Windows tools, OTOH, can more or less optimize all they want because desktop Windows is a x86-only world.

...but does Adobe Flash still hang up?

[flyingfsck]

The Javascript speed is not much of a factor. The one truly annoying thing with Firefox is the gawdawful Adobe Flash plug-in that hangs up at random, causing the whole browser to come to a screeching halt.

Re:...but does Adobe Flash still hang up?

[asa]

The Javascript speed is not much of a factor. The one truly annoying thing with Firefox is the gawdawful Adobe Flash plug-in that hangs up at random, causing the whole browser to come to a screeching halt.

So why not get Flashblock or remove the Flash plugin?

Re:My problem with Firefox is this

[AmigaHeretic]

>>I hate how Windows fonts look pixelated even with Cleartype on

There not pixelated, they have holes.

http://www.ecofont.eu/ecofont_en.html
It's save electricity. See, MS is justing trying to be a "green" company.

GCC, ICC, MSVC

[JambisJubilee]

It is not a myth. ICC kicks the crap out of GCC. I didn't believe it until I had access to a computing cluster (Intel processors) with ICC installed. My ANSI C code runs about twice as fast using ICC than with GCC. Would you really expect anything different?

As always, YMMV, but I suggest that anyone who doubts this to download Intel's compiler (it's free as in beer) and try it out.

It's not open source, which does suck. But it does consistently produce faster code.

Re:GCC, ICC, MSVC

[PsychicX]

I worked on a commercial PS3 title (none of that homebrew bull), where the GCC compiler is available as one of the options for the platform. It generates noticeably worse -- mainly longer -- code than is reasonable, and larger x86 code than Visual C++ generates. In turn, the larger code causes a lot of methods not to be inlined, and the cascaded effect (no doubt with caching issues etc thrown in) is notably slower. We're talking maybe 5-10% total here, but 5% because of a subpar compiler is pretty harsh.

Re:GCC, ICC, MSVC

[True Grit]

but I suggest that anyone who doubts this to download Intel's compiler (it's free as in beer) and try it out.

...unless you're running an AMD system, in which case don't bother, because ICC won't show your code nearly as much love as it would for a Genuine-Intel-Inside (or so I've heard)...

At least you must admit that GCC is fair in its handling of its backends: it provides mediocre performance in equal doses. :)

Re:My problem with Firefox is this

[zuperduperman]

The horrible fonts were what drove me away from Ubuntu after I installed it recently, hoping to use it as my primary desktop. I'm sure you've managed to fix up your fonts somehow, but let me tell you, a default ubuntu install (from the 8.x series, haven't tried more recent) produced such an eyeball searing ugliness in FireFox that it almost single handedly convinced me that Ubuntu wasn't ready yet (for me). The fact that a few searches with Google reveal hundreds of various ways to improve the fonts actually makes it even worse.

Since you'll undoubtably deny this having not witnessed it yourself, just search on google and see the thousands of perplexed newbies being driven away from linux by the fonts you think are so beautiful:

http://www.google.com/search?q=ubuntu+firefox+ugly+font

Re:There! You have it!

[cbhacking]

Iroincally enough, IE8 is faster at it than Firefox 3.0, too. One of the first things I noticed when the IE8 public RC (never mind the actual release) came out. Kinda sad...

Re:There! You have it!

[electrosoccertux]

I emailed Malda about this a year ago; we exchanged several emails; here is where it ended (I do not know how to check for this; I'm more EE than CS):

Is it possible that your ISP is transparently proxying your requests? A lot of providers do this, and very few people ever notice.

FYI.

Can anyone look into this?

Re:My problem with Firefox is this

[metalhed77]

I read somewhere that's because Flash video decodes to RGB while X likes YUV video, so flash video can't use XV. If you try playing any video without XV it'll be slow and stutter.

That said, for some reason flash video plays much better on my nvidia card at work than my ati card at home.

Re:Smell the bull

[msclrhd]

I want to run ray-traced Quake that is written in JavaScript on Firefox ;)!

Fix the urgent stuff first

[multi io]

I have a Firefox 3.0.11 installation at home (Iceweasel 3.0.11 on Debian), and one at work (Firefox 3.0.11 on FC 9). The machines are comparable (2 GB RAM, Intel Core 2 proc in both). In the installation at work, scrolling down in a Slashdot article forum is about 100 times slower than in the home installation: if I press cursor-down once, it scrolls about 10 pixels down at a speed of 5 pixels per second -- I'm not exaggerating. Running under a different user account with a clean profile and no extensions makes no difference.

Something is obviously completely out of control there.

Re:Fix the urgent stuff first

[amorsen]

Running under a different user account with a clean profile and no extensions makes no difference.

I bet there is a setting for what cursor-down is supposed to do, which Fedora sets differently from Debian. Try a diff on about:config.

Re:Fix the urgent stuff first

[BZ]

Assuming the problem is also there with mozilla.org builds, and not just the customized distro build, the next-most-likely issue is some interaction of Firefox, X, graphics driver, graphics card. Firefox 3 offloads a lot of rendering to the X server (instead of doing it itself in software like Firefox 2). Unfortunately, as often as not the X server does the rendering in software itself instead of actually using the graphics hardware. And the software it uses is older than what a client would typically use and somewhat more generic, so slower...

So some cases of using the X server lead to a significant speedup over doing the rendering yourself; others to a significant slowdown. And which it is depends not on your code but on the user's hardware/X/driver configuration.

Re:Fix the urgent stuff first

[multi io]

Intel onboard on the FC system, NVidia (+ their blob driver) on the Debian one.

Re:Fix the urgent stuff first

[multi io]

The diff is 1500 lines, not sure where to look there. Scrolling with the mouse wheel or the scrollbar is equally unbearable (clicking a scrollbar button seems to trigger essentially the same behaviour as pressing cursor down).

Re:Fix the urgent stuff first

[multi io]

The strange thing is that this behaviour only happens on the Slashdot site. On other sites, the scrolling speed looks OK.

Re:Fix the urgent stuff first

[BZ]

Scrolling behavior is very dependent on the details of the exact CSS used, the exact images used, etc... So it can vary very much by site.

Re:There! You have it!

[webheaded]

Seriously? Ever time I load a story with a lot of replies, my browser damn near freezes while I wait. And I'm posting from a Core 2 Duo machine with 4gb of RAM. That's fucking retarded no matter how you look at it. And OMFG like that other guy said...the lag between hitting preview and seeing the preview is ridiculous.

I'm not normally one to hate new stuff, but this is completely insane. Digg did the same damn thing. You can't load up a page with 100's of replies with AJAX ffs. It doesn't work. It runs like SHIT and makes browsing the site so very painful.

Re:There! You have it!

[William Ager]

I'm reasonably certain this isn't the case: I've seen the behaviour through several connections, and most of those connections are not the sort that would have transparent proxies.

Re:There! You have it!

[LS]

are you sure that's not an anti-spam feature?

Re:My problem with Firefox is this

[RightSaidFred99]

Funny, they modded you troll but you're of course right. Firefox on linux looks like shit.

Re:There! You have it!

[psyclone]

The comments on slashdot might take more screen real estate, but they're much easier on the eyes (when the CSS mostly works).

The Daily Kos' narrow column of constrained text makes it painful to sift through many comments.

Their page loads do seem faster, but that's probably due to a simpler DOM (and feature set).