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
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
Proxies traps receiver
Hi,
On this webpage:
http://wiki.ecmascript.org/doku.php?id=harmony:proxies
They show this:
{
has: function(name) - boolean // name in proxy
hasOwn:function(name) - boolean //
({}).hasOwnProperty.call(proxy, name)
get: function(receiver, name) - any// receiver.name
set: function(receiver, name, val) - boolean // receiver.name = val
enumerate: function() - [string] // for (name
in proxy) (return array of enumerable own and inherited properties)
keys: function() - [string] //
Object.keys(proxy) (return array of enumerable own properties only)
}
How come the get and set traps get a receiver argument when the others don't?
I mean the only aim of having a receiver argument is to be able to use
the same trapsobject for several proxies and in fact, you can for
get and set traps. But it won't work on has, hasOwn and so on...
What's the reason for that?
Thank you in advance.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
The way too handle readonly properties in the prototype.
Hi,
First of all here's the code that made me thought if this:
function Constructor( ) { }
Constructor.prototype.property = 'prototype';
var object = new Constructor( );
object.property = 'instance';
console.log( object.property );// 'instance'
function Constructor( ) { }
Object.defineProperty( Constructor.prototype, 'property', {
value: 'prototype'
} );
var object = new Constructor( );
object.property = 'instance';
console.log( object.property );// 'instance'
function Constructor( ) { }
Object.defineProperty( Constructor.prototype, 'property', {
value: 'prototype',
writable: false
} );
var object = new Constructor( );
object.property = 'instance';
console.log( object.property );// FF: 'prototype', Chrome: 'instance'
As you can see, the only difference is on the last line.
Let's say you have an object O, whose prototype is P.
The difference in the behavior happens if P has a readonly
(writable: false) value. Let's call the property p.
Setting P.p is forbidden and reading O.p or P.p is allowed.
But what about setting O.p?
Firefox says you can't while Chrome says you can.
When I say Firefox says, you can't I mean you really can't:
( function ( ) {
'use strict';
function Constructor ( ) { }
Object.defineProperty( Constructor.prototype, 'property', {
value: 'prototype',
writable: false
} );
var object = new Constructor( );
object.property = 'instance';// Error: 'object.property is
read-only' (in Firefox)
} )( );
I'm quite sure this is a bug. But I find this behavior interesting.
Defining properties of the prototype with Object.defineProperty lets
you prevent other instances or anything else from modifying common
methods.
But most of the time, at least for methods, you want them to remain
the same for the life of the object.
Here is an example:
Let's say you want to prevent anything stupid from happening to the
methods you need:
function Constructor( ) { }
Object.defineProperty( Constructor.prototype, 'method', {
value: function ( ) { },
writable: false
} );
Now, your instances are safe since their method can't be removed.
But sometimes, you don't even want the person using the object to be
able to set another next method for you object.
You could prevent him from doing so by doing this:
function Constructor ( ) {
Object.defineProperty( this, 'method', {
value: function ( ) { },
writable: false
} );
}
but then, your methods won't be shared between instances.
--
To put it in a nuttshell:
- Is it the normal behavior that if a property is protected on the
prototype, you can't set it on the object?
- I think it is a behavior that could be used in some cases, even
though it isn't suited as default behavior.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proxies traps receiver
On Sep 17, 2011, at 12:03 PM, Xavier MONTILLET wrote: How come the get and set traps get a receiver argument when the others don't? Please catch up on relevant threads in this list if you can. In any case, see http://wiki.ecmascript.org/doku.php?id=strawman:strawman under proxy extensions, in particular http://wiki.ecmascript.org/doku.php?id=strawman:proxy_drop_receiver /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The way too handle readonly properties in the prototype.
On Sep 17, 2011, at 1:14 PM, Xavier MONTILLET wrote:
function Constructor( ) { }
Object.defineProperty( Constructor.prototype, 'property', {
value: 'prototype'
} );
NB: writable is undefined in that property descriptor, and undefined is falsy.
var object = new Constructor( );
object.property = 'instance';
console.log( object.property );// 'instance'
No, 'prototype' in a conforming implementation (tested in SpiderMonkey shell
and Firefox).
You're re-discovering a v8 bug that I believe is already reported, possibly
even fixed. The ES5.1 spec is clear on this.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proxies traps receiver
On Sep 17, 2011, at 2:07 PM, David Bruant wrote: Le 17/09/2011 19:39, Brendan Eich a écrit : On Sep 17, 2011, at 12:03 PM, Xavier MONTILLET wrote: How come the get and set traps get a receiver argument when the others don't? Please catch up on relevant threads in this list if you can. In any case, see http://wiki.ecmascript.org/doku.php?id=strawman:strawman under proxy extensions, in particular http://wiki.ecmascript.org/doku.php?id=strawman:proxy_drop_receiver And http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy Thanks. Also, these are all on track for ES6, I should have added. We just need to get Tom and Andreas R. and everyone else required to ratify at the same meeting, which looks like it will be the November meeting. /be ___ 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: IDE support?
The best way to avoid the over-annotation of codes is probably to teach
users about WHEN or WHY they should add types guards. If you add the feature
and don't explain what's her purpose and what specific scenarii it can
solve, you'll get in trouble.
However, if you can coordinate with the whole community and publish a bunch
of blog posts explaining how to type efficiently, you'll get great
results. But, in order to achieve that, all the implementations must be
optimized for the same specific cases.
JavaScripters are acustomated to a untyped language. They will not type
everthing because we know how handy it's to rely on compiler optimization.
The most critical part will be to teach cross-compiler makers and people
learning JavaScript after beeing used to, let's say, Java.
Anyway, another usage of type will be automatic class instanciation from
json data. For exemple, let's say I've a type defined like this :
class A {
var myFirstField : B;
var mySecondField : B;
function areEqual() : bool {
if(myFirstField==null) { return mySecondField==null; }
if(mySecondField==null) { return false; }
return myFirstField.x == mySecondField.y;
}
};
class B { int x; int y; }
You can do things like that :
var myA = { myFirstField: {x:5, y:6}, mySecondField: {x:5, y:7} } as A;
console.log(myA.areEqual());
François
-Message d'origine-
From: Brendan Eich
Sent: Saturday, September 17, 2011 7:15 PM
To: Andreas Rossberg
Cc: es-discuss@mozilla.org
Subject: Re: IDE support?
On Sep 15, 2011, at 11:57 AM, Andreas Rossberg wrote:
On 13 September 2011 16:48, Brendan Eich bren...@mozilla.com wrote:
On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
* There are extra costs in space and time to doing the runtime analysis.
* Compile time is runtime, so there are severe limits to how smart you
can afford to get in a compiler.
These are bearable apples to trade against the moldy oranges you'd make
the world eat by introducing type annotations to JS. Millions of
programmers would start annotating for performance, i.e., gratuitously,
making a brittle world at high aggregate cost.
The costs born in browsers by implementors and (this can hit users, but
it's marginal) at runtime when evaluating code are less, I claim.
Depends on how good you want to optimize. Aggressive compilers can be
really slow. There are limits to what you can bear at runtime.
You the user, yes -- good point. It's not just an implementor's burden.
* The massive complexity that comes with implementing all this affects
stability.
This one I'm less sympathetic to, since we won't get rid of untyped JS up
front. A sunk cost fallacy? If we could make a clean break (ahem),
sure. Otherwise this cost must be paid.
Well, the counter-argument would be that you wouldn't need to care
about optimising untyped code as much, if the user had the option to
switch to a typed sublanguage for performance.
I was really turned off by how AS3 users over-annotate. If we added guards
and users turned to them for performance, I'm afraid we'd see the same
contamination.
Annotating might not even help performance -- in AS3, evaluation of
arithmetic operators must widen from int to double, not wrap around 32 bits,
so annotating int on storage types that annotate slots fetched and used via
+, *, etc. can actually lose performance when storing back, since you have
to use the FPU, or analyze and guard on overflow (as JS engines do today to
avoid the FPU).
More analysis can help to stick to the ALUs but that works for untyped JS
too.
Still, I agree that for performance-critical storage, annotations help. This
is obviously so with typed arrays, which the fast VMs target with dedicated
type inference and instruction selection machinery.
Is there a way to avoid the contamination problem we saw with AS3 during the
ES4 days?
* Wrt limits, even in the ideal case, you can only approximate the
performance of typed code -- e.g. for property access you have at
least two memory accesses (type and slot) plus a comparison and
branch, where a typed language would only do 1 memory access.
That's *not* the ideal case. Brian Hackett's type inference work in
SpiderMonkey can eliminate the overhead here. Check it out.
I'm actually pretty excited about that, and hope to see more on that
front. Cool stuff.
However, that ideal case is achieved in a relatively small percentage
of cases only. Otherwise we should probably not see a (already
impressive) 20-40% speed-up (IIRC), but rather something closer to
200-400%.
Oh, we're not done! The current work does not analyze the heap as
aggressively as it might. We want objects that can be, say, four int32
machine types in a row, to be inferred that way and represented that way.
Currently such a type would take four any values in a row, plus the usual
header for metadata.
So the inferencer has to work with
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: IDE support?
On Sep 17, 2011, at 2:57 PM, François REMY wrote:
The best way to avoid the over-annotation of codes is probably to teach
users about WHEN or WHY they should add types guards. If you add the feature
and don't explain what's her purpose and what specific scenarii it can solve,
you'll get in trouble.
However, if you can coordinate with the whole community and publish a bunch
of blog posts explaining how to type efficiently, you'll get great results.
But, in order to achieve that, all the implementations must be optimized for
the same specific cases.
That all sounds great, but it's harder to do than you might think. My blog
isn't read by everyone. People disagree with me anyway. The implementors won't
all converge on the same economics in rapid fashion (they might over the long
run, certainly for SunSpider :-P).
JavaScripters are acustomated to a untyped language. They will not type
everthing because we know how handy it's to rely on compiler optimization.
The most critical part will be to teach cross-compiler makers and people
learning JavaScript after beeing used to, let's say, Java.
Here be dragons.
Anyway, another usage of type will be automatic class instanciation from
json data. For exemple, let's say I've a type defined like this :
class A {
var myFirstField : B;
var mySecondField : B;
function areEqual() : bool {
if(myFirstField==null) { return mySecondField==null; }
if(mySecondField==null) { return false; }
return myFirstField.x == mySecondField.y;
}
};
class B { int x; int y; }
You can do things like that :
var myA = { myFirstField: {x:5, y:6}, mySecondField: {x:5, y:7} } as A;
console.log(myA.areEqual());
Syntax aside, this is all stuff we talked about in ES4 days, and the notion of
initializing narrower types using object and array literals (with suffixed
annotation, as A or : A or these days ::A doesn't matter) is a natural.
The cosmic god-mode trade-off still lies ahead, and it bothers me. I would hate
to make implementors' and bench-marketers lives easier if the net result for
developers was negative.
/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: IDE support?
On Fri, Sep 16, 2011 at 1:55 AM, Andreas Rossberg rossb...@google.com wrote: Being able to detect when a condition is violated is not equivalent to knowing that it always holds. You're right, of course. Thanks for slicing that more finely for me. Mike ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Class Syntax Proposal, Complete With Arguments For and Examples.
Hi Jonathan, Your class recapitulates a mistake the committee almost made as well. Your private and public member are in the same namespace. Private members should not affect the behavior of the public API. However, if a class makes an extensible instance, and a client of the instance tries to add an _x expando property to that instance, where that happens to conflict with one of that abstraction's private names, what should happen? -- Cheers, --MarkM ___ 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
Re: Class Syntax Proposal, Complete With Arguments For and Examples.
Hello Mark, I think mistake is a harsh word. It is really a question of how much the community wants javascript to adopt object-oriented paradigms. You could go all the way and make classes a very strict subset of the language: throw an error if the user tries to set a property of a class instance that has already been declared private. Or, on the complete opposite side of the spectrum: setting the property on an instance overwrite it, just like it would if the class instance was a normal object. I would personally prefer the prior route: sacrifice some of javascript's dynamic attributes in favor of better abstraction and encapsulation capabilities. Of course, we're only talking about class instances here, so I think that's a very small sacrifice to be made. Perhaps you could direct me to the discussion the committee has already had on this matter so I could better form my arguments? Jonathan Dumaine +1 50.55.10.11.12 On Sat, Sep 17, 2011 at 3:37 PM, Mark S. Miller erig...@google.com wrote: Hi Jonathan, Your class recapitulates a mistake the committee almost made as well. Your private and public member are in the same namespace. Private members should not affect the behavior of the public API. However, if a class makes an extensible instance, and a client of the instance tries to add an _x expando property to that instance, where that happens to conflict with one of that abstraction's private names, what should happen? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
