Chrome Wasm Performance Regression

[Gaurav Dewan]

In Chrome 64, the wasm initialization time has increased by 300-400% as 
compared to Chrome 63 (easily reproducible on windows machine - other 
platforms are impacted too)
The issue is reproducible in "Tanks Demo" too - is it a known issue ?

Thanks
Gaurav

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I find a big problem(WebAssembly).

[Gaurav Dewan]

Hi ming_zhao,

I am able to repro the issue with code generated by em++ 1.37.8 (version 
does not matter in this case)
I have added this test case and wasm file to that bug. you can add 
subscribe to the bug (star the issue) to get updates.


Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I find a big problem(WebAssembly).

[Gaurav Dewan]

Wow !!
I hit into somewhat similar issue but was not able to find that it would be 
so easy to repro !! Now that this easy repro is here, chrome team could 
solve this issue
https://groups.google.com/forum/#!searchin/emscripten-discuss/chrome%7Csort:relevance/emscripten-discuss/enLqQMj_bmM/o3LG4t_HAQAJ

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Chrome Android webassembly Aw snap

[Gaurav Dewan]

On redmi note 4 4gb ram chrome canary and stable latest crashes with Aw snap on 
opening any medium sized webassembly like
Websighjs
FF works fine on same device. 
Maybe Chrome thinks there is less memory on mi environment
Is Aw snap in webassembly  common issue on Android Chrome ? 
Logged
https://bugs.chromium.org/p/chromium/issues/detail?id=76

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

out of memory exception and subsequent FF crash

[Gaurav Dewan]

Android FF runs out of memory on opening the wasm (or even asm.js) pages in 
multiple tabs; so does the 32 bit firefox on windows. 
Chrome on android is multi-process and is able to open many tabs with wasm 
open simultaneously. 
Safari is magically able to open many tabs(with asm.js) - maybe it releases 
the memory of background tab.

Is it a design limitation of Firefox or is it possible to  work-around it 
in asm.js in some way?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using custom C and CXX library with emscripten

[Gaurav Dewan]

