5 ms·

I'm going to argue against the idea that functional languages are flourishing as a result of the availability of parallelism. There are two reasons for this: *

I'm going to argue against the idea that functional languages are flourishing as a result of the availability of parallelism. There are two reasons for this: * Performance is not that big an issue for many applications. And if performance is not an issue, then neither is parallelism: the only reason to do parallelism is for performance (as opposed to concurrency, which makes sense even on sequential processors). So parallelism only really matters for performance-critical applications, because in most non-performance critical applications, you can squeeze out 10x by just running a profiler and writing better serial code. * If you do want performance, parallelism alone is not sufficient. On modern processors, data movement is significantly more expensive than computation. And in that regard, most functional languages perform poorly. Imperative languages, for all their faults, give you much more fine grained control over memory usage patterns. So for performance-critical applications (which are again, the only applications where you really care about parallelism), it is not uncommon to see the core of the application written in C/C++, even if the rest of the application is written in something else. By the way, if you aren't measuring your performance by comparing it against the peak compute/memory bandwidth of the machine, then you don't really care about performance, because you don't really have any idea what you're leaving on the table. This is why it's possible, for many applications, to give the code to an experienced performance programmer and see speedups in excess of 10x.

ShardPhoenix 13y ago
I agree - for me, immutability is much more about making code easy to reason about than it is about making it parallelizable.
- vandeekamp 13y ago
  I'm frankly tired of this rich hickey meme of "reasoning about" code. And I'm sorry but when you and even rich says it it's misleading conflation intended to confuse the listener. Implementing stateless systems in OOP is trivial. As in fucking a child can do it. And we have been doing it for DECADES. This "reasoning about" meme also implies that all code we write is inherently algorithmic and simply a computation. It is NOT.. 90 percent of code is just moving data around. The ten percent of algorithmic code, That involves actual math is usually trivially implemented in OOP languages. So lets rid ourselves of blowhard statements like "reasoning about' Because if you had any real experience you would understand we deal with these problems quite simply in OOP every day. Here's something for YOU to reason about. Us OOP guys can do the same thing better and actually understand the code 2 weeks later. We don't need to "reason" about it
