Hacker News Reader

Comment by preek | Hacker News Reader

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction.

If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended.

Learning a language that makes a proper distinction will help - I got it through Clojure, but there's certainly others like (obviously) Golang.

0. https://youtu.be/cN_DpYBzKso

View on HN

You've got to love computer scientists:

"Hey, there's this word 'concurrent', which means to happen at the same time, what should it mean in our field?"

"How about, 'happening in independent processes'?"

"Great! There's this other word, 'parallel', that means coexist alongside but be structurally independent. What should that mean?"

"How about, 'happening at the same time'?"

"Fantastic! OK, let's go to the pub."

Hard to believe that people get confused.

Even loop is not concurrency.

Just because concurrency and parallelism are different does not meant that concurrency and event loops are the same.

You can build concurrency on the event-loop, though, which is what the OP was probably referring to.

Not quite. Consider a component in your code that does this:

    for (let blah of things)
        foo(blah);

In an event loop, if things has a lot of stuff in it, this can block the event loop. Other things in the event loop won't be able to run until this completes.

With threads, this just works.

That is parallelism, not concurrency.

Concurrency: two functions can run one after the other while they are non blocking for the callers (e.g. hyperthreading).

Parallelism: two functions can run at the same time (e.g. multiple processors).

Your definition of concurrency is not correct. Concurrency usually implies that the work is chopped up into very small interleavable bits. A while function call with a loop of unbounded length being the default granule of interleaving is definitely not part of the definition of concurrency.

The term "concurrency" subsumes both event loop style concurrency and two-cores-running-code-at-the-same time concurrency.

Yes, it is. The JavaScript event loop is a very lazy scheduler than does no preemption. It's a very primitive concurrency model. It's up to the users of the language to break their tasks down into sufficiently small components or yield to allow for interleaving of work.

Creating async tasks that can run concurrently and deliver progress via events is a concurrency model.

How? Explain please. https://en.wikipedia.org/wiki/Concurrency_(computer_science)

"order-independent components", which makes sense for the Event loop.

I draw the line at whether the interleaving granule is under the programmer’s control or not.

For example, I can say that when a task executes on an event loop, no other tasks are executing concurrently to it because the event loop executes tasks sequentially.

Ok you draw the line there, but definitions are supposed to be commonly understood, that's how language works...

Yeah, I agree it would be better if people in the event loop community learned to use the word “concurrency” correctly.

Events and asynchronous operations are sufficient enough for a concurrency library to be built on top of JS with minimal changes. I wouldn't consider what JS has now a reasonable concurrency model but the asynchronous event handling could serve as a starting point for a source of events that run on multiple threads.

That was the state-of-the-art in OS concurrency in the early nineties. Sometimes, you would have to reboot your computer because some app forgot to yield the event loop.

It's not as bad if you have to restart your app because some task forgot to yield the event loop, but it's still bad.

Threads solve this problem comprehensively because threads get to make progress regardless of whether or not other threads are in a loop.

> That was the state-of-the-art in OS concurrency in the early nineties.

Many systems had pre-emptive multitasking in seventies and eighties.

I think Amiga was the first implementation for consumers. Released in 1985. https://en.wikipedia.org/wiki/Amiga_1000

In case anyone is wondering: this is nonsense.

JS the language has about as much to say about concurrency as C does.

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.

It's a proper concurrency model, it's just not an efficient one when it comes to execution.

Concurrency has (at least) two components: design concurrency, execution concurrency. The event loop mechanism in JavaScript allows you to do effective concurrent design. It does not provide for concurrent execution. This is the primary distinction in academic CS between concurrency and parallelism.

The event loop mechanism in JavaScript is not well suited to designing OR executing a computation concurrently. Try replacing a for loop in numeric code with anything that allows for events to be handled. It's extremely awkward.

Surprisingly, that's not what concurrency model means.

What you describe is parallelism.

Concurrency generally means preemption. Event loops have no preemption. It's not correct to use parallelism to mean preemption, as you seem to be doing.

In CS, parallelism is simultaneity. Two things are parallel if they occur at the same time.

Concurrency is design, which may allow for parallelism. And may allow for preemption. Preemptive or cooperative concurrency is a design decision, both are concurrency.