EM_CACHE works well  !
The use case is scenario where we need to optimize the footprints of wasm 
(or asm.js) for example to ensure that all script code in browser fits 
nicely in SRAM of mobile device (on chip cache) for maximum performance.
For smaller projects like "hello world",
(1)  we can reduce the size of data section (in custom c/cxx library):
We do not need any of the error strings specified in _strerror.h
We can compile with -fno-rtti to strip out symbols from binary
We can compile with -DNDEBUG=1
(2) We can reduce the size of code section under certain assumptions
If iostream is used for string manipulation only (a kind of safe sscanf), 
we do not need big init code of money/locale (We deviates from standard for 
such projects, but we get custom bare-metal kind of optimizations.


Thanks
Gaurav

>
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Using custom C and CXX library with emscripten

[Gaurav Dewan]

We can ask emscripten(clang) to use custom C/cxx header in this way:

set EMMAKEN_NO_SDK=1
em++ -Xclang -nobuiltininc -Xclang -nostdsysteminc -Xclang 
-isystemc:\em\emsdk-portable\emscripten\CUSTOM\system\include\libcxx 
-Xclang -isystemc:\em\emsdk-portable\emscripten\CUSTOM\system\include\libc 
 a.cpp

How can we ask it to use library binaries(cached libcxx bc) from custom 
cache locations (instead of /.emscripten_cache/asmjs? (we want 
different custom optimized c++ libraries for different c++ to wasm projects_

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ctor_evaller: not successful

[Gaurav Dewan]

using -s EVAL_CTORS=0 in command line
em++ -Oz -s EVAL_CTORS=0 should work

Refer settings.js

On Saturday, August 5, 2017 at 6:49:39 PM UTC+5:30, awt wrote:
>
> Alon, is there a way in which we can turn off the constructor evaluator 
> even if we are using Oz or O3?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Debugging slow wasm compilation on MAC chrome

[Gaurav Dewan]

I observed  that slow startup of webassembly on Mac chrome canary is due to 
large amount of time taken in up front compilation. As compared to Windows 
chrome, the compile time is very high on Mac chrome for small wasm module. 
Not sure if it is due to hardware or software limitations of Mac. Or a bug in 
chrome. 
Is there any js flag in d8 or chrome using which I can find the granular 
compilation time for each Wasm function in a module? 
The issue does not happen on Firefox maybe because of indexeddb caching

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: WASM optimizations

[Gaurav Dewan]

I see f64 to int callback to js is fixed in latest emscripten. 
But unfortunately we are using emscripten 1.37.3 and unable to upgrade because 
of huge performance loss due to inlining strategy even after llvm lto. 
Any way we can port that fix to older version by cherry picking? 

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-DNEDBUG causes a size bloat in emscripten

[Gaurav Dewan]

Testcase here(all bcs, js makefile and gcc/clang generated exes):
https://github.com/gauravdewan007/ndebug

using -DNDEBUG helps to get rid of the assert (and save size and prevent 
strings from getting into the code).
Both clang and gcc generate smaller binary if -DNEDBUG option is used.

But using -DNDEBUG with emscripten build system causes a huge bloat in size 
(irrespective of optimization level) and lot of new code is getting added

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Libcxx update

[Gaurav Dewan]

>
> This  looks to be very interesting prospect. Could you write a wiki or 
> blog on how to update libcxx  (and libc) ?  

 

> This could help in some of the optimizations(unneeded code getting added 
> to the generated asm.js binary) when nothing else work.

 

> On a seprate note, I was toying with the idea of using clang 3.7 instead 
> of clang 4.0 with the latest emscripten builds. But then I also reckon that 
> all the testing (and new feature development in emscripten) would be 
> getting done using clang 4 (and packaged C runtime).


On Tuesday, July 18, 2017 at 3:37:22 PM UTC+5:30, jj wrote:
>
> It should be an llvm-nm listing dump. You can recreate it by 
>
> cd $EMSCRIPTEN 
> python embuilder.py build libcxx 
> llvm-nm $HOME/.emscripten_cache/asmjs/libcxx.a 
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: WebAssembly status on chrome

[Gaurav Dewan]

I see that indexeddb is targeted for M62 canary so AOT time as of today 
makes sense. Maybe I should try response api in M61.
 I am concerned more about slowness like that on mac and specifically 
android phones?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WASM optimizations

[Gaurav Dewan]

Are there methods to optimize these calls out of wasm (change code or use 
compiler options or add to webassembly)

(1) f64 to int - there is pattern (promote f64, and call 50 - f64 to int 
outside wasm)  - BINARYEN imprecise option is removed. I see this is the 
only asm-wasm imports getting called in my application.
https://github.com/kripken/emscripten/issues/4885
I am using default trap mode(not specifying anything).BINARYEN_IMPRECISE is 
not present in new toolchain versions.

(2) emscriptenmemcpy_big with 32768 bytes - is it some performance 
technique or necessary evil ?

(3) clock_get_time - perhaps there is no wasm instructions for this.

Chrome devtools profiler does not seem to profile inside wasm for 
performance(it just shows it as a monolithic blackbox) - only calls out to 
js are shown. Same with JS profiler tabs (although debugger is able to 
disassemble wasm). 
Has FF nightly started WASM debugging and profiling now ?
I remember seeing a snapshot of profiler with fast trampoline (calls from 
wasm to asm.js are shown) somewhere.

(4) Shadow stack - If application is taking address of local variable, wasm 
size can increase due to shadowing. Does it mean that even if I take 
address of a local variable in just one function, the application will 
always maintain the shadow stack ? Or does it increase proportionally with 
such instances ?
How can I spot such pattern in my application ?

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WebAssembly status on chrome

[Gaurav Dewan]

Hi Derek, all,
What is the WASM performance improvements roadmap for chrome canary?

As per my observations:

(1) Windows -  latest Chrome canary is now fast (good throughput after 1 
second of AOT - 20 to 50% slower than FF). It appears to be supporting 
indexeddb but there is no difference in startup performance Regardless of 
whether indexeddb is used or not, the AOT time is always 1 sec (time taken 
from first line of prejs to first line of  main). If indexeddb is used, 
shouldn't AOT time be 100 sec instead of 1+ sec ?  Once in a quarter, when 
a major update of browser with breaking change is released, it would be 
fair to expect to AOT hit of 1 sec.
Is there any way to hint chrome to avoid re-AOT of indexeddb code(whatever 
it is - parsing, validation) ? There should not be any security issue(SOP 
is still followed for indexeddb and no poisioning should be possible in 
threat model.

(2) Mac - Chrome canary on Mac still does not support indexeddb. And 
performance is still at earlir older levels (about 300% slower than 
windows). This performance is at same level  as what was on in initial wasm 
release build of chrome on windows.
This leads me to believe that all new webassembly features (including 
performance improvements) are disabled on mac (or are win only) despite the 
pipeline being same on both platforms. Is it true ?

(3) Android - chrome canary on Android is slow ( 250% slower than firefox 
nightly on same device). chrome 58 crash on android(wasm) was fixed in 
chrome 59 - wasm changes are happening on chrome android but something is 
missing looking at PERF side. 
Does it uses 8 cores (when cores are not sleeping) for AOT ?  And are there 
any techniques in chrome or application code to speed up the throughput 
(yes throughput is much slower than expected). In JS benchmarks (old-octane 
and jetstream) chrome and FF are at par mostly on android. Do these 
observations correlate with WASM versions of embenchen and massive 
(micro-benchmark or macro-benchmark apps) on android phone ? Is this 
slowness due to RAM/android resource management or chrome optimization on 
android ?
I am testing under ideal conditions (and repeating the tests).


Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

 We use EVAL_CTORS=0 for asm.js and wasm (because of the issue described in 
the previous thread) - does it still call simplify-ifs optimizations 
(leading to crash) ?

> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Profiling workflow

[Gaurav Dewan]

I have few queries regarding profiling workflow of asm.js and wasm:

(1) What is the ideal profiling workflow for asm.js now ?
 - using -Oz --llvm-lto --profiling-funcs options, I see a lot of one line 
functions end up as top bottleneck (like functions that just add two 
numbers). These functions are called from loop and emcc 1.37.9 does not 
inline functions at all ( actually,  with emcc 1.37.3 even the caller 
function of these is not listed as bottleneck). It appears that --llvm-lto 
and --profiling option do not work well together creating a noise.

(2) As for profiling & debugging workflow for wasm
- is it possible to generate a function table which maps function names to 
function identifier(numeric id of wasm function) which appears in chrome 
devtools (or wasm function numeric identifier in FF profiling workflow) ? I 
have seen chrome does not show wasm function names even with -g or 
--profiling but it shows each wasm function in separate file identified by 
numeric function id. And FF devtools are unable to disassemble large wasm 
file at the moment.

(3) Is it possible to create a code coverage report by dynamic analysis 
tool for asm.js or wasm (like bullseye code coverage for c++ or istanbul 
coverage report karma for JS) ? We want to list all the functions that are 
getting called at runtime (not just statistical profiling) - PGOMonitor 
does not work with fastcomp - so is there any way to instrument all the 
functions and generate such a report ?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: WebAssembly Regression in Safari TP 27

[Gaurav Dewan]

Thanks.
The hang issue is fixed in  Safari Technical preview 29. And I noticed that 
WASM startup time is now much faster that Safari TP 26.

For crash while opening debug console, I have logged webkit bug and added 
jj to cc list:
https://bugs.webkit.org/show_bug.cgi?id=171651



>>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Understanding contents of Mem file (asm.js)

[Gaurav Dewan]

Interesting: to use -fno-rtti, I only need to get rid of dynamic_cast and 
typeid.
If I am removing exception code at time of linking bc file (using -s 
DISABLE_EXCEPTION_.. em++ option), will using -fno-rtti compile time option 
still help with significant size reduction (other than symbol names and 
runtime code)  ? I am using link time option instead of compile time 
-fno-exception; because there are lots of "try catch throw" construct usage 
already which I do not want to patch in codebase.
I tried a simple hello world kind of c++ file with classes/dyn cast: - 
-fno-exception helped but -fno-rtti did not help (maybe program was too 
small).

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: WebAssembly Regression in Safari TP 27

[Gaurav Dewan]

Both the bugs are still happening in Safari TP 28:
(1) hang in WebAssembly.instantiate method invoked in WebWorker (which goes 
away if console is opened and we pause the javascript and continue both the 
threads). Not sure if this is due to use of webassembly in webWorker or 
some instructions in the webassembly module which is leading to hang.
(2) crash on opening the console (for which I have sent the crash reports 
to apple)
The codebase is not open source; but I could try to repro it in small 
testcase.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: indexeddb in chrome

[Gaurav Dewan]

This is strange. On OSX with even with latest chrome canary, I get error 
that "wasm module was not found in indexedDB"  - The wasm binary I am 
testing is less than 5mb.
And on windows chrome 32 bit (7 days old build of canary), wasm module is 
loaded from indexeddb but there is no difference in startup performance. 
The startup time is still much slower than asm.js in chrome. Is there a 
threshold on filesize or time for webassembly serialization with 
optimization?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Understanding contents of Mem file (asm.js)

[Gaurav Dewan]

I noticed that names of these functions are very big and occupy space in 
mem file.-These are essential artifacts of RTTI - which is required for c++ 
projects (dyn cast , virtual functions etc) - typeid is used less.
In fact removing these can help in upto 1% size reduction in a fully 
optimized asm.js made from c++ program.
IMO Requirement for these names is that they should be unique but they do 
not need to be too long (made of mangled names of all namespaces and 
functions) - yet clang and other compilers use name mangling for RTTI. I 
guess there is not much we could do here without llvm.
Is there some technique or some obsure option in toolchain to help that 
names generated are of smaller size ?
Reference: https://www.reddit.com/r/cpp/comments/5923sc/hiding_rtti_symbols/

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

Yes this happens only on this branch - i re-verified it with original and 
branch binaryen.
Interestingly, this did not happen with 1.37.3 when I replace the binaryen 
there with this branch version - so perhaps the complex interaction between 
these tools (optimizer) is causing this issue to surface.

Currently, I am not much familiar with reading of wasm binary (I am 
comfortable reading asm.js file) - so I am using printf as basic debugging 
tool. Anyways I am debugging chrome 32 bit issue - so maybe after learning 
of webassembly tools in that exercise, I might be able to repro it in small 
testcase.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is there some fundamental bug in 32 bit Chrome with regard to WebAssembly ?

[Gaurav Dewan]

I am able to pinpoint the point of failure in my program - at one place I 
am calling a function (passing it 6 floating points and int as last 
argument). Inside that function, second last argument comes out to be 
garbage (unexpected) while it is okay from where I am calling it (it all 
happens in header file in precompiled header). This anomaly happens only in 
32 bit chrome with webassembly version - works fine in 64 bit browser or 32 
bit FF. Asm.js works fine as well

In C, I know such errors are caused by calling convention or prototype  
mismatch - the same can be confirmed by assembly debugging. It does not 
appear to be that case here.

In a small testcase, I am unable to repro this issue.
How can I debug further to create a small test case for repro ? Is there a 
webassembly tool available to ease this job? seeing wast of this function 
or debugging ?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

That would be really nice (lto)
Regarding exception
Invalid function pointer '3044' called with signature 'vi'. Perhaps this is 
an invalid value (e.g. caused by calling a virtual method on a NULL 
pointer)? Or calling a function with an incorrect type, which will fail? 
(it is worth building your source files with -Werror (warnings are errors), 
as warnings can indicate undefined behavior which can cause this)
 at nullFunc_vi 
at b38271 ([51813]+4)

I tried to create small test but was unable. This is function table which 
is getting called (all functions in table take reference to class as 
argument) - in the callstack

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

indexeddb in chrome

[Gaurav Dewan]

Today I noticed indexeddb caching in chrome canary - but I did not notice 
any performance gain - Is it work in progress (module is stored in cache - 
but not used - right?)

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

Now that it appears llvm-lto helps a lot with size reduction with latest 
clang(this was not the case earlier), does it make sense to include in 
regression test suite and make it on by default on Oz build ?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

>
> Crash is fixed now during build(latest code of inline-small). The 
> generated wasm using newtool(and this new binaryen) throws an exception 6 
> during runtime(and asks to build with -s ASSERTIONS); while the generated 
> wasm using oldtool(and this new binaryen) seems to be working fine.
>

After disabling the unneeded construct (identified in bug1 - which was 
adding static constructors which we never need - which should be compiled 
out as dead code ideally)  and using llvm-lto, the binary generated (both 
asm and wasm) from new tool are comparable size (2% larger) with old tool.

With this new binaryen,our codebase is able to loose additional 1 or 2% in 
size; but it throws runtime exception. 

Without llvm-lto, this new binaryen helps in size but it only brings us 
midway (that is, it is not self sufficient in size reduction)

Just to confirm, does just replacing the contents of binaryen folder 
(before linking bc files) suffice(bin, /scripts/ and src/js) for testing ? 
Or is there some cache that we need to flush ? I created binaryen_old and 
binaryen_new folder and kept switching between them by renaming one of them 
to binaryen before linking bcs.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

>
> I have update the repo bug1 with bc and JS(--profiling)
>
I have added another test case:
https://github.com/gauravdewan007/bug2
 
--llvm-lto 1 help in both the testcases.
(1) In the (bigger) actual program, I am still seeing size increase of 
about 10% (after llvm-lto) with new tool as compared to old tool. The gap 
has narrowed by a great margin but is a degradation over old tool in terms 
of size of WASM. asm.js size is almost fine.
(2) Is llvm-lto safe to use and recommended ? (I remember reading that it 
is not tested that thoroughly and used with caution(testing))

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

(1) Firstly with exceptions enabled, 1.37.9(new tool) generates lots of 
functions as compared to 1.37.3(old tool). I will check if those are really 
dead functions which would mean new tool is not able to do dead code 
elimination effectively. 
(2) With exceptions disabled: new tool generates smaller sized asm.js (code 
size of wasm is almost same - just a little bit smaller with new tool)
(3) For exception enabled, I started off by investigating static 
initializer codebase (_GLOBAL_filename_cpp  function called at init time 
before main). I have created a small testcase for same at:
https://github.com/gauravdewan007/bug1/

(a) New tool generates smaller binary in this testcase since the code is 
too small - its size is dominated by emscripten and runtime setup cost 
which is better in new tool. 
(b) But lets focus on static intializer - for each c++ file having try 
catch block, static intializer function is emitted (_GLOBAL_filename..). 
With old tool, all the static initializer code (one line of heap write) is 
inlined in that same function. But with new tool, this global init function 
(one for every cpp file) calls ___cxx_global_var_init_xx functions which 
has actual init code(that is, init function is not inlined ).
(c) In this small test case, if I use EVAL_CTORS=1 instead of 0, body of 
these functions is eliminated at all; __Global function which do not exist 
now are exposed in asm and Module object(just one extra line). This happens 
in both old and new tool.
(d)  But in the actual big program with EVAL_CTORS=1, these global 
functions are still getting called from global init func - resulting in 
call to non-existent functions and failure at launch time itself. I am 
unable to repro that in this small testcase- no idea if that is result of 
complex interaction happening inside compiler with large codebase.This 
happens in both old and new tool. As a workaround, I disabled EVAL_CTORS in 
big program.
(e) Even with EVAL_CTORS=1, the codesize of generated asm.js as well as 
wasm is huge(50% or so larger) with new tool as compared to old  code. 
(f) I did not have any performance comparison between generated code from 
old and new tool(if it is trade-off between size and performance with 
exceptions enabled, it would be fine to use O3 instead of Oz - but it 
likely is bug)


I still need to investigate other causes of code bloat (if the root cause 
is same as this one or they are different) with new tool with exception 
disabled. Any idea to investigate(and generate minimal test case) for the 
same (EMCC_DEBUG or verifying dead code) is appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enhancement in preamble.js

[Gaurav Dewan]

I modified preamble.js "locally" to include wasm_utils.js under binaryen 
async macro and found this issue (uglify step had issue with ES6 syntax). 
So as a workaround, I used babel on wasm_utils(indexeddb loading code) 
before adding it to preamble.js which works fine. (I did not test whether 
the same is true for prejs or not.)
 

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WebAssembly Regression in Safari TP 27

[Gaurav Dewan]

Anyone else seeing the same issue (the WebAssembly application which worked 
in TP 26 does not work in TP 27 ) ?
On showing console, the browser crashes.
In some instances, I can show the console without crashing (It does not 
crash if I try to show the console at just the right time when it is trying 
to store the results in indexedDB (or has just failed)). In that case, 
after pause and continue debugging, It start working fine - but otherwise 
it seems to be hung (with 5% cpu) - probably wasm module had been 
instantiated (since cpu usage is down from 490% to 5%)

Floooh's virtualkc wasm demos seem to be working (so webassembly can be 
atleast instantiated there)

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enhancement in preamble.js

[Gaurav Dewan]

1.37.9 portable installer


>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Size bloat with option -Oz -s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=0

[Gaurav Dewan]

from em++ 1.37.3 to 1.37.9 there is massive increase in size (but with 
exceptions disabled it is not so) 
There are lots of these symbols which are getting added (and doing same 
thing - static boost exception pointer initalization):
___cxx_global_var_init_495()
___cxx_global_var_init_5_960()

Is this because of clang version 4 or emscripten changes?
Is this intended change?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Enhancement in preamble.js

[Gaurav Dewan]

Making changes in Preamble.js, we cannot use => ES6 arrow function

Workaround:
Use older syntax:
return fetch(url).then(function(response) {
return response.arrayBuffer(); }
)

instead of 
return fetch(url).then(response =>
response.arrayBuffer
)

Due to this we cannot directly use FF wasm_utils.js here.

Reference:
http://stackoverflow.com/questions/36179245/gulp-uglify-unable-to-handle-arrow-functions



-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is there some fundamental bug in 32 bit Chrome with regard to WebAssembly ?

[Gaurav Dewan]

>
> I was trying the demo on 32 bit chrome - What does this demo do? It just 
> keeps showing downloading spinner on chrome 32 bit
> http://mzl.la/webassemblydemo 
> 
>  

It built shaders(23 seconds) compile webassembly(28 mb) 
downloading(39Mb/39Mb - 100% and spinner is moving) 
Failed to store file wasmModule to IndexedDB, error: DataCloneError: Failed 
to execute 'put' on 'IDBObjectStore': An object could not be cloned.
This is expected on chrome as chrome does not have structured cloning 
support for WASM.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Is there some fundamental bug in 32 bit Chrome with regard to WebAssembly ?

[Gaurav Dewan]

Is there some known bug in wasm pages opened in 32 bit chrome ?
My Wasm based application is working fine in 32 bit firefox and all 64 bit 
browsers.
But on 32 bit Chrome, I get black patches all over the canvas(cpu rendering 
only)

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Impact of big functions on WebAssembly

[Gaurav Dewan]

Is it true that big functions have no impact on runtime performance in 
WebAssembly in first load and load of module from indexeddb cache ?
In asm.js big functions hurt the JIT since they needed to be compiled 
(O(n^2) in terms of AST nodes) 

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Documentation issue on MDN regd WASM

[Gaurav Dewan]

Refer
https://developer.mozilla.org/en-US/docs/WebAssembly/C_to_wasm#Using_a_custom_HTML_template
There is confustion regarding -o hello2.js vs -o hello2.html
Is -o hello2.js discouraged ? (it is working pretty fine if wasmBinary 
contains wasm files. Ofcourse wasm is currently downloaded fully 
(streaming) )

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

WebAssembly browsers

[Gaurav Dewan]

Hi

How can I get prerelease build of Safari and Edge which support Webassembly 
? Do I need to build those ?

Is WebAssembly supported in the below browsers:

·   - Microsoft Edge included with Insider >=15019 

·   -  Safari Technology Preview Release 22 (Safari 10.2, WebKit 
12604.1.4.2) or 24 

Her  On Safari, I got error WebAssembly.instantiate is not defined 
(although WebAssembly object is exposed) 

 - Which are the updated working demos of webassembly (except the 
webassembly.org demo)

A

W







-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Status of WebAssembly with emscripten after the version bump to 0x1

[Gaurav Dewan]

>
> It's working now
>
Thanks 

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Status of WebAssembly with emscripten after the version bump to 0x1

[Gaurav Dewan]

Anybody able to compile hello world program to webassembly now(after the 
version bump) ?
I deleted ~/.emscripten_cache and ~/.emscripten_ports folder and tried to 
build hello world program with emcc -s WASM=1 (which fetched and build 
binaryen tag 28 succesfully).
While tag 27 binaryen was working, with tag 28 (which has version bump) of 
binaryen, wasm build step is failing.


-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Profiling asm.js WebWorker

[Gaurav Dewan]

I am profiling asm.js WebWorker in Chrome (without automatic compilation to 
wasm) with --profiling-funcs option.
I noticed that for my application, "Record Allocation Profile"(memory 
allocation from JS functions) shows similar bottleneck as "Record JS CPU 
profile".
How to interpret "Allocation Profile" of Webworker as reported by Chrome ? 
Because in asm.js memory should have been allocated at start-up time.

Does it mean that that those functions are causing JS engine to get commit 
page memory from OS for some reasons: 
(1)Size of those functions may be large taking up large memory to compile 
(in chrome) ?
(2) Too much local variables in those functions or memory allocation in 
asm.js
(3) TypedArray (and arraybuffer) memory was not committed at time of 
startup but only when that page is touched in those function (heap access) 
- so that is being shown in profile as hotspot

 I still have to profile behavior in firefox where I can profile asm.js in 
only the main thread (and there will be little noise from DOM functions).
Does the above pattern sound familiar ? Is there a pattern which can 
prevent asm.js from reaching close to 2.5X performance(slower) of native 
like large functions, inlining llvm opts, or long switch case or something 
else which hurt JS performance?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Understanding contents of Mem file (asm.js)

[Gaurav Dewan]

(1) Mem file seems to contain mangled c++ symbols and "some" filepaths of 
sourcecode even in fully optimized build as seen using "strings" utility on 
memfile. Why ? Is there any utility or trick by which these symbols can be 
stripped ? I am not sure if I am using __FILE__ and func macro somewhere 
which is causing this or if it is caused by compiler internals.
(2) I can comment static intialization of tabular arrays(binary data) to 
diff the generated memfile. But is there any other systematic way(compiler 
logging, etc) to figure out what contribute to size of memfile (to see if 
size can be reduced) ?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Issue with EVAL_CTORS option

[Gaurav Dewan]

During initialization time in asm.js build, it tries to call global 
initializer of file (which should have been stripped by dead code removal, 
I guess)

With "-s EVAL_CTORS=1 -s DISABLE_EXCEPTION_CATCHING=1", no error is issued 
at build time; but generated asm file fails to run with error:
Uncaught TypeError: __GLOBAL__sub_I_regex_cpp is not a function
 at func 
at callRuntimeCallbacks 
at ensureInitRuntime
at doRun (acrobat.js:18)
at run 
at runCaller
at removeRunDependency
at applyMemoryInitializer 
at XMLHttpRequest.xhr_onload 
Interestingly,  generated WASM build (same compiler/same options except -s 
WASM=1) does not fail.

EVAL_CTORS is enabled by -Oz option automatically. 

With "-s EVAL_CTORS=1 -s DISABLE_EXCEPTION_CATCHING=0", generated asm file 
appears to work correctly. 
With "-s EVAL_CTORS=0 -s DISABLE_EXCEPTION_CATCHING=1", generated asm file 
appears to work correctly. 

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Optimization options in em++

[Gaurav Dewan]

I was investigation various optimization options by referring to here:
https://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-Code.html
https://github.com/kripken/emscripten/blob/master/src/settings.js

(1) Is there any way to debug and find the culprits which cause failure 
with ALIASING_FUNCTION_POINTERS option and fix those (that is, when not 
using -s ALIASING_FUNCTION_POINTERS=0 with O3)? What is the gain generally 
expected (size and performance) with this option ?


(2) Is FORCE_ALIGNED_MEMORY still supported?
I noticed FORCE_ALIGNED_MEMORY=1 on commandline causes toolchain error 
immediately that it is not compatible with fastcomp(latest incoming).
Anyways, WARN_UNALIGNED=1 warns about number of unaligned store including 
standard libraries like std::money_put etc - so I guess it would be very 
less useful.


-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Webassembly status

[Gaurav Dewan]

Thanks Charles

about (3) - is there any emscripten flag to generate wasm with "grow 
memory" capabilities (or is the total memory size fixed at build time) to 
reduce browser memory footprints (and not over-guess the size) ?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Webassembly status

[Gaurav Dewan]

I have Couple of questions about latest WebAssembly status

(1) I have seen that WASM works like charm in Chrome and FireFox and 
believe check-ins are happening in Chakra(Edges). What is the state (and 
any indicator of release readiness) in Safari; especially all (webkit based)* 
iOS browsers*(iphone/ipad) ? Infact asm.js is absent in ios (under 
development - but not sure of timelines)

(2) What is the current recommended way of testing Wasm support (feature 
detection) in browser ?

(3) A key thing missing in asm.js is fast "allow memory growth/shrink" 
option (true dynamic memory support upto 1 or 2 gb). Is it tacked in 
Webassembly(wasm32) in FF and Chrome efficiently -any example test-code 
(performance characteristics) ?

(4) I see the page about webassembly security on main site but I would like 
to see more papers (something like NaCl blackhat conference presentations) 
and attack vectors and mitigations. How c++ based vulnerabilities translate 
to WASM world(risk) and if separate WASM pipeline/processing opens up any 
additional attack surface (or is the attack surface/vector same as normal 
JS code) in design and browser impleentations

(5) Do we expect to see further improvements in WASM startup time in 
Chrome/FF (wasm streaming, cache, any parallelization or others) ? Or is it 
recommended to explore other avenues like wasm splitting (dynamic linking) 
based on profile/early-use-code, or any other?

[ (6) Just from theoretical point - will wasm run fine on browsers running 
on big-endian(or pdp-endian) systems ]

Thanks in advance.

Regards

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Power Consumption of Webassembly/asm.js

[Gaurav Dewan]

Being natively built into javascript engine, WebAssembly is expected to be 
power efficient.

Has anybody done analysis on power efficiency of webassembly and asm.js ?
CPU consumption/energy rating of idle asm.js tab indeed shows up as 
zero(<1); but are there any precise benchmarks/tools/methodologies/setup to 
get (repeatable-)measurements with regard to cpu consumption of these 
technologies ?
For example,is it possible to come up with a metric to compare cpu 
efficiency of "WASM vs ASM.JS vs vanilla-js vs Native app" (with similar 
functionality -idle and active usage scenario).
At the client side, I can think of power tests like observing cpu/energy 
impact of process via task/activity montor or using tracing events

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Allocating large memory in ASM.JS

[Gaurav Dewan]

What is the recommended method of allocating and reallocation large memory 
size buffers in ASM.JS build ?

We are allocating large memory (40MB and more) and on reallocation (as seen 
in memoryprofiler) the buffers keep jumping to higher location leading to 
fragmentation. 

Sometimes fragmentation is clearly visible in memoryprofiler graph(but not 
always) where tiny objects are allocated just near to huge objects so when 
huge object is reallocated, it must move to higher memory leading to large 
amount of lower memory remaining unutilized and running out of memory even 
when there is 30% actual memory use(dynamic memory as % of all free space).

Another characteristic is that running the same sequence of commands faster 
(as compared to issuing the commands slowly) causes greater degree of 
fragmentation.

Is the memory allocator (malloc/free) derived from gcc/some C runtime ? 

Can we reserve a portion of memory for chunky allocations and tiny 
allocations separately?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to debug wasm compile error in firefox - works fine in chrome

[Gaurav Dewan]

Thanks
Issue found to be fixed in today's fireforx canary build - 
51.0a1(2016-08-03)

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to debug wasm compile error in firefox - works fine in chrome

[Gaurav Dewan]

>
> Indeed it is issue with size limit of table in firefox as I can confirm 
> with wast:
>
 

> table $b0 $b0 .(same funcname repeated 2000 times) $b1 $b1 ...
>
> Chrome is able to handle atleast 500k table size (maybe there is no limit).
I also verified that when devtools are not open, chrome works fine.

>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to debug wasm compile error in firefox - works fine in chrome

[Gaurav Dewan]

Using 1.36.5 emscripten. 
em++ -O3 -s TOTAL_MEMORY=201326592 -s ALIASING_FUNCTION_POINTERS=0 -s 
BINARYEN=1 -s 'BINARYEN_METHOD="native-wasm"' -s 
'BINARYEN_SCRIPTS="spidermonkify.py"' -s GLOBAL_BASE=1000 -s 
ALIASING_FUNCTION_POINTERS=0 

Updating JS-shell used for compilation and recompiling wasm did not same to 
> change any behavior in both the browsers (latest Firefox Nightly and Chrome 
> Canary)
>
Then I Updated binaryen used for compilation and recompiled binaryen and 
wasm - 
Chrome Canary also started showing the error(on updating binaryen !) - 
out-of-bounds memory access.
Firefox Nightly showed the same error for native wasm method. I tried 
interpret-binary fallback and changed total memory to 128mb. Got following 
console output

trying binaryen method: native-wasm
failed to compile wasm module: TypeError wasm error: compile error at 
offset 10051: too many table elements
trying binaryen method: interpret-binary
wasm trap: highest > memory: 134217728 > 134217724

-s SAFE_HEAP =1 test is green in asm.js build
Changing total memory allocation in wasm build does not help
My initial thought is that some "new C++ application source code" is 
causing emscripten to generate WASM which firefox js engine parse as 
invalid. 
This "new C++ application source code" when compiled with older binaryen 
 works fine on chrome. 
And older builds (with older application source code and older binaryen) 
continue to work well in both the browsers today.

Is there any wasm-validator tool or tool from which I can map wasm 
offset/s-expression-functions to C source code/function names ? 

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Exception Handling in ASM.JS & Webassembly

[Gaurav Dewan]

>
> 2(b) 
>
 

> Seems to be quote error on Windows cmdline.
>
It prints success when following is inside makefile 
em++ whitelist.cpp -O1 -s DISABLE_EXCEPTION_CATCHING=2 -s 
EXCEPTION_CATCHING_WHITELIST='["_main"]' -o whitelist.js 
For windows cmd line following worked (it does not work in makefile though)
em++ whitelist.cpp -O1 -s DISABLE_EXCEPTION_CATCHING=2 -s 
EXCEPTION_CATCHING_WHITELIST=[\"_main\"] -o whitelist.js 

Has anyone experimented with this kind of setting and seen gains or when is 
it recommended ?
Any ideas if size can be improved?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: std::chrono::high_resolution_clock::now throwing exception in Safari (when ASM.JS is run in webworker)

[Gaurav Dewan]

>
> To reproduce, on emscripten 1.36.5 (incoming branch)
>
 
(1) here is simple test case (c.cpp)
#include 
#include 


int
main()
{
std::cout << "before" << std::endl;
auto now = std::chrono::high_resolution_clock::now();
std::cout << "after" << std::endl;
return 0;
}

(2) Compile it using
 em++ c.cpp -o c.html

(3) In generated c.js, add following line as first line (To simulate 
Safari/IE/Edge webworker environment restriction on FF/Chrome)
performance={};

Output:
Only before is printed followed by exception (some implementations of 
boost::chrono::steady_clock::now may throw exception; but here we are using 
std::chrono )

Reason:

*__ZNSt3__26chrono12steady_clock3nowEv *(_std::__2::chrono::
*steady_clock::now(*))   calls (via invoke_ii)*_clock_gettime(*clk_id 
=1,tp) 
*_clock_gettime *calls*_emscripten_get_now_is_monotonic* which return false
*_clock_gettime* then sets error number and return -1.
*__ZNSt3__26chrono12steady_clock3nowEv  *on seeing this error throws if 
exceptions are enabled *or *continue (with unexpected time value) if 
exceptions are disabled.
YES, _emscripten_get_now checks if performance exists and then uses a 
fallback but it is not called due to monotonicity test failure


Other consideration: 
As mentioned in comment, Date.now does not guarantee monotonicty and it may 
be issue depending on some implementation. An answer here indicate how 
Date.now can be forced to be monotonic:
http://stackoverflow.com/questions/7272395/monotonically-increasing-time-in-javascript



-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Exception Handling in ASM.JS & Webassembly

[Gaurav Dewan]

Currently enabling exception handling support lead to increase in size of 
optimized build (asm.js as well as wasm) by about 33% in our codebase.

(1) Will the planned Zero cost exception support in wasm shave off a 
significant size from the wasm file ?

(2) With regard to asm.js, are there ways to decrease the codesize bloat 
with regard to exception handling -

(a) One way could be to replace try, throw and catch in construct C++ code 
with equivalent sequential error handling construct. But then 
emscripten/clang toolchain would already be optimized to do the same in 
automated manner.

(b) Identifying the errors in applications which are gracefully handled and 
enable exception handling only for those workflows. This is generally 
error-prone and not maintainable way since sometimes fatal error like 
out_of_memory could be potentially handled (by freeing C++ memory or not 
performing a specific task). 
I looked at EXCEPTION_CATCHING_WHITELIST with disable exception catching = 
2 option but it appeared to be not working (throwing in try block)
em++ whitelist.cpp -O1 -s DISABLE_EXCEPTION_CATCHING=2 -s 
EXCEPTION_CATCHING_WHITELIST='["_main"]' -o whitelist.js 

> #include 
> int main(void) {
>  try {
>  throw 5;
>  }
>  catch (...) {
>  printf("SUCCESS\n"); //not printed
>  }
>  return 0;
> }
>
> I guess, even if it worked - it would not catch exceptions from nested 
function (or function pointer) calls. So it may not be that useful.

(c) Any other way to solve "this" size bloat ?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

std::chrono::high_resolution_clock::now throwing exception in Safari (when ASM.JS is run in webworker)

[Gaurav Dewan]

Based on quick read of C++ specs (although more thorough reading of C++ 
specs would be required), 
(1) std::chrono::high_resolution_clock::now is declared to be 
no-except(cannot throw exceptions). 
(2) high_resolution_-clock may be a synonym for system_clock or steady_clock

When calling this function in Safari ASM.JS worker(Mac), 
The test program is same as:
https://github.com/kripken/emscripten/issues/2980
It's just that this asm.js is loaded from javascript webworker.

Function *__ZNSt3__16chrono12steady_clock3nowE *calls 
*__ZNSt3__120__throw_system_errorEiPKc 
(via *invoke_vii).
Shouldn't emscripten fallback to Date.now() if Performance.now() is not 
implemented ?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug in source map generation of emcc?

[Gaurav Dewan]

I have seen 3 kinds of issues with source map facility here:
(1) "Unable to find original file" issue and file path in asm.js are not 
rel. To workaround this, I would make multiple copies of directory in local 
server(bring nested directories nearer to the root path) while debugging in 
chrome.
(2) Unable to debug c++ templates using source-map.To workaround this 
require putting breakpoints in ASM.js(instead of c++ code) in all the 
specialization of templated function(located using line debugging directive)
(3) Map file not getting generated in linking phase with -g4( with some 
traceback shown).

Björn, Looking forward to know if this patch addresses the first issue for 
you.

On Thursday, April 21, 2016 at 8:04:11 PM UTC+5:30, Björn K. wrote:
>
> Hi there!
>
> I've the following scenario:
>
> 1) a C library which is compiled in directory a
> 2) a C++ class which uses the library and exposes it's functionality via 
> embind
>
> The library is built via a very simple makefile which ensures -g4 als emcc 
> option. The C++ class is compiled with -g4 as well.
>
> In the end I get the following error message when compiling the C++ class 
> to :JavaScript:
> sourcemapper: Unable to find original file for mean.c at /home/.../source
> /emscripten-tests/sourcemap-test-01/mean.c
>
> Since it were very helpful to debug the behaviour of 3rd party libraries 
> which are used in my project I'd really enjoy this working...
>
> For reproduction I've put the simple project online here:
> https://github.com/cee-dee/emscripten-tests/tree/master/sourcemap-test-01
> Note: When putting the sourcecode of the library into the same directory 
> as the C++ class everything works fine.
>
> Anyone here who can help me out?
>
> Best regards,
> Björn
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Webassembly Startup Time too high

[Gaurav Dewan]

>
> Thanks for comprehensive explanation. I now reckon that we will see 
> browser improvements in startup time.
>
 
 I will look at the timing data of webassembly based webpage startup to 
verify there is no other surprise angle here.The main thread cannot do much 
more than showing progressbar until the cpu/memory intensive single wasm 
file is downloaded fully and loaded into memory.  Single WASM cannot in 
general be broken down into multiple WASM files(not many portable C++ 
projects would be designed to look at on-demand dynamic loading as means of 
increasing startup performance). I guess, the whole WASM file needs to be 
downloaded into Module.wasm variable and instantiateModuled  before "any" 
WASM function can be invoked (not read the mvp specs). 
 

> BTW, is there any forum(w3c working group or webassembly specific forums) 
> or bug tracker using which I can remain updated on browser webassembly 
> progress ?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Webassembly Startup Time too high

[Gaurav Dewan]

I have noticed that webassembly application startup time is too slow as 
compared to ASM.JS application(even when the whole wasm file is loaded from 
cache. The slow startup is not due to network download.).
Once the webpage has loaded fully then the webpage interaction with user is 
very fast. But the primary concern is slow startup(1.5 times slower than 
ASM.js).
Both chrome canary and firefox nightly exhibit this behavior.
Is it AsDesign or any 3x improvement planned in this area from browser side?
Do browser validate Webassembly and take large time in the process or is 
there any option to  ask browser to speed up?

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to compile asm.js to webassembly

[Gaurav Dewan]

ok SIMD type and intrinsic are not part of webassembly MVP 
(https://github.com/WebAssembly/design/blob/master/MVP.md)
We could add a bug/task for the toolchain (asm2wasm and earlier tool(if 
they know we are targeting webassembly)) could generate warnings/errors 
about use of unsupported features/modules giving 
meaningful information on how to spot such code and correct it.

On Wednesday, April 13, 2016 at 7:15:31 PM UTC+5:30, Gaurav Dewan wrote:
>
> Lack of SIMD support in asm2Wasm (or webassembly specs & implementation) - 
> is it a bug ? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to compile asm.js to webassembly

[Gaurav Dewan]

Lack of SIMD support in asm2Wasm (or webassembly specs & implementation) - 
is it a bug ? 

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable to compile asm.js to webassembly

[Gaurav Dewan]

>
> EMCC_DEBUG=1 showed emcc output but did not logged any output from 
> asm2wasm internals(asm2wasm -d option did that). 
>
I found abort was called in asm2wasm because it appears that only float, 
double,int, none datatype are supported in asm.js module currently(function 
AsmType wasmToAsmType(WasmType type).
During wasming step of asm2wasm tool, "$198" local variable inside a 
function was of type ASM_FLOAT32X4. 
Inside asm2wasm.h Function* Asm2WasmBuilder::processFunction(Ref ast)
---snip begin---
 unsigned start = params->size();
  while (start < body->size() && body[start][0] == VAR) {
Ref curr = body[start];
for (unsigned j = 0; j < curr[1]->size(); j++) {
  Ref pair = curr[1][j];
  IString name = pair[0]->getIString();
  *AsmType asmType = detectType(pair[1], nullptr, true, Math_fround); 
//This returned ASM_FLOAT32X4 for "*  function->locals = $198 
function->name=somefloatingpointfunction
  function->locals.emplace_back(name, asmToWasmType(asmType));
  functionVariables.insert(name);
  asmData.addVar(name, asmType);
}
start++;
  }
---snip end---

I looked at "somefloatingpointfunction" in my source code(after demangling) 
and the corresponding code in file.asm.js that $192 was SIMD_Float32x4. It 
appeared only 2 function were using SIMD support.
I removed the SIMD architecture specific code and rebuilt the bc file for 
that library and on linking that bc file, webassembly was finally getting 
generated. (Now asm.js contain no SIMD too)
The webassembly worked like charm in both the browsers.

I found that initial load time (via webassembly) is very slow (Even when 
all files are cached in browser and no request is sent to server) but 
afterwards it runs faster. This behavior is noticable with other 
webassembly demos like unity etc too. Not sure if it is design limitation 
of webassembly or work in progress

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Unable to compile asm.js to webassembly

[Gaurav Dewan]

I have a large C++ project. I am able to compile it to asm.js and load it 
in browser.
But I am unable to compile it to web assembly  ( I am linking multiple 
libraries(bc files) ) I get following error in make: (Basically asm2wasm is 
failing with error 6 or -6). Any idea what it means and how to fix it?

An pointers for debugging it into asm2wasm source code. (I have not looked 
up the source yet though)

Command:

em++ -O1 -s TOTAL_MEMORY=134217728 -s DISABLE_EXCEPTION_CATCHING=1 -s 
BINARYEN=1 -s 'BINARYEN_METHOD="native-wasm"' -s 
'BINARYEN_SCRIPTS="spidermonkify.py"' -s GLOBAL_BASE=1000 -s 
ALIASING_FUNCTION_POINTERS=0  boost_new.bc sample.bc -o ./plugin.html
//I am using javascript engine from firefox nightly code. Do I need to try 
chrome V8 for this issue?

Error

Traceback (most recent call last):

  File 
"/Users/test/scratch/fips-sdks/osx/emsdk_portable/emscripten/incoming/em++", 
line 13, in 

emcc.run()

  File 
"/Users/test/scratch/fips-sdks/osx/emsdk_portable/emscripten/incoming/emcc.py", 
line 1864, in run

subprocess.check_call(cmd, stdout=open(wasm_text_target, 'w'))

  File 
"/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
 
line 540, in check_call

raise CalledProcessError(retcode, cmd)

subprocess.CalledProcessError: Command 
'[u'/Users/test/scratch/binaryen/bin/asm2wasm', './plugin.asm.js', 
'--mapped-globals=./plugin.wast.mappedGlobals', 
'--total-memory=134217728']' returned non-zero exit status -6


Debugging steps:

I tried with -O0 and -O1 in linker command line but same result.If I remove 
sample.bc and replace it with simple.bc (which just contain hello world 
printf), It works fine and work in both chrome canary and firefox nightly.

Is it caused due to some specific C++ feature(code generation in asm.js) or 
large file size ?


I am using latest stable version of emscripten(main branch) to generate bc 
files. And for linking those bc files(and to generate web assembly file) I 
am using incoming branch of emscripten. I guess bc file contents would just 
be matter of clang compiler and it is only for linking step(to generate 
javascript or web assembly) that I need to use incoming branch.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.