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?"
What I "lose" in javascript performance, I think I more than make up for in not wasting any cpu cycles on anti-virus crud.
I'm not at all sure how relevant these synthetic tests are. I use Ubuntu 8.10 on a 2 year old laptop and it honestly feels snappier now than it did when it was running XP. Maybe some things are slower and some things are faster. Beats me, as I'm too busy actually using it for real work to be bothered benchmarking it. But on the whole, it certainly "feels faster" now.
Best,
More interested in Firefox 3.1 JavaScript speed!
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?
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.
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.
Nothing for 6-digit uids?
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
And isn't there another story out there that says that Firefox is faster on Linux than on Microsoft? So what they are saying is,that Firefox is faster in Wine than it is on native Linux. which is still faster than Firefox on Windows.
CAPS LOCK: ITS LIKE THE CRUISE CONTROL FOR AWESOME
It's not just JavaScript, the whole damn thing feels sluggish in Linux compared to the Windows build. It's really annoying, particularly if I'm trying to show how "fast" Linux is when compared to Windows. Yes I know Firefox /= Linux, but it's a primary application so if that is running slow, it's not a good sign.
The only conclusion I can gather is GTK is damn slow. Maybe the upcoming rewrite with QT (so I hear) will be more zippy.
If the results are confirmed, could it be because it uses the GTK2 widgetset?
And Linux is not a monolithic do-it-all library architecture?
And UNIX is easier to bug fix? Huh? Come on this is fairy tale stuff...
What they are talking about here is that a Windows application using Wine is faster than a UNIX application on UNIX.
I also would believe your argument if we were talking about a UNIX app built specifically for UNIX and Windows app built specifically for Windows. But we are not. We are talking about Firefox...
My guess is like a poster up above who said that optimization flags were used on Windows, and not on the Linux native build.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
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.
Since when does measuring JavaScript performance automatically indicates if a browser is faster or not? Op honestly didn't phrase the subject well.
And why all these "JavaScript benchmarks"? Is it common for people to do matrix math with it or what?
So now all of a sudden having a responsive application, which doesn't crash and/or eats all of the available memory and does the job without me thinking that I'm driving on a snail doesn't matter?
They should be looking elsewhere.
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.
In theory if you have the web browser the performance of the Anti-Virus running on different CPU so you are not getting any real speed savings. So if you have a slow web browser you still have a slow web browser with or without Anti-Virus. (Yes I know it is more complex then that, wait time for sharing IO, Joining Busses etc...)
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
... RTFA
>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
Switch from Ubuntu to LFS, only level 10+ dwarves are allowed there.
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.
Ah, but with FOSS, #1 is assumed (for the end users, not the developers) because FOSS can be seen as charity after a sort, it's quite possible for it to be #2, #3 for for devs, and all three for end users.
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.
Running firefox in TinyXP in Virtualbox is faster then native on my Ubuntu......
PS. My captcha is 'rejoice'
What I "lose" in javascript performance, I think I more than make up for in not wasting any cpu cycles on anti-virus crud.
Firefox in _Wine_, not Win. TFA was still using Linux, but was using Wine on top of Linux, with Windows version of FF.
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
But those benchmarks are done by a f'n noob! How can you possibly trust them?
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
My experience of using Ubuntu via wubi (i.e.a file image stored on an NTFS disk) is that the performance is hit severly by the ntfs-3g process. Run top while performing mild disk activity and you'll see what i mean. If you use it regularly you might want to use dual boot instead.
what FireFox would do on tequila! Mucho rapido.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
You're talking about what Linux was like 6 years ago. Now it's no harder than Windows.
No ascii art.
Firefox is way more stable in my experience under MS Windows (and maybe WINE?) than under LINUX/X.
Admittedly I'm probably more of a 'power user' than most, but the thing that kills me about LINUX Firefox
is its GROSS instability under heavy load (e.g. problematic on both Fedora and Ubuntu 64 bit editions anyway).
It takes anywhere from a few minutes to a couple of hours of ordinary use in order for it to just crash and close down on me with no core dump.
This is on systems with 8GB RAM (so it is not a resource shortage), not using FLASH or similar plugins, and not always / generally using proprietary ATI/NVIDIA video drivers. Admittedly this often occurs with a high number of windows/tabs open (e.g. 85 windows, 500 tabs) -- just because that's a normal evolution of me leaving stuff open instead of closing them. However I've had it crash similarly frequently when only a few dozen windows/tabs are open, so it isn't strictly a super heavy load issue. Generally the crash is accompanied by some X windows system error, BadIDChoice or such. Here's a ~ 2 year old Ubuntu "confirmed" bug report listing very similar crash problems, though the exact X error seems like it could be a bit different here:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/97492
I just don't get their LINUX quality control, this happens so repeatedly over numerous 3.X versions of FF that I must assume that an automatic test script that repeatedly opened / closed a few hundred windows mocking normal usage would repeatedly trigger this, yet after apparently a couple of years of the problem being unresolved I still see no diagnosis / workaround / fix.
This just doesn't happen under MS Windows, though I tend to load down XP / Vista SLIGHTLY less with open tabs / windows than on LINUX, but on LINUX I can run FF for hours or days if I'm lucky. On MS Windows I can run it for days or weeks, so this is rather embarrassing / frustrating since in all other day to day use respects LINUX tends to be equal or superior to MS Windows in stability / functionality.
No chrome (yuck), super unstable firefox, konqueror just doesn't compare, opera I'm not a fan of == unhappy LINUX browsing.
One thing Chrome got right is one system process per window, at least a single error doesn't take down HUNDREDS of open browser windows. Even better would be true error recovery so that any error would just cause the affected threads / tabs to be reloaded with no loss of context and not having the whole browser crash. The automatic crashed session recovery is about the only thing that has kept me using FF on LINUX, though it sucks to wait like 20 minutes for your pages to reload, and then never perfectly (lost form data / buggy reload processes / whatever).
I've never done any benchmarks, but Firefox certainly FEELS faster in Ubuntu and Fedora than it did in XP or now Vista. I haven't tried Wine, but it does seem a tad faster in my XP VM than it did in native XP.
Anyway, I for one don't care until the differences are are noticeable during normal use. The rest is academic or even just pointless.
The confidence of ignorance will always overcome the indecision of knowledge.
You seem to be confused.
Calling a library does not do a context switch.
And there is no possible way that some difference between Windows&Linux could explain how the Windows program running atop another *Linux* program would be faster.
It sounds to me like the Linux version does something incredibly inefficient when talking to the system, so that the Windows version, plus the code to translate and execute it using something on Linux is faster! They really should identify what this is and make the Linux version use it. Supposedly if you took the relevant code out of Wine and merged it with the Windows calling code and removed the unnecessary intermediate steps, you would have a Linux interface that is faster than either one of these.
I have a dual boot XP / Ubuntu on my Asus EEE 1000H.
Firefox feels more responsive under XP then it is under Ubuntu.
I use the eee-pc kernel and I turn down all the visual extras both under Ubuntu and XP. Also Firefox runs with the same addons: Adblock, Flashblock and NoScript.
Love many, trust a few, do harm to none.
Unless I have a HUGE hole in my dynamic library knowledge, you are wrong.
Linux dynamic libraries, like any windows dynamic library, don't force context switches at all, neither on windows or on linux. They force a few page faults to generate new data segments, but they do so on both systems.
And in practice ... linux easier to bugfix ? Dream on. Truth be told, as long as it's "high level" stuff, windows is massively easier to bugfix, due to massively better development tools (sorry but nothing beats microsoft's visual set of tools).
The article is saying that the Windows version under Wine runs faster than the Linux version. It does not compare it to the Windows version running under Windows and you do not need Vista to reproduce the result.
Most likely the Windows version on Windows is faster than the Windows version on Wine, and thus faster than the Linux version as well. However as far as the article is concerned, it could be slower than either one. It is not relevant to the question.
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"
In my experience this is for multiple reasons gnome, compiz, pango, flash... Try running it on a gentoo system compiled without pango and on kde. Probably will be faster and more responsive
with GCC, and Intel. Lets find out if the code base difference between Windows and Linux is the issue OR the compilers.
I prefer the "u" in honour as it seems to be missing these days.
The structure of the libraries has nothing to do with it. When a library is dynamic linked in linux, it is simply mapped in to the processes memory space. Once they're mapped in, there's no appreciable difference between a function call across libraries and one within the library (yes, there is a jump through a table, but that table tends to stay hot in the cache).
The optimization options to the compiler are a much more likely explanation.
What do you have in your make.conf
CFLAGS="-march=k8 -O2 -pipe"
USE="mmx sse sse2"
MAKEOPTS="-j2"
How much ram do you have? I have 4GB DDR2. Do you use integrated graphics, or do you have a graphics card? I have an HD 3870. If you do have a graphics card, what drivers do you use? I use proprietary fglrx. I would ask what Desktop Environment you use, but the results were pretty much the same on both.
I don't know what your installation feels like, by my system is fast as shit under Gentoo. (and no, I'm not a fanboy. In fact, I'm very critical of the distro.)
I recently went through a round of attempting to use OpenSolaris on my work laptop (damn I want that ZFS juju)... and there were a couple of things that drove me back to Debian - one of them was the horrible performance of Firefox under OpenSolaris. Under VirtualBox on OpenSolaris host, Firefox was faster on either a Debian or a WinXP guest than it was on the host... the difference between usable and not. The specific application that really showed this was Zimbra (pretty heavily AJAXy). In trying to track this issue down, the general feedback on OpenSolaris forums was "Firefox on OpenSolaris kinda sucks, sorry". My personal experience with Firefox is that under Linux or Windows it's subjectively close enough not to worry about (on a variety of hardware, not just the laptop that I tested OpenSolaris on).
You must be using a different Firefox on Linux than I am. Mine is neither fast nor stable.
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
GUI tools are fine, but when you are debugging a program running on a remote, non-X11 machine through a slow SSH link, then gdb and friends are teh roxx0r :P
Colorless green Cthulhu waits dreaming furiously.
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.
Just sayin'
And for your career 1) Like what you do 2) Make lots of money 3) Operate within the law
Pick any two
Huh?
You've made two assertions that I believe are incorrect.
That a context switch occurs when you go from a one library to another.
That context switches can account for a 20% speed difference in executing Javascript.
The first one is outright wrong. There's no need to either start a new process just to use a different library, or switch to some other already running process.
The second one is extraordinarily hard for me to believe. You'd only see a high overhead for a context switch (which isn't happening here anyway) if you were doing a tiny amount of work that doesn't make up for the cost of the switch.
AccountKiller
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 ;).
Now it's no harder than flushing your toilet.
There fixed it for you.
I am the lawn!
Think about it. If this WAS the problem, then running the windows version under Wine would not be faster. Wine still has to live on top of X and thus it would suffer from similar issues.
Now, it could be that the Linux port uses X BADLY and Wine uses X WELL, but that still doesn't make it an X problem.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Intelligence often precludes sanity. At least it does in my social circle.
A latent existence
And then there was silence.
I am the lawn!
Firefox really feels sluggish under Linux. On the same hardware Firefox is way more snappier, doesn't freeze and lag under Windows. When I set up Wine I also setup Firefox + Flash and it certainly was faster than the native versions. Youtube looked worse (lots of banding) but overall the responsiveness was much better than of the native versions.
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.
How come we haven't see fast, reliable software that is FOSS that is also GOOD?
Can you really claim an exception for FOSS?
Given that FOSS always gets you #1, it should be concluded that you can only get #1 and #2 or #1 and #3.
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.
No, he's right. I still use Linux to distribute my TRON fanzines and personal Dungeons and Dragons web-sites. Although I have expanded its use to include presenting slideshows of my Sailor Moon hentai.
I was taught early in life that there are 3 considerations on any woman.
1. She can be good looking
2. She can be rich
3. She can be sane
Now go and pick 1 out of 3. Or 2 if you're lucky.
I ran the google v8 test 3 times and took the high on my Ubuntu machine, the results: Firefox linux: 68 Firefox wine: 104
Back in the days of Pentium 200mhz, I was running Slackware whose compile target was i386. Many of the applications could be speeded up by recompiling just a few of the most used libraries with optimizations for my AMD K6. Obviously the kernel was custom rolled, and at the time there was a different version of gcc available, called pgcc which generated even faster code for pentium computers.
I remember looking through the list of libraries my most used applications were linked with, and went through them re-compiling them. This was before Gentoo ever existed. I broke my system trying to install an optimized version of libc5.
Obviously, as mentioned in the article, almost no-one compiles their own systems these days, we just have to rely on the distributions to take care of that for us.
1. The PROJECT can be cheap
2. The PROJECT can be fast
#3 applies to the finished project, and generally refers to achieving the right balance of performance and reliability, but #1 and #2 do not.
Can you really claim an exception for FOSS?
Given that FOSS always gets you #1, it should be concluded that you can only get #1 and #2 or #1 and #3.
Numbers 1,2,3 are from the developer's point of view. If the developer sees only 2&3 (ie, someone - maybe even the dev - pays for the development), then end user sees all 1,2,3.
I rebooted today after 42 days of uptime, and that includes 42 days of uptime of FF3 under Mandriva 2007.1. No crashes, not a one.
One thing I'd immediately observe, are you using a compositing window manager? Turn that crap off, nothing destabilizes X apps more than compiz and friends.
Other than that, I don't know, but your experience is totally opposite mine. Not only is FF3 adequately fast, it is perfectly stable. I can't say if it would be faster in windows or not because I don't HAVE windows and don't need it, but it is a perfectly fine browser as is.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
It's actually: "Attractive, single, sane - pick 2."
(appearance, marital status, personality)
But their system seemed to be a decent one with well enough memory to run Firefox without any swapping to disk. Unless the benchmarks are doing things that cause Firefox to use an inordinate amount of memory, I don't see how this PGO would make a difference. For instance on a machine with no writeable disk or swap, it shouldn't make a difference at all.
...
I noticed this even on Gentoo where everything I run is compiled from source code. For me Firefox hangs badly when hitting Google sites such as gmail and groups. Why? when under Windows (XP/Vista32/64) it doesn't and I wish the firefox devs would get off their asses to fix the problem especially if all it takes is the creation of a single GPO profile to do it.
Mod me up/Mod me down: I wont frown as I've no crown
Sanity is the most important of the three, and the rarest.
...
... The "Unix way", OTOH, relies on the safer and more resilient "do one thing well" multiple library concept, so while it may be easier to bugfix, the resulting program (Firefox in this case) spends an inordinate amount of time in context switches.
You don't context-switch when you are doing library calls.
You do, however, loose some performance when running position independent shared code (-PIC). What you loose here, you probably gain in reduced cache-trashing. DLLs in windows also have this performance problem, but seldom have the cache gain, as libraries isn't shared as often between applications.
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.
Thank you! I was scratching my head over this one. I think someone smacked the grand parent with a lead filled whiffle ball bat. A context switch is, generally, when you go from kernel mode to user mode. Windows and Linux both have rather beefy kernels that implement a lot of functionality (and force context switches). And even with a micro kernel where you theoretically have a small amount of kernel code you still end up forcing context switches indirectly a lot because some things just HAVE to be done by the kernel to maintain OS and security integrity. You could crunch numbers, render JavaScript and HTML all day and never hit a syscall after you have loaded things into memory and done your business with your system calls. I call bunk. In fact I just actually read the article and the things they were testing in the JS engine are almost purely user mode code. I can't see the test items invoking system calls much at all. I think there is a compiler optimization issue at the heart of this thing and the scope of the test was to narrow to ferret it out. I would want to see lots of different compilers and compile options in a rather comprehensive comparison from one system to the next. This was a narrow "gotcha" kinda test.
export MOZ_DISABLE_PANGO=1
From womens' point of view, I'd imagine the choices are sort of a mix of the two: "Cheap, Attractive, Fast, pick two."
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.
Sunspider (total only - lower is better)
win 32 bit = 2936.4ms, win 64 bit = 3602.0ms, linux 64 bit = 3383.6ms
V8 (total only - higher is better)
win 32 bit = 201, win 64 bit = 156, linux 64 bit = 157
Dromaeo (total only - higher is better)
win 32 bit = 43.41runs/s, win 64 bit = 35.78runs/s, linux 64 bit = 30.69runs/s
So while the totals are slightly misleading, FF under linux beats FF under windows in 2 out of 3 tests.
(if you compare non optimised versions rather than cherry picking)
Dual Xeon Quad 2.33GHz, 12 GB RAM, 250 GB drives
Fedora 9 x86-64
Win XP pro 64
All copies of FF from Mozilla, not distro.
FTW
GTK+ has dog-slow performance. This is common knowledge. The developers are more interested in wiz-bang features than quality high-performance software.
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
Double edge sword here - yeah, reliability is a good thing, but Linux (still) has a large base of users who run it on ancient hardware - so, speed matters.
I think the problem here is that since Windows based Firefox has a bazillion users, it has been optimized a bit better than the Linux version, enough so that it's faster on Wine. If the Linux Firefox build team is sufficiently embarrassed by this, they'll soon fix it.
Also depends on your CPU...
AMD cpus tend to perform considerably faster in 64bit mode while Intel are generally only slightly quicker... Also, gcc generates better code for AMD while Intel concentrate more on their own compiler.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
And disturbingly, many distros are still compiled for i386, even those that won't actually run on such systems...
Not sure about windows, but i imagine it's compiled for i686 at the least...
OSX is compiled for core1 (x86 with sse3).
I think the desktop linux distros should target a p3 as a bare minimum, and leave anything below that to specialized cut down distributions. I doubt many people are running XP on lesser systems, and noone will be running Vista on a P3 let alone anything slower.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Erm... glibc?
Anyways, how does having a "monolithic, doitall architecture" mean that "many functions do not need to force a context switch"? Somehow having a more 'monolithic' API means less of the function calls lead to system calls? That is ridiculous, especially considering that Windows has significantly more of the operating system in the kernel (the GUI subsystem), meaning all kinds of basic functions for handling GUI applications force a context switch where none would be needed in Linux.
Most of all, OP is speaking nonsense about why Wine+Win32 Firefox is faster. As if there is less intrinsic overhead due to the API design of Win32 using Wine means FireFox+Wine should be faster. That is idiotic when you realize that Wine's Win32 implementations ultimately have to perform the same context switches to achieve the same results.
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.
This reminds me of the setup I use with the laptop the company issued me. It's a nice Dell laptop, except that it came with XP, and for a variety of reasons I can't blow XP away and put a Real OS (tm) on it. I have an older Toshiba laptop that runs Linux (and only Linux), and it's my network tool: plug it in and it talks to things, every time. It's saved my butt (and the company's) on many occasions.
My solution: Linux (Slackware, naturally :-)
under Virtual PC. Except that Linux on a virtual
system works better than XP does on
the real hardware.
The networking may actually be faster, and
all the usual network stuff, including NFS and X, works
just fine.
There's got to be a lesson there somewhere, but I can't quite figure out what it is.
...laura
which is faster, Firefox on Wine, or Firefox on Windows... both on identical hardware...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Remember that we use browsers for a LOT these days. A small slowdown on an hourly basis multiplied by the number of workers using it turns into real scratch.
It is in our best interest to make sure the most used software is as fast as it possibly can be.
The stuff that's used just now and then, we shouldn't care so much about.
Also, Wine would need more context switches than either Linux or Windows. If you are running a single process you usually switch between at most two contexts, your userspace process and the kernel. However since the functionality of the Linux kernel isn't a perfect match for the Windows kernel, Wine needs an additional context/process, the wineserver, to provide this functionality. So context switches wouldn't benefit wine over plain Linux.
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.
step out of the 90s buddy, todays GNU/Linux is not your hippy geeks OS any more. I've got 70 something year old grandmothers using it, teens, and in-betweens. And when there is something they must have and is only available in a Windows app, virtual machines solve that issue.
it does amaze me how many times I try to run something across a self-described Windows geeks and they have no idea what I'm talking about. It's as if technology only emanates from Microsoft and as if the "We are a Microsoft shop" is a badge of ignorance or something. Get out and try something new every now and then. You will be surprised at what new things are turning up outside your fracturing Windows. IMO.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
I think OP was talking about library functions which make system calls (context switch from usermode to kernelmode). Although I wouldn't be surprised if he was talking about context switches from pineapplemode to bananamode, given how much everything else he says makes sense.
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.
Well, that's a no brainer. Pick Attractive and Intelligent; the crazy ones are always more fun.
And disturbingly, many distros are still compiled for i386, even those that won't actually run on such systems...
Are you sure? debian compile for 486 and current debian will still just about run on a 486. I think ubuntu and fedora compile for 686 but i'm not positive.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Except that in software you want all three, only option 1 and 3 are needed in a woman. Option 2 just makes it more difficult to get laid.
I don't believe I've met a sane woman yet. But I'd take attractive and sane if I ever found that combination ;)
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.
On my HP Compaq 8510w laptop with 3gb ram, I got totally different results. Firefox 3.0.6 was used in both Windows & Linux. At least I am happy Linux user, even I still have dual boot on my machine.
Linux ubuntu-810 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux
RESULTS (means and 95% confidence intervals)
Total: 4006.6ms +/- 1.3%
3d: 471.8ms +/- 9.4%
cube: 168.4ms +/- 19.6%
morph: 176.4ms +/- 17.7%
raytrace: 127.0ms +/- 14.5%
access: 573.8ms +/- 5.5%
binary-trees: 85.0ms +/- 29.3%
fannkuch: 197.8ms +/- 16.5%
nbody: 188.0ms +/- 6.8%
nsieve: 103.0ms +/- 19.7%
bitops: 452.4ms +/- 11.3%
3bit-bits-in-byte: 87.6ms +/- 43.8%
bits-in-byte: 98.4ms +/- 32.6%
bitwise-and: 125.4ms +/- 12.6%
nsieve-bits: 141.0ms +/- 20.7%
controlflow: 61.8ms +/- 45.3%
recursive: 61.8ms +/- 45.3%
crypto: 256.0ms +/- 26.4%
aes: 93.0ms +/- 18.3%
md5: 81.0ms +/- 50.7%
sha1: 82.0ms +/- 42.8%
date: 415.0ms +/- 15.3%
format-tofte: 243.6ms +/- 11.5%
format-xparb: 171.4ms +/- 23.0%
math: 467.8ms +/- 11.9%
cordic: 165.2ms +/- 22.5%
partial-sums: 197.0ms +/- 9.8%
spectral-norm: 105.6ms +/- 33.2%
regexp: 306.4ms +/- 11.0%
dna: 306.4ms +/- 11.0%
string: 1001.6ms +/- 4.3%
base64: 142.8ms +/- 4.9%
fasta: 228.0ms +/- 16.3%
tagcloud: 181.6ms +/- 16.6%
unpack-code: 325.8ms +/- 3.4%
validate-input: 123.4ms +/- 20.8%
Windows XP SP3
RESULTS (means and 95% confidence intervals)
Total: 4917.4ms +/- 4.3%
3d: 564.2ms +/- 13.9%
cube: 209.2ms +/- 6.0%
morph: 164.4ms +/- 37.6%
raytrace: 190.6ms +/- 6.7%
access: 779.4ms +/- 9.2%
binary-trees: 116.2ms +/- 5.4%
fannkuch: 328.4ms +/- 4.2%
nbody: 189.4ms +/- 28.5%
nsieve: 145.4ms +/- 37.9%
bitops: 650.4ms +/- 32.3%
3bit-bits-in-byte: 155.0ms +/- 43.7%
bits-in-byte: 174.8ms +/- 29.5%
bitwise-and: 131.0ms +/- 44.7%
nsieve-bits: 189.6ms +/- 29.4%
controlflow: 94.4ms +/- 40.8%
recursive: 94.4ms +/- 40.8%
crypto: 409.2ms +/- 31.0%
I'll bet the biggest difference is caused by the choice of compilers. The windows compiler has been optimized for x86, while gcc has to optimize for numerous targets.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
Javascript is slower on the Linux build.
Well, that makes me even happier that I run No-Script due to security paranoia.
Whether or not it's worth the effort to "fix" the Linux build is another matter.
A Pirate and a Puritan look the same on a balance sheet.
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.
What does Wine use to emulate GDI and USER? I'd be willing to bet that their implementation of widgets is faster than whatever native widget kit that Firefox uses...
This is my sig.
Opera is even worse. The results were right there in the original article.
Although I don't think they said which platform they tested on.
That said, I would never have guess that Opera is supposed to be a slower browser.
A Pirate and a Puritan look the same on a balance sheet.
Can you compile Firefox & Ubuntu yourself and get better performance, then?
I'm not sure what the secret to success is, but the secret to failure lies in trying to please everyone -Bill Cosby
Don't you think 2 is being a little overly optimistic?
The tyrant will always find a pretext for his tyranny - Aesop
I always build gentoo with --dwarf-min-level 100
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
No shock here.
Try this one. The Linux build of Prey preforms the same as the Windows build running under Wine. Prey preforms best on Windows XP.
If I were to hazard a guess the differences have mostly to do with drivers. Windows graphics drivers are often optimized for the more popular 3D engines used by games. Linux drivers for the most part aren't.
Here are a few quick and dirty benchmark runs of Prey on my admittedly old and crappy hardware. All settings are turned up to their maximum with the exception of antialiasing which is turned off in all runs (Not supported by Wine yet).
Linux build:
3545 frames rendered in 100.8 seconds = 35.2 fps
3545 frames rendered in 100.7 seconds = 35.2 fps
3545 frames rendered in 101.0 seconds = 35.1 fps
Windows build under Wine:
3545 frames rendered in 100.5 seconds = 35.3 fps
3545 frames rendered in 100.6 seconds = 35.2 fps
3545 frames rendered in 100.5 seconds = 35.3 fps
Windows build under Windows XP:
I don't have them. XP died a while back and I haven't got around to reinstalling (Take whatever you want from that). I do however know that when I tested them last year sometime that XP had a significant lead over both ways of running Prey on Linux.
What does all this have to do with Firefox? Nothing really. It has more to do with Wine once again not being a limiting factor in performance vs a "native" application.
I want this account deleted.
I dated a girl in Korea who turned out to be completely fucking nuts, to the point where she almost got me beaten up. We split up. Later on I talked to one of her (many) exs who told me he used to hide things in his apartment which she could use to hurt him, back when they were dating. Knives, even pots and pans and some weights he had.
Happy days.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Hio. I'm running a 1.5.3 xorg server under KDE 4.2. When I disable Desktop Effects, FF 3.0.6 is very snappy, even with 100, 150 tabs open (spread over three windows). When I enable Desktop Effects, new windows take a little while (.5->1 second) to draw. Tab switching is instantaneous, though.
Underlying hardware:
Core Duo L2400
4GB DDR2 RAM
Intel Mobile 945GM Express
That's on Linux. On Windows Opera is faster than Firefox
http://www.extremetech.com/article2/0,2845,2335250,00.asp
Firefox 3.04 = 222
IE7 = 44
Google Chrome = 2936
Opera = 299
Safari = 229
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Hm, it seems likely that human consciousness is a derived form of schizophrenia so I'd go with Attractive and Intelligent and take it on faith that Insane will be part of the base package.
As for men. I'd say it's about the same. I've not been with one recently so YMMV but in general most of them seem to want a hooker not a date anyway so it probably doesn't really matter much.
Actually they did both. Maybe you should go read the article. :)
... the Wine widget set is faster than the GNOME widget set. News at 11.
In addition to the differences in optimization already mentioned, it also makes a big difference whether you run applications isolated (which is what running under WINE is) or as part of a desktop; when running as part of a (Linux) desktop, there's a lot of other code a browser talks to and waits for.
No, he's right. I still use Linux to distribute my TRON fanzines and personal Dungeons and Dragons web-sites.
websight!
I don't know why, but even under complete OS virtualization FireFox is faster in Windows under VMWare or VirtualBox than it is natively on the same box.
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.
The OP was talking plain nonsense. He indeed started to say something like what you imply, but then he slipped in this gem:
it has the speed edge due to the fact that many functions don't need to force a context switch.
Obviously, having a large single library vs a number of smaller ones doesn't make any difference in the number of context switches.
And while we are at it, let us not forget to mention Qt.
sig intentionally left blank
what's the point? How do you think wine performs the system calls ? Oh yeah... The unix way, so using all the layers... While your explaination may explain why windows could be faster than linux in some cases, it does not explain why wine is faster than using "native" libraries. (while wine is in a sense as native as gtk)
Also hide all knives and scissors.
You'd be surprised at how easy it is to disembowel a human with a ballpoint pen.
(you can guess which two of the three categories mentioned above I fall in)
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.
A system call is not a full context switch overhead. You keep the same page tables. This was the point of moving some UI into the kernel, to keep shared code and data and not have a context switch per call. It's more expensive than a pure user library call, though.
On the other hand, most libraries on Linux are loaded in the address space. Heck, Mozilla used XPCOM and even started going away from that because the vtable usage and other aspects (all in-process) seemed too slow. The only relevant "library" doing things in the UNIXy way is the X server, I guess.
Library calls cause context switches?
I thought the whole deal with libraries is that they get mapped into the local process space. I certainly don't have a 'libc', 'gtk,' or 'libffmpeg' process running, yet I'm running processes that use that library. Where is the context switching to, exactly?
If you had meant system calls, I don't think there are many (any?) things that are implemented as system calls that could have been implemented as cheap library calls, in other OS, unless I'm missing something.
-bugg
Yeah, I was going to mention the same thing about system calls requiring a context switch but there are other types of context switches as well.
Actually, in the broadest sense, a context switch can be considered any significant change made to the CPU Machine State.
For example, Intel originally implemented MMX as a CPU context switch that turned off the ability to do floating point (since MMX shared FP registers) and had to be restored via EMMS (Exit MMX MAchine State). When exiting MMX mode, the Pentium had to do some very slow heavy duty internal work that made EMMS take a long time and this significantly hampered MMX programs. Newer CPU's still use the EMMS instruction but shadow registers so they do not actually perform an internal context switch. Also, SSE avoided this context switch by introducing new registers rather than reusing old registers.
I've got 70 something year old grandmothers using it, teens, and in-betweens.
Ha ha ha. That's hilarious. Even a little bit kinky. You nearly covered all the stereotypes.
it does amaze me how many times I try to run something across a self-described Windows geeks and they have no idea what I'm talking about.
That's because they don't live in your dreamworld where the Linux geeks have taken over.
"When you see a unixer brainwashed beyond saving, kick him out of the door." - Xah Lee
That IE7 number is really quite interesting.
I got a number like that out of Konqueror.
Although I am still not sure how much difference it makes in the end.
A Pirate and a Puritan look the same on a balance sheet.
Because you haven't been looking?
I think we've pushed this "anyone can grow up to be president" thing too far.
This will go unnoticed, but what the heck.
I was able to greatly improve the reactivity of both firefox and opera by moving the cache onto tmpfs systems. Actually, I moved full rc directories (.opera and .mozilla) and just rsync them from time to time.
Caveat - I have a sort of an improvised SSD (using a CF card and an adapter), which is quite slow esp. for concurrent writes. But maybe this is why I noticed it at all. I don't understand why the browsers insist on writing tons of data onto the hard drive when there's plenty of perfectly good memory lying around.
Cheers,
j.
Hopefully your glibc is washing the dishes in the emacs kitchen sink.
I am becoming gerund, destroyer of verbs.
I don't know enough about WINE to know, what's the heap manager in WINE? Would it fall through to glibc's malloc, which is known to be suboptimal or something else?
I see, keep em stupid and keep em paying. And MS Excel makes a great source control tool. Yes, I've seen a business using it for this. Ignorance is bliss seems to be a way of life for many a Windows shop. And it is not about GNU/Linux, it's about knowing there are tools out there for both Windows and/or GNU/Linux which do the task designed for quite well.
It's not about "The Year of the Linux Desktop" it is about another year of "Open Source Illiterate Windows IT people". IMO.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
I don't understand what this continual battle over browser speed is all about. Surely 99% of the delay on any page is fetching the data off the internet? Who cares if 8ms or 10ms of the 500ms delay is due to browser speed. Is this really relevant to the normal user? Is this just universities on the internet backbone trying to measure tiny delays in some browser pissing contest?
Unicorn Setu. "Eagles may soar, but weasels don't get sucked into jet engines".
Actually insane + intelligent is damn frightening. Even worse, b/c now she's hot too by the formula...
Actually, I think the better one is "Physically Fit, Enjoys Sex, Sane".
I think i386 became difficult to support a few years ago now, needing a few special tweaks to some things and even then, it was admitted there was becoming unlikely that anyone would still be wanting to use a modern distribution on them. There are plenty of old distributions available that can still be downloaded if anyone should so wish to play around with an i386... but yeah, i486 support shouldn't be on the agenda anymore for a modern desktop orientated distribution.
There always be some being used as routers, or small home servers though, even as X terminals. Maybe someone is even reading this on one.
"Cheap" doesn't refer to the cost to end-users, it refers to developer time/salaries/whatever. Many open source projects are funded - Mozilla, for example, funds Firefox development, Google funds development of several projects, etc etc.
So, theoretically, we've chosen "fast" and "reliable".
I'd really rather go with sane & attractive. There's nothing wrong with a sweet but ditzy woman, especially if you can help supply brainpower as needed.
And how much it hurts.
--
"I'm going to carve out his heart with a spoon!"
"Why a spoon?"
"Because it will hurt more, you twit!"
Depends on desire. If you just want a one night stand, you don't need intelligent, If you want long term you only get #2 (in a physical sense) for a while (baring plastic surgery), so you might as well go for 1 and 3 to start with (after you've had some of the others and understand the problems with not having 1 and 3).
It can be all three if you make your program small enough, hence all the tiny little programs you get in your common unix, that all do just one thing and one thing well.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
There's nothing like making a generalized quality statement (cheap, fast, reliable) an absolute rule, is there?
Using your line of reasoning, because Windows is expensive, it should also be both fast and reliable - and that, relatively speaking, Linux (and the user software which runs on top of it to make it a comparable environment to Windows) it can not possibly be both reliable and fast. There are dozens, if not hundreds, of examples of this to the contrary.
With open source (unlike closed source) a developer can 'afford' to spend a month doing optimizations, because there is no set release deadline or a profit to be made in order to meet stock shareholder needs. This is unlike the closed source model, and does indeed mean that open source can be "cheap" (in terms of time restraints to release, which is the only real metric in determining the cost of software) while still having both other qualities.
Of course, it's all relative. You can't assume that developers, or money, or your relative metrics for determining quality, or anything else is an unlimited quantity. The point here is that a big limiting factor on both speed and robustness is development time (often represented in terms of money, or numbers of developers) - and open source has no concrete limitation on these things vs. the closed model.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
The text rendering would be a good possibility. I've noticed substantial speed decreases when turning up AA; I don't know how, or if Wine does it, but my recollection is that it doesn't (by default).
If I recall correctly, there was a kernel module for WINE a while back to allow direct system calls by win32 applications - or something to that effect. Whatever happened to that project? Could that not be used to further speed things up, if it were still around?
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
LOL, who cares about worldy possessions? I'd rather still have all my manly bits intact when I trade her in.
It's amazing how my comment from at least 4 hours ago isn't visible at +2 minimum. On 64 bit, linux beats windows 2 to 1. ...
Assholes. And my remaining 2 mod points (2 days old) have disappeared
x86 CPUs have a horrid amount of data to page-out on a context switch - and to boot, some of the data is not byte-aligned if I recall correctly. The amount of work necessary to perform a to-memory context switch dwarfs the internal register renaming/flushing of a CPU mode transition.
Further, I've heard people incorrectly post that switching to the OS constitutes a context-switch. This isn't true in any CPU that I'm aware of.. A user-space -> kernel-space switch changes some CPU registers - opens up the address space/protected instructions, etc. But the x86 segment registers are unaffected. The main registers including the stack pointers are unaffected.
The kernel has to explicitly trigger a CPU -> memory, memory -> CPU dump/restore when initiating a context switch. Otherwise the kernel has little overhead more than a function call (saving local registers that it's going to modify, etc).
Please someone correct me if I'm wrong about the performance implications, and certainly different CPUs have different volumes of data to passivate/activate obviously, but just about any CPU since the early 90's is very kernel-switch performance sensitive.
Consider that I typically see only 3000 ctx-switch /sec in linux, but I can call 800k 'time' OS calls / sec in Java of all things.
-Michael
for the heck of it I ran the first benchmark listed, Sunspider and got a time of 2475.4 vs their run of 2478.6 - like them I am running XP SP3. But I did this on an ancient AMD Sempron 3000+, not a quad-core Intel Core 2 running at 2.66GHz, with 4GB of RAM. Oh.. and I was playing tunes using Billy.
So either the benchmark is bogus or.. you all have something to look forward to as it seems Firefox 3.1b3pre (Shiretoko) kicks some ass!
"Would it fall through to glibc's malloc, which is known to be suboptimal. . ."
Is anyone working on optimizing the glibc malloc()? I'm actually a little bit surprised - malloc has been in glibc, I would assume, since the very first versions of glibc, which would have been what, like 15 or 20 years ago?. I would have thought it would have been optimized a very long time ago, and continually improved over time. . .
gcc does have whole program optimization, which is a different thing from LTO.
Stuff all the source for a program into one dirty great file.... and compile with gcc -fwhole-program and the compiler can then make such happy optimizations as if a func is use only once anywhere, then it can always be inlined.
LTO means compile all your .c's into .o's and then at link time do an additional set of optimizations.
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.
I can see that, looking at the problem today. Given the age of those functions, I don't think it's necessarily a bad thing. When the whole locale and i18n system was added, there was nothing else to do the job and something low level like the C library probably seemed the natural place.
Today, now that the problem has been redefined, it is woefully inadequate. As a whole, the community has decided, "why do it half-assed?" and has moved towards representing all locales with Unicode and specific libraries like ICU.
As a stepping stone in i18n development, having these functions in the C library was a very good thing. I think what should happen now is that they should be marked as obsolete to discourage people from using them for new projects. Hopefully that will move more people towards newer solutions like ICU.
Elrond, Duke of URL
"This is the most fun I've had without being drenched in the blood of my enemies!"-Sam&Max
Truetype fonts generally contain some information for hinting purposes, i.e. they tell the font renderer (Freetype) the best way to render the character at small pixel sizes. The "bytecode interpreter" that makes use of such information is available in Freetype, but the method is patented (IIRC by Apple) in the U.S., so most distributions turn it off by default. Without such information, Freetype has to decide the small-size rendering method all by itself ("autohinting"), and some people may find the result blurry.
If you are not in the U.S. or don't care for software patents, there are plenty of information on the Internet about how to turn on the bytecode interpreter in Freetype. For example, in Fedora you can simply download Freetype's source RPM and recompile it with rpmbuild using some --with options.
As mentioned on the nedmalloc page, glibc uses ptmalloc which (on average) isn't that slow.
glibc 2.3's malloc certainly isn't optimal for every possible workload but it doesn't tend to be incredibly poor for any workload either. For Firefox on Linux switching to jemalloc didn't cause as big an improvement as it did on Windows.
Wow, when's the last time you used Linux?
I am not devoid of humor.
It blows that minor architecture differences need to create another project. Anybody know if Apple's got a patent on their CAFE BABE format? Seems like linux could pretty easily learn to exec a 'fat binary'. (maybe it already does?)
A smart, small, Mozilla updater could fetch the appropriate binary code from the 'net on first launch.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
On the test they have two OS's.
Windows NT and Linux (kernel)
Test had few different versions from Mozilla Firefox.
One what is compiled for Windows NT and other what was compiled for Linux.
Then on the test, intresting part is not that Windows is faster (well... it is, but not after other tests) but that Wine runs Firefox faster.
If Linux + Firefox is slower than Linux + Wine + Firefox... something is wrong between Internet Browser (Firefox) and the operating system (Linux kernel), because when using Wine, the typical system libraries and applications gets passed.
So, the real question actually is, why software between operating system (Linux kernel) and Internet Browser (Mozilla Firefox) slows down the Internet Browser so damn much?
We all know that Wine is not emulator but "swapper". And these tests proofs again that Wine can run software almost as fast as native versions on Windows systems.
As someones has already questioned speed of - as example - the GNU project glibc, the system library. Is it possible, that GNU software is actually so bloated, that Linux OS (kernel) can not run applications as fast it could? And you can swap any other software part to between Linux and Firefox, when thinkin where the problem might be.
At least what was proofed, was that Linux OS (kernel) can run Internet Browser as fast than on Windows platform, you just need Wine for that.
If Linux OS would be slower, then the Wine version would be on same level too.
So what can be tought from that? Simple, problems exist all over other places than Linux OS (kernel). You just need to find it and fix it... It can be even on the Mozilla's fault, on the Firefox version, if swapping all software between Linux OS and the Mozilla Firefox does not bring more speed. If more speed is gained, then about the gained speed, problem might be on elsewhere than Mozilla Firefox and Linux OS (kernel).
So, as Linux user, I dont blame it to be slow... I blame other software top of the operating system to being slow...
No, but after my wife read that comment I might as well be. :wq!
Just disrupt the deflector shield with a tachyon burst.
If Wine can do that, then so can ANY OTHER APPLICATION CODE! My point was just that if Wine hasn't got a problem then other code won't either IF it is written as well as Wine is. And if it is NOT written as well as Wine is, then why is it the problem of X?
Granted that the best solution is for X to be improved so it is easier for application writers to get good performance. So I don't see it as a black and white thing. Still, mozilla is a LARGE project with lots of resources, certainly at least as big as Wine. They should be able to make their code run fast.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
The first thing is I just don't see the whole 'firefox is so slow on Linux' thing. Maybe its just me, I don't use windows, but on my crufty old machine ff3 seems pretty quick. Even if it is rendering 4x slower than on windows I am just not sure what people are bitching about. Of course it could be faster, but calling it slow is a real overstatement IMHO. If I hit CTRL-+ any given page rerenders in 1-2 seconds, tops.
And secondly, if Render is slow and it doesn't seem to be getting faster as rapidly as everyone wants, then why aren't more resources being directed to that? xorg's progress seems glacial. If people already HAVE faster code, then get it in there. Between Intel, RH, Novel, IBM, Google, etc the resources needed to do that would appear to me to be trivial. 5 or 6 guys could be added to that effort without anyone even breaking a sweat. And if it is just all political, then screw the politics. Running code always trumps politics. If whoever is(n't) making progress on it now doesn't like that, to friggin bad for them, this stuff just has to get done and if they cannot deliver then they need to be sidelined.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Neither of those developers are well-paid. Nor are there anywhere near enough developers on either type of projects.
So sorry, yes it helps what they do, no it does not constitute the equivalent of microsoft's boss telling the hiring manager "money is no object !".
It's helpful to know that PGO is the reason the windows version works faster but it raises more questions than it answers:
* What *is* Profile Guided Optimisation (I might know, but for one person like me there are hundreds of others who don't)
* What build would happen to be newer than the CURRENT RELEASE for Fedora? A quick google doesn't doesn't point to an obvious location of a "firefox-pgo" or similar package. Casual users would struggle to find a PGO-built FF package as they would not be standard with their distro, or would be beta/pre-releases of FF 3.1.
* The test was only with Fedora--do any other Linux OSes package FF with PGO enabled as standard?
* How do the 64-bit editions compare? This was a 32-bit only test, and reader's posts aren't very specific. It looks like the only version of FF 3.0.x that IS PGO-built and widely distributed is the 32-bit version, because 64-bit Windows FF is even slower than the Linux version to Javascript from what little is posted.