An Introduction to JS-Ctypes

[Sam Tobin-Hochstadt]

On Sat, Sep 17, 2011 at 2:34 PM, Andrea Giammarchi
<andrea.giammarchi at gmail.com> wrote:
> First of all thanks for clarifications ... as I have said, js-ctypes
> extension looked way too similar to what Brendan showed in his slides.
> In any case, there are still a couple of confusing points to me and yes, I
> will update my post as soon as these things are clear.
> For example ...
>
>>
>> 1. Binary Data, a spec for handling bit-level encodings of various
>> values.  This is related to Typed Arrays, another spec that's shipping
>> already in some browsers.
>
> precisely, these are indeed part of the benchmark code: Int32Array
> Also I have explicitly slowed down the logic creating a "classic" literal JS
> object per each loop iteration ... still, way too slow performances so
> whatever js-ctypes has been created for, something went wrong, imo

The benchmark code you posted doesn't show how you use Int32Array, so
I can't say anything definitive about it, but again, Int32Array is
part of the Typed Arrays system, which is *not the same* as js-ctypes.
 They are for totally different things.

>> 2. js-ctypes, which is a foreign function interface for JS in Firefox.
>> This is used for calling host libraries using the native platform
>> (C-based) calling convention.  If you're coming from a python
>> background, it's very similar to, and named after, the 'ctypes'
>> library.
>
> Still way too similar to what JS.next is proposing ... but I am actually
> glad this js-ctypes "thingy" is not the JS.next purpose.

No, this is *not similar at all* to what is proposed for ES.next.
js-ctypes is an FFI, which is not related at all to any ES.next
proposal.

>> 3. Cython, a restricted dialect of Python that compiles to C for
>> performance.
>
> And with TraceMonkey/tracer/whatever I would expect natively optimized JS
> structures and collections since it's about defining static type *into* JS
> world, regardless the fact C will use them for its purpose.

TraceMonkey does not add static types to JavaScript.  TraceMonkey is a
system for dynamic optimization of JavaScript code, based on its
runtime behavior.  Static types have nothing to do with it.

> Again, glad I have used the only way I had to test this stuff and this is
> not what we gonna have on JS world.

What you tested was not at all like what you thought you were testing,
or what you wrote about.

>> These are all totally different things.  Your blog post compares 2 and
>> 3, and then draws conclusions about 1.  If you want to benchmark
>> js-ctypes against something from Python, you should benchmark it
>> against ctypes, although they both use the same underlying library,
>> libffi, so the results probably won't be that different.
>
> If I compare Cython with js-ctypes I bet Cython will be faster ... then
> again, why?

Because Cython is a compiler from a restricted subset of Python,
annotated with static types, and js-ctypes is an FFI.  The point of
js-ctypes is to bind to an existing C library, which you do not do in
your blogpost.

> But at this point I don't care much since this extension brings
> JS.next without JS.next optimizations

js-ctypes has nothing to do with anything in ES.next.

>> There is currently no high-performance implementation of the Binary
>> Data spec, so it can't be usefully benchmarked at this point.
>
> at which point it will be useful to benchmark them then?
> Also why nobody gave me an answer about double memory/object allocation per
> each typed instance?

I'm sure that when browsers ship optimized implementations of Binary
Data, that will be widely announced.

>>
>>  Typed
>> Arrays does have high-performance implementations currently.  There's
>> also no analogue of Cython of JS, because the JS implementation
>> community has focused on making fast implementations of all of
>> JavaScript, rather than limiting the language.
>
> and this is good, indeed Int32Array is part of my benchmark

Int32Array is not for the same sort of thing as Cython.

>> Finally, your use of the Function constructor prevents many
>> optimizations -- don't do that in JavaScript code that you want to be
>> high-performance.
>
> NWMatcher is the fastest DOM engine out there and it's based on this trick
> ... I wonder why engines can optimize runtime but these cannot optimize
> runtime runtime created stuff ... in any case, check those functions, these
> can rarely be faster in JagerMonkey since only necessary checks are
> performed so that a tracer will optimize once rather than twice or more ...
> am I wrong?

DOM interaction will almost certainly dominate the performance of
anything like NWMatcher, so the performance of eval is unlikely to be
the issue here.

>>  There's an excellent overview of how to write
>> high-performance JavaScript code by David Mandelin here:
>>
>> http://blog.mozilla.com/dmandelin/2011/06/16/know-your-engines-at-oreilly-velocity-2011/
>
> this has been linked in the post itself and I know those slides and I have
> asked him personally questions ... questions that I really would like to
> understand in this ML before I update my post so that I can provide a proper
> feedback about my doubts.

However, you don't seem to have fully read the slides.  As he says "Do
not use [eval] anywhere near performance sensitive code".  The
Function constructor is a version of |eval|.

> Once again, why once a struct has been defined we need to create per each
> instance its counterpart in native JS ?
>
> new Point2D({x: 1, y: 2}) ... why?
> what's wrong with a *shimmable*
> new Point2D(x = 1, y = 2)
> so that no object has to be created?

You'd need a benchmark that shows that the object allocation you're
avoiding here is worth the lack of flexibility.
-- 
sam th
samth at ccs.neu.edu