Vim.js with EMTERPRETER

97 views
Skip to first unread message

Lu Wang

unread,
Mar 3, 2015, 11:32:57 PM3/3/15
to emscripten-discuss
Hi all,

   Recently I tried EMTERPRETER on Vim.js, and I got this: http://coolwanglu.github.io/vim.js/emterpreter/vim.html

   I was compiling using -s EMTERPRETIFY=1 -s EMTERPRETIFY_ASYNC=1, without any WHITELIST or BLACKLIST, which means all the functions are interpreted? The file size is reduced significantly, comparing with the 26M monster-sized ASM.js version, this version with EMTERPRETER is only 2.5M, which improves the startup time a lot.

  While I was planning to optimize after making it work, I found the performance is good enough, I don't feel any delay for normal navigation or editing operations, but it does become slightly slower for commands like `%s/^/hello/g`, which inserts 'hello' at the beginning of each line.

  This interpreter is surprisingly faster than I had expected, probably there were already lots of async operations in Vim maybe? Anyway I'm quite happy with this new technique!

  Thanks!


   regards,
   - Lu
  

Floh

unread,
Mar 4, 2015, 6:11:38 AM3/4/15
to emscripte...@googlegroups.com
Wow, that's impressive! Startup is basically instant for me, here are the timings (with disabled browser cache):



The huge difference in compiled size is actually strange, Alon mentioned in a tweet that the compressed size is similar. Did you compile the asm.js version with one of the size-reduction options (like -Oz?)? In my experience, uncompressed asm.js is about 5x bigger compared to native code, and when gzipped, the difference nearly vanishes.

Cheers,
-Floh.

Floh

unread,
Mar 4, 2015, 6:19:25 AM3/4/15
to emscripte...@googlegroups.com
Aerhm, for some reason the embedded screenshot didn't make it and uploading doesn't work either at the moment :/

The timings from the Firefox network tools panel are (uncached) are:

92ms for vim.js at 704.52 KB and 392ms for vim.js.mem at 1,534.38 KB. The unrelated stuff actually took longer: 'forkme_on_github' PNG: 724ms, api.github.com callback: 265ms, etc...

Great work! :)
-Floh.

王璐

unread,
Mar 4, 2015, 7:13:46 AM3/4/15
to emscripte...@googlegroups.com
Sorry I didn't make it clear, the previous version was with the ASYNCIFY version, which is likely to increase the size. Even 10x increase could be common.

There are ways of reducing size for ASYNCIFY, but it could be quite complicated.


regards,
- Lu

Floh

unread,
Mar 4, 2015, 10:53:37 AM3/4/15
to emscripte...@googlegroups.com
Ah ok I see, the old ASYNCIFY explains why the code is so big. I wonder if it is worth it or even possible to isolate the pieces that need asyncify, and only run those through the emterpreter, while the majority of code would be compiled to asm.js :)

-Floh.

キャロウ マーク

unread,
Mar 4, 2015, 7:56:51 PM3/4/15
to emscripte...@googlegroups.com

> On Mar 4, 2015, at 8:19 PM, Floh <flo...@gmail.com> wrote:
>
> Aerhm, for some reason the embedded screenshot didn't make it and uploading doesn't work either at the moment :/
>

It did make it to my inbox. Perhaps your mail client has a problem.

Regards

-Mark


Alon Zakai

unread,
Mar 4, 2015, 10:51:11 PM3/4/15
to emscripte...@googlegroups.com
Wow, that is faster than I would expect (both startup and later)! Yes, without a blacklist or whitelist, it is 100% in the interpreter.

With blacklist it could probably be even faster. Actually, I'd be curious how the emterpreter static analysis does, if you feel like trying it,

https://github.com/kripken/emscripten/wiki/Emterpreter#static-analysis

I wonder if the size of the list will be most of the program, which I think was the case with asyncify? The difference might that the emterpreter analysis uses function pointer types, which I think asyncify didn't (but could add)?

- Alon


--
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-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Lu Wang

unread,
Mar 5, 2015, 12:50:21 AM3/5/15
to emscripten-discuss
I remembered that we have pessimistic analysis for function pointers, and we left that on for safety.
I'll do a static analysis later. I wonder if it can be integrated, i.e. I trust emscripten such that it will decide which functions to be interpreted and which are not, instead of copying the arguments and paste to emscripten every time.


regards,
- Lu


--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/yfvDabeq8TM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.

Lu Wang

unread,
Mar 5, 2015, 4:44:22 AM3/5/15
to emscripten-discuss
The output of EMTERPRETER_ADVISE is "67% out of 2554 functions", which agrees with our previous conclusion with Asyncify.


regards,
- Lu

Alon Zakai

unread,
Mar 5, 2015, 12:29:35 PM3/5/15
to emscripte...@googlegroups.com
Thanks for checking. I guess vim just has a lot of synchronous stuff happening...

- Alon

Reply all
Reply to author
Forward
0 new messages