Skip to main content

64-bit Browser Performance

A complaint I've had with Flash lately is its lack of 64-bit support for Windows. This forces us to run 32-bit browsers on our 64-bit machines if we intend on having Flash support while browsing. My initial thought was that we're missing out on a very nice performance boost because of this. I then questioned just how sure I really was that this performance boost really existed. Thus, I decided to do some really simple testing between some 32 and 64 bit browsers just to see what happens. The results were, interesting, though not necessarily conclusive of much.

The plan is simple. Run a small JS script that will calculate all prime numbers from 1 to 10,000 and record the time taken for the operation. The end code uses a modified algorithm that I stole from the Web Workers Wikipedia page.
var n = 1;
var holder = document.getElementById('holder');
var startTime = (new Date).valueOf();
search: while (n < 10000) {
  n++;
  var nSqrt = Math.sqrt(n);
  for (var i = 2; i <= nSqrt; i++)
  if (n % i == 0)
    continue search;
  // found a prime!
  holder.innerHTML += (n + '');
}
document.getElementById('time').innerHTML = ((new Date).valueOf() - startTime);
One of the FireFox versions was complaining about the script running too long so I also decided to do a second test, this one only going up to the number 5000.

Complete browser version list for test:
IE8 8.0.7600.16385 (32 and 64 bit)
IE9 Platform Preview 1.9.7766.6000
Chrome 5.0.375.55 beta
Chromium 6.0.420.0 (48547)
Firefox-32bit 3.6.3
Unofficial Firefox Namoroka/3.6.3 (64 bit) from http://wiki.mozilla-x86-64.com/Firefox:Download
Firefox-32-3.7a5pre Nightly Built on 19-May-2010

Times in ms for 5000:
IE8-322539
IE8-642954
IE9-321556
Chrome 5752
Chromium 6635
Firefox-325669
Firefox-645520
Firefox-32-3.7a5pre920


Times in ms for 10000:
IE8-326368
IE8-645733
IE9-325048
Chrome 52481
Chromium 62051
Firefox-3230163
Firefox-6429002
Firefox-32-3.7a5pre2830


Note I did tell FF to stop dialog'ing about the script taking a while so these oddly high times don't include me clicking the No button for the warning. Thus, I really have no explanation for the obscure duration for FF 32 and 64 to calculate under the 10000 limit.

IE8 also beats Firefox in both tests by considerable margins. Something I find to be rather strange as Firefox has native code compilation for Javascript whereas IE8 does not.

Also of note, in the 5000 limit, IE8-64 actually takes longer than IE8-32. Elsewhere the 64 bit browser out-performed its 32-bit brother but only marginally. Keep in mind, this is a pure mathematical JS test. A more robust test would probably include things like heavy DOM manipulation and HTML tree searching. So again, interesting results but nothing too conclusive regarding 64-bit browsers being extra powerful.

Some graphs:



Comments

Popular posts from this blog

Quick Deepstream.io Setup Using JSPM

Cross post from my employer's development blog: http://rootinc.github.io/2016/02/12/deepstream-jspm/
Want to use JSPM rather than Bower for running the Deepstream.io example? Follow these steps. This is basically a duplicate of the [Getting Started tutorial][tutorial] on the [Deepstream.io website][website] but using a really simple JSPM setup. This is a very crude guide where I list everything I had to do to get things running.

Create an empty project folder npm install deepstream.io Copy server code verbatim from the Getting Started guide jspm install npm:deepstream.io-client-js Hit enter for all the prompts from JSPM

We’re going to modify the client side code a little bit. We have native support for ES6 compiling with JSPM/Babel so we can import the Deepstream client directly:

import deepstream from 'deepstream.io-client-js'; let ds = deepstream( 'localhost:6020' ).login();

let record = ds.record.getRecord( 'someUser' );

let input = document.querySelector( 'inp…

Accessing other HTTP servers on Cloud 9 IDE

If you're using Cloud 9 to do development, you'll quickly realize that only ports 8080 through 8082 are available to the outside world from your development box. This is generally not an issue as you can set your application to bind to the $PORT environment variable when in development mode. However, there are sometimes other servers that we want to make use of that host on different default ports.

I recently had to setup a Neo4j server which defaults the admin interface of port 7474. Unfortunately, I could not access the admin interface even through the IDE based web browser window. So, what to do? I could change the default server settings so that it runs on a different port. However, the app I'm working on with a team has 7474 hard-coded and I currently don't feel like writing a local only work-around.

After some searching, I ran across a neat Linux tool called socat. This allows us to easily forward one port to another. After a quick install via apt-get, I ran the …

Atari E3 2004 PAL digital press kit

Making note of some old swag. The Atari E3 2004 PAL digital press kit. See video for details.