Thread

1. criddell · 1790278663 · focus · HN ↗

   This review seems to equate parallelism and concurrency as the same thing and they are not.

   As I understand it, the parallelism is about task execution and concurrency is about task structure. Or, as Rob Pike said:

   "Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."

   He said that in his Concurrency is not Parallelism talk.

   1. threethirtytwo · 1790320780 · focus · HN ↗

      Yeah although they say something like nodejs is not parallel but concurrent it’s not technically true from a systems standpoint. There are actually tons of operations happening at the same time. It’s just all delegated to IO.

      True concurrency that is absolutely absent of parallelism is a bit pointless, that’s why although node is concurrent, it is explicitly designed such that it migrates parallelism to IO.

      1. gpderetta · 1790325907 · focus · HN ↗

         > True concurrency that is absolutely absent of parallelism is a bit pointless

         It is very important in interactive or realtime systems.

         1. threethirtytwo · 1790363349 · focus · HN ↗

            I disagree. You don't need concurrency. Say for a video game with many things happening all at once. You think you need concurrency... but you don't.

            Imagine for the simplest example of a CPU only based game. If I want to render the positions of thousands of soldiers, just do it in a loop. Why would I spawn thousands of coroutines ONLY for the coroutines to do it all in order anyway? Makes no sense.

            1. gpderetta · 1790679274 · focus · HN ↗

               how do you implement, for example, a general purpose OS kernel without concurrency?

               For some tasks, the static scheduling you described is appropriate (although you could still consider it a form of concurrency), but it needs complete cooperation between tasks and an overall design.

               But as soon as you need some sort of fairness, responsiveness, and tasks that are not designed for full cooperation if not outright hostile, you need not only concurrency, but full preemption.

               1. threethirtytwo · 1790861451 · focus · HN ↗

                  In the game it seems like everything is concurrent but all of that was built without using concurrency primitives.

                  Same thing with the OS. You can build in concurrency without using concurrency primitives because it’s not needed. Right? Let’s say when building an os I had access to spawn go routines in a single threaded context and I used that to build the os. It would be pretty pointless right? You would use a loop here and iterate over the tasks to build the concept of “threading” you wouldn’t need go routines.

                  It’s strange to talk about it at this level because what’s going on is your implementing “concurrency” from no concurrency. Is having a loop iterate over tasks really concurrency? I would say no, because people think of concurrency like using a threading primitive. If you didn’t fork or activate a call back or await something you didn’t activate “concurrency”.

                  Concurrency is a higher level concept that only exists where primitives for using concurrency exist.

                  Thus It makes More sense to frame my argument from the application layer. Without parallelism, concurrency is pointless in the sense that the usage of concurrency primitives given to you by the framework or the OS is pointless.

Unofficial Hacker News client; not affiliated with Y Combinator.