Hi Alon,
Thank you for your suggestions, but I can't build asm.js with *incoming*
(on Windows), only with *latest*.
Not sure what the problem is, since building wasm works fine.
When I compile my sample without `-s WASM=1`, simply as:
emcc t.cpp -std=c++14 -O3 -o index.html
I get the following error (after successfully building libcxx_noexcept.a,
libcxxabi.bc, libc.bc, and dlmalloc.bc):
INFO:root:generating system library: dlmalloc.bc... (this will be cached in
"C:\Users\boris\.emscripten_cache\asmjs\dlmalloc.bc" for subsequent builds)
INFO:root: - ok
Traceback (most recent call last):
File "C:\Util\Emscripten\emscripten\incoming\\emcc", line 13, in <module>
emcc.run()
File "C:\Util\Emscripten\emscripten\incoming\emcc.py", line 1958, in run
JSOptimizer.flush()
File "C:\Util\Emscripten\emscripten\incoming\emcc.py", line 1854, in flush
run_passes(chunks[0], title, just_split=False, just_concat=False)
File "C:\Util\Emscripten\emscripten\incoming\emcc.py", line 1827, in
run_passes
final = shared.Building.js_optimizer(final, passes, debug_level >= 4,
JSOptimizer.extra_info, just_split=just_split, just_concat=just_concat)
File "C:\Util\Emscripten\emscripten\incoming\tools\shared.py", line 1828,
in js_optimizer
ret = js_optimizer.run(filename, passes, NODE_JS, debug, extra_info,
just_split, just_concat)
File "C:\Util\Emscripten\emscripten\incoming\tools\js_optimizer.py", line
559, in run
return temp_files.run_and_clean(lambda: run_on_js(filename, passes,
js_engine, source_map, extra_info, just_split, just_concat))
File "C:\Util\Emscripten\emscripten\incoming\tools\tempfiles.py", line
78, in run_and_clean
return func()
File "C:\Util\Emscripten\emscripten\incoming\tools\js_optimizer.py", line
559, in <lambda>
return temp_files.run_and_clean(lambda: run_on_js(filename, passes,
js_engine, source_map, extra_info, just_split, just_concat))
File "C:\Util\Emscripten\emscripten\incoming\tools\js_optimizer.py", line
451, in run_on_js
filenames = pool.map(run_on_chunk, commands, chunksize=1)
File
"C:\Util\Emscripten\python\2.7.5.3_64bit\lib\multiprocessing\pool.py", line
250, in map
return self.map_async(func, iterable, chunksize).get()
File
"C:\Util\Emscripten\python\2.7.5.3_64bit\lib\multiprocessing\pool.py", line
554, in get
raise self._value
WindowsError: [Error 2] The system cannot find the file specified
Thank you for your help,
Boris
On Monday, January 2, 2017 at 6:20:39 PM UTC-7, Alon Zakai wrote:
>
> First thing I would check is that asm.js on incoming is the same as asm.js
> from before, just to remove one possible difference.
>
> If that's not it, then try to build to wasm in imprecise mode, -s
> BINARYEN_IMPRECISE=1. Some details and discussion here:
> https://github.com/kripken/emscripten/issues/4625
>
> If that's not it, then it might be a libc difference. We build libc
> differently for wasm for various reasons. Looking at profiles from asm.js
> and wasm should show a noticeable difference if that's the case.
>
> On Mon, Jan 2, 2017 at 4:18 PM, Boris Sergeev <[email protected]
> <javascript:>> wrote:
>
>> Happy New Year everybody!
>>
>> I've encountered some weirdness in *WebAssembly* vs. *asm.js*
>> performance comparison and I'm wondering if I'm doing something wrong...
>>
>> 1. I've compiled some simple computationally intensive code (calculation
>> of Pi to 10,000 digits with Rabinowitz & Wagon spigot algorithm) as x64
>> with VS2015 Microsoft's compiler and Clang in Windows, then with Clang 4.0
>> & libcpp in Ubuntu 14.04 (Windows 10 Ubuntu subsystem) and got very close
>> results: about 6.7 seconds.
>>
>> 2. Then I compiled this code to *asm.js* with Emscripten latest and -O3
>> flag and ran it in the latest released Chrome (8.7 sec) and Nightly (7
>> sec). Impressively close to the native speed!
>>
>> 3. Finally, I installed Emscripten incoming, which uses Clang 3.9, and
>> compiled my code:
>> emcc t.cpp -std=c++14 -O3 -s WASM=1 -o index.html
>> Running the resulting *WebAssembly* code in Nightly produced the
>> following console output:
>> trying binaryen method: native-wasml
>> binaryen method succeeded.
>> and took almost 15 seconds.
>> In Canary, it took almost 17 seconds.
>>
>> The time was measured only for the Pi calculation:
>>
>> int main(int argc, char** argv)
>> {
>> Stopwatch<> sw;
>> Pi::calculate(10000);
>> sw.stop();
>> std::cout << sw.elapsed()/1.0e+6 << " seconds\n";
>> }
>>
>> So, any asm.js or wasm translation time shouldn't affect the numbers...
>>
>> What is wrong here???
>>
>> Thank you,
>> Boris
>>
>>
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
