+ 36

IS FUNCTIONAL PROGRAMMING SLOW ??

Let's bring a bit of context: C is like assembly with a bit of syntatic sugar. It's full of mutable variables in its for loops, but those loops are fast , perhaps because assembly works same way where a register will be incremented or decremented(via single processor instruction) until looping stops. In my mind, C translates easy to assembly. Now functional programming would rather have everything immutable, including elements of a loop for example, like iterating over an object that contains or generates all possible values of that loop. Which means if something has to change (change is inevitable) at some point in the program(not just in loops), those immutable state objects/structures will have to be deallocated while new state objects be created, over and over. I cannot fathom this to ever surpass traditional C like procedural programming in terms of efficiency (both speed and memory) at the fundamental machine operational level. Am I right to believe that ?

5th Mar 2021, 4:53 AM
ChillPill 🌶
ChillPill 🌶 - avatar
21 Answers
+ 15
I think this is not totally correct, because you are forgetting all the compiler optimisations. Let see what optimisations are done in Haskell, for instance : - 'common subexpression elimination' : computes common subexpression only once - inlining of functions thanks to the function definition - specialisation of functions (like templates in C++ : the same function is automatically generated a multiple of times to be more efficient ; zero-cost at runtime) - lazyness : an expression is evaluated only if it is necessary to evaluate it - function fusion. Quoted from the website, in the case of lists, for instance "these intermediate lists never exist in memory entirely". So there are optimisations to avoid at maximum allocation and deallocation of objects. - stream fusions : optimized into efficient for loops (wich also means only one memory allocation for the whole operation) From : https://wiki.haskell.org/GHC_optimisations And you can look at benchmarks! Haskell is efficient!
5th Mar 2021, 7:17 AM
Théophile
Théophile - avatar
+ 12
In terms of speed I think you are right. On the lowest level everything boils down to mutable operations (changing bits in memory). Immutability is a higher level concept, that helps the programmer controlling state changes throughout the program. It's a bubble to protect us from our own fallacies. If we talk about memory usage, I would say this depends on the programming language. For example, Clojure applies "persistent data structures" and "structural sharing". This eliminates the need to allocate lots of new memory, when we only change a small part of a large data structure. Some languages are not so graceful with memory management of immutable data. https://augustl.com/blog/2019/you_have_to_know_about_persistent_data_structures/
5th Mar 2021, 7:17 AM
Tibor Santa
Tibor Santa - avatar
+ 11
I think functional programming has the benefit to concisely describe complicated operations with short expressions. For example, map and filter, they also translate to "for loops" eventually, but they are declarative in saying: "I want this function run through my data" - whereas a for loop is imperative by nature, saying: "take each value from this group of values, and do something with it". Maybe it does not sound very different, but functional languages can very easily compose (chain) multiple functions that would be possible imperatively by nesting many for loops. This programming style has the benefit to convey the intention of the program to the developer more clearly, but obviously it does have additional costs, comparing to imperative instruction to change memory bit by bit.
5th Mar 2021, 7:21 AM
Tibor Santa
Tibor Santa - avatar
+ 11
Théophile i agree about all optimizations that it helps performance but... take the laziness for example. You create yourself a handle, you return yourself an evaluation when needed at a later time. At assembly level, to me it sounds like It is a two functions block calling, calling first block returns only a pointer to call the second function block. every call, at assembly level, means stuff be push and popped off the stack. i dont see that possibly ever being faster that traditional C programming where a value is returned immediately.
5th Mar 2021, 12:41 PM
ChillPill 🌶
ChillPill 🌶 - avatar
+ 11
Good question and it also depends on whether "slow" applies to: 1) writing code, 2) understanding and editing prewritten existing code, 3) compiling or 4) running the written code. :) The answers to those four different options are likely different. Worth creating a matrix and weighing the options?
6th Mar 2021, 2:19 PM
Marko Rillo
+ 10
Now, let's consider another thing : C is meant to be a system programming langage. It means that you have full control of what you are doing. I don't know any pure functional langage meant to be a system programming langage. They are usually not designed to be low-level. However, as we can see in the case of Haskell, functional programming langages can be very efficient, at the end. Yes, procedural programming in C is fast. But I could argue that procedural programming in Python is not. 😉
5th Mar 2021, 7:25 AM
Théophile
Théophile - avatar
+ 10
I'd wager that most people write faster C than assembly, and most people write faster C# than C. That's because the compiler generally does a pretty good job optimizing while you get tired eventually. There's no reason we can't keep climbing the abstraction ladder so long as compilers follow suit. There is no "inherent" slowness in any language. Immutability isn't really a show-stopper, if you have a function that operates on immutable data then the compiler can probably reason about your code a lot better, optimize better, and optimize away all the copying later. It's a win-win for both you and the compiler. That's in an ideal world anyway.
8th Mar 2021, 8:14 AM
Schindlabua
Schindlabua - avatar
+ 9
I would say the loss in speed made by functional language by avoiding mutable states can easily be balanced by the fact that for the same reason it makes it easier to implement parallel processing in them ( as less mutable states means less synchronisation and locking overheads ) And I think in every case where speed practically matters, a multithreaded functional program will always have an edge over single threaded procedural C program.
5th Mar 2021, 12:41 PM
Arsenic
Arsenic - avatar
+ 9
#define CPP ChillPill if you are try to parallelise stuff in C, you will eventually run into issues where the mutable variables are shared between concurrent processes which will end up costing more runtime overheads ( as then we also have to create some syncing mechanism involving locking and unlocking mutexes for it ) And on other hand if you have a functional program containing all pure function, it will not only make it easier to implement multithreading but will also reduce some runtime overheads ( as a pure function will have no mutable state )
5th Mar 2021, 1:05 PM
Arsenic
Arsenic - avatar
+ 9
Arsenic while it is true often times one will need to use locks of some kind to prevent data racing, it is also possible to multithread something else without a need to use mutable data. all depends on the task to be performed, but i get what you mean.
5th Mar 2021, 1:56 PM
ChillPill 🌶
ChillPill 🌶 - avatar
+ 7
Arsenic what about pthread in C? you can multithread in C too
5th Mar 2021, 12:44 PM
ChillPill 🌶
ChillPill 🌶 - avatar
+ 7
"optimizing imperative code for an imperative target is probably way easier" yeah that s what i was thinking too. C code to assembly is like translating french to english. easy, compared to translating martian to english. hhh
6th Mar 2021, 2:17 AM
ChillPill 🌶
ChillPill 🌶 - avatar
+ 7
Sonic i would like to see the kind of benchmark used. interesting. Someone said to me recently: "C++ is the best"
6th Mar 2021, 3:44 AM
ChillPill 🌶
ChillPill 🌶 - avatar
+ 5
Sonic C++ faster than C, and Java faster than C# How?
6th Mar 2021, 4:25 AM
Kiwwi#
Kiwwi# - avatar
+ 3
I always thought that C was the fastest programming language, this topic is very interesting as well big O notation in algorithms performance...
6th Mar 2021, 5:01 AM
Frank Castro
Frank Castro - avatar
+ 3
In most of the cases, YES. They need the infrastructure that inevitably adds overheads over what can theoretically be attained using assembler by hand. Specifically, first-class lexical closures only work well with garbage collection because they do allow values to be carried out of scope. I hope this will clarify your doubts.
10th Mar 2021, 4:17 AM
Shaili Shah
Shaili Shah - avatar
+ 2
so in general functional langs compile a bit slow but runs at good speed, right?
5th Mar 2021, 4:36 PM
Kiwwi#
Kiwwi# - avatar
+ 2
When you want to be fast use Fortran! https://www.nature.com/articles/physci231208a0
5th Mar 2021, 9:01 PM
Jholler
Jholler - avatar
+ 2
Yes there are so many people and I also thing that c is the fastest language that's why we learn c first then after other languages
6th Mar 2021, 5:12 AM
亗𝙰𝙽𝚄𝚁𝙰𝙶亗
亗𝙰𝙽𝚄𝚁𝙰𝙶亗 - avatar
+ 1
Sonic is right 👌👌👌👌
6th Mar 2021, 4:45 AM
亗𝙰𝙽𝚄𝚁𝙰𝙶亗
亗𝙰𝙽𝚄𝚁𝙰𝙶亗 - avatar