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.edu>wrote: > 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 I can provide a > proper > > feedback about my doubts. > > However, you don't seem to have fully read the slides. As he says "Do > not use [eval] anywhere near performance sensitive code". The > Function constructor is a version of |eval|. > > > Once again, why once a struct has been defined we need to create per each > > instance its counterpart in native JS ? > > > > new Point2D({x: 1, y: 2}) ... why? > > what's wrong with a *shimmable* > > new Point2D(x = 1, y = 2) > > so that no object has to be created? > > You'd need a benchmark that shows that the object allocation you're > avoiding here is worth the lack of flexibility. > -- > sam th > sa...@ccs.neu.edu >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