barrkel 13y ago
You can still care about performance by having acceptance criteria for throughput and latency, even when it's not the best the machine can do. You sound like you're arguing for a binary perspective on performance. But performance is a tradeoff. Often performance comes from de-abstracting multiple steps in a program's operation, reducing redundancies introduced by modularity and composability, and increasing complexity by denormalising data structures. Design for performance thus often comes at the cost of development agility and operational correctness. Being correct and agile yet still meeting performance criteria is a bigger win for most businesses, which usually aren't constrained by cost and raw speed of hardware. Functional programming, to the degree that it let's you exploit machine parallelism, gives you more leeway for good design before you risk missing your perf requirements. And that's a reason functional programming is actually given a boost by hardware parallelism. (Much bigger is that it's often a better way to structure programs, and now there is less integration costs since you hide behind the - yes - functional, stateless API of a http request handler, an explicit function of input to output.) PS: your perspective on perf is kinda off to me. Almost all applications care about performance. If they never terminated they'd be useless. Performance isn't just a priority, it's a requirement. But usually it's just a deadline and a hardware cost multiplier - and money saved on hardware may not be enough to pay for extra / more expensive people elsewhere.
- eslaught 13y ago
  > Design for performance thus often comes at the cost of development agility and operational correctness. Being correct and agile yet still meeting performance criteria is a bigger win for most businesses, which usually aren't constrained by cost and raw speed of hardware. This point illustrates exactly the reason why people don't really care about performance. Performance is an arbitrarily deep rabbit hole that you can go down as far as you want. But because performance trades off with other things that people frequently want more (simplicity and maintainability, among others), they stop when performance is "good enough". What is "good enough" for most people? Probably 10x away from what the machine is actually capable of. You probably think I'm being flippant by claiming that these sort of speedups are possible on real applications. I am not. In high performance computing (HPC), this happens surprisingly frequently, perhaps because people are willing to trade off almost anything for performance. Here's an example of a paper showing speedups over some 30 year-old Fortran/MPI code: http://conferences.computer.org/sc/2012/papers/1000a040.pdf http://conferences.computer.org/sc/2012/papers/1000a040.pdf And for this particular application I happen to know that there is another paper in submission which shows additional speedups over what this paper got. People who are willing to squeeze keep finding ways to optimize this application.
georgewfraser 13y ago
> On modern processors, data movement is significantly more expensive than computation This is so true, and is really an emperor-has-no-clothes statement with respect to this claim that in the future we're all going to use immutable data structures to leverage multiple cores. Every situation where I've had to write performant code has ended up in one of these two cases: 1. All the time is spent in linear algebra, in which case it's all about planning out the computation so LAPACK can do its thing. 2. There's some funky custom signal manipulation. Some tiny bit of code needs to be in C, with everything in nice packed arrays in the right order so you can sweep straight through.

ShardPhoenix 13y ago

I agree - for me, immutability is much more about making code easy to reason about than it is about making it parallelizable.

vandeekamp 13y ago
I'm frankly tired of this rich hickey meme of "reasoning about" code. And I'm sorry but when you and even rich says it it's misleading conflation intended to confuse the listener. Implementing stateless systems in OOP is trivial. As in fucking a child can do it. And we have been doing it for DECADES. This "reasoning about" meme also implies that all code we write is inherently algorithmic and simply a computation. It is NOT.. 90 percent of code is just moving data around. The ten percent of algorithmic code, That involves actual math is usually trivially implemented in OOP languages. So lets rid ourselves of blowhard statements like "reasoning about' Because if you had any real experience you would understand we deal with these problems quite simply in OOP every day. Here's something for YOU to reason about. Us OOP guys can do the same thing better and actually understand the code 2 weeks later. We don't need to "reason" about it

barrkel 13y ago

You can still care about performance by having acceptance criteria for throughput and latency, even when it's not the best the machine can do. You sound like you're arguing for a binary perspective on performance. But performance is a tradeoff. Often performance comes from de-abstracting multiple steps in a program's operation, reducing redundancies introduced by modularity and composability, and increasing complexity by denormalising data structures. Design for performance thus often comes at the cost of development agility and operational correctness. Being correct and agile yet still meeting performance criteria is a bigger win for most businesses, which usually aren't constrained by cost and raw speed of hardware. Functional programming, to the degree that it let's you exploit machine parallelism, gives you more leeway for good design before you risk missing your perf requirements. And that's a reason functional programming is actually given a boost by hardware parallelism. (Much bigger is that it's often a better way to structure programs, and now there is less integration costs since you hide behind the - yes - functional, stateless API of a http request handler, an explicit function of input to output.) PS: your perspective on perf is kinda off to me. Almost all applications care about performance. If they never terminated they'd be useless. Performance isn't just a priority, it's a requirement. But usually it's just a deadline and a hardware cost multiplier - and money saved on hardware may not be enough to pay for extra / more expensive people elsewhere.

eslaught 13y ago
> Design for performance thus often comes at the cost of development agility and operational correctness. Being correct and agile yet still meeting performance criteria is a bigger win for most businesses, which usually aren't constrained by cost and raw speed of hardware. This point illustrates exactly the reason why people don't really care about performance. Performance is an arbitrarily deep rabbit hole that you can go down as far as you want. But because performance trades off with other things that people frequently want more (simplicity and maintainability, among others), they stop when performance is "good enough". What is "good enough" for most people? Probably 10x away from what the machine is actually capable of. You probably think I'm being flippant by claiming that these sort of speedups are possible on real applications. I am not. In high performance computing (HPC), this happens surprisingly frequently, perhaps because people are willing to trade off almost anything for performance. Here's an example of a paper showing speedups over some 30 year-old Fortran/MPI code: http://conferences.computer.org/sc/2012/papers/1000a040.pdf http://conferences.computer.org/sc/2012/papers/1000a040.pdf And for this particular application I happen to know that there is another paper in submission which shows additional speedups over what this paper got. People who are willing to squeeze keep finding ways to optimize this application.

georgewfraser 13y ago

> On modern processors, data movement is significantly more expensive than computation This is so true, and is really an emperor-has-no-clothes statement with respect to this claim that in the future we're all going to use immutable data structures to leverage multiple cores. Every situation where I've had to write performant code has ended up in one of these two cases: 1. All the time is spent in linear algebra, in which case it's all about planning out the computation so LAPACK can do its thing. 2. There's some funky custom signal manipulation. Some tiny bit of code needs to be in C, with everything in nice packed arrays in the right order so you can sweep straight through.