5 ms·

https://lukewagner.github.io/test-tanks-compile-time/ https://lukewagner.github.io/test-tanks-compile-time/ Firefox Nightly: WebAssembly.instantiate took 227.6

https://lukewagner.github.io/test-tanks-compile-time/ https://lukewagner.github.io/test-tanks-compile-time/ Firefox Nightly: WebAssembly.instantiate took 227.6ms (54.4mb/s) Chrome Canary: WebAssembly.instantiate took 8576ms (1.4mb/s) Wow. (Edit: And I believe that's not even using the streaming compilation mentioned in the article, it's just the new baseline compiler in action)

styfle 9y ago
Where did you even find that repo? Was that mentioned in the article or is this your code?
- callahad 9y ago
  Linked in the article under "give it a try" in the sixth paragraph. The repo itself is at https://github.com/lukewagner/test-tanks-compile-time https://github.com/lukewagner/test-tanks-compile-time
callahad 9y ago
> I believe that's not even using the streaming compilation mentioned in the article That's correct. Streaming compilation would finish earlier, but might actually benchmark more slowly because you'd be adding in the time that the compiler is idle and waiting for the network to catch up. Preloading the .wasm file in the test lets us measure just the speed of the compiler, independent of the network.
- derefr 9y ago
  An interesting benchmark would be the total energy usage of the CPU while loading a page in each browser. The compiler managing to idle waiting for network packets should theoretically allow some of the CPU cores to enter sleep states. (Not all, since others are still busy rendering the page, and at least one is busy doing whatever non-DMA kernel bits are involved with receiving the network packets.)
  - etep 9y ago
    It should be the case that if the same amount of work is done, then the energy used will be the same. If it takes less work to compile the web assembly, then less energy (holding all other parameters the same). If you have to idle a CPU, then you probably use more energy (holding all other parameters the same) i.e. because you will spend more time and accomplish the same amount of real work (but waste energy on the idled core, albeit waste very little, accomplishing extra, but non-productive, work). Cannot let some other CPU parameter changes as a result of cores being idled (e.g. frequency gets boosted on non-idle cores as a result of dynamic frequency scaling with idle cores) to run this experiment. Thinking about CPU energy use is interesting :)
    - yjftsjthsd-h 9y ago
      I don't think that's true; isn't the relationship between clock speed and power non-linear?
      - ethbro 9y ago
        That's for max frequency on a given process node. Power scales with voltage squared. But that doesn't say anything about wasted power. And dynamic scaling screws that up in modern chips. I believe I could summarize things by saying the only way you can really save energy* doing the same work+ is by using a different semiconductor process (either power/leakage-reduction-focused or smaller). * For serious values of "energy" + Where the same work is not always true for a given task, if one optimizes an algorithm
        naikrovek 9y ago
        Can you explain the voltage squared thing? To me, power = voltage * current.
        etep 9y ago
        For chips, power scales with voltage squared. Is also true that P=IV (since both are true, these observations cannot be in contradiction). Apparently, for chips, the current must be proportional to voltage also. Glossing over some details, turning on (off) a transistor is the same as charging (discharging) a capacitor. The energy stored on a capacitor is 1/2 C V^2. If you turn on and off the transistor periodically (say with frequency f) you use 1/2 C V^2 energy f times per second (energy per unit time is power). Normally the capacitance is ignored when discussing how power changes because for a given design the capacitance is a fixed quantity.
therockhead 9y ago
My times are similar. I also ran on Safari which is faster than Chrome but slower than Firefox.
mort96 9y ago
I'm running Firefox 57, and even here, Firefox is significantly faster; 3182.3ms (3.9mb/s) in Firefox, 7575ms (1.6mb/s) in Chrome 63.
SubiculumCode 9y ago
Chrome: WebAssembly.instantiate took 22861.1ms (0.5mb/s) Nightly:WebAssembly.instantiate took 1825.3ms (6.8mb/s) Mine was a laptop in low power mode. Yours was much faster all around.
depressedpanda 9y ago
I ran the tests on my Nexus 5X running stock Android 8.1. Chrome: WebAssembly.instantiate took 12935.5 ms (1 MB/s) Firefox Nightly: WebAssembly.instantiate took 1223.1 ms (10.1 MB/s) Yikes, one order of magnitude in difference.
- alexeldeib 9y ago
  Similar for me, a touch over 10x FF: WebAssembly.instantiate took 280.3 ms (44.2 MB/s) Chrome: WebAssembly.instantiate took 3022.4 ms (4.1 MB/s)
