5 ms·

The CPU and the von Neumann architecture itself is procedural. High level code is mapped to assembly code, which is then mapped to binary machine code. Given t

The CPU and the von Neumann architecture itself is procedural. High level code is mapped to assembly code, which is then mapped to binary machine code. Given that, then higher level languages are merely another layer of abstraction. C is procedural, and while it can be functionally separated, it still maps down to assembly, and then to machine code. Same goes for Lisp, or Haskell, or any other functional language. It still follows the chain down, and maps to assembly and machine code. Given that, then what is the ability for a purely functional language, like Haskell, or whatnot, to utilize the full feature of today’s multi-core CPUs? For example, a common functional approach, is to use a map() function, and apply a specific function, against a set of data. Say, you have a list of 1000 strings, and you want to capitalize it all, and return the new list of all capitalized strings. Then, you’d have another function called upper() that will apply to each element in that list. So, your function call might look something like: capped_list = map( upper, my_list ) And your return data, capped_list, will contain the list of all strings, capitalized. Simple enough. So, the question is, do functional languages automatically have the ability to take this instruction, and spread the data over multiple cores, or multiple processors, in order to return the final answer, in a faster or more efficient process than a regular procedural language?

Athas 6y ago
> So, the question is, do functional languages automatically have the ability to take this instruction, and spread the data over multiple cores, or multiple processors, in order to return the final answer, in a faster or more efficient process than a regular procedural language? Purely functional languages make it trivial to get correct parallelism. In all cases, such a 'map' can be parallelised without risk of race conditions. Impure languages rely either on complex analyses to figure out when parallelism is safe, or on programmer annotations. Whether it's a good idea to parallelise 'map' automatically is a different question. More parallelism is not always better, as all parallelism comes with overhead. Indeed, the entire point of this ray tracing benchmark is to investigate to which degree the trivial exploitation of parallelism also translates to good performance in practice (as that is ultimately the purpose of parallelism).
imtringued 6y ago
It's easy to create parallel algorithms. It's difficult to create an algorithm that scales linearly with core count.
pjc50 6y ago
Generally they won't auto-parallelise, because the tradeoff between inter-thread communication time and performance as well as thread lifetime tends to need manual control. Both functional and imperative languages can auto-vectorise, although in a functional language it's a lot easier to check that the map is side-effect-free! If your "upper" function is allowed to mutate other list elements then suddenly order of execution matters. C#'s functional-flavoured sublanguage of LINQ has an auto-paralleliser: https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/introduction-to-plinq https://docs.microsoft.com/en-us/dotnet/standard/parallel-pr... (I absolutely love writing functional-style code in a fairly-strongly-typed imperative language, because you can usually get all the benefits of functional when you need them and not trip over yourself when you need to actually do IO or interface with the system)
dtech 6y ago
> So, the question is, do functional languages automatically have the ability to take this instruction, and spread the data over multiple cores, or multiple processors, in order to return the final answer, in a faster or more efficient process than a regular procedural language? Generally not, because you need a decent seize dataset and/or operation duration before parallelization has an advantage Capitalizing 1000 strings is not going to be faster in parallel, but 1 billion probably is. So it solving 10 ILP problems. However, the advantage is that when you want to parallelize, the risk of bugs, race conditions or unintended ordering is much, much smaller in functional programming languages.
entha_saava 6y ago
Explicit parallelism can be much easier on abstract streams. And that is better than implicit parallelization. Running on many cores for max throughput is not important for many applications, as compared to power consumption and CPU / mem usage.
goldenkey 6y ago
https://reference.wolfram.com/language/ref/ParallelMap.html https://reference.wolfram.com/language/ref/ParallelMap.html https://reference.wolfram.com/language/ref/Parallelize.html https://reference.wolfram.com/language/ref/Parallelize.html Yes. waits for the Wolfram hate
- lucozade 6y ago
  > Yes I think you mean no. It's not automatic, you have to tell the language to use parallel constructs. And as others have said, this is probably the right approach. At least if it's not taking runtime information into account. What is very good about this approach (and Rayon does something similar for Rust), is that the code transformation between sequential and parallel constructs is so small. The closer one can come to writing idiomatic code then tweaking it slightly for high performance, the better. Apologies if this answer isn't hate-y enough. I'll try harder next time.
  - goldenkey 6y ago
    If you wrap your entire program block in Parallelize, it becomes automatic. Let's not be too pedantic.

Athas 6y ago

> So, the question is, do functional languages automatically have the ability to take this instruction, and spread the data over multiple cores, or multiple processors, in order to return the final answer, in a faster or more efficient process than a regular procedural language? Purely functional languages make it trivial to get correct parallelism. In all cases, such a 'map' can be parallelised without risk of race conditions. Impure languages rely either on complex analyses to figure out when parallelism is safe, or on programmer annotations. Whether it's a good idea to parallelise 'map' automatically is a different question. More parallelism is not always better, as all parallelism comes with overhead. Indeed, the entire point of this ray tracing benchmark is to investigate to which degree the trivial exploitation of parallelism also translates to good performance in practice (as that is ultimately the purpose of parallelism).

imtringued 6y ago

It's easy to create parallel algorithms. It's difficult to create an algorithm that scales linearly with core count.

pjc50 6y ago

Generally they won't auto-parallelise, because the tradeoff between inter-thread communication time and performance as well as thread lifetime tends to need manual control. Both functional and imperative languages can auto-vectorise, although in a functional language it's a lot easier to check that the map is side-effect-free! If your "upper" function is allowed to mutate other list elements then suddenly order of execution matters. C#'s functional-flavoured sublanguage of LINQ has an auto-paralleliser: https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/introduction-to-plinq https://docs.microsoft.com/en-us/dotnet/standard/parallel-pr... (I absolutely love writing functional-style code in a fairly-strongly-typed imperative language, because you can usually get all the benefits of functional when you need them and not trip over yourself when you need to actually do IO or interface with the system)

dtech 6y ago

> So, the question is, do functional languages automatically have the ability to take this instruction, and spread the data over multiple cores, or multiple processors, in order to return the final answer, in a faster or more efficient process than a regular procedural language? Generally not, because you need a decent seize dataset and/or operation duration before parallelization has an advantage Capitalizing 1000 strings is not going to be faster in parallel, but 1 billion probably is. So it solving 10 ILP problems. However, the advantage is that when you want to parallelize, the risk of bugs, race conditions or unintended ordering is much, much smaller in functional programming languages.

entha_saava 6y ago

Explicit parallelism can be much easier on abstract streams. And that is better than implicit parallelization. Running on many cores for max throughput is not important for many applications, as compared to power consumption and CPU / mem usage.

goldenkey 6y ago

https://reference.wolfram.com/language/ref/ParallelMap.html https://reference.wolfram.com/language/ref/ParallelMap.html https://reference.wolfram.com/language/ref/Parallelize.html https://reference.wolfram.com/language/ref/Parallelize.html Yes. waits for the Wolfram hate

lucozade 6y ago
> Yes I think you mean no. It's not automatic, you have to tell the language to use parallel constructs. And as others have said, this is probably the right approach. At least if it's not taking runtime information into account. What is very good about this approach (and Rayon does something similar for Rust), is that the code transformation between sequential and parallel constructs is so small. The closer one can come to writing idiomatic code then tweaking it slightly for high performance, the better. Apologies if this answer isn't hate-y enough. I'll try harder next time.
- goldenkey 6y ago
  If you wrap your entire program block in Parallelize, it becomes automatic. Let's not be too pedantic.