On 17/09/2012, at 06:35, Ben Noordhuis wrote: > (...) > That small gain is offset by the need to serialize access to your data > structures - which is often a lot more expensive than the small gain > you get by using threads. > > As for transferring objects, you don't need threads for that, just > shared memory.
If the processes are sharing memory, then they *too* "need to serialize access to data structures"... > We'll probably implement that someday but don't expect too much from > it. Shared memory avoids some syscalls but the cost of moving the > object from one V8 heap to another remains. That's the problem for transferable objects: there's no way to grab an object reference from isolate A to use it on isolate B. > By the way, if you want to hasten that day, post (non-contrived) > benchmarks that conclusively show that IPC is a bottleneck. :-) If the processes can communicate via shared memory -which is always a given for threads- then IPC is fast. But if they can not then you've got to copy the data and speed becomes a function of ( data.length ) which might be *irremediably* slow. Big data.length copies also flush other data from the caches, which results in extra slowdowns. And as the memory bus is a shared resource, under high loads these (many) unnecessary big.data.length copies will (pretty soon) have a global impact on the performance of *all* the rest of system (รก la `cat /dev/zero > /dev/null` memory bus bandwidth exhaustion). -- Jorge. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
