Slashdot Mirror
Firefox Faster In Wine Than Native
An anonymous reader writes "Tuxradar did some benchmarks comparing Firefox's Windows and Linux JavaScript performance. 'We did some simple JavaScript benchmarks of Firefox 3.0 using Windows and Linux to see how it performed across the platforms — and the results are pretty bleak for Linux.' Later on, they tried Wine. 'The end result: Firefox from Mozilla or from Fedora has almost nil speed difference, and Firefox running on Wine is faster than native Firefox.'"
Check the doco
Firefox 3.0 built for Windows was PGOed (Profile Guided Optimisation)
PGO was not yet enabled for linux builds
Try a newer build.
FAIL
The Singularity is closer than you think
Quant
except I'm using Linux
On the flip side, the pop-unders I get from my local newspaper's site under Firefox don't happen under Linux, only Windows.
"Can't you see that everyone is buying station wagons?"
Mozilla created Firefox for Windows, and then they made a half-assed version for Linux. I'm not really surprised that the Windows version runs faster. Wine usually runs programs at about the same speed as the Windows version. Sometimes a little more, sometimes a little less.
I don't see how this "looks bleak for Linux." Damn trolls.
For everyone else in the world who does not know what PGO is maybe some details on why it is not enabled would be helpful.
Seriously, how fast does a web browser *need* to be? I've never been using Firefox on Linux and thought to myself that it was prohibitively or even annoyingly slow.
Reading TFA, in most cases, the differences in times don't seem dramatic, either, so who really cares?
if you want to talk about monolithic, do-it-all library architecture... lets talk about glibc. does far far far more than any libc is needed to do.
portfolio
i usually develop on Linux, and test against Konqueror and Firefox 3, and periodically fireup a KVM virtual machine running winXP for testing against IE, Chrome, and Firefox (again).
when doing heavy JS animations, and even more when using Canvas, it's pretty obvious that FF on windows is far smoother than on Linux, even with the VM overhead.
I'd say that there are lots of optimizations that the FF/Linux dev team left out.
-Kz-
Firefox Faster In Wine
And here I was thinking inebriation led to slower brain functions!
The disappearing pencil trick. Let me show you it.
By default Firefox for Linux uses shared system libraries rather than statically linking them altogether as the Windows version does. That's bound to have an impact on performance because code and data pages will be all over the place. Type "about:buildconfig" into the browser and it will tell you its build settings.
Serious question: What is glibc doing that you don't think it should be doing?
Elrond, Duke of URL
"This is the most fun I've had without being drenched in the blood of my enemies!"-Sam&Max
I dual boot between Windows XP and Ubuntu GNU/Linux (of the Intrepid Ibex flavor).
Firefox is slow on Linux in general. Page Up, Page Down, Arrow Up, Arrow Down, Ctrl+Plus and Ctrl+Minus (to increase and decrease the font size)...all of these things are instantaneous on Windows XP, but there's a noticeable lag on Linux.
I'm not sure what the problem is. I'm using the proprietary ATI drivers on Linux, which should be pretty fast. And my machine is old enough that all the kinks should have been worked out of the Linux drivers for my hardware.
>But are we really going to try to maximize speed over durability?
I was taught very early in my IT career that there are 3 considerations on any project.
1. It can be cheap
2. It can be fast
3. It can be reliable.
Now go and pick 2 out of 3.
I want a list of atrocities done in your name - Recoil
That's way off base. There are no context switches when making a library call. Context switches occur when you ask the kernel to do something by making a syscall. So memcpy or memcmp don't incur a context switch. Nor do fopen or fread in and of themselves cause context switches. But one will occur when the underlying open and read calls are made.
What's really needed here is a profiler to find where the code is spending the bulk of its time. My guess is that it's a compiler issue. And other comments about the windows build using profile guided optimization tell me my guess is probably right.
If Firefox ran faster in Wine than in native Windows, that would be great news. As it is, it's undoubtedly because Firefox's code is optimized for Windows, rather than Linux.
If it runs faster in Wine than either native on Windows or native on Linux, that'd be really cool. Or funny. Or sad. I'm not yet sure which.
Actually, I think it's "Good, Fast, Cheap. Pick 2". And for online dating, it seems to be "Attractive, Intelligent, Sane. Pick 2".
happy for non-technical reasons, but I continue to use Swiftfox on Linux because it is so damned much faster than Fedora's Firefox build.
I know that there is a CPU optimization difference, but I haven't looked into other differences. Someone who has looked at the buildconfig for both and/or who knows about the build processes and configurations of both: is the reason for the slowness in the comparison referenced in this post related at all to something that Swiftfox is fixing?
STOP . AMERICA . NOW
I think it stands as a testamant to the WINE folks. I know Linux distros and the various Window Managers - KDE/Xfce/IceWM/Gnome - have to handle things that Wintendo doesn't, as it is integrated into the OS from the get-go.
However, the results are not that dramatic. I'd be curious to see a few things, including how Native FF runs in KDE with the Gnome libraries loading up. (I run KDE.)
Also of note - I've posted before on lists that "starting" Word 2003 takes about half the time as it does to "start" OpenOffice 2.x on my distribution. I run CrossoverOffice and have Office 2003 loaded. My guess is that there may be something in Wine that optimizes these processes.
The Kai's Semi-Updated Website Thingy
You obviously have no idea what a context switch is.
A context switch happens when the scheduler stops one process/thread and gives the CPU to a different one. This has nothing to do with cross-library calls.
sig intentionally left blank
Browser response, not speed, is what annoys most people on Firefox, since version 1.
Instead, it's the lack of threading - that the notion "UI, the rending engine, and plugins should run in separate threads, with the UI thread having the highest priority".
Konqueror runs Flash player in its own process "nspluginviewer", which I can renice to 19 - just like how IE runs Flash in the lowest priority by default. Still, on Firefox 3, a few tabs running CPU-intensive Flash can still effectively freeze the browser UI.
And for your career 1) Like what you do 2) Make lots of money 3) Operate within the law
Pick any two
Laptops in particular often have slow hard drives. Antivirus slows them further. You're probably waiting for the disk all the time.
It's often compounded in a business environment by other disk access apps (auditing etc).
I know on my laptop, lauching firefox involves McAfee scanning Firefox, then Centennial scanning Firefox, then McAfee scanning Centennial, then McAfee scanning Firefox again.
"Those who cast the votes decide nothing; those who count the votes decide everything." (attrib. Joseph Stalin)
Attractive and Intelligent works for me! Just don't sleep with her, and by sleep I mean fall asleep. Also hide all knives and scissors.
I am not sure how you got modded insightful. Linux, in terms of the kernel, is in fact a monolithic structure but has nothing to do with the API/lib/small packages that can be chained together that the OP was talking about. Linux in the GNU/Linux sense (a distribution), is in fact composed from many small libraries that each perform a specific function well.
Regarding your point about how the app was built: How do you draw a distinction between the Windows, Linux, and UNIX builds of Firefox? I'll help you - each version is a port using libraries on the system that it is ported to. Those dependencies do in fact have an impact on compilation, how the memory map is built, and how well the application performs.
Also - the optimization process differences are significantly more complicated than you implied. I strongly suspect, although am not positive because I have never built it from source or examined how an RPM was built, that the Linux Firefox build was done with at least -O2 or -O3 flags. The difference that FP was talking about was PGO (Profile Guided Optimization), which is more involved (and thus better performance gains) than just turning on the default compiler optimizations.
Actually he's right but in the wrong direction. On Wine many things that would be pure syscalls on Windows do force a context switch into the wineserver, because the emulated "kernel" is actuall a separate process. For instance opening a file involves an RPC to the wineserver on Wine, whereas it simply switches into kernel mode on Windows and there's no TLB flush overhead. The fact that Firefox is still faster under Wine than native suggests a serious bottleneck somewhere rather than a general problem - if I had to choose, I'd pick text rendering as my first guess.
I guess it's all a matter of preference. Right now my glibc is washing the dishes, which is great since my wife won't. However, in some other house they might want glibc to stay the hell out of the kitchen.
Just disrupt the deflector shield with a tachyon burst.
Firefox appears to be using an inefficient method to render the content to the screen. If a load up a page in Firefox and drag the window around fast, the content inside the window tears and blurs and stays that way for a second after I stop whipping the window around. Konqueror and Opera don't do this.
GCC does everything MSVC does, and more
This is simply not true. From the chart, Microsoft has Fastcall, disabling exception handling, simple member functions, and GCC does not. Additionally, the chart also incorrectly states that Microsoft does not have an option for fast but imprecise floating point. It does.
On the flipside, MSVC++ has whole program optimization, which GNU calls LTO. LTO doesn't exist for GNU yet. See here:
http://gcc.gnu.org/wiki/LinkTimeOptimization
Scroll down and read. Pretty much, LTO looks to require a new C/C++ parser. That's not going to happen overnight.
This is my sig.