On Fri, Nov 15, 2013 at 1:13 PM, Ben Noordhuis <[email protected]> wrote:
> On Thu, Nov 14, 2013 at 2:28 PM, Dmitry Lomov <[email protected]> > wrote: > > Thanks a lot for your yelling :) > > > > My general remark here is if you implement your own Buffer classes and > not > > doing what the rest of the language does, in the long run you will not be > > able to benefit from all optimizations we will be doing to speed up > > ArrayBuffers and typed arrays. > > I don't disagree with that point. If we were just starting out, typed > arrays would be the obvious choice. But there were no typed arrays in > the early days of node.js, they were still a glimmer in the eye of the > Khronos group. > > So we have the Buffer class and a large body of code that's built > around it. One in two modules on npm probably uses it in some way or > another. > > > I know that our d8 implementation of ArrayBuffers and friends has been > > pretty terrible w.r.t. allocation speed, but it is already improving and > > will improve further. > > > > > > On Wed, Nov 13, 2013 at 12:08 AM, Trevor Norris <[email protected]> > > wrote: > >> > >> > >> > >> On Tuesday, November 12, 2013 12:08:28 AM UTC-8, Dmitry Lomov wrote: > >>> > >>> These implementations feature faster allocation, better garbage > >>> collection performance and a potential to become even faster in the > future > >>> with deep compiler optimizations - they are the finest available. > >> > >> > >> Except they are at least twice as slow as our Node's internal Buffer > >> implementation for allocations over 1KB. I've been on the receiving end > of > >> much debate about why Node doesn't transition to using ArrayBuffers and > the > >> bottom line is always performance. > > > > > > Is it still true in the latest releases (3.20 and up)? I am curious as to > > what is the bottleneck here. > > I remember you pointing out (in a different bug) that allocating weak > > handles is costly - non-externalized ArrayBuffers do not require any weak > > handles anymore, and we can think of ways to avoid weak handle allocation > > for some externalized array buffers as well. > > > > Ben mentioned zero-initialization: in my tests, zero-initialization cost > was > > actually pretty small (maybe within 5%). Of course, we will never be > able to > > ship something exposing uninitialized external memory to Javascript. > > In the v0.3.x days we had, for a short while, bzero-ing Buffers. That > was a change that quickly got reverted when people started complaining > about ~30% performance drops. > > That number makes sense in a way because a common use case for Buffers > is a) instantiate a buffer, then b) copy data into it. Zeroing the > memory in step a) then simply wastes CPU cycles. > > That said, I can think of one or two solutions to the zeroing overhead > issue, like mapping and pre-faulting memory in a separate thread. > That gives you zero-initialized memory without the main thread > incurring the performance penalty. > > (Caveat emptor: this is me brainstorming while still nursing my first > coffee of the day, no doubt you can come up with a better solution.) > > >> Other than the fact that instantiating an ArrayBuffer is slower, there's > >> the lost consideration of then needing to turn that into a Uint8Array > before > >> it's usable. > > > > > > You can allocate Uint8Array directly (I know it allocates an ArrayBuffer > > under the hood now - getting rid of that for some/most cases is one of my > > optimization goals). > > > >> > >> What I feel you're considering a nuisance, being able to set external > data > >> to any object, has been an excellent feature. With the release of Node > v0.12 > >> there's a new API that'll allow users to roll out their own Buffer-like > >> classes. Making it easy to extend a constructed instance with data and > >> easily exposing a set of methods to work with the data. I myself have > been > >> using this as a simplified way to create mathematical API's around the > >> object's instance directly. Instead of needing to pass around an Type > Array > >> View. > >> > >> We use it extensively as an extremely light weight way of sharing state > >> between C++ and JS. Currently it's ridiculously slow to read Object > >> properties from a JS Object in C++, so a technique has been used where a > >> struct is wrapped around a set of data in C++ and that same data is > attached > >> to an Object in JS. This way they can communicate as quickly as > possible. > >> This has allowed significant performance gains. When the Function is a > >> singleton it's also useful to attach the memory directly to the Function > >> instead of an Object somewhere close by. > > > > > > It feels like this scenario can be adequately captured by having an > > ArrayBuffer wrapping external data. It also aligns closely to the goals > of > > typed objects proposal (formerly binary data: > > http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects), and again > > that is probably what V8 will be optimizing for. > > > > Looking through Buffer API > > (http://nodejs.org/api/buffer.html#buffer_buffer), I think that > everything > > there can be implemented by subclassing Uint8Array (admittedly, we do not > > support subclassing of builtin objects yet! :)) > > Right. In a quick experiment I did a few days ago, I could only get > that to work by mucking around with this.__proto__ and delegating > properties with this.__defineGetter__. > > > Anyway, given how deep this external data feature had taken deep roots in > > node.js code, I agree that completely deprecating this API is premature. > > Here are the steps I would still like to do though: > > - Does node.js use any ExternalArrayType besides > kExternalUnsignedByteArray? > > I'd love to reduce at least this part of the zoo. > > We do but only in code that hasn't made its way into a stable release > yet. We could still roll that back. > If you could that would be great. Thanks! Dmitry > > > - I would dearly love to make sure node.js can switch to standard JS > > features instead of inventing your own. Can haz some benchmarks? :) I > > definitely do not want to force it down your throat though - I would > like to > > get the perf to the point where the switch will be a perf win. > > > > Cheers, > > Dmitry > > -- > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
