Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrent JavaScript: It can work

webkit.org

Post reply on HN
Print view View original

141–150 of 189 posts

Re: Concurrent JavaScript: It can work

#141

Post by millstone »

coldtea wrote: post #49
millstone wrote: post #42

Earlier quoted context omitted.

The event loop doesn't allow you to do a computation concurrently with handling user events, so it's not at all a proper concurrency model.

Surprisingly, that's not what concurrency model means. What you describe is parallelism.

Parallelism means using multiple hardware resources on some task. Concurrency means multiple tasks may make progress in the same time period - perhaps via interleaving.

What I'm saying is that JS is terrible at allowing multiple tasks to make progress when one of those tasks is computation. Try taking some numerical algorithm and allowing interleaving user events with it - it's super nasty.

I hope I'm wrong because I've struggled with this. How would you perform a JS computation concurrently with handling user events?

Re: Concurrent JavaScript: It can work

#142

Post by tiles »

pizlonator wrote: post #124
pcwalton wrote: post #102

Earlier quoted context omitted.

With all due respect, no, it doesn't do fine grained parallelism in the areas I described. Do I think it would be impossible to add parallel styling or layout to WebKit? No. Do I think it would be difficult? Absolutely, primarily because of the difficulty of finding all the concurrency hazards in existing objects and making them thread-safe. It would be easier with a type system that automatically checks for and high…

JavaScript has no type system currently, other than a trivial one with exactly one type. So, adding concurrency via a type system would be like trying to fit a square peg into a round hole. Also, shared memory with no type system help is a proven technique that is used in shipping software and has been for a long time. This leads me to believe that it would be easier to use our existing full shared memory approach to…

> Maybe type system help is for people who don’t practice enough.

That's like advocating that tests are for people who "can't" write bug free code. Is this the attitude of all JSC developers toward engineering abstractions? I would expect designing a system that JITs third-party code from adversarial parties would lead you to be more cautious about code quality, not less.

Re: Concurrent JavaScript: It can work

#143

Post by _dps »

millstone wrote: post #141
coldtea wrote: post #49

Earlier quoted context omitted.

Surprisingly, that's not what concurrency model means. What you describe is parallelism.

Parallelism means using multiple hardware resources on some task. Concurrency means multiple tasks may make progress in the same time period - perhaps via interleaving. What I'm saying is that JS is terrible at allowing multiple tasks to make progress when one of those tasks is computation. Try taking some numerical algorithm and allowing interleaving user events with it - it's super nasty. I hope I'm wrong because I…

I'm not a JS expert, but I do a lot of work with heavy numerical computing that occasionally has to run inside a responsive UI without threading (it's no fun). The solution is "simple", if annoying:

1) you find a small-enough granule of work inside each compute kernel so that one iteration/update/whatever of it is under the target frame duration (for these kinds of UIs 30 FPS is plenty and 15 FPS is tolerable, we're talking business visualization apps and so on)

2) you organize your computation as a resume/yield loop [0]; you run a few iterations of a function like "percent_finished = make_progress(state_of_computation)" then schedule yourself to do another round of progress on the next frame, and return/yield so that the event loop / UI can flush any pending I/O events

Needless to say, this gives up a lot of compute efficiency in return for making it relatively easy to maintain responsiveness. And it doesn't work on problems where you can't find good "yield" points in the computation. But a lot of numerical computing problems have natural/reasonable yield points, e.g. after each data point is processed, or after every 100 elements of a large vector are processed.

[0] A great example of this in a widely used library is the streaming compression interface in zlib, which lets you compress or decompress a nearly-arbitrarily-small granule on each invocation.

Re: Concurrent JavaScript: It can work

#144

Post by olliej »

coldtea wrote: post #101
pizlonator wrote: post #97

Earlier quoted context omitted.

I do threads and I just said that they are not messy.

Well, nobody sane then if I'm allowed the Scotsman! People also defend all kinds of dangerous constructs or practices blaming other programmers for not being good enough to use them even though statistically even the best programmers suffer from problems derived from them (e.g. buffer overflows, or in the case of threads race conditions, starvation, etc.). And since we're particularly talking about adding threads to…

Appealing to authority isn't a valid argument.

Brendan and I have had many discussions about the nature of threading in JS.

The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers.

If you read the article you'll see that there isn't any way to mismatch lock/unlock.

The other massive footgun is the for whatever reason people insist on creating standard libraries that are not thread safe (collections, apparently bigint in java?). JS is never going to have completely undefined behavior, but non-determinism already exists.

Is concurrent code easier to screw up than single thread? yes. Is that cost enough to discount the possibility of ever having threads? I don't know. The article goes one way, you clearly go the other.

Re: Concurrent JavaScript: It can work

#145

Post by millstone »

Jtsummers wrote: post #68
pizlonator wrote: post #65

Earlier quoted context omitted.

"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. One really bad way to do this is to have the timeslicing granule be computations of unbounded length with no preemption. I agree with you that it's valid to refer to event loops as a kind of concurrency. I would call it a very primitive and low-quality kind of concurrency. But it's…

I'll generally agree with your definitions for concurrency and parallelism. Our parallelism definitions were essentially the same. But what you say about coldtea is not a fair interpretation of their post. millstone said this: The event loop doesn't allow you to do a computation concurrently with handling user events, so it's not at all a proper concurrency model. By this definition, concurrency is only occurring whe…

