Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 11:12 PM, Andrea Giammarchi wrote:
right, that's nice, just wonder if at that time to pass an object will be
slightly ambiguous
function fn({a: a = {}, b: b = true}) { ... }
fn(genericObject) will fail as first argument so that
No, that would not fail. There is no requirement that the caller pass an object
expressed as a literal.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
right, that's nice, just wonder if at that time to pass an object will be
slightly ambiguous
function fn({a: a = {}, b: b = true}) { ... }
fn(genericObject) will fail as first argument so that
fn({a: genericObject}) will be necessary
If these things are optimized on engine levels then who cares, same as I
would not care about
StructType({x: 1, y: 1})
if engines are smart enough to understand the purpose of that unreferenced
object is to initialize a static type
In that case 90% of my worries about typed stuff are gone so, good stuff.
Regards,
Andrea
On Sun, Sep 18, 2011 at 6:26 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 18, 2011, at 12:09 PM, Andrea Giammarchi wrote:
I know it's the same, for this reason I said it was shimmable
New syntax would be fine as long as minifiers won't break everything so ...
as long as minifiers are compatible, but this is an extra story I guess,
also it's not fundamental it's just nicer addiction since many libs are
using single object as function argument to obtain similar behavior
fn({a: 1, b: 2})
and back to the too many objects created due lack of defaults/named
arguments trap ...
For this style of parameter-object passing, ES6 destructuring helps. The fn
function would be declared:
function fn({a, b}) {...}
This is already supported in SpiderMonkey in Firefox, but ES6 adds a
feature wanted for defaulting missing properties:
function fn({a = 1, b = 2}) {...}
(long-hand is function fn({a: a = 1, b: b = 2}) {...}).
That way you can call fn({a: 3}) or fn({b: 4}) and have the missing
property filled in with its default value.
Optimizing implementations can avoid creating the object passed as an
actual parameter by specializing when inlining or caching.
This parameter-object style is already popular. With destructuring +
parameter default values, it tends to take away the motivation for keyword
parameters of the kind you sought.
Never mind, this is not for this thread.
It's ok, we can change the subject if necessary to fork a sub-thread.
/be
Best Regards,
Andrea Giammarchi
On Sun, Sep 18, 2011 at 3:14 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich bren...@mozilla.comwrote:
The point is that you don't *have* to pass a fresh object literal to each
constructor call.
/be
I know Brendan, my point is that I can predict devs will do every time
we'll see
Thanks for other reply, I thought named arguments where proposed tho ...
any chance we can discuss this somehow ? ( not here )
Can't use =, that is just the assignment operator, so
foo(a = 1, b = 2)
is the same as
(a = 1, b = 2, foo(a, b))
We'd need some new operator or punctuator, e.g.
foo(a: 1, b: 2)
or
foo(a = 1, b = 2) // clashes with arrow function syntax
Anyway, this only helps for the top ply of the object/array tree
containing values to store as binary data. You'd still have object and array
literals starting one ply down.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich bren...@mozilla.com wrote: The point is that you don't *have* to pass a fresh object literal to each constructor call. /be I know Brendan, my point is that I can predict devs will do every time we'll see Thanks for other reply, I thought named arguments where proposed tho ... any chance we can discuss this somehow ? ( not here ) Cheers ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote: On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich bren...@mozilla.com wrote: The point is that you don't *have* to pass a fresh object literal to each constructor call. /be I know Brendan, my point is that I can predict devs will do every time we'll see Then they'll optimize. Developers know how to make code fast, just by A-B testing and folklore, if not by profiling. The problem for JS is when performance is unpredictable, i.e., when optimization faults happen. This isn't analogous. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
I know it's the same, for this reason I said it was shimmable
New syntax would be fine as long as minifiers won't break everything so ...
as long as minifiers are compatible, but this is an extra story I guess,
also it's not fundamental it's just nicer addiction since many libs are
using single object as function argument to obtain similar behavior
fn({a: 1, b: 2})
and back to the too many objects created due lack of defaults/named
arguments trap ...
Never mind, this is not for this thread.
Best Regards,
Andrea Giammarchi
On Sun, Sep 18, 2011 at 3:14 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich bren...@mozilla.com wrote:
The point is that you don't *have* to pass a fresh object literal to each
constructor call.
/be
I know Brendan, my point is that I can predict devs will do every time
we'll see
Thanks for other reply, I thought named arguments where proposed tho ...
any chance we can discuss this somehow ? ( not here )
Can't use =, that is just the assignment operator, so
foo(a = 1, b = 2)
is the same as
(a = 1, b = 2, foo(a, b))
We'd need some new operator or punctuator, e.g.
foo(a: 1, b: 2)
or
foo(a = 1, b = 2) // clashes with arrow function syntax
Anyway, this only helps for the top ply of the object/array tree
containing values to store as binary data. You'd still have object and array
literals starting one ply down.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 12:09 PM, Andrea Giammarchi wrote:
I know it's the same, for this reason I said it was shimmable
New syntax would be fine as long as minifiers won't break everything so ...
as long as minifiers are compatible, but this is an extra story I guess, also
it's not fundamental it's just nicer addiction since many libs are using
single object as function argument to obtain similar behavior
fn({a: 1, b: 2})
and back to the too many objects created due lack of defaults/named
arguments trap ...
For this style of parameter-object passing, ES6 destructuring helps. The fn
function would be declared:
function fn({a, b}) {...}
This is already supported in SpiderMonkey in Firefox, but ES6 adds a feature
wanted for defaulting missing properties:
function fn({a = 1, b = 2}) {...}
(long-hand is function fn({a: a = 1, b: b = 2}) {...}).
That way you can call fn({a: 3}) or fn({b: 4}) and have the missing property
filled in with its default value.
Optimizing implementations can avoid creating the object passed as an actual
parameter by specializing when inlining or caching.
This parameter-object style is already popular. With destructuring + parameter
default values, it tends to take away the motivation for keyword parameters of
the kind you sought.
Never mind, this is not for this thread.
It's ok, we can change the subject if necessary to fork a sub-thread.
/be
Best Regards,
Andrea Giammarchi
On Sun, Sep 18, 2011 at 3:14 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 18, 2011, at 5:07 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich bren...@mozilla.com wrote:
The point is that you don't *have* to pass a fresh object literal to each
constructor call.
/be
I know Brendan, my point is that I can predict devs will do every time
we'll see
Thanks for other reply, I thought named arguments where proposed tho ... any
chance we can discuss this somehow ? ( not here )
Can't use =, that is just the assignment operator, so
foo(a = 1, b = 2)
is the same as
(a = 1, b = 2, foo(a, b))
We'd need some new operator or punctuator, e.g.
foo(a: 1, b: 2)
or
foo(a = 1, b = 2) // clashes with arrow function syntax
Anyway, this only helps for the top ply of the object/array tree containing
values to store as binary data. You'd still have object and array literals
starting one ply down.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
The Mozilla implementation is probably not optimized and is intended only for testing purposes. However, I agree with you on some points like typechecking and double memory consumption during initialization. From: Andrea Giammarchi Sent: Saturday, September 17, 2011 10:12 AM To: es-discuss@mozilla.org Subject: An Introduction to JS-Ctypes my thoughts, my benchmark, and my worries about JS.next StructType and ArrayType: http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html I know current Mozilla implementation is not exactly what will be in JS.next but it was the only way I had to test efficiency of this proposal and performances speaking it looks like an epic fail so far and please feel free to correct me as much as possible, thanks. Best Regards, Andrea Giammarchi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sat, Sep 17, 2011 at 4:12 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: my thoughts, my benchmark, and my worries about JS.next StructType and ArrayType: http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html This blog post is confusing 3 different things, and thus coming to wrong conclusions: 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. 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. 3. Cython, a restricted dialect of Python that compiles to C for performance. 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. There is currently no high-performance implementation of the Binary Data spec, so it can't be usefully benchmarked at this point. 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. Finally, your use of the Function constructor prevents many optimizations -- don't do that in JavaScript code that you want to be high-performance. 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/ -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
Andrea; On 17 September 2011 04:12, Andrea Giammarchi andrea.giammar...@gmail.comwrote: I know current Mozilla implementation is not exactly what will be in JS.next but it was the only way I had to test efficiency of this proposal and performances speaking it looks like an epic fail so far and please feel free to correct me as much as possible, thanks. I ... just don't know where to begin. JS-CTypes is a foreign-function interface for SpiderMonkey. It's purpose is to allow JavaScript programs to execute code in native C libraries. It was developed so that extension developers could call into native libraries without shipping binary extensions, thus improving extension compatibility from one version of the browser to another. In order to know how to pass arguments to C functions, you need to know the data types, so some special JS Objects were created to host the data and carry type information with them. I don't understand why you expect these special-purpose JS objects to be faster than JS values at storing numbers. Of course they are going to be slower. Similarly, I don't understand why you would compare JS-CTypes with Cython. A much better analogue is Python's CTypes. *check all properties, check all types, convert them into C compatible structs, bring them back to JS world per each index access* ... I mean, this cannot be the way to make things faster. Of course not, don't be ridiculous. It is not the way to make JS faster. It is the way to make JS interoperate with C libraries. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 17, 2011, at 2:34 PM, Andrea Giammarchi wrote:
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
Why are you doing that? I mean this, from your ctypes.perf.html:
for (var t = new Date, i = 0, length = npoints.length; i length; i += 2) {
window.lastPoint = {x: npoints[i], y: npoints[i + 1]};
}
Don't make an object per loop iteration, instead assign to .x and .y separately.
Anyway, the ctypes performance bug you're reporting does not predict binary
data perf. Ctypes as a privileged FFI for SpiderMonkey, based on Python ctypes,
was just brought up recently (in the life of SpiderMonkey). The JITs do not
optimize for it as they do for typed arrays. Please file it at
bugzilla.mozilla.org with your testcase. Thanks,
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sat, Sep 17, 2011 at 2:34 PM, Andrea Giammarchi andrea.giammar...@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
Re: An Introduction to JS-Ctypes
On Sep 17, 2011, at 2:54 PM, Sam Tobin-Hochstadt wrote: 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|. An exception, or special case if you will: using Function or eval up front, hoisted and common'ed out of loops, and (this is crucial) not called from a function that you want optimized, in order to generate optimized JS. This kind of query optimization or JS-in-JS specialization is done, e.g. by ExtJS and other Ajax libraries. Also by a simple assembly-to-JS trace compiled emulator that Robert O'Callahan blogged about here: http://robert.ocallahan.org/2010/11/implementing-high-performance-emulator_01.html /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 17, 2011, at 3:02 PM, Brendan Eich wrote: An exception, or special case if you will: using Function or eval up front, hoisted and common'ed out of loops, and (this is crucial for eval, I meant to write here. ) not called from a function that you want optimized, in order to generate optimized JS. This kind of query optimization or JS-in-JS specialization is done, e.g. by ExtJS and other Ajax libraries. Also by a simple assembly-to-JS trace compiled emulator that Robert O'Callahan blogged about here: http://robert.ocallahan.org/2010/11/implementing-high-performance-emulator_01.html /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
Brendan I wrote I did it on purpose trying to predict what JS devs will do
once JS.next will bring ctypes like syntax.
I wrote the object with properties only assigned too indeed but as is for
functions expressions usually created everywhere by common developers rather
than reused where possible I bet devs will do the same if that will land in
JS.
I will file the bench at mozilla soon, thanks.
On Sat, Sep 17, 2011 at 8:43 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 17, 2011, at 2:34 PM, Andrea Giammarchi wrote:
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
Why are you doing that? I mean this, from your ctypes.perf.html:
for (var t = new Date, i = 0, length = npoints.length; i length; i +=
2) {
window.lastPoint = {x: npoints[i], y: npoints[i + 1]};
}
Don't make an object per loop iteration, instead assign to .x and .y
separately.
Anyway, the ctypes performance bug you're reporting does not predict binary
data perf. Ctypes as a privileged FFI for SpiderMonkey, based on Python
ctypes, was just brought up recently (in the life of SpiderMonkey). The JITs
do not optimize for it as they do for typed arrays. Please file it at
bugzilla.mozilla.org with your testcase. Thanks,
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
Can we at least agree that if some extension brings *exactly* same constructor name, StructType and ArrayType, and more or less exactly the same signature/usage of what Brendan showed in his slides it become kinda natural to compare/test/confuse these two different implementations for different purposes ? What would you expect from a namespace.Array constructor if not something similar or exactly the Array constructor we are all familiar with ? On Sat, Sep 17, 2011 at 8:54 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Sat, Sep 17, 2011 at 2:34 PM, Andrea Giammarchi andrea.giammar...@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
Re: An Introduction to JS-Ctypes
On Sep 17, 2011, at 10:34 PM, Andrea Giammarchi wrote: Brendan I wrote I did it on purpose trying to predict what JS devs will do once JS.next will bring ctypes like syntax. My objection is that you're confounding test2 by adding object literal overhead to each loop iteration, in addition to typed array accesses. You want to focus on just the typed array accesses, from what I can tell of your benchmark. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 17, 2011, at 10:39 PM, Andrea Giammarchi wrote: Can we at least agree that if some extension brings *exactly* same constructor name, StructType and ArrayType, and more or less exactly the same signature/usage of what Brendan showed in his slides it become kinda natural to compare/test/confuse these two different implementations for different purposes ? Your blog mixes things together based on less than names being the same -- why did you drag in Cython? Anyway, please take the point that Mozilla SpiderMonkey's jsctypes FFI has had no JIT optimizations at all, unlike the nearby typed arrays implementation -- and that ES6 binary data is an extension of the latter, not anything to do with the former. Can we at least agree that you were connecting dots that have no dashed lines between them? Yes. Common names recur in many places in JS, but namespaced somehow. This case is no different. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 17, 2011, at 10:48 PM, Andrea Giammarchi wrote: So here I don't understand why Sam had to bring it into the discussion ... anyway, still missing the answer from you Brendan: Why JS.next is bringing StructType and requires an object description per each created instance ? Binary data does no such thing! The descriptors are per generated type-constructor, not per instance. What is wrong with new DefinedStruct(propA = 123, propB = 456); or why this has not been considered ??? I have no idea what that syntax even means. Are you assigning to free variables in a call to DefineStruct, or showing parameter default values in the head of a DefineStruct function definition, or what? Losing patience here... /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
at least now we agree object literals *add* overhead and with current JS.next typed structs/arrays proposal you can bet developers will do those kind of non-sense things ;-) I have updated the test case using a second Int32Array loop simply to access the index On Sun, Sep 18, 2011 at 6:03 AM, Brendan Eich bren...@mozilla.com wrote: On Sep 17, 2011, at 10:34 PM, Andrea Giammarchi wrote: Brendan I wrote I did it on purpose trying to predict what JS devs will do once JS.next will bring ctypes like syntax. My objection is that you're confounding test2 by adding object literal overhead to each loop iteration, in addition to typed array accesses. You want to focus on just the typed array accesses, from what I can tell of your benchmark. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
Cython is used to create Python extension so does js-ctypes ... Cython is a superset of Python statically compilable so is, or it should be, js-ctypes and/or JS.next proposal The fact js-ctypes are not trace-JITed at all was *in any case* unexpected to me and the fact js-ctypes are coupled with the native compiled system library interaction makes sense only now since it would have been *great* to have StructType and ArrayType in Mozilla add-ons if these would have brought performances boost. We can agree I compared two different things but we all know duck typing so: 1. looks the same 2. has same name 3. it's experimental/extension only 4. it's used same way ( at least in a JS context ) 5. must be the same In any case I have already updated the post explaining it was my mistake plus I have filed the bug explaining, again, I am not sure anymore what to expect from js-ctypes in therms of raw performances boost On Sun, Sep 18, 2011 at 6:05 AM, Brendan Eich bren...@mozilla.com wrote: On Sep 17, 2011, at 10:39 PM, Andrea Giammarchi wrote: Can we at least agree that if some extension brings *exactly* same constructor name, StructType and ArrayType, and more or less exactly the same signature/usage of what Brendan showed in his slides it become kinda natural to compare/test/confuse these two different implementations for different purposes ? Your blog mixes things together based on less than names being the same -- why did you drag in Cython? Anyway, please take the point that Mozilla SpiderMonkey's jsctypes FFI has had no JIT optimizations at all, unlike the nearby typed arrays implementation -- and that ES6 binary data is an extension of the latter, not anything to do with the former. Can we at least agree that you were connecting dots that have no dashed lines between them? Yes. Common names recur in many places in JS, but namespaced somehow. This case is no different. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 12:09 AM, Andrea Giammarchi wrote:
at least now we agree object literals *add* overhead
Who ever said they didn't?
and with current JS.next typed structs/arrays proposal you can bet developers
will do those kind of non-sense things ;-)
I see what you are getting at now, but you're missing something: your test2 has
an object literal per loop iteration which cannot be optimized away easily. The
object and array literals in my slide that you are concerned about:
new Triangle([{ point: { x: 0, y: 0 },
color: { r: 255, g: 255, b: 255 } },
{ point: { x: 5, y: 5 },
color: { r: 128, g: 0, b: 0 } },
{ point: { x: 10, y: 0 },
color: { r: 0, g: 0, b: 128 } }]);
are neither mandatory -- see
http://wiki.ecmascript.org/doku.php?id=harmony:binary_data_semantics#array_objects
and note how you can call new Triangle() and set members using dotted access
and assignment -- nor as hard to optimize away than in the general case.
I have updated the test case using a second Int32Array loop simply to access
the index
How did the performance change?
/be
On Sun, Sep 18, 2011 at 6:03 AM, Brendan Eich bren...@mozilla.com wrote:
On Sep 17, 2011, at 10:34 PM, Andrea Giammarchi wrote:
Brendan I wrote I did it on purpose trying to predict what JS devs will do
once JS.next will bring ctypes like syntax.
My objection is that you're confounding test2 by adding object literal
overhead to each loop iteration, in addition to typed array accesses. You
want to focus on just the typed array accesses, from what I can tell of your
benchmark.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich bren...@mozilla.com wrote:
Binary data does no such thing! The descriptors are per generated
type-constructor, not per instance.
once you define a StructType how do create an instance ?
new Point2D({x: 0, y: 0});
or binary data can create instances only through ArrayTypes as shown in your
slides ?
What is wrong with new DefinedStruct(propA = 123, propB = 456); or why
this has not been considered ???
I have no idea what that syntax even means. Are you assigning to free
variables in a call to DefineStruct, or showing parameter default values in
the head of a DefineStruct function definition, or what?
is there no proposal to bring named arguments as is for python in JS.next ?
function withDefaults(a = 0, b = 0, c = 0) {
return a + b + c;
}
If yes, is there no way to call arguments pythonish way ?
withDefaults(a = 1, c = 2)
?
This is off topic in any case so no need to discuss it here
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sun, Sep 18, 2011 at 6:19 AM, Brendan Eich bren...@mozilla.com wrote:
Who ever said they didn't?
Sam did:
You'd need a benchmark that shows that the object allocation you're
avoiding here is worth the lack of flexibility.
I see what you are getting at now, but you're missing something: your test2
has an object literal per loop iteration which cannot be optimized away
easily. The object and array literals in my slide that you are concerned
about:
- new Triangle([{ point: { x: 0, y: 0 },
color: { r: 255, g: 255, b: 255 } },
{ point: { x: 5, y: 5 },
color: { r: 128, g: 0, b: 0 } },
{ point: { x: 10, y: 0 },
color: { r: 0, g: 0, b: 128 } }]);
are neither mandatory -- see
http://wiki.ecmascript.org/doku.php?id=harmony:binary_data_semantics#array_objectsand
note how you can call new Triangle() and set members using dotted access
and assignment -- nor as hard to optimize away than in the general case.
So you are suggesting to do something like this:
var p0 = new Point2D,
p1 = new Point2D,
p2 = new Point2D,
c0 = new Color,
c1 = new Color,
c2 = new Color,
px0 = new Pixel,
px1 = new Pixel,
px2 = new Pixel,
t = new Triangle([px0, px1, px2])
and per each typed object assign properties ...
p0.x = 0; p0.y = 0;
... sure this avoid creation of literal but who's gonna do that ? OK, at
least it is possible.
How did the performance change?
in my Mac 13ms VS 16ms surely more if I use the Atom based Netbook
Best Regards,
Andrea Giammarchi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 12:22 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich bren...@mozilla.com wrote:
Binary data does no such thing! The descriptors are per generated
type-constructor, not per instance.
once you define a StructType how do create an instance ?
new Point2D({x: 0, y: 0});
p = new Point2D;
p.x = 0;
p.y = 0;
or binary data can create instances only through ArrayTypes as shown in your
slides ?
The slide shows both struct and array type constructor generation and
invocation via new. See the harmony proposals for details.
is there no proposal to bring named arguments as is for python in JS.next ?
function withDefaults(a = 0, b = 0, c = 0) {
return a + b + c;
}
Yes, that's in the wiki.
If yes, is there no way to call arguments pythonish way ?
withDefaults(a = 1, c = 2)
No, that's unrelated and not proposed.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 12:34 AM, Andrea Giammarchi wrote: On Sun, Sep 18, 2011 at 6:19 AM, Brendan Eich bren...@mozilla.com wrote: Who ever said they didn't? Sam did: You'd need a benchmark that shows that the object allocation you're avoiding here is worth the lack of flexibility. Sam did not say object literals are cost-free (you wrote at least now we agree object literals *add* overhead, implying he did). The issue is whether the cost is too great. It depends. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: An Introduction to JS-Ctypes
On Sep 18, 2011, at 1:14 AM, Brendan Eich wrote:
On Sep 18, 2011, at 12:22 AM, Andrea Giammarchi wrote:
On Sun, Sep 18, 2011 at 6:07 AM, Brendan Eich bren...@mozilla.com wrote:
Binary data does no such thing! The descriptors are per generated
type-constructor, not per instance.
once you define a StructType how do create an instance ?
new Point2D({x: 0, y: 0});
p = new Point2D;
p.x = 0;
p.y = 0;
Default value is 0 so there' s no need for these assignments. If you have
non-zero initial values, perhaps they are constant, in which case you can hoist
the object literal out of any loops and make it a singleton (frozen even,
denoted by a const).
The point is that you don't *have* to pass a fresh object literal to each
constructor call.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
