Hi,
The extra cost could be brought by sandboxing (protected jmp) and different computing architect. In my macbook air the native interpreter runs (pi 10000) for 182ms with a 64bit compilation while it take 403ms in nativeclient with a 32bit compilation(native client run 32 bit code on an osx)
Currently there's no directly way to interact with DOM, though nacl module could interact with javascript with PostMessage / HandleMessage primitives thus affect the DOM.
Thanks Meng
On Tue Feb 04 2014 at 9:28:01 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
On Feb 3, 2014, at 6:46 AM, Zhang Meng wsxiaoys.lh@gmail.com wrote:
Hi, Marc
It has been quite a long time since the last discussion in Silicon
Valley and I finally got some spare time to complete it during the Lunar new year Holiday.
- HTML5 local storage is mount at /mnt/html5
- http://mzh.im/gambit-in-nacl/scm/ is mounted at /mnt/http, the pi
example is loaded with it.
Enjoy! Meng
Happy new year to you!
The Gambit NACL port is very cool!
I did a very quick performance testing using (pi 10000) and, on Chrome, gambit-in-nacl is about 36 times faster than gambit-in-the-browser ( http://feeley.github.io/gambit-in-the-browser) which is compiled with emscripten. On the other hand, the native Gambit interpreter on my machine runs (pi 10000) about 4 times faster than gambit-in-nacl.
Note that these are not definitive figures because these 3 instances of Gambit were not compiled with the same configure options, C compiler, C optimization levels and word width. I know that gambit-in-nacl was compiled with -O2, and gambit-in-the-browser could not be compiled to use single-host mode and indirect branches (because of an issue with emscripten).
Do you have an idea why compiling with NACL gives a 4x slowdown compared to native compilation?
Also, is there a way for Scheme code to interact with the DOM?
Marc