Re: Firefox 3 runs faster on Linux+Wine than on Linux -- comparative to running on Windows
Hi,
For those not monitoring slashdot [1], there is an article [2] that is comparing the Google V8 benchmark on Windows and Linux versions of Firefox 3.
The result of this is that the Windows and Wine runs are pretty close (241 vs 227) when compared to the Linux run (181) and Opera (155).
I wonder what the results are like on Firefox 3.1 with tracemonkey enabled on Windows, Wine and Linux.
[1] http://tech.slashdot.org/article.pl?sid=09/02/13/0058251 [2] http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-f...
- Reece
One thing that interested me... one person wrote that Linux/Firefox compiled with msvc was faster than gcc, because msvc is better at optimization. Has anyone tried compiling wine with msvc? Susan
2009/2/13 Susan Cragin <susancragin(a)earthlink.net>:
Hi,
For those not monitoring slashdot [1], there is an article [2] that is comparing the Google V8 benchmark on Windows and Linux versions of Firefox 3.
The result of this is that the Windows and Wine runs are pretty close (241 vs 227) when compared to the Linux run (181) and Opera (155).
I wonder what the results are like on Firefox 3.1 with tracemonkey enabled on Windows, Wine and Linux.
[1] http://tech.slashdot.org/article.pl?sid=09/02/13/0058251 [2] http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-f...
- Reece
One thing that interested me... one person wrote that Linux/Firefox compiled with msvc was faster than gcc, because msvc is better at optimization. Has anyone tried compiling wine with msvc?
Hi Susan, WARNING: This is fairly technical, so apologies if this goes over your head! The reason that Firefox javascript is faster when built with msvc (according to the slashdot comments -- of which I am only part of the way through) is because they use Profile Guided Optimization (PGO). [sidebar] This means that the code is compiled with special information that records what methods and variables are being accessed. This program is then run under normal usage patterns to gather profiling data. The data collected here shows what the most common methods and variables are. The data is then fed into the linker along with the original program. The linker can then use this information to organise the code so that it performs better. That is, it uses the profile data to hint at where to optimise the program (hence the name). [/sidebar] The commenters also point out that GCC (which is used to build Wine) also has PGO capabilities. In order to do this, you need to record the profile information for a given build. IIUC, you need to do this manually for each build to gather the data for that build. NOTE: I am not an expert on this, as I have only read bits and pieces on the subject and not actually tried it out. As for optimisation in general, I am not sure on how gcc compares with msvc in terms of overall performance. Both allow you to optimise for speed, size or balance the two. They both also allow you to do other independent optimisations (e.g. target newer CPUs or enable enhanced CPU instruction calls). Here, it is a matter of trying out different combinations of options to get better results. NOTE: The distribution versions of Firefox (and Wine) will be built to support older hardware and thus won't benefit from taking advantage of the newer hardware (Gentoo is your friend here :D). For building Wine with msvc, I have had limited success building the Wine components and (more specifically) tests with it, and have contributed patches to help build more of them with msvc. In addition to this, you will only be able to do this with a portion of the dlls and components -- the ones that do not make use of any Linux components. Adding PGO support in Wine (which would have to be using gcc, since the Wine program loader and other core components are likely to benefit -- possibly the GDI and DirectX/WineD3D stuff as well). It would be interesting to run a profiler on Wine with profile data for different programs and games to see where the slow areas are. The real benefit in terms of speed for Wine would be not to use msvc, but to hand-optimise specific algorithms to take advantage of faster assembly instructions. This would likely be for the cryptographic algorithms (SHA1, MD5, etc), DirectX mathematic functions, GDI/DIB code and pixel format transformations in DirectX/GDI. NOTE: These should be done (if done at all) using the data from the profile runs to see where the slow areas are. I apologise for rambling, but hopefully this makes things clearer. - Reece
On Friday 13 February 2009 18:54:23 Reece Dunn wrote:
The real benefit in terms of speed for Wine would be not to use msvc, but to hand-optimise specific algorithms to take advantage of faster assembly instructions. This would likely be for the cryptographic algorithms (SHA1, MD5, etc),
I doubt that'll be worth it. the crypto routines shouldn't be called that often, as opposed to say.. the DX math functions or the like. Of course as you said, this would only matter if any of these turn out to be performance hogs anyway. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
participants (3)
-
Kai Blin -
Reece Dunn -
Susan Cragin