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
the qt rewrite is dead jim.
Its a shame i was really looking forward to the qt port, but just like the old port, it got done then dropped AFAICanTell there wasn't enough developer interest and no users were using it as it wasn't quite usable :(.
IranAir Flight 655 never forget!
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
You're talking about what Linux was like 6 years ago. Now it's no harder than Windows.
No ascii art.
No it's not. Due to developers having to foot the bill themselves, you don't get to choose one of your options. Open source software HAS to be cheap. Value is not measured in money you know. Money's just the in-between "equalizer". Value is measured in computers, development time, eyeballs, testers, people, management, internet servers, ... Just because you don't have to pay for something doesn't mean that the value you received wasn't created using resources.
Your argument would include stuff like "pirated games are free to produce for publishers". After all, there is no money involved in their "acquisition". More extreme, the same would be true for stolen goods.
Open source is only free for one side of the equation : it's only free for users, not for developers.
Actually, I think it's "Good, Fast, Cheap. Pick 2". And for online dating, it seems to be "Attractive, Intelligent, Sane. Pick 2".
More often "Pick 1"
I'm not sure what the specifics are causing it, but I can honestly say that native Firefox on my Linux (Mint 6) system just blows. I have no idea just what they got wrong, but compared to my Windows systems (Vista on laptop, XP on my home desktop and work desktop), or my Mac systems, it just blows. Firefox on my 500mhz G4 Mac with 512MB of RAM is literally a whole different experience compared to Firefox on a 2.8Ghz Celeron Linux system with 2GB of RAM (I've also testing similiar results on my MythTV box which is a Sempron 3400 w/ 1GB RAM, and my old Linux machine which was an Athlon XP2100 w/ 1.5GB).
If I'm working slow - casually browsing the web, then I can't notice. Thing is I tend to crank open tons of tabs and flip between then when I'm web surfing. At work now (where I open less than at home), and having been here 15 minutes I count 12 tabs open in this browser session. At home I can easily have 75 or more open at once. Usually when flipping between them I'm a very fast clicker, and there is a most definate noticeable pause in the rendering as Firefox on Linux switches between tabs or closes/launches one compared to the other platforms. In general the pages themselves, when network bandwidth isn't the bottleneck, also render a tad slower and more "klunky" (ie, for fractions of a second I can see things appear in one spot and then quickly rearrange to their final positions, where on the other platforms I would have seen far more items just appear in their final location).
Even though it still doesn't match regular Firefox on the other platforms, I've taken lately to using Epiphany. While it has it's own issues, it still does have a slight speed edge over FF so I continue to use it for now.
Truthfully, if Linux could FINALLY ditch the inherent "slow" feel to most of it's apps (which I think it really more an issue with xorg and the GUI toolkits more than "Linux", though I'm speaking as an overall platform not a kernel here), then I think it'd pickup a lot of new users, and some part-time users might well become full time.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
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)
But FF's crappy performance/speed/response on Linux just really really sucks.
I keep looking for a new browser, but Konq + multimedia = crashtastic, midori & kahazekhaze are too overall unstable, and Epiphany is just under-featured. Opera isn't FOSS (which slays me--I love Opera like a little girl loves ponies, but I've got a pretty strong ethical committment to FOSS).
There's always elinks ;).
And then there was silence.
I am the lawn!
You fail to realize that ultimately both versions of Firefox must eventually go through the same layers of Linux in order to do pretty much the same thing. The story is that the Windows version is still faster even though it has a whole extra layer to go through.
It is not even a comparison of Linux/Windows but of Linux and Linux+Wine.
The Linux build of Firefox is the problem here and has nothing to do with the trade-offs between how Windows does things and how Linux does things.
Besides, how can you say that everybody should fall on one side of the Performance/Reliability trade-off? Such things are case-by-case by definition.
Don't bother replying to this guy. He posted the exact same comment in the post-beta windows 7 leak story that was posted.
http://tech.slashdot.org/comments.pl?sid=1126249&threshold=2&commentsort=0&mode=thread&cid=26836579
We get it you don't like linux. Just go away.
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.
Well he said the Unix way so I'm assuming he's thinking of some sort of demented scheme involving fork() and a filter-style JS interpreter which spits out a shell script which is then piped to bash with the DOM as an HTML file and the output redirected back to Firefox. Or the official Windows binary was compiled with Intel's monolithic compiler rather than gcc.
"Anyone who attempts to generate random numbers by deterministic means is living in a state of sin." -- John von Neumann
cache misses are __WAY__ more expensive than subroutine calls.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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.
Context Switch also refers to switching between user and kernel modes via system calls or interrupts. OP is still a raving lunatic though.
It's basically a compiler benchmark. What this proves is that the microsoft C++ compiler produces better code than gcc. This isn't suprising. Re-run the benchmark with the Linux code compiled with the intel compiler. gcc is a good compiler, but it doesn't produce code as tight as some commercial offerings.
Serious question: What is glibc doing that you don't think it should be doing?
This isn't so much a complaint about glibc-as-implementation, but I do think the standard C library design has a lot of crap in it that it just doesn't do well.
In my mind, the main offender is internationalization and localization support. It's a non-trivial problem that the standard library just isn't very well-suited to--I usually end up using a library like ICU for this.
The C people should have stuck to byte string manipulation, math, and basic I/O, but there's no putting the horse back in the barn after that.
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.
It's basically a compiler benchmark. What this proves is that the microsoft C++ compiler produces better code than gcc. This isn't suprising. Re-run the benchmark with the Linux code compiled with the intel compiler. gcc is a good compiler, but it doesn't produce code as tight as some commercial offerings.
To be honest, the quality of generated code between MSVC and gcc is not that different. MSVC tends to do inlining somewhat better (I've personally witnessed it unroll a ~60000-deep call chain - produced by template metaprogramming - into a single statement). On the other hand, gcc is sometimes more tricky with rearranging the code smartly to produce the same effect for less effort, on the level of individual instructions. I do not think that it's what makes a difference here.