That's not the definition I had in mind. What I meant is that JavaScript lacks an easy way to allow for computation that doesn't block the event loop.

We can imagine an old school cooperative multithreading architecture:

    for (var i = 0; i
but JavaScript does not support this. Instead you have to awkwardly re-structure your computation in CPS or an equivalent to do this sort of thing.

Re: Concurrent JavaScript: It can work

#146

Post by pizlonator »

tiles wrote: post #142
pizlonator wrote: post #124

Earlier quoted context omitted.

JavaScript has no type system currently, other than a trivial one with exactly one type. So, adding concurrency via a type system would be like trying to fit a square peg into a round hole. Also, shared memory with no type system help is a proven technique that is used in shipping software and has been for a long time. This leads me to believe that it would be easier to use our existing full shared memory approach to…

> Maybe type system help is for people who don’t practice enough. That's like advocating that tests are for people who "can't" write bug free code. Is this the attitude of all JSC developers toward engineering abstractions? I would expect designing a system that JITs third-party code from adversarial parties would lead you to be more cautious about code quality, not less.

Tests are great. No harm in tests.

I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. Therefore, I err on the side of not using the type system for that purpose so that I can use it for many other things that I think it's really good at.

(Just take a look at JSC's source code if you want to see our extensive reliance on those areas of C++'s type system that we can use to get hard guarantees. It's not that we don't like types. It's that we use types in an evidence-based way in those places where they actually help us catch bugs.)

Re: Concurrent JavaScript: It can work

#147

Post by coldtea »

millstone wrote: post #141
coldtea wrote: post #49

Earlier quoted context omitted.

Surprisingly, that's not what concurrency model means. What you describe is parallelism.

Parallelism means using multiple hardware resources on some task. Concurrency means multiple tasks may make progress in the same time period - perhaps via interleaving. What I'm saying is that JS is terrible at allowing multiple tasks to make progress when one of those tasks is computation. Try taking some numerical algorithm and allowing interleaving user events with it - it's super nasty. I hope I'm wrong because I…

>I hope I'm wrong because I've struggled with this. How would you perform a JS computation concurrently with handling user events?

Like everything else -- by breaking the work into small steps, and e.g. doing looping etc asynchronously.

There's this coming officially now too: https://tc39.github.io/proposal-async-iteration/

Re: Concurrent JavaScript: It can work

#148

Post by zackmorris »

I'm late to the party but please for anyone reading this, look into the actor model. Shared mutable state quickly becomes unmaintainanble. It used to be slow to do shared immutable state but that's no longer the case. Today there are many better ways to do shared memory with copy-on-write so data is only copied if it's changed. Think back on history - there are only a handful of computation approaches that have stood the test of time. Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker. Had concepts from those programs made it into programming, our lives would be a lot simpler today. We don't need to torture ourselves for imagined efficiency by copying the C threading model that quickly dissolves into spaghetti.

Re: Concurrent JavaScript: It can work

#149

Post by olau »

flagxor wrote: post #137
colordrops wrote: post #133

Earlier quoted context omitted.

> Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O. That's non determinism from I/O, not from the callback or the setTimeout. setTimeouts are called in order based on schedule time. And you can't blame non-determinism in JS on I/O. No language in existence is deterministic based on that measure.

This seems rather racy in Chrome, despite the I/O being deferred to the end :-) (function() { var x = ''; setTimeout(function() { setTimeout(function() { x += 'a'; }, 6); }, 4); setTimeout(function() { setTimeout(function() { x += 'b'; }, 5); }, 5); setTimeout(function() { console.log(x); }, 50); })(); It's a fair point that generally I/O is the source of the bulk of the non-determinism in most JS programs. But if th…

I object to the term "similar care". There's a big difference in what it takes to understand thread issues compared to single-threaded event-based systems.

For instance, if I'm not mistaken, your setTimeout thing is relying on precise timing. But this is documented when you look up setTimeout. It's not difficult to understand.

How to use locks and conditions/monitors correctly IS difficult to understand. You can't just read a few lines in the API documentation and proceed on to write correct code, beyond small toy examples.

Re: Concurrent JavaScript: It can work

#150

Post by coldtea »

olliej wrote: post #144
coldtea wrote: post #101

Earlier quoted context omitted.

Well, nobody sane then if I'm allowed the Scotsman! People also defend all kinds of dangerous constructs or practices blaming other programmers for not being good enough to use them even though statistically even the best programmers suffer from problems derived from them (e.g. buffer overflows, or in the case of threads race conditions, starvation, etc.). And since we're particularly talking about adding threads to…

Appealing to authority isn't a valid argument. Brendan and I have had many discussions about the nature of threading in JS. The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers. If you read the article you'll see that there isn't any way to mismatch lock/unlock. The other massive footgun is the fo…

>Appealing to authority isn't a valid argument.

Calling out "argument from authority" when someone posted actual arguments an authority made is even less valid.

>The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers.

Perhaps, but this is an orthogonal concern as to the issues with threads themselves (not to mention with an environment that has since forever assumed a single thread of execution).

Post reply on HN