- weaksauce 9y ago
  mine was even a bit more of a change. Chrome: WebAssembly.instantiate took 13692.8 ms (0.9 MB/s) Firefox: WebAssembly.instantiate took 330.8 ms (37.4 MB/s)
- flobbers 9y ago
  Safari 11.0.2: 4.7mb/s Chrome: 1.2mb/s This is on MacOS 10.13.2. I'd love to run Firefox but the battery savings and reduced heat from using Safari makes it too hard to pass up in this regard.
kbumsik 9y ago
My old i5 Thinkpad L450: Firefox 57: 5053.8 ms (2.4 MB/s) Firefox Nightly 59: 454.6 ms (27.2 MB/s) Chrome 63: 9034.9 ms (1.4 MB/s) Wow, it's over x10 faster...
clouddrover 9y ago
In Firefox 58 beta I get: WebAssembly.instantiate took 200.9 ms (61.6 MB/s) In Safari 11.0.2 I get: WebAssembly.instantiate took 2885.9 ms (4.3 MB/s) In Vivaldi 1.13.1008.40 I get: WebAssembly.instantiate took 7719 ms (1.6 MB/s)
schance 9y ago
Chrome Dev: WebAssembly.instantiate took 2254 ms (5.5 MB/s) Firefox Nightly: WebAssembly.instantiate took 158.2 ms (78.3 MB/s) Edge 41.16299.15.0: WebAssembly.instantiate took 99.2 ms (124.8 MB/s) I did not expect Edge to be even faster.
- justinjlynn 9y ago
  Is the runtime performance similar to the startup performance measurement?
- markdog12 9y ago
  As stated elsewhere in this thread, Edge compiles WebAssembly lazily, so it's basically skipping the test: https://news.ycombinator.com/item?id=16170496 https://news.ycombinator.com/item?id=16170496
vitorgrs 9y ago
I tried Chrome Canary, Firefox Nightly and Edge. Edge was the fastest here! But I believe they are using streaming compilation already.
deleted 9y ago
[deleted]

styfle 9y ago

Where did you even find that repo? Was that mentioned in the article or is this your code?

callahad 9y ago
Linked in the article under "give it a try" in the sixth paragraph. The repo itself is at https://github.com/lukewagner/test-tanks-compile-time https://github.com/lukewagner/test-tanks-compile-time

callahad 9y ago

> I believe that's not even using the streaming compilation mentioned in the article That's correct. Streaming compilation would finish earlier, but might actually benchmark more slowly because you'd be adding in the time that the compiler is idle and waiting for the network to catch up. Preloading the .wasm file in the test lets us measure just the speed of the compiler, independent of the network.

derefr 9y ago
An interesting benchmark would be the total energy usage of the CPU while loading a page in each browser. The compiler managing to idle waiting for network packets should theoretically allow some of the CPU cores to enter sleep states. (Not all, since others are still busy rendering the page, and at least one is busy doing whatever non-DMA kernel bits are involved with receiving the network packets.)
- etep 9y ago
  It should be the case that if the same amount of work is done, then the energy used will be the same. If it takes less work to compile the web assembly, then less energy (holding all other parameters the same). If you have to idle a CPU, then you probably use more energy (holding all other parameters the same) i.e. because you will spend more time and accomplish the same amount of real work (but waste energy on the idled core, albeit waste very little, accomplishing extra, but non-productive, work). Cannot let some other CPU parameter changes as a result of cores being idled (e.g. frequency gets boosted on non-idle cores as a result of dynamic frequency scaling with idle cores) to run this experiment. Thinking about CPU energy use is interesting :)
  - yjftsjthsd-h 9y ago
    I don't think that's true; isn't the relationship between clock speed and power non-linear?
    - ethbro 9y ago
      That's for max frequency on a given process node. Power scales with voltage squared. But that doesn't say anything about wasted power. And dynamic scaling screws that up in modern chips. I believe I could summarize things by saying the only way you can really save energy* doing the same work+ is by using a different semiconductor process (either power/leakage-reduction-focused or smaller). * For serious values of "energy" + Where the same work is not always true for a given task, if one optimizes an algorithm
      - naikrovek 9y ago
        Can you explain the voltage squared thing? To me, power = voltage * current.
        etep 9y ago
        For chips, power scales with voltage squared. Is also true that P=IV (since both are true, these observations cannot be in contradiction). Apparently, for chips, the current must be proportional to voltage also. Glossing over some details, turning on (off) a transistor is the same as charging (discharging) a capacitor. The energy stored on a capacitor is 1/2 C V^2. If you turn on and off the transistor periodically (say with frequency f) you use 1/2 C V^2 energy f times per second (energy per unit time is power). Normally the capacitance is ignored when discussing how power changes because for a given design the capacitance is a fixed quantity.

