What's not quite clear to me is whether "the cell never moves" is one of the assumptions that actually goes into making this work or not. And if it is, how that plays with a compacting or generational collector, where you do in fact want the cell to move.
Concurrent JavaScript: It can work
71–80 of 189 posts
Re: Concurrent JavaScript: It can work
#72Please, no. Shared-by-default heap memory is one of the greatest mistakes ever made in language design. We need a better design justification than it's the easiest thing to implement right now.
The justification is that when you have an array of 100000 elements and split it into into isolated chunks that can be processed without any synchronisation and then marshall it into json and then actually do the computation and then marshall the result into a json string and marshall it back into a javascript array is very wasteful. Heck even when I'm passing immutable messages I'd still implement it via shared memo…
Fork/join on arrays and trees would be an easier to manage model, IMO.
Re: Concurrent JavaScript: It can work
#73Earlier quoted context omitted.
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.
[deleted]
Re: Concurrent JavaScript: It can work
#74Earlier quoted context omitted.
WebKit uses threads. WebKit is not a twisted mess.
WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads.
Any well written software requires effort to properly design and maintain. What’s the argument here? “Don’t give them shotguns, they might shoot themselves”?
Re: Concurrent JavaScript: It can work
#75Earlier quoted context omitted.
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…
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.
Re: Concurrent JavaScript: It can work
#76Earlier quoted context omitted.
Event loops are great for handling work that can be handed off occasionally to worker threads (like how Node works with libuv), but are awful when doing consistent CPU-bound work, such as with games, 2D/3D visualizations, finance, and the like. SharedArrayBuffer is a nice primitive that allows multiple Threads (or WebWorkers) to work on data in parallel. The additional primitives they're proposing offer quite a bit o…
If you're that concerned about performance, though, aren't doing things like `.asyncJoin()` just going to eat up any potential gains by 1) wrapping the result in a Promise and 2) throwing the Promise back into the event/microtask queue? It seems like the transport would quickly become the bottleneck. I'm also struggling to understand what tier of performance you're aiming for, since you're hoping to boost performance…
Joins like that wouldn't really be used for coordinating between multiple threads in a fine-grained fashion. For example, maybe you'd kick off two worker thread from your main thread, and each of those is going to do some fine-grained processing on some shared set of data. The main thread needs to know when that process is finished, so it joins both threads.
Re: Concurrent JavaScript: It can work
#77Earlier quoted context omitted.
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.
>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".
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.
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.
Re: Concurrent JavaScript: It can work
#78Earlier quoted context omitted.
JS already supports immutable objects, by using Object.freeze().
That doesn't really make things immutable. Even ignoring the deep vs shallow issue, consider what effect Object.freeze has on a JS Map (hint: none, really; you can still add/remove things).
Right, that's where libraries like ImmutableJS come in.
Re: Concurrent JavaScript: It can work
#79They mean parallelism, right? Concurrency is what JS is already known for.
Re: Concurrent JavaScript: It can work
#80Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each... For browsers, this is a bad idea. The biggest advantage of the event loop approach is that it is somewhat deterministic. With threads, that determinism goes out of the window. Lock-management? No way I do that for Browsers. I will quit working on client-side code if that is becoming a requirement! Threads for…
For that matter, anyone who'd like to have "fun" with concurrency and lock management in browser-side JS is free to play around with recurring asynchronous data fetching cached in localStorage when multiple browser tabs are open.
Spoiler: locks are the wrong approach and you should be relying on events/callbacks instead. Oddly enough, that's similar to my gut feeling about Threads in JS.