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.
>
> http://mzh.im/gambit-in-nacl/
>
> * 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