Articles about topics ranging from technology and software to scientific research. Occasional book reviews. Topics of general interest such as lifestyle, and nutrition. Exploration of blogs and the technical side of blogging.

Nov 28, 2009

Firefox in Parallel - A Pre-Release Version

If you run Firefox and look at the system resources, you will see the use of one processor go up until 100 percent when you load several pages at once. Most personal computers today have at least two processors, if not more, and not using them is a waste of your time. Instead of loading multiple pages one after the other as it is doing now, it might as well load them at the same time using different processors. While Chrome and Internet Explorer 8 support multi-threading (running on different processors), Firefox still lacks it in the official version. Support for multiple processors in Firefox is in the works and I tested a pre-release version of Firefox that loads different tabs in parallel. In this post I show some of the results I found.

The image illustrates performance increases of firefox version 3.5 versus versions 3 and 1.5. The TraceMonkey JavaScript engine in 3.5 makes javascript execute twice as fast as in Firefox 3 and 10 times faster than in Firefox 2. Image credit: Firefox web browser - under the hood.

While the official version of Firefox still runs on a single processor currently people at Mozilla foundation, which is responsible for the development of Firefox, are working to implement multicore support for Firefox. The project, called Electrolysis, is very ambitious and will bring a lot of value to Firefox users including security and speed. The first stage of development, what they call the sprint, is finished and developers around Benjamin Smedberg are now busy ironing out bugs. You can already download and build (compile) an early version for Linux or Windows and this is what I did.

This post is structured into three parts. First I report what I found with this pre-release version. The other parts are more technical. In the second part I report a detailed speed test results comparing it to another version of Firefox and Google Chrome. In the third part I'll show how to compile this version if you want to run it on your computer. You might want to skip the last two parts if you are not interested in technical details and don't feel up to the task of compiling Firefox yourself.

I found out that Firefox pre-releases are titled minefield not only to deter the feeble. When I tried to load different pages at once, minefield crashed on me and a second attempt also failed. After restarting Firefox Shiretoko (version 3.5.6pre), the version I had installed previously, I noticed that all my preferences, extensions, and bookmarks had disappeared. Fortunately I use the XMarks add-on to synchronize my bookmarks, so quickly recovered my bookmarks. It took me about 10 minutes to re-install by add-ons and I might have to write my passwords out for some time, that's all I lost.

Well... what did I learn? Firefox is going to improve a lot in speed in upcoming versions. Chrome is now about 3 times faster than Firefox in JavaScript performance. What else? Don't run bleeding-edge pre-release versions. They may not work properly, can crash on you, and might delete your browser preferences.

Performance Test

Here come the details of the performance tests all performed on the same machine, my laptop.

-

Firefox 3.5.6pre

Electrolysis 3.7a1

Chrome 4.0.221.1

Total

4554.4ms +/- 2.0 %

1849.2ms +/- 4.5 %

1211.6ms +/- 3.9

3d

509.2ms +/- 4.3 %

268.0ms +/- 6.9 %

187.6ms +/- 16.1

cube

173.6ms +/- 9.9 %

97.6ms +/- 12.4 %

66.6ms +/- 25.2

morph

171.4ms +/- 9.2 %

56.8ms +/- 16.4 %

63.2ms +/- 26.0

raytrace

164.2ms +/- 6.3 %

113.6ms +/- 13.9 %

57.8ms +/- 16.1

access

676.2ms +/- 6.1 %

226.0ms +/- 6.5 %

99.2ms +/- 2.6

binary-trees

79.2ms +/- 12.2 %

53.0ms +/- 19.2 %

6.2ms +/- 9.0

fannkuch

262.0ms +/- 4.4 %

102.2ms +/- 16.1 %

36.4ms +/- 1.9

nbody

244.2ms +/- 11.1 %

42.6ms +/- 7.9 %

46.2ms +/- 6.1

nsieve

90.8ms +/- 13.5 %

28.2ms +/- 10.5 %

10.4ms +/- 6.1

bitops

535.2ms +/- 4.1 %

76.0ms +/- 5.8 %

95.4ms +/- 1.5

3bit-bits-in-byte

77.4ms +/- 17.6 %

