ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
50% Positive
Analyzed from 774 words in the discussion.
Trending Topics
#concurrency#parallelism#parallel#watch#concurrent#video#java#multiple#code#threads
Discussion (24 Comments)Read Original on HackerNews
I sometimes wonder where we would be now if people would have gone "Wow, mr Reppy! concurrentML is so cool!" in 1993.
instead we got pthreads and collective amnesia and later we got go's girly times and channels which are only half way there.
What is useful is the state machine aspects of things like coroutines or async/await, but those aren't quite fibers and very much aren't M:N threading. A major use of them is in UI where they have strict thread requirements even.
> This video is not rated
> Join vimeo to watch
> Already have an account? Log in
Funnily enough, yt-dlp has no trouble downloading it.
In much the same vein, I rarely actually watch stuff _on_ netflix, through a browser - I watch sped up, and the quality just degrades. Since I pay for it, I feel nothing for downloading a ripped copy to watch it locally :D
concurrency _is_ parallelism, but for I/O. People often think of parallelism for the case of making something go faster - eg placing two computations in parallel (the definition posed in the video), OR placing two I/O operations in parallel - so this is the keyboard-vs-mouse in the OS, even when you're on one core only; this is multiple web requests in JavaScript, which does not support multi-threading, but 100% does support concurrency for I/O operations - that... badum-tiss! RUN IN PARALLEL.
I get the point of the talk, and it's well interesting, but I think it depends on how one views things.
Not really. They're just separate but related concepts.
E.g. coroutines are a form of concurrency that doesn't have to involve any sort of I/O, you're just taking two logical processes (e.g generating a sequence and consuming it) and abstracting away how they execute relative to each other.
Describing your tasks using the language of concurrency is a requirement for process-based parallelism (multiple CPUs/cores), but data-level parallelism (SIMD) is a form of parallelism that doesn't involve concurrency either.
There's no actual guarantee in the API that if you spawn multiple threads and call blocking network I/O that those happen literally simultaneously. Maybe the OS has a big mutex on network I/O to serialise them.
Of course, that's not what happens in practice. But neither is it what happens, in practice, to async network APIs called concurrently in one thread. So I don't think that can be the difference between concurrent and parallel.