In my view, there is enough information to deduce, with a high level of
certainty, that single-threaded compilation performance (in general) is far
too slow in chrome, and that this is a problem, irrespective of how fast or
slow it happens to be in any other browser.
If there's additional
On Tue, Dec 11, 2018 at 5:03 PM Goran Milovanovic
wrote:
>
> Performance seems to depend heavily on the number of available hardware
> threads, and is far too poor on machines that only have a few.
>
> In short: Single-threaded performance seems abysmal, so that would be the
> thing to look
If wasm "can be almost directly executed", I think one could reasonably
expect compile times to be negligible (under ~200ms), for any payload under
~10M, even on a single core.
Perhaps the design of wasm makes that possible, in theory, but the liftoff
baseline compiler fails to meet that
Hello,
It would be interesting if you could also time your application in Firefox,
which also has a baseline wasm compiler. That may be a useful data point to
help us determine what to look into further.
Regards,
Dan
On Tue, Dec 11, 2018 at 2:04 AM Goran Milovanovic
wrote:
> I'm not really
The number of cores definitely matters, yeah - that could explain your
results.
Wasm is sort of in the middle of the options you mentioned, I think. It can
be almost directly executed by the VM, which is what baseline compilers do,
and they can compile at around the speed of the network, so VM
I'm not really sure what you mean by "hitting a bad case in the VM". Are
you implying that my code could be doing something highly unusual, which V8
can't really process effectively? This seems highly unlikely, because the
application in question is a pretty typical OpenGL program, that just
Interesting, it's possible you're hitting a bad case in the VM then. Can
you perhaps make a public testcase of your codebase, and we can show it to
them?
On Sun, Dec 9, 2018 at 11:02 PM Goran Milovanovic
wrote:
> I'm using the chrome dev tools Network panel to observe relevant events:
>
> * At
I'm using the chrome dev tools Network panel to observe relevant events:
* At the 1.25 second mark, all the necessary files (wasm, data, js, ...)
have been downloaded.
* - WASM processing seems to happen here (cpu utilization goes up to
100%) -
* At the 4.25 second mark, emscripten
A lot of good stuff has happened since April. The main issue has on the
browser side, where things are now a lot better. In particular, baseline
compilers are now common, like V8's Liftoff,
https://v8.dev/blog/liftoff
That should be enabled in Chromium 71, but you can confirm in
chrome://flags.
I've made a thread back in April, with a similar focus:
https://groups.google.com/forum/#!searchin/emscripten-discuss/still$20slow%7Csort:date/emscripten-discuss/Ft3UT0PHX_w/gXUMRN4hAgAJ
While somewhat useful, I think that thread was a bit side-tracked, because
instead of discussing why WASM
10 matches
Mail list logo