3.2ms +/- 17.4 %

8.0ms +/- 0.0

bits-in-byte

113.2ms +/- 19.2 %

20.4ms +/- 23.8 %

20.8ms +/- 2.7

bitwise-and

208.4ms +/- 8.3 %

5.2ms +/- 10.7 %

28.8.4ms +/- 4.7

nsieve-bits

136.2ms +/- 12.6 %

47.2ms +/- 5.1 %

37.8ms +/- 1.5

controlflow

67.4ms +/- 27.7 %

52.0ms +/- 106.3 %

7.8ms +/- 17.5

recursive

67.4ms +/- 27.7 %

52.0ms +/- 106.3 %

7.8ms +/- 17.5

crypto

264.0ms +/- 11.2 %

117.0ms +/- 8.7 %

77.8ms +/- 7.7

aes

96.6ms +/- 16.4 %

63.0ms +/- 13.5 %

27.6ms +/- 21.3

md5

91.4ms +/- 6.8 %

33.2ms +/- 10.4 %

26.0ms +/- 3.4

sha1

76.0ms +/- 18.4 %

20.8ms +/- 26.5 %

24.2ms +/- 2.3

date

357.6ms +/- 7.5 %

265.0ms +/- 6.3 %

189.2ms +/- 7.8

format-tofte

160.6ms +/- 13.4 %

155.4ms +/- 7.3 %

87.4ms +/- 6.5

format-xparb

197.0ms +/- 3.7 %

109.6ms +/- 14.8 %

101.8ms +/- 14.6

math

531.6ms +/- 4.8 %

90.0ms +/- 4.0 %

124.0ms +/- 9.2

cordic

205.0ms +/- 5.9 %

31.2ms +/- 10.7 %

51.8ms +/- 22.9

partial-sums

229.4ms +/- 7.0 %

42.6ms +/- 4.4 %

50.8ms +/- 6.1

spectral-norm

97.2ms +/- 16.5 %

16.2ms +/- 8.4 %

21.4ms +/- 12.7

regexp

483.0ms +/- 8.2 %

153.0ms +/- 6.0 %

29.6ms +/- 2.3

dna

483.0ms +/- 8.2 %

153.0ms +/- 6.0 %

29.6ms +/- 2.3

string

1130.2ms +/- 3.6 %

602.2ms +/- 2.5 %

401.0ms +/- 5.4

base64

90.8ms +/- 16.4 %

18.0ms +/- 21.8 %

40.6ms +/- 4.6

fasta

224.4ms +/- 6.7 %

117.4ms +/- 11.4 %

73.4ms +/- 3,9

tagcloud

257.0ms +/- 11.3 %

186.0ms +/- 8.2 %

85.6ms +/- 5.5

unpack-code

407.6ms +/- 2.6 %

212.0ms +/- 12.8 %

118.8ms +/- 7.5

validate-input

150.4ms +/- 11.3 %

68.8ms +/- 11.3 %

82.6ms +/- 20.3

Compilation of Electrolysis

For the rest of this post I'll walk through an installation of Electrolysis on ubuntu. If you use a different Linux distributions or Windows, you can follow a similar path.

Download archive in gzip, zip, or bz2 formats, I downloaded gzip. The file took a while to download. Then you unpack the files, depending on the format you chose for download. I did tar -xvvf tip.tar.gz

