1. Threads are a feature, one that will unlock new exciting things we can do and make
existing features better (namely child_process.fork()).
2. "We don't have that feature" is not a feature, is not a pro.
3. Being dogmatic about what others ought do is bad: accept if not embrace input liberally.
4. Doing threads, safe concurrency right is what makes Rust so attractive, and Node can do
it safely, cleanly too and nearly did, in the "isolates" branch.
https://github.com/joyent/node/tree/isolates
Onwards:
On Sat, Sep 15, 2012 at 11:32:56AM -0700, Mark Hahn wrote:
> @rektide, are you saying that joyent is asleep at the wheel because they
> are stopping the community from using threads?
> The community doesn't want threads because they violate the founding
> principle of Node, which is to use non-blocking event loops and get rid of
> threads.
"violate the founding principle"?
"community doesn't want"?
As for "doesn't want" and "founding principles," before threads became an awful horrible
thing the Node community would have nothing to do with ever, there was a feature that got
canned for being too complicating called Isolates, that, shock and awe, Node leads were hard
at work on which would have added threading as a drop in replacement for child_process.fork().
Certainly no one was calling the feature "anti-Node" at the time, it would have been an
implementation detail, offered the same functionality as already exists in Node today, and
would have made us capable of doing more.
https://groups.google.com/forum/?fromgroups=#!msg/nodejs/zLzuo292hX0/... https://github.com/joyent/node/tree/isolates
Threading is not evil. Shared state is evil. Which is why the rest of the JavaScript world
has Transferables, a way to move ownership of an object from one isolated thread/container
to another. Processes preservation [read: apropo exclamative], Node is already a
multi-reactor not a reactor, and there's no harm, nothing but technical gain (faster context
switches, Transferables), from allowing that multi-reactor to run on threads as easily as it
runs on processes. Aside from the work to get there, there's no cause to keep ourselves
locked in to just using processes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-do...
I'm not at all saying Joyent is asleep at the wheel. They punted on this topic, this big
hard hairy to implement topic: fine. It does hurt us, is a killer feature a mature runtime
ought have in it's toolkit, but I have faith eventually we'll go to bat on the topic again
in a serious manner in due time and I'm not sweating the innings lost between now and then.
In the mean time, Joyent has been doing great things with Node and I'm delighted they
continue doing so much to further Node.
I know Ryah has gone on twitter and said he still sees Node as a web runtime. Isaac has
similarly lamented allowing other languages to play in Node's pool. Online discussions have
a lot of people defending node's lack of threading. I think much of this makes us look bad,
(hipster-ish, dogmatic, and even jingoistic), to soapbox about what this thing is for, to
rather than find value and positives define negatives and ills, to proscribe.
For comparison, I'd champion Larry Wall's Perl: a super flexible language, but what I love
more than anything else is how a-dogmatic it was, an explicitly post-modern language with
an explicitly post-modern culture, where people didn't tell each other what to think or do
and couldn't do otherwise in any kind of definitive manner because there were a dozen ways
to do a thing: liberty came standard. Even if you were using it to shoot yourself in the
foot, the guy on the other side of the lab can be using feature X or factor Y to great
effect.
Make options available, help people see what things are possible. That's humble, that's
respectful, and speaks to an understanding that lasting things grow and change and take on
new roles. If we knew all the answers, we'd have built ourselves all-too-sterile and
flavorless an environment.
Threads are great. Fact. Better than processes (at at least context switching and
transfering objects). Fact. And like most great powers, they come with great responsibility
(more than processes, fact). Which isolates, WebMessaging all support, all work to harness
the capabilities of while insuring they are used responsibly.
Fwiw, Rust is going to be a serious language to look at because it has such deeply ingrained
respect for safe concurrent containers. And continuing my opining, Node owes itself
isolates, it's parallel: threads are faster context switches than processes, and threads allow
Transferable, both are clear safe wins with zero risk or cost to non-users. Threading is a
feature, one from a usage standpoint that need not be any different than
child_process.fork(), and it's one I hope Node.js comes back to to continue being a
pre-eminent and delighting runtime for all users.
> On Sat, Sep 15, 2012 at 11:19 AM, Ted Young <[1]t...@radicaldesigns.org>
> wrote:
> I take it no one knows what he's actually complaining about?
> Ted
I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a pretty daft silly thing.
It's certainly not the safe sane shared-nothing threading that keeps Node & JS safe. That
responsible multi-threading work was attempted in the 'isolates' branch of Node.js. I would
definitely not push the threads-a-go-go work upstream. :)
Google is too smart for me. I wrote this reply as a new thread, and Google has attached it to the old one. Apologies, but I am about to repost it sans-excerpts.
1. Threads are a feature, one that will unlock new exciting things we can do and make
existing features better (namely child_process.fork()).
2. "We don't have that feature" is not a feature, is not a pro.
3. Being dogmatic about what others ought do is bad: accept if not embrace input liberally.
4. Doing threads, safe concurrency right is what makes Rust so attractive, and Node can do
it safely, cleanly too and nearly did, in the "isolates" branch.
https://github.com/joyent/node/tree/isolates
Onwards:
On Sat, Sep 15, 2012 at 11:32:56AM -0700, Mark Hahn wrote:
> @rektide, are you saying that joyent is asleep at the wheel because they
> are stopping the community from using threads?
> The community doesn't want threads because they violate the founding
> principle of Node, which is to use non-blocking event loops and get rid of
> threads.
"violate the founding principle"?
"community doesn't want"?
As for "doesn't want" and "founding principles," before threads became an awful horrible
thing the Node community would have nothing to do with ever, there was a feature that got
canned for being too complicating called Isolates, that, shock and awe, Node leads were hard
at work on which would have added threading as a drop in replacement for child_process.fork().
Certainly no one was calling the feature "anti-Node" at the time, it would have been an
implementation detail, offered the same functionality as already exists in Node today, and
would have made us capable of doing more.
https://groups.google.com/forum/?fromgroups=#!msg/nodejs/zLzuo292hX0/... https://github.com/joyent/node/tree/isolates
Threading is not evil. Shared state is evil. Which is why the rest of the JavaScript world
has Transferables, a way to move ownership of an object from one isolated thread/container
to another. Processes preservation [read: apropo exclamative], Node is already a
multi-reactor not a reactor, and there's no harm, nothing but technical gain (faster context
switches, Transferables), from allowing that multi-reactor to run on threads as easily as it
runs on processes. Aside from the work to get there, there's no cause to keep ourselves
locked in to just using processes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-do...
I'm not at all saying Joyent is asleep at the wheel. They punted on this topic, this big
hard hairy to implement topic: fine. It does hurt us, is a killer feature a mature runtime
ought have in it's toolkit, but I have faith eventually we'll go to bat on the topic again
in a serious manner in due time and I'm not sweating the innings lost between now and then.
In the mean time, Joyent has been doing great things with Node and I'm delighted they
continue doing so much to further Node.
I know Ryah has gone on twitter and said he still sees Node as a web runtime. Isaac has
similarly lamented allowing other languages to play in Node's pool. Online discussions have
a lot of people defending node's lack of threading. I think much of this makes us look bad,
(hipster-ish, dogmatic, and even jingoistic), to soapbox about what this thing is for, to
rather than find value and positives define negatives and ills, to proscribe.
For comparison, I'd champion Larry Wall's Perl: a super flexible language, but what I love
more than anything else is how a-dogmatic it was, an explicitly post-modern language with
an explicitly post-modern culture, where people didn't tell each other what to think or do
and couldn't do otherwise in any kind of definitive manner because there were a dozen ways
to do a thing: liberty came standard. Even if you were using it to shoot yourself in the
foot, the guy on the other side of the lab can be using feature X or factor Y to great
effect.
Make options available, help people see what things are possible. That's humble, that's
respectful, and speaks to an understanding that lasting things grow and change and take on
new roles. If we knew all the answers, we'd have built ourselves all-too-sterile and
flavorless an environment.
Threads are great. Fact. Better than processes (at at least context switching and
transfering objects). Fact. And like most great powers, they come with great responsibility
(more than processes, fact). Which isolates, WebMessaging all support, all work to harness
the capabilities of while insuring they are used responsibly.
Fwiw, Rust is going to be a serious language to look at because it has such deeply ingrained
respect for safe concurrent containers. And continuing my opining, Node owes itself
isolates, it's parallel: threads are faster context switches than processes, and threads allow
Transferable, both are clear safe wins with zero risk or cost to non-users. Threading is a
feature, one from a usage standpoint that need not be any different than
child_process.fork(), and it's one I hope Node.js comes back to to continue being a
pre-eminent and delighting runtime for all users.
This thread was forked from the Crockford fork YNode thread below,
http://is.gd/0fiBAV
There are long discussions in the Node community about what happened when we did try to use Isolates. The lack of thread level protections from things like mucking with process.* and the fact that native modules need to add complex support for Isolates to be first class (many C level libraries deal poorly with Isolates due to them not being exactly like threads from what I understand) are fairly well discussed. In addition things like C's abort(), and any shared memory still cause problems with Isolates. It would be interesting to delve into these problems, but for example if you use rust the runtime has explicit knowledge of threads rather than v8 so you can reduce most of the problems with concurrency to message passing and the same problems as process.* . People who complain about threads generally do not have in depth knowledge of difficulties in doing so with Node's environment, but should feel free to look them up and discuss solutions rather than simply stating "it should have threads". I personally really like what Threads a Go Go does, but it still faces the difficulties listed above difficulties when you start to delve deep into it.
On Sunday, September 16, 2012 4:51:43 PM UTC-5, rektide wrote:
> TL;DR:
> 1. Threads are a feature, one that will unlock new exciting things we can > do and make > existing features better (namely child_process.fork()). > 2. "We don't have that feature" is not a feature, is not a pro. > 3. Being dogmatic about what others ought do is bad: accept if not embrace > input liberally. > 4. Doing threads, safe concurrency right is what makes Rust so attractive, > and Node can do > it safely, cleanly too and nearly did, in the "isolates" branch. > https://github.com/joyent/node/tree/isolates
> Onwards:
> On Sat, Sep 15, 2012 at 11:32:56AM -0700, Mark Hahn wrote: > > @rektide, are you saying that joyent is asleep at the wheel because > they > > are stopping the community from using threads? > > The community doesn't want threads because they violate the founding > > principle of Node, which is to use non-blocking event loops and get > rid of > > threads.
> "violate the founding principle"? > "community doesn't want"?
> As for "doesn't want" and "founding principles," before threads became an > awful horrible > thing the Node community would have nothing to do with ever, there was a > feature that got > canned for being too complicating called Isolates, that, shock and awe, > Node leads were hard > at work on which would have added threading as a drop in replacement for > child_process.fork(). > Certainly no one was calling the feature "anti-Node" at the time, it would > have been an > implementation detail, offered the same functionality as already exists in > Node today, and > would have made us capable of doing more.
> Threading is not evil. Shared state is evil. Which is why the rest of the > JavaScript world > has Transferables, a way to move ownership of an object from one isolated > thread/container > to another. Processes preservation [read: apropo exclamative], Node is > already a > multi-reactor not a reactor, and there's no harm, nothing but technical > gain (faster context > switches, Transferables), from allowing that multi-reactor to run on > threads as easily as it > runs on processes. Aside from the work to get there, there's no cause to > keep ourselves > locked in to just using processes.
> I'm not at all saying Joyent is asleep at the wheel. They punted on this > topic, this big > hard hairy to implement topic: fine. It does hurt us, is a killer feature > a mature runtime > ought have in it's toolkit, but I have faith eventually we'll go to bat on > the topic again > in a serious manner in due time and I'm not sweating the innings lost > between now and then. > In the mean time, Joyent has been doing great things with Node and I'm > delighted they > continue doing so much to further Node.
> I know Ryah has gone on twitter and said he still sees Node as a web > runtime. Isaac has > similarly lamented allowing other languages to play in Node's pool. > Online discussions have > a lot of people defending node's lack of threading. I think much of this > makes us look bad, > (hipster-ish, dogmatic, and even jingoistic), to soapbox about what this > thing is for, to > rather than find value and positives define negatives and ills, to > proscribe.
> For comparison, I'd champion Larry Wall's Perl: a super flexible language, > but what I love > more than anything else is how a-dogmatic it was, an explicitly > post-modern language with > an explicitly post-modern culture, where people didn't tell each other > what to think or do > and couldn't do otherwise in any kind of definitive manner because there > were a dozen ways > to do a thing: liberty came standard. Even if you were using it to shoot > yourself in the > foot, the guy on the other side of the lab can be using feature X or > factor Y to great > effect.
> Make options available, help people see what things are possible. That's > humble, that's > respectful, and speaks to an understanding that lasting things grow and > change and take on > new roles. If we knew all the answers, we'd have built ourselves > all-too-sterile and > flavorless an environment.
> Threads are great. Fact. Better than processes (at at least context > switching and > transfering objects). Fact. And like most great powers, they come with > great responsibility > (more than processes, fact). Which isolates, WebMessaging all support, all > work to harness > the capabilities of while insuring they are used responsibly.
> Fwiw, Rust is going to be a serious language to look at because it has > such deeply ingrained > respect for safe concurrent containers. And continuing my opining, Node > owes itself > isolates, it's parallel: threads are faster context switches than > processes, and threads allow > Transferable, both are clear safe wins with zero risk or cost to > non-users. Threading is a > feature, one from a usage standpoint that need not be any different than > child_process.fork(), and it's one I hope Node.js comes back to to > continue being a > pre-eminent and delighting runtime for all users.
> > On Sat, Sep 15, 2012 at 11:19 AM, Ted Young <[1]
> t...@radicaldesigns.org <javascript:>> > > wrote:
> > I take it no one knows what he's actually complaining about? > > Ted
> I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a > pretty daft silly thing. > It's certainly not the safe sane shared-nothing threading that keeps Node > & JS safe. That > responsible multi-threading work was attempted in the 'isolates' branch of > Node.js. I would > definitely not push the threads-a-go-go work upstream. :)
> > On Sep 15, 2012, at 10:52 AM, Nuno Job <[2]nunojo...@gmail.com<javascript:>>
> > wrote:
> > This again? Oh mah gawd. :)
> > Sent from my iPhone
> > On Sep 15, 2012, at 6:18 PM, rektide <[3]rek...@voodoowarez.com<javascript:>>
> > wrote:
> > On Sat, Sep 15, 2012 at 04:56:40PM +0200, Arnout Kazemier > wrote:
Thanks so much for the informative reply: that's a lot of things I don't know about!
On Sunday, September 16, 2012 6:22:50 PM UTC-4, Bradley Meck wrote:
> There are long discussions in the Node community about what happened when > we did try to use Isolates. The lack of thread level protections from > things like mucking with process.*
Caveat emptor, doesn't seem like a real issue, just a fact of life.
> and the fact that native modules need to add complex support for Isolates > to be first class (many C level libraries deal poorly with Isolates due to > them not being exactly like threads from what I understand) are fairly well > discussed.
This in particular would be great to read about! This seems like the chief potential show-stopper, and most open ended problem.
> In addition things like C's abort(), and any shared memory still cause > problems with Isolates.
I'm less willing to say caveat emptor here, sounds harrier, but again "doing it and creating potential problems" (particularly if they're exit case problems) seems preferable to not doing it.
> It would be interesting to delve into these problems, but for example if > you use rust the runtime has explicit knowledge of threads rather than v8 > so you can reduce most of the problems with concurrency to message passing > and the same problems as process.*
People who complain about threads generally do not have in depth knowledge
> of difficulties in doing so with Node's environment, but should feel free > to look them up and discuss solutions rather than simply stating "it should > have threads".
I have done some attempts at research on the topic: this has been considerably more informative than any threads I've turned up. Perhaps I was doing my search wrong. That all said, apologies for not being able to bring a more balanced perspective to my "should have threads" stance, I would like to be able to do better.
> personally really like what Threads a Go Go does, but it still faces the > difficulties listed above difficulties when you start to delve deep into it.
Just thought I would add from experience of building a threaded version of node. The process.* problem does not really exist if you create a new v8 context for each thread, there are some issues, particularly with process.exit() behaviour but nothing too nasty.
Modules are a 50:50 issue I think. If threads were supported in the core it would be fairly easy to provide helpers to handle thread specific data, I do that with a C++ template to most of the node globals, it's work but certainly not hard work unless you want to do something more involved that just maintain compatibility. On the other hand, I have just finished work on loading a threaded version of node as a native module into a stock version of node. This is really easy to deploy but I have not found anyway to make this support native modules, I kind of doubt there can be any single process solution given the current code, but I really like the model of being able to bolt fully functioning threads on as a module for those of us who care so I will probably look for other solutions.
I am really only chasing the gains to be had in shared state rather than any philosophical position, to that end I have tuned messaging passing between threads, a rough & ready benchmark shows throughput of 500k-msg/sec between threads, the comparative figure for inter-process is 20k-msg/sec, although this was only tested in WIN32. My work is on github<https://github.com/organizations/hut78>, but I am a couple of week away from an initial release, plenty of test cases to be run yet.
On Sunday, September 16, 2012 4:54:24 PM UTC-7, Kevin Jones wrote:
> Just thought I would add from experience of building a threaded version of > node. The process.* problem does not really exist if you create a new v8 > context for each thread, there are some issues, particularly with > process.exit() behaviour but nothing too nasty.
> Modules are a 50:50 issue I think. If threads were supported in the core > it would be fairly easy to provide helpers to handle thread specific data, > I do that with a C++ template to most of the node globals, it's work but > certainly not hard work unless you want to do something more involved that > just maintain compatibility. On the other hand, I have just finished work > on loading a threaded version of node as a native module into a stock > version of node. This is really easy to deploy but I have not found anyway > to make this support native modules, I kind of doubt there can be any > single process solution given the current code, but I really like the model > of being able to bolt fully functioning threads on as a module for those of > us who care so I will probably look for other solutions.
> I am really only chasing the gains to be had in shared state rather than > any philosophical position, to that end I have tuned messaging passing > between threads, a rough & ready benchmark shows throughput of 500k-msg/sec > between threads, the comparative figure for inter-process is 20k-msg/sec, > although this was only tested in WIN32. My work is on github<https://github.com/organizations/hut78>, > but I am a couple of week away from an initial release, plenty of test > cases to be run yet.
On Sun, Sep 16, 2012 at 11:51 PM, rektide <rekt...@voodoowarez.com> wrote:
> Threads are great. Fact. Better than processes (at at least context switching and
> transfering objects). Fact.
It's much (much!) more nuanced than that.
Threads in most common threading implementations are only marginally
cheaper than processes. You avoid some TLB flushes and that's about
it.
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.
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.
By the way, if you want to hasten that day, post (non-contrived)
benchmarks that conclusively show that IPC is a bottleneck. :-)
Depends on what you consider to be problematic with process.* ,
process.cwd() in particular bit me while trying a couple things, but could be worked around, a slightly more annoying error dealt with cluster using env variables, once again possible to work around.
As stated, I really like the approach taken by threads a gogo. I am not against threading, just very cautious.
On Sunday, September 16, 2012 6:11:48 PM UTC-5, rektide wrote:
> Thanks so much for the informative reply: that's a lot of things I don't > know about!
> On Sunday, September 16, 2012 6:22:50 PM UTC-4, Bradley Meck wrote:
>> There are long discussions in the Node community about what happened when >> we did try to use Isolates. The lack of thread level protections from >> things like mucking with process.*
> Caveat emptor, doesn't seem like a real issue, just a fact of life.
>> and the fact that native modules need to add complex support for Isolates >> to be first class (many C level libraries deal poorly with Isolates due to >> them not being exactly like threads from what I understand) are fairly well >> discussed.
> This in particular would be great to read about! This seems like the chief > potential show-stopper, and most open ended problem.
>> In addition things like C's abort(), and any shared memory still cause >> problems with Isolates.
> I'm less willing to say caveat emptor here, sounds harrier, but again > "doing it and creating potential problems" (particularly if they're exit > case problems) seems preferable to not doing it.
>> It would be interesting to delve into these problems, but for example if >> you use rust the runtime has explicit knowledge of threads rather than v8 >> so you can reduce most of the problems with concurrency to message passing >> and the same problems as process.*
> People who complain about threads generally do not have in depth knowledge >> of difficulties in doing so with Node's environment, but should feel free >> to look them up and discuss solutions rather than simply stating "it should >> have threads".
> I have done some attempts at research on the topic: this has been > considerably more informative than any threads I've turned up. Perhaps I > was doing my search wrong. That all said, apologies for not being able to > bring a more balanced perspective to my "should have threads" stance, I > would like to be able to do better.
>> personally really like what Threads a Go Go does, but it still faces the >> difficulties listed above difficulties when you start to delve deep into it.
> I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a > pretty daft silly thing. > It's certainly not the safe sane shared-nothing threading that keeps Node > & JS safe. That > responsible multi-threading work was attempted in the 'isolates' branch of > Node.js. I would > definitely not push the threads-a-go-go work upstream. :)
My FUD detector is blinking red!!!
Threads-a-gogo is perfectly safe and 100% shared nothing. Every worker thread runs in its own isolate, and worker threads communicate with the main thread by passing immutable strings.
If you did not take the time to experiment about it or just read about it, don't post counter-truths like this.
If TAGG could be criticized, it would be for lacking certain useful features. To me, the most crying ones are 1) a module system and 2) the ability to transfer ownership of objects (so that we don't have to serialize everything), or at least pass "frozen" objects.
I don't know if this is behind Crockford's comment but the "thread-a-gogo" story is, IMO, a perfect illustration of the lack of professionalism that's going to hurt node. Instead of embracing something that brings a plus to node (the ability to write CPU intensive operations in JavaScript, with worker threads) and was carefully designed to be aligned with the basic node model (CPU intensive operations are handled as async ops with a standard node callback, eventing API between threads is aligned on node's emitter API), the solution is being at best ignored, when not covered with FUD. The end result is that we are going to get tens of half-backed threading libraries instead of having consolidation around one promising solution (that needed help).
The dogma will be preserved (threads are bad, you need to do this with processes and shared memory, even if this is less performant and more complex) but this is just a childish attitude.
> (...)
> 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.
It would be nice if Crockford could elaborate on where he thinks Joyent are making mistakes with Node.js. I'm sure Joyent would be receptive to feedback from him.
On Mon, Sep 17, 2012 at 10:49 AM, Jorge <jo...@jorgechamorro.com> wrote:
> 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"...
Yes, but the big difference - and I hate to spell it out because it
should be obvious - is that you only need to synchronize a single
thing instead of every global data structure.
>> 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).
> On Mon, Sep 17, 2012 at 10:49 AM, Jorge <jo...@jorgechamorro.com> wrote:
>> 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"...
> Yes, but the big difference - and I hate to spell it out because it
> should be obvious - is that you only need to synchronize a single
> thing instead of every global data structure.
But that's a different problem. If you want to make thread-safe a program that's abusing globals then yes you're ~ fucked.
On the other hand it didn't take too long for the V8 guys to fix exactly that in the isolates branch...
>>> 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).
> No doubt. Now show me the numbers. :-)
Ok. Please tell me the secret :-P
Because to me it's obvious that a copy of (sizeof void*) length is faster than a copy of anything much larger than that.
Do you guys wonder why there is a collective groan when you show up? Especially considering how difficult it is for a group of geographically remote people to convey a collective groan in a written medium ;)
Threads-a-go-go lives exactly where it should; in userland where anyone who wants to can try it. You should stop being so bothered by how things work in the community. There are so many people in the node community that wish their modules got more attention. Those people don't have nearly as many stars and forks on github as threads-a-go-go. Whatever it is you think you're entitled to, you've already got it.
:Marco
PS: And find some way to get rid of the "eval" thing for chrissakes. If you want javascript people to take you seriously, show them you're serious about javascript.
On Monday, September 17, 2012 12:20:13 AM UTC-7, Bruno Jouhier wrote:
> I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a >> pretty daft silly thing. >> It's certainly not the safe sane shared-nothing threading that keeps Node >> & JS safe. That >> responsible multi-threading work was attempted in the 'isolates' branch >> of Node.js. I would >> definitely not push the threads-a-go-go work upstream. :)
> My FUD detector is blinking red!!!
> Threads-a-gogo is perfectly safe and 100% shared nothing. Every worker > thread runs in its own isolate, and worker threads communicate with the > main thread by passing immutable strings.
> If you did not take the time to experiment about it or just read about it, > don't post counter-truths like this.
> If TAGG could be criticized, it would be for lacking certain useful > features. To me, the most crying ones are 1) a module system and 2) the > ability to transfer ownership of objects (so that we don't have to > serialize everything), or at least pass "frozen" objects.
> I don't know if this is behind Crockford's comment but the "thread-a-gogo" > story is, IMO, a perfect illustration of the lack of professionalism that's > going to hurt node. Instead of embracing something that brings a plus to > node (the ability to write CPU intensive operations in JavaScript, with > worker threads) and was carefully designed to be aligned with the basic > node model (CPU intensive operations are handled as async ops with a > standard node callback, eventing API between threads is aligned on node's > emitter API), the solution is being at best ignored, when not covered with > FUD. The end result is that we are going to get tens of half-backed > threading libraries instead of having consolidation around one promising > solution (that needed help).
> The dogma will be preserved (threads are bad, you need to do this with > processes and shared memory, even if this is less performant and more > complex) but this is just a childish attitude.
"Threads-a-go-go is a pretty daft silly thing. It's certainly not the safe sane shared-nothing threading that keeps Node & JS safe. That responsible multi-threading work was attempted in the 'isolates' branch of Node.js"
Jorge should just swallow the FUD, bend over and apologize for having proposed such a "daft silly thing" to the community!
BTW, the 'isolates' branch failed, probably because it was trying to do too much (put a complete node into every isolate). TAGG solves a much narrower problem: delegating CPU intensive operations to threads, and it does it in a safe and efficient way.
The problem is that we cannot even discuss anything related to threads in a rational way. There may be perfectly valid use cases for threads in node (I think that CPU intensive computations are one - you can do them in threads with C++, why not in JS?), and there are perfectly safe and clean ways to add threads to node (and I think that TAGG is one - the "eval" situation can be improved with modules). But how can we discuss this without everyone jumping to the ceiling?
> "Threads-a-go-go is a pretty daft silly thing.
> It's certainly not the safe sane shared-nothing threading that keeps Node
> & JS safe. That
> responsible multi-threading work was attempted in the 'isolates' branch of
> Node.js"
> Jorge should just swallow the FUD, bend over and apologize for having
> proposed such a "daft silly thing" to the community!
> BTW, the 'isolates' branch failed, probably because it was trying to do
> too much (put a complete node into every isolate). TAGG solves a much
> narrower problem: delegating CPU intensive operations to threads, and it
> does it in a safe and efficient way.
> The problem is that we cannot even discuss anything related to threads in
> a rational way. There may be perfectly valid use cases for threads in node
> (I think that CPU intensive computations are one - you can do them in
> threads with C++, why not in JS?),
Let me paraphraze you, why should you do it in javascript, when there're
C++/C which is much better for computational problems. Sure you can use 3rd
party module for making your js code run in multiple threads, but as far as
it can be implemented as a external dependency - why should it be placed in
node.js core?
and there are perfectly safe and clean ways to add threads to node (and I
> think that TAGG is one - the "eval" situation can be improved with
> modules). But how can we discuss this without everyone jumping to the
> ceiling?
Jorge doesn't have to swallow anything. In fact he has not. He has engaged with the subject at hand and has not responded to the troll bait about his lib. Notice he continues to receive feedback, about the subject. As does rektide even though he was the person who derailed the conversation in the first place.
You however, chose to respond to the bait by throwing a tantrum and calling the whole community childish and unprofessional (** groan **). Even though it looks like the comment that set you off from rektide, who brought up TAGG in the first place.
So as desperately hard as you're trying to have a rational discussion about this, you seem to be the only person who can't seem to do so. And at this point, responding to you is starting to feel dangerously like feeding trolls... oh damn. Guess I fell for it too.
:Marco
Sent from my iPhone
On Sep 17, 2012, at 4:25 AM, Bruno Jouhier <bjouh...@gmail.com> wrote:
> "Threads-a-go-go is a pretty daft silly thing. > It's certainly not the safe sane shared-nothing threading that keeps Node & JS safe. That > responsible multi-threading work was attempted in the 'isolates' branch of Node.js"
> Jorge should just swallow the FUD, bend over and apologize for having proposed such a "daft silly thing" to the community!
> BTW, the 'isolates' branch failed, probably because it was trying to do too much (put a complete node into every isolate). TAGG solves a much narrower problem: delegating CPU intensive operations to threads, and it does it in a safe and efficient way.
> The problem is that we cannot even discuss anything related to threads in a rational way. There may be perfectly valid use cases for threads in node (I think that CPU intensive computations are one - you can do them in threads with C++, why not in JS?), and there are perfectly safe and clean ways to add threads to node (and I think that TAGG is one - the "eval" situation can be improved with modules). But how can we discuss this without everyone jumping to the ceiling?
Childish and amateurish were not my words in the first place, they were Crockford's. And, although there may have been a bit of provocation in my post, I think that the problem is real (otherwise, why would Crockford use these words?).
The problem that I see is that a number of smart people (Jorge being one) have proposed interesting things to fill some of the holes in node's story (like the inability to do CPU intensive stuff in JS - remember the "node is cancer" story). Of course, Jorge has been stepping a bit on what node's core team was doing (as they tried to attack the thread problem from a slightly different angle but decided to backtrack) but maybe this means that they took the problem from the wrong angle and that what he has done, although more limited in scope, could be interesting. My expectation would have been that the topic be discussed at the technical, professional level between the different people involved. Did this ever happen? Did any member of the core team ever show any interest in what Jorge had produced? I may be simplifying a bit but I have the impression that all he got was negative feedback. And then people feel authorized to post sarcastic remarks ("this again? oh mah gawd", "daft silly thing") about his work. And of course, nobody reacts. This is what I find very childish and I am sure that a number of other professionals who are watching our discussions feel the same way.
There should be a way to discuss issues like threads without going into sarcasms and personal things.
@Fedor,
Of course, CPU intensive stuff can be done in C++ but this is a completely different story: you have to dive into C++, deploy C++ extensions, etc. Being able to do it in JS (with the help of a generic C++ library) can be an attractive proposition. At least it is for people like me who have rusty C++ skills and are ready to trade a bit of performance for some comfort and piece of mind.
To me, TAGG is a bit crippled today by the fact that you have to serialize data as strings to pass it between threads. But if we were able to transfer ownership of JS objects, or, although this is less powerful, at least pass frozen objects between threads, this would allow us to pass buffers or whole object graphs very efficiently to worker threads. Then the TAGG proposition would become really attractive.
This feature (being able to do CPU intensive stuff in JS) may not hit the sweet spot of node, which is I/O intensive apps. But it does not hurt node either; it enables something that was impossible (or much harder) to do before, and it does it with a design which is aligned with node's principles (computations being treated just like async operations). So why bash it?
On Monday, September 17, 2012 5:10:07 PM UTC+2, Marco Rogers wrote:
> Jorge doesn't have to swallow anything. In fact he has not. He has engaged > with the subject at hand and has not responded to the troll bait about his > lib. Notice he continues to receive feedback, about the subject. As does > rektide even though he was the person who derailed the conversation in the > first place.
> You however, chose to respond to the bait by throwing a tantrum and > calling the whole community childish and unprofessional (** groan **). > Even though it looks like the comment that set you off from rektide, who > brought up TAGG in the first place.
> So as desperately hard as you're trying to have a rational discussion > about this, you seem to be the only person who can't seem to do so. And at > this point, responding to you is starting to feel dangerously like feeding > trolls... oh damn. Guess I fell for it too.
> :Marco
> Sent from my iPhone
> On Sep 17, 2012, at 4:25 AM, Bruno Jouhier <bjou...@gmail.com<javascript:>> > wrote:
> So it is perfectly fine if someone writes:
> "Threads-a-go-go is a pretty daft silly thing. > It's certainly not the safe sane shared-nothing threading that keeps Node > & JS safe. That > responsible multi-threading work was attempted in the 'isolates' branch of > Node.js"
> Jorge should just swallow the FUD, bend over and apologize for having > proposed such a "daft silly thing" to the community!
> BTW, the 'isolates' branch failed, probably because it was trying to do > too much (put a complete node into every isolate). TAGG solves a much > narrower problem: delegating CPU intensive operations to threads, and it > does it in a safe and efficient way.
> The problem is that we cannot even discuss anything related to threads in > a rational way. There may be perfectly valid use cases for threads in node > (I think that CPU intensive computations are one - you can do them in > threads with C++, why not in JS?), and there are perfectly safe and clean > ways to add threads to node (and I think that TAGG is one - the "eval" > situation can be improved with modules). But how can we discuss this > without everyone jumping to the ceiling?
If you want to add something to core it'll need to be a GitHub issue.
For all the same reasons non-blocking APIs fail on platforms that traditionally use threading a threading API in Node will fail just the same. It's a matter of community, the two approaches are not compatible and this means that the code in the community divides along these lines.
It's not good for the community to divide in to incompatible camps. Node code runs in node, period. If you want threads you'll need to fork, and you'll need to call it something other than node because it's not Node anymore, it's something else. Maybe it's better, but it's not Node.
You can talk all day about the "possibilities" but your'e just talking about technology and waxing about what is possible. It doesn't really matter, it's not why things gain traction or grow a community, which is necessary for success. If you want to take on this science project, go for it, but take it off the list, this isn't productive.
-Mikeal
On Sep 17, 2012, at September 17, 20122:39 AM, Jorge <jo...@jorgechamorro.com> wrote:
> On 17/09/2012, at 11:12, Ben Noordhuis wrote:
>> On Mon, Sep 17, 2012 at 10:49 AM, Jorge <jo...@jorgechamorro.com> wrote:
>>> 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"...
>> Yes, but the big difference - and I hate to spell it out because it
>> should be obvious - is that you only need to synchronize a single
>> thing instead of every global data structure.
> But that's a different problem. If you want to make thread-safe a program that's abusing globals then yes you're ~ fucked.
> On the other hand it didn't take too long for the V8 guys to fix exactly that in the isolates branch...
>>>> 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).
>> No doubt. Now show me the numbers. :-)
> Ok. Please tell me the secret :-P
> Because to me it's obvious that a copy of (sizeof void*) length is faster than a copy of anything much larger than that.
> Childish and amateurish were not my words in the first place, they were > Crockford's. And, although there may have been a bit of provocation in my > post, I think that the problem is real (otherwise, why would Crockford use > these words?).
No, childish is your word, and so is unprofessional, which you alude to again in your response. Don't hide behind Crockford just because he also used them. He's not here.
The node community IS sometimes unprofessional. Because we don't really buy the old school idea of why being "professional" is supposed to be so great. If you want to work with people, you deal with real people. Not rigid, restrained approximations of real people. You can make the argument that the underlying irreverence is in some way hampering node adoption. That's debatable I think. But what you fail to realize is that even if it were true to a certain extent, we simply do not care. There are things we're willing to compromise on to push node to the top, and some things we are not. Nuno Job is is part of 2 successful node businesses (Nodejitsu, The Node Firm), and he manages to do it while still being funny. Oh mah gawd, how is that possible?! The community has chosen to be genuine instead of "professional". You can disagree, but I'm afraid your protests fall on deaf ears there. We all get enough of being professional at our day jobs.
> My expectation would have been that the topic be discussed at the > technical, professional level between the different people involved. Did > this ever happen? Did any member of the core team ever show any interest in > what Jorge had produced?
This is happening right now. In this thread. Ben is a core member and he's being very receptive and offering lots of info in return. Bradley Meck is also very active and expressed his appreciation for TAGG in the right context. And it has happened in other threads as well. I'm not sure what you think this is supposed to look like. Your beef seems to be that the core team isn't over the moon about the way TAGG approaches the problem. Again, they have opinions about what they want threading support in node to look like. If you want to influence those opinions, you should engage more often, with more data, and in better faith. But you should be prepared for some obstinance because first class threaded programming is not something the community at large is clamoring for. It doesn't fit with the current vision of node. So you'll be fighting to change the vision. That is no small thing and I'm not sure why you think it should be easy.
> There should be a way to discuss issues like threads without going into > sarcasms and personal things.
There probably is. I don't think you've found it yet, and you may not find it here. People here are not a huge fan of threads, and we're doing awesome without them.
We may be swayed with some cajoling though. But you are terrible at cajoling. Just terrible. Get your cajoling skills up. <-- This is me having a little fun with you. You could practice reading it and not going into apoplectic fits.
> This feature (being able to do CPU intensive stuff in JS) may not hit the > sweet spot of node, which is I/O intensive apps. But it does not hurt node > either; it enables something that was impossible (or much harder) to do > before, and it does it with a design which is aligned with node's > principles (computations being treated just like async operations). So why > bash it?
You've heard the reasons why. You just don't like them. And you also seem to be misunderstanding what node's principles are.
On Mon, Sep 17, 2012 at 11:39 AM, Jorge <jo...@jorgechamorro.com> wrote:
> On the other hand it didn't take too long for the V8 guys to fix exactly that in the isolates branch...
That's actually a good example of the cost of threading support: all
benchmarks dropped by 2 to 8% on the day isolates support got merged
into V8 HEAD.
> On Mon, Sep 17, 2012 at 11:39 AM, Jorge <jo...@jorgechamorro.com> wrote:
>> On the other hand it didn't take too long for the V8 guys to fix exactly that in the isolates branch...
> That's actually a good example of the cost of threading support: all
> benchmarks dropped by 2 to 8% on the day isolates support got merged
> into V8 HEAD.
I don't believe it. The benchmarks of the successive versions of node with a single version of V8 show that 99% of the times the culprit of the decrease in node's performance has *not* been V8, much rather the opposite.
-- Jorge.