therockhead 9y ago

My times are similar. I also ran on Safari which is faster than Chrome but slower than Firefox.

mort96 9y ago

I'm running Firefox 57, and even here, Firefox is significantly faster; 3182.3ms (3.9mb/s) in Firefox, 7575ms (1.6mb/s) in Chrome 63.

SubiculumCode 9y ago

Chrome: WebAssembly.instantiate took 22861.1ms (0.5mb/s) Nightly:WebAssembly.instantiate took 1825.3ms (6.8mb/s) Mine was a laptop in low power mode. Yours was much faster all around.

depressedpanda 9y ago

I ran the tests on my Nexus 5X running stock Android 8.1. Chrome: WebAssembly.instantiate took 12935.5 ms (1 MB/s) Firefox Nightly: WebAssembly.instantiate took 1223.1 ms (10.1 MB/s) Yikes, one order of magnitude in difference.

alexeldeib 9y ago
Similar for me, a touch over 10x FF: WebAssembly.instantiate took 280.3 ms (44.2 MB/s) Chrome: WebAssembly.instantiate took 3022.4 ms (4.1 MB/s)
weaksauce 9y ago
mine was even a bit more of a change. Chrome: WebAssembly.instantiate took 13692.8 ms (0.9 MB/s) Firefox: WebAssembly.instantiate took 330.8 ms (37.4 MB/s)
flobbers 9y ago
Safari 11.0.2: 4.7mb/s Chrome: 1.2mb/s This is on MacOS 10.13.2. I'd love to run Firefox but the battery savings and reduced heat from using Safari makes it too hard to pass up in this regard.

kbumsik 9y ago

My old i5 Thinkpad L450: Firefox 57: 5053.8 ms (2.4 MB/s) Firefox Nightly 59: 454.6 ms (27.2 MB/s) Chrome 63: 9034.9 ms (1.4 MB/s) Wow, it's over x10 faster...

clouddrover 9y ago

In Firefox 58 beta I get: WebAssembly.instantiate took 200.9 ms (61.6 MB/s) In Safari 11.0.2 I get: WebAssembly.instantiate took 2885.9 ms (4.3 MB/s) In Vivaldi 1.13.1008.40 I get: WebAssembly.instantiate took 7719 ms (1.6 MB/s)

schance 9y ago

Chrome Dev: WebAssembly.instantiate took 2254 ms (5.5 MB/s) Firefox Nightly: WebAssembly.instantiate took 158.2 ms (78.3 MB/s) Edge 41.16299.15.0: WebAssembly.instantiate took 99.2 ms (124.8 MB/s) I did not expect Edge to be even faster.

justinjlynn 9y ago
Is the runtime performance similar to the startup performance measurement?
markdog12 9y ago
As stated elsewhere in this thread, Edge compiles WebAssembly lazily, so it's basically skipping the test: https://news.ycombinator.com/item?id=16170496 https://news.ycombinator.com/item?id=16170496

vitorgrs 9y ago

I tried Chrome Canary, Firefox Nightly and Edge. Edge was the fastest here! But I believe they are using streaming compilation already.

deleted 9y ago

[deleted]