6 ms·

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.

Jtsummers 9y ago
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.
- millstone 9y ago
  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.
coldtea 9y ago
Surprisingly, that's not what concurrency model means. What you describe is parallelism.
- pizlonator 9y ago
  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.
  - Jtsummers 9y ago
    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.
    - pizlonator 9y ago
      "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.
      - Jtsummers 9y ago
        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).
        millstone 9y ago
        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.
  - coldtea 9y ago
    >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.
- millstone 9y ago
  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?
  - _dps 9y ago
    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.
  - coldtea 9y ago
    >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/ https://tc39.github.io/proposal-async-iteration/

Jtsummers 9y ago

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.

millstone 9y ago
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.

coldtea 9y ago

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

pizlonator 9y ago
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.
- Jtsummers 9y ago
  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.
  - pizlonator 9y ago
    "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.
    - Jtsummers 9y ago
      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).
      - millstone 9y ago
        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.
- coldtea 9y ago
  >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.
millstone 9y ago
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?
- _dps 9y ago
  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.
- coldtea 9y ago
  >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/ https://tc39.github.io/proposal-async-iteration/