5 ms·

Kind of strawmanning here, no? Obviously sequential tasks are run sequentially. The OP isn't saying "magic" happens. Just, Erlang was written from the beginning

Kind of strawmanning here, no? Obviously sequential tasks are run sequentially. The OP isn't saying "magic" happens. Just, Erlang was written from the beginning to encourage parallelized code. Its whole programming model is around that. Unlike pretty much every language it was contemporary with, which assumed that the default was a single unit of execution (and that code running in parallel was the exception). Think of task scheduling; the normal Algol/C family of languages would say "create a priority queue for your tasks, wait until the top of the queue is ready to run, pull it off, run it, repeat". Very sequential thinking. Of course, you then end up with issues around what happens if the processes take non-negligible amounts of time, what happens if you need to add new items into the queue, etc. At the lowest level that might be solved with interrupts, at a higher level it might be threads or separate processes, but you still have to worry about concurrent data access (locks and the like around the queue). But both the general approach, and the 'best practice' guidelines, especially prior to multi-core, (due to the difficulties of shared data), were/are to minimize concurrency. Erlang, you just spin up every task as its own process. The process sleeps until it's time to do something, then it does it. The language encourages you to solve the problem in a parallel manner, and it did so from the beginning. So, yes, you "need to build parallel algorithms and data structures". The point is, Erlang took advantage of them, as a language, even before the hardware could. The way you would write Erlang for a single core was the way you would write Erlang for many cores, which was unique for a language at the time, and the OP is arguing that not only was Erlang unique in doing that, but that there really isn't a better model for handling parallelism from a language and correctness standpoint (presumably; from a performance perspective m:n threading, of which Erlang actors are a form, is generally agreed upon to lose some efficiency).

chrisseaton 5y ago
> Kind of strawmanning here, no? I don't think so? I'm responding to: > no programs needed changing at all to get the full advantage of all the cores (barring some special cases) Those 'special cases' are all the algorithms which aren't inherently parallel, which is most of them! How many algorithms inherently have a large amount of natural parallelism? I'd say it's very few. For example no matter how you write MD5 on Erlang... it's not going to run in parallel is it?
- lostcolony 5y ago
  As I said before - 'Obviously sequential tasks are run sequentially.' Innately sequential algorithms will still be sequential. Erlang already gave developers the tools, and incentive, to write things in a parallelized fashion. If a developer had a need that was directly sequential, it will, of course, still be sequential. If they had a need that would benefit from parallelism, they had the tools, the context, and the encouragement from the language itself to write it in parallel. Again, I think you're strawmanning here. You kind of implied it yourself with your earlier statement, "Erlang's not going to magic parallelism out of thin air in a program that doesn't have any". Saying that implies you think that's the OP's claim. As I said before, the OP wasn't claiming magic happens, and algorithms written serially suddenly become parallel. You can, of course, still write sequential code in Erlang, same as every language, because execution takes place in time. Just that the natural, ergonomic way of writing the language, of solving problems in the language, has always been parallel. And if you mean "well, I run MD5 checksums on individual blocks of the file, and parallelize it that way" - yes, that is going to be one of those special cases the OP mentioned, if you didn't already optimize it that way due to memory pressure concerns. But if it's "run an md5 checksum against every file in this directory and check it against a manifest", the ergonomic approach in Erlang pre-multicore is to scatter/gather it across actors (since any one file might fail in strange ways and you want to isolate that failure and handle it predictably with a supervisor), and that would parallelize "for free", with no concurrency concerns. Unlike every other contemporary language.
  - chrisseaton 5y ago
    > they had the tools, the context, and the encouragement from the language itself to write it in parallel No I think Erlang gives you the tools, context, and encouragement to write it concurrently. After you have concurrency, you may or may not have parallelism. And if you don't you will have to restructure your program to get it, even if your program was already highly concurrent. That's contrary to what the person I was replying to said.
    - lostcolony 5y ago
rramadass 5y ago
PSA: Great discussion on Concurrency vs. Parallelism starting here; everybody should read the chain starting here.

chrisseaton 5y ago

> Kind of strawmanning here, no? I don't think so? I'm responding to: > no programs needed changing at all to get the full advantage of all the cores (barring some special cases) Those 'special cases' are all the algorithms which aren't inherently parallel, which is most of them! How many algorithms inherently have a large amount of natural parallelism? I'd say it's very few. For example no matter how you write MD5 on Erlang... it's not going to run in parallel is it?

lostcolony 5y ago
As I said before - 'Obviously sequential tasks are run sequentially.' Innately sequential algorithms will still be sequential. Erlang already gave developers the tools, and incentive, to write things in a parallelized fashion. If a developer had a need that was directly sequential, it will, of course, still be sequential. If they had a need that would benefit from parallelism, they had the tools, the context, and the encouragement from the language itself to write it in parallel. Again, I think you're strawmanning here. You kind of implied it yourself with your earlier statement, "Erlang's not going to magic parallelism out of thin air in a program that doesn't have any". Saying that implies you think that's the OP's claim. As I said before, the OP wasn't claiming magic happens, and algorithms written serially suddenly become parallel. You can, of course, still write sequential code in Erlang, same as every language, because execution takes place in time. Just that the natural, ergonomic way of writing the language, of solving problems in the language, has always been parallel. And if you mean "well, I run MD5 checksums on individual blocks of the file, and parallelize it that way" - yes, that is going to be one of those special cases the OP mentioned, if you didn't already optimize it that way due to memory pressure concerns. But if it's "run an md5 checksum against every file in this directory and check it against a manifest", the ergonomic approach in Erlang pre-multicore is to scatter/gather it across actors (since any one file might fail in strange ways and you want to isolate that failure and handle it predictably with a supervisor), and that would parallelize "for free", with no concurrency concerns. Unlike every other contemporary language.
- chrisseaton 5y ago
  > they had the tools, the context, and the encouragement from the language itself to write it in parallel No I think Erlang gives you the tools, context, and encouragement to write it concurrently. After you have concurrency, you may or may not have parallelism. And if you don't you will have to restructure your program to get it, even if your program was already highly concurrent. That's contrary to what the person I was replying to said.
  - lostcolony 5y ago

rramadass 5y ago

PSA: Great discussion on Concurrency vs. Parallelism starting here; everybody should read the chain starting here.