Issue metadata
Sign in to add a comment
|
Important degradation in measured Faust generated WebAssembly benchmarks
Reported by
l...@grame.fr,
Oct 23 2017
|
||||||||||||||||||||
Issue description
Chrome Version : Version 64.0.3247.0 (Build officiel) canary (64 bits)
URLs (if applicable) : faust.grame.fr/bench
Safari: Safari WekKit
Firefox: Nighy OK
IE:
What steps will reproduce the problem?
Faust generated WebAssembly code suddenly degraded on latest Canary versions (starting from a few days ago, I don't have the exact version number).
On the faust.grame.fr/bench site, several html pages allow to bench Faust wasm code, and display performances. The displayed number dropped significantly since several days.
What is the expected result?
Consistent benchmark results
What happens instead?
Dorp in measured performances
Please provide any additional information below. Attach a screenshot if
possible.
,
Oct 23 2017
Unfortunately I don't know the exact Canary version number where is started, but: http://faust.grame.fr/bench/freeverb.html gives : ==> 146.98 Mbyes/sec on Version 63.0.3239.9 (Chrome dev channel) ==> 80.63 Mbyes/sec on Version Version 64.0.3247.0 (Build officiel) canary (64 bits)
,
Oct 25 2017
,
Oct 25 2017
,
Oct 25 2017
In case it helps: we compiled the same Faust DSP code but using Faust ==> C == EMCC => wasm path. In this case the difference between tested versions is less: http://faust.grame.fr/bench-emcc/freeverb.html ==> 90.20 Mbyes/sec on Version 63.0.3239.9 (Chrome dev channel) ==> 90.26 Mbyes/sec on Version Version 64.0.3247.0 (Build officiel) canary (64 bits) So it seems the drop in performances is more visible with the direct Faust ==> wasm path, which produces different wasm code compared to what EMCC does.
,
Oct 26 2017
Unable to reproduce the issue on Windows 7 & Mac 10.12.6 using chrome reported version-64.0.3247.0 as per URL provided in C#5. Upon clicking " Start benchmark" button observed info as below: Dev ->63.0.3239.18 --- 94.41 MBytes/sec Canary->64.0.3249.0 -- 93.89 MBytes/sec Reported->64.0.3247.0 --91.66 MBytes/sec Please find the attached screenshots for reference & let us know the clear repro steps, OS details & exact expected behavior to proceed further. Thanks in advance..!
,
Oct 26 2017
Texting on MacBook Pro (Retina, 15 pouces, mi-2015) 2,2 GHz Intel Core i7, El Capitan 10.11.6 (15G1611) Actually I see: Chrome official 62.0.3202.62 ==> 148,6 MBytes/sec Chrome dev 63.0.3239 ==> 85,17 MBytes/sec Chrome Canary 64.0.3250.0 (from today) ==> 85,70 MBytes/sec So it seems the problem was already there in dev 63.0.3239 Could you should test again on Chrome stable ?
,
Oct 27 2017
Testing with official Version 62.0.3202.75 (Build officiel) (64 bits) (so a bit more recent compared to the 62.0.3202.62 one tested yesterday) Chrome official 62.0.3202.75 => 100.64 MBytes/sec This is rather confusing: - could it be that the most efficient compiler does not run ? And that a faster one but that generates less efficient code is used? - could is be the benchmark method itself ? (that is calling the hot function in a loop and using Date().getTime(); API to measure the duration)
,
Oct 27 2017
No, we have not yet finished the baseline compiler for WASM. It is most likely due to no longer specializing to a specify memory buffer, but using an indirection. We should investigate further.
,
Oct 27 2017
,
Dec 21 2017
Version 65.0.3300.0 (Build officiel) canary (64 bits) shows an improvement, but still far behind Firefox Nigthly (59.0a1 (2017-12-18) (64-bit)) and Safari (11.0.2)
,
Jan 8 2018
Just wanted to post a quick update to this bug. Recent changes to prevent exploitation of the speculative side-channel attacks known as Meltdown and Spectre have impacted WebAssembly performance. We will look into reducing the cost of this impact in the coming weeks, and reevaluate the regression reported in this bug as well. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by hongchan@chromium.org
, Oct 23 2017Components: Blink>JavaScript>WebAssembly
Status: Untriaged (was: Unconfirmed)