There are pre-requisites for building of firefox. On linux, you need to install some packages (you'll also find instructions for other linux distributions and windows).
> sudo apt-get build-dep firefox
> sudo apt-get install mercurial libasound2-dev libcurl4-openssl-dev libnotify-dev libxt-dev libiw-dev mesa-common-dev

Once finished, you find the build in dist/bin/. On Linux you execute the filefox binary, on windows you run firefox-bin. According to Mozilla, it is best to run it in a separate profile.
> cd dist/bin
> ./firefox -P JunkProfile

@Jaya: I am also a big fan of firefox, but I can't deny that it's sometimes very slow. The tests that I present in my post give hope that the competition with chrome will bring us both feature-rich and faster browsers.

Your times on Firefox 3.5.6pre and Chrome 4.0.221.1 are identical. In the article, you stated that Chrome was slightly faster. Was there a cloning mistake in the table listing the times? If so, could you please fix that?

@Benjamin Auggarth: Thanks. That will make comparitive analysis easier. Were you using Ubuntu for the analysis or was it something else? Also, did you do any tweaks to the default optimizations the GCC profile uses?

@Anonymous: I was using ubuntu (9.04). For compilation of electrolysis I used gcc options as per the .mozconfig file shown in the post. Most important I think is the O2 switch. I don't know if the --enable-optimize mozconfig options has any additional effect.

I don't know how Firefox 3.5.6pre was compiled. I am now downloading source of Firefox in order to compile with exactly the same options that I used for electrolysis. For the record: to download the firefox source code base go to developer.mozilla.org.

I compiled Firefox 3.5.6 with the same compiler options as before used for compiling Electrolysis. I redid the test with the recompiled 3.5.6. You can find results here.

I think they do not significantly differ from the results I found without recompiling. The total is a 5185.8ms +/- 1.9% which is much slower than Chrome or Electrolysis, so I think it's warranted to say that the differences in speed between 3.5.6 and Electrolysis came not from compiler optimization but from differences in Firefox.

It's fantastic that you're excited about the early 3.7 development work, but there are a few issues with your post that I think should be clarified...

1) There's no need to compile your own 3.7pre build -- we make nightly builds available (see http://nightly.mozilla.org/). It helps if people use these, because these builds keep themselves up-to-date automatically, and will report crash data to us (opt-in, natch) so we can catch problems early.

2) Doing your own compile for performance comparisons usually isn't a good idea, we've already spent a lot of time tweaking how things are built (eg https://bugzilla.mozilla.org/show_bug.cgi?id=409803). Your inclusion of "--enable-optimize=-O2" has, in fact, likely made your build slower than the official builds! If you're really keen on doing your own build, the steps at https://developer.mozilla.org/En/Simple_build are really all that's needed. We don't recommend people put extra stuff in their mozconfig unless there's a very specific reason for it.

4) Electrolysis itself won't really help with things like Sunspider -- speedups there are due to improvements in the JS engine itself. Electrolysis is more about stability and security, and performance when running multiple tasks on a multicore box.

