An Introduction to JS-Ctypes

[Andrea Giammarchi]

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



>
> 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.




>
> 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.

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.



>
> 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? But at this point I don't care much since this extension brings
JS.next without JS.next optimizations



>
> 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?



>  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



>
> 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?




>  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.

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?

How can engines optimize that the moment somebody would think that rather
than create an object per each instance a generic object could be reused,
same as is for defineProperty/ies ?

var once = {};

for loop
    once.x = 1;
    once.y = 2;
    new Point2D(once)

Please let me understand how this can be a solution in therms of
performances, thanks.

Best Regards,
    Andrea Giammarchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110917/fecebee4/attachment.html>