"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 not at all valid to claim, as @coldtea seems to be doing, that concurrency excludes the notion of two things happening at the same time. He's implying that if you run things at the same time then it's called parallelism. That's just not true. It's still called concurrency, even though it could also be called parallelism in the right circumstances.

I think it's best to understand this terminology this way:

Concurrency: the phenomenon of two things happening at the same time, or being made to appear that way.

Parallelism: the study of how to make things run to completion in less time by using multiple CPUs or computers.

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 when two things happen simultaneously. coldtea is correct that that is parallelism.

Parallelism, and coldtea's comment does not exclude this, is a special case of concurrency. It is the case where a program's components execute simultaneously. Whereas, generally, concurrency in CS does not require simultaneous action (as you state in your definition).

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 < arr.length; i++) {
        someCalculation(arr[i]);
        yieldToNextEvent();
    }

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.

I don't think that's the fault of JavaScript - it does not specify the event loop itself. ES6 has generators, so all you need is an enqueue(fn*(){}). There's already an enqueue in the browser - setTimeout(), and one in node - nextTick(), so all the functionality you need is there.

In the context of computing, I prefer to simplify to:

Concurrency: Having more than one linear sequence of instructions logically active at the same time.

Parallelism: Having more than one instruction physically being executed at the same time.

>"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.

For one, the CS literature defines concurrency as not necessarily being at the same time.

Second, timeslice, by definition, is not at the same time. Hence the need to use quotes there. Concurrently does not mean "at the same time" any more than "timeslice" implies.

>But it's not at all valid to claim, as @coldtea seems to be doing, that concurrency excludes the notion of two things happening at the same time.

I never claimed that. I wrote that concurrency is not parallelism (which it isn't), not that it excludes parallelism.

Basic timeslicing (baring any other mechanism) for example is concurrent but not parallel. Node's evented "cooperative" concurrency is also not parallel.

Timeslicing makes it impossible for a program to accidentally discover that its threads or processes are not really running at the same time. For example, an infinite loop in one thread will not halt all other threads. To me, that’s concurrency.

Event loops are not like that. They run tasks to completion before starting other tasks and indeed the whole point of how you leverage an event loop is to take advantage of the fact that other things don’t happen at the same time. I would prefer to say other things don’t happen concurrently, and you would have understood my meaning.

It’s not correct to have used the word “parallel” in that context since my example only needs one CPU.

I think it’s ok to think of event loop interleaving bugs as being concurrency bugs, but insisting that event loops are proper instance of concurrency is diluting the terminology too much IMO. Hence I much refer to use concurrency to mean the case where the interleaving granule is not under the programmer’s control.

>Concurrency generally means preemption

No, it doesn't. Concurrency is about the logical structure of the code. From Wikipedia:

  "In computer science, concurrency is the decomposability 
  property of a program, algorithm, or problem into order-
  independent or partially-ordered components or units. This 
  means that even if the concurrent units of the program, 
  algorithm, or problem are executed out-of-order or in 
  partial order, the final outcome will remain the same".

And from "Parallel and Concurrent Programming in Haskell":

  In many fields, the words parallel and concurrent are 
  synonyms; not so in programming, where they are used to 
  describe fundamentally different concepts.

  A parallel program is one that uses a multiplicity of 
  computational hardware (e.g. multiple processor cores) in 
  order to perform computation more quickly. Different parts 
  of the computation are delegated to different processors 
  that execute at the same time (in parallel), so that 
  results may be delivered earlier than if the computation 
  had been performed sequentially.

  In contrast, concurrency is a program-structuring technique 
  in which there are multiple threads of control. Notionally 
  the threads of control execute "at the same time"; that is, 
  the user sees their effects interleaved. Whether they 
  actually execute at the same time or not is an 
  implementation detail; a concurrent program can execute on 
  a single processor through interleaved execution, or on 
  multiple physical processors.

Note: "program-structuring technique", "Notionally" and "implementation detail".

Concurrency is NOT "running in parallel" (running simultaneously), as you seem to believe, and not even about your code getting preempted. As long as it's structured concurrently, that is.

But if you have concurrency AND preemption OR different independent processes etc over multiple cpus you can have parallelism. In a sense concurrency is a more generic principle.

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?

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.

>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/

Reply on news.ycombinator.com