5) As other comments noted, multiprocess != multithreaded. Firefox is already multithreaded (eg, top reports 18 threads in my particular case), and web sites can already make use of that with web workers (see http://hacks.mozilla.org/2009/07/working-smarter-not-harder/).

In any case, your basic point is correct. There's a lot of exciting things in the Firefox pipeline, and 2010 is going to be a very awesome year. :-)

A process is a block of code (i.e. an application) that has it's own memory area, stack and other computer resources. This means that if a process crashes, it will not affect another process. In the case of Chrome, Chrome runs each tab in it's own process, so if a tab crashes it will not crash the Chrome browser itself.

A thread shares some of the resources for a process, and is usually cheaper to create. A process will always have at least one (main) thread. A thread is a block of code to be executed. The Operating System will assign different threads to different processors (or the same processor) to be run.

Time slicing is one mechanism that an Operating System can use to schedule different threads to be executed, but is not the only one.

Thanks a lot for all the comments. Your corrections and pointers are appreciated.

I should have been more clear about the terms multi-thread and multi-process. I was trying to make the introduction understandable to a general audience and it ended up too sloppy. I put the links to wikipedia article here for the record: thread, and process.

@Nick Nethercote: The 3.5.6 is a standard build. I didn't make any changes.

I've been running nightly builds of Minefield 3.7a1pre (Mozilla/5.0 (X11; U; Linux x86_64; sv-SE; rv:1.9.3a1pre) Gecko/20100106 Ubuntu/9.10 (karmic) Minefield/3.7a1pre GTB7.0) as my main browser on a HP Pavilion d4595se, AMD Athlon 64 X2 5000+ Dual Core box for quite some time, and have found it snappier than both 3.5.x and 3.6.bx versions, but not quite as snappy as Chromium (no objective tests, just subjective impressions). This, however, is the first time I've heard of «electrolysis» - have I been speaking prose without being aware of it ? Furthermore, I note that the value of my «dom.ipc.plugins.enabled» Boolean is set to «false» by default ; what would the effects of changing it to «true» be, if any ?...

IPC stands for inter-process communication. As I understand it, with both properties, dom.ipc.plugins.enabled and dom.ipc.tabs.enabled, you have options to enable parallelization of both plugins or tabs. As Nicholas Furgiuele points out, enabling any of the properties will electrolyze your Firefox (if it's a newer version).

@Anonymous: I use a 64bit system. If the JIT compiler for 64bits was added as you say in 3.6 and for 32bits earlier than this could mean that at least part of differences between 3.5.6 and 3.7 would apply only for 64bit systems. However I am not sure it is true what you say. I found in this post by Andreas Gal that the tracemonkey jit compiler was in the Firefox main trunk since August 2008 and also worked for 64bits.

Benjamin, JIT compiler for 64-bits were turned on on September 15th, 2009 (on the branch that lead to Fx 3.6).

Prior to this only confidential test builds (aka Tracemonkey builds) could have JIT on 64-bits. But no official build, neither by Mozilla, neither by the different Linux publishers.

The proof: http://www.bailopan.net/blog/?p=595

So the upcoming Fx 3.6 (now at the RC stage) will be the first released version of Firefox to support JIT on x64.

Concerning dom.ipc.tabs.enabled, it does nothing on a trunk build, and will likely be much buggy on a electrolysis-branch build. plugins.enabled does work though (on Windows and Linux, not Mac). They are discussion if they want to port it back to a 3.6.x release or way for a mid-year 3.7 release. This is not yet decided, but the 3.6.x release of plugin electrolysis has the lead.

Finally concerning the better results in Sunspider, basically (and informally) the results are:Fx 3.5 -> Fx 3.6: -15% (and much more if you are using a 64-bits build as JIT is now working)Fx 3.6 -> current trunk nightly: -5% (a little better if you take a tracemonkey nightly).

Thanks for the feedback again. I conclude from the discussion that the javascript execution improved a lot with the introduction of the new JIT compiler, which was in version 3.6 on 64bit platforms.

I just found a newer benchmark of HTML5 Canvas Javascript performance that again shows big differences in rendering between different browsers and I thought it worth mentioning here. Freeciv developers compared Safari on Windows, IE 8 on Windows, Firefox 3, Firefox 3.0.15 on Linux, Firefox versions 3.6 and Firefox 3.7a1 on Windows, and Chrome 3.0 on linux, and Chrome 4.04 on Windows. They found that internet explorer is slowest by a great margin, Firefox version 3.0.15, next slowest, has about double the speed. Next come Firefox 3.6 and Firefox 3.7a1, which are about the same level and bring a great speed-up with respect to 3.0.15. Safari nearly doubles their speed. Chrome versions 3.0 and 4.0.4 are fastest and in turn much faster than Safari.

Let me start by saying nice post. Im not sure if it has been talked about, but when using Chrome I can never get the entire site to load without refreshing many times. Could just be my computer. Thanks

Considerably, this post is really the sweetest on this notable topic. I harmonise with your conclusions and will thirstily look forward to your incoming updates. Saying thanks will not just be sufficient, for the phenomenal clarity in your writing. I will directly grab your rss feed to stay informed of any updates. Admirable work and much success in your business dealings! Please excuse my poor English as it is not my first tongue.

Electrolysis itself won't really help with things like Sunspider -- speedups there are due to improvements in the JS engine itself. Electrolysis is more about stability and security, and performance when running multiple tasks on a multicore box.

I found this blog through google on accident.wow, sweet post. I’ve been telling me friends about this blog, hopefully they spread the word about it to. Keep up the good work, thanks for all the hard work and great info." ClenbuterolAND Clenbuterol

I would like to thank you for the efforts you have made in publishing this article. I am hoping the same best work from you in the future as well. In fact your fanciful writing ability has urged me to start my own blog now. Actually the blogging is spreading its wings rapidly. Your write up is a fine example of it. Thanks.Professional packers Denver

I think the advantage the chrome is having over Mozilla is that it can handle more traffic at a given instant . i mean if one opens a lot of sites together one often finds that the chrome will keep on working normally whereas the Mozilla will just stop