Comment by eslaught | Hacker News Reader

Comment by eslaught | Hacker News Reader

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.

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.

> 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

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.

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

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

Reply on news.ycombinator.com