yeah, i use that often, eg when a video is slow on a website - at least yt-dlp will shard out multiple piece-downloaders, and I can get the video in a few seconds or minutes, and just watch it. Also great for anonymizing sharing videos - download the actual video, share that. Not an url (:
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.
No, and that's the point of the article. What you are calling parallel w/r/t IO should be called concurrency (conceptually happening at the same time by virtue of being able to interrupt and resume units of work). The reason IO APIs like you've described is concurrent but not necessqrily parallel is because there is no guarantee in the API that they both happen literally simultaneously; I could build a JS runtime that "works" for all the code written against XMLHTTPRequest (ignoring side-effects) but which under the hood only ever makes one HTTP request at a time. And because I can do that, that means JS code is living in a concurrency-only world, even though as an implementation detail most runtimes support parallel execution of those concurrent operations.
> there is no guarantee in the API that they both happen literally simultaneously
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.
Why does Vimeo require me to verify my age in the UK to watch Robert Pike talking computer science?
Surveillance, got to track you all across the internet.
Compliance with the absurd and draconian OSA
In Greece (EU). Can’t play it either. I’m getting:
> This video is not rated
> Join vimeo to watch
> Already have an account? Log in
Alt link: https://www.youtube.com/watch?v=54EV4dDdLO0
because otherwise how would the queen know what you're up to all the time? :D
Since she was probably sent by God to rule, I assume he called her back upstairs upon her passing. In this case, she can just ask the big man.
Funnily enough, yt-dlp has no trouble downloading it.
Side note: we do have a Queen. She's married to the King.
Hah! Fair point. Not sure why she would want to surveil me, but at this point...
yeah, i use that often, eg when a video is slow on a website - at least yt-dlp will shard out multiple piece-downloaders, and I can get the video in a few seconds or minutes, and just watch it. Also great for anonymizing sharing videos - download the actual video, share that. Not an url (:
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
Slides - https://go.dev/talks/2012/waza.slide
To HN moderators: title needs to note that this talk is 13 years old.
The title must have been edited in the last 40min - it shows (2012) now
it's an interesting talk, my take being:
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.
> concurrency _is_ parallelism, but for I/O.
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.
Concurrency is the property of a program or algorithm such that:
Your data-level parallelism is taking advantage of the concurrent properties of a problem.No, and that's the point of the article. What you are calling parallel w/r/t IO should be called concurrency (conceptually happening at the same time by virtue of being able to interrupt and resume units of work). The reason IO APIs like you've described is concurrent but not necessqrily parallel is because there is no guarantee in the API that they both happen literally simultaneously; I could build a JS runtime that "works" for all the code written against XMLHTTPRequest (ignoring side-effects) but which under the hood only ever makes one HTTP request at a time. And because I can do that, that means JS code is living in a concurrency-only world, even though as an implementation detail most runtimes support parallel execution of those concurrent operations.
> there is no guarantee in the API that they both happen literally simultaneously
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.