Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

vimeo.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#21

Post by quietbritishjim »

lelandbatey wrote: post #13
davydm wrote: post #3

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 n…

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 tha…

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

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#23

Post by bjoli »

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not like m:n stuff.

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.

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#24

Post by petilon »

After watching the video I can see how go lang makes it easier to write correct concurrent programs. But with AI writing the code these days, it is just as "easy" to write correct concurrent programs in Java (because AI is doing the work). Java's virtual threads are light weight, just like go's routines. Java's LinkedBlockingQueue offers roughly the same functionality as go's channels. I would like to hear from go experts as to why I am wrong. Does go have any inherent advantage if AI is writing the code?

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#26

Post by convolvatron »

quietbritishjim wrote: post #21
lelandbatey wrote: post #13

Earlier quoted context omitted.

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 tha…

> 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 concu…

concurrent programs enable parallel evaluation. concurrency is necessary but not sufficient for parallelism.

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#27

Post by kllrnohj »

bjoli wrote: post #23

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not like m:n stuff. 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.

That's because they are very rarely useful. This was true then and it's still true now. There's just not many workloads where it makes sense to need to rapidly launch a thread that doesn't need to do much of anything but does need to exist for a while before terminating.

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.

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#28

Post by smallstepforman »

bjoli wrote: post #23

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not like m:n stuff. 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.

Yet the average software engineer hasn’t heard or Carl Hewitt, Joe Armstrong, has never programmed in an Actor Programming model, and dont even know what it is.

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#29

Post by BobbyJo »

bjoli wrote: post #23

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not like m:n stuff. 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.

Back then you could spend 6 months making something twice as fast, or wait six months for computers to become twice as fast. People obviously did the latter.

It also became a cycle: People write single threaded code -> CPUs/OSs optimize performance/ergonomics for single threaded programs -> People write single threaded code ->...

It wasn't until scaling slowed down that interest/investment in concurrency/parallelism took off.

Re: Rob Pike – 'Concurrency Is Not Parallelism' [video] (2012)

#30

Post by freedomben »

kllrnohj wrote: post #27
bjoli wrote: post #23

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not like m:n stuff. 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.

That's because they are very rarely useful. This was true then and it's still true now. There's just not many workloads where it makes sense to need to rapidly launch a thread that doesn't need to do much of anything but does need to exist for a while before terminating. 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 threadi…

Exactly. When I started getting into go 15 years ago, and 10 years ago or so into elixir, I loved the easy concurrency and tried to use it to the maximum possible. What I discovered is that they're just aren't that many things that you can do concurrently. Reading many different files or servicing many different network sockets being the exception, but realistically that isn't done very often relative to single threaded stuff.

State machine/management is really what is most useful

Post reply on HN