Why There is no FP Language Fast As C++

[OvermindDL1]

@dixi-sixi

So the question is more like - why do people don’t develop at system level in functional style? Because it’s costly

Actually it’s quite easy, there is even a kernel called mirage built in OCaml that is blazing fast, very safe, and fantastic for embedded usages.

@NobbZ

The main reason why equivalent programs are often not as fast as C is mainly caused by additional runtime environments, garbage collectors and such stuff. Also immutability does cause a lot of copying values around that you would manipulate inplace in C/C++.

These are the big things, yet OCaml works around it by allowing you to add safe mutability when necessary, and if even further needed you can do entiirely unsafe code (in the Rust sense) via Obj.magic (which honestly you should never need to touch unless doing systems programming. The last bit is the GC, but that is fairly controllable in OCaml when necessary unlike most other languages.

@dokuzbir

Some programs can be faster in a spesific language. I just mean general situations.

‘In General’ OCaml and C will compile to very similar machine code (Excepting GC and such) and using the same algorithms in both you will achieve almost identical speed. This cannot be said of something like Haskell for example.

@dokuzbir

I read calling a function harder. And that is why article owner wrote recursion is slower than a loop. But as you say a loop already function right ? So there is no reason slowness from recursion.

Correct, recursion is just a loop in another form, if it compiles slower then that’s an issue of the compiler and/or the programmer, not the fact that it is recursion. OCaml, for example, compiles recursion into assembly jumps, which is what loops do as well.

@mkunikow

If you want something FAST go RUST …

It has some functional aspects.

Rust Programming Language

Rust is very nice, sadly it has a lot of Haskell’isms that I wish it really really did not have that is contributing to some syntax woes, but it is very nice overall. OCaml with a borrow system to get rid of it’s GC would be even better though. ^.^;

@dokuzbir

Even ruby is fast for my algorithms.

Uh, algorithm or not Ruby is SLOW, on the order of hundreds of times slower than something like C/Rust/OCaml, that is the difference of processing data between, oh, 5 seconds or 5 hours…

@NobbZ

Also modern C compilers (at least CLang and GCC) do proper TCO if not deactivated.

You can add attributes to functions that specify that they fail to compile if TCO cannot be performed as well in most compilers (clang can and I think gcc can too) too.

@NobbZ

Go, Python, and Java (and others on the JVM) are the only 3 languages I am aware of right from my fore head, that do not do TCO and therefore force you to carefully write your loops.

In python you can fake it via generators to an extent. Go is just garbage. The JVM and .NET both don’t like that TCO removes stack frames (while they completely ignore the fact that loops have no stack frames at all so why does that even matter?!).

@NobbZ

for go I’ve once heard that detecting TCs would hurt compilation speed to much.

That is also garbage, detecting TC is trivial in every compiler I’ve ever looked at. You literally just look at the last expression and see if it is a function call and if it returns the same type as ‘this’ function itself…

@NobbZ

JVM-stuff did never explain to me why, well, clojure people once told me, clojure does not do it automatically bacause Java doesn’t do as well…

Yeah they complain that TCO/Recursion removes stack frames which makes debugging harder, and yet they completely ignore the fact that the loop has no stack frames at all, so I don’t know what they are thinking there… ^.^;

Plus the average programmers are not that stupid, like really… And if they want to fix debugging stack frames then just with a flag have it store the ‘stack frames’ to a shadow stack, which is another popular pattern. The JVM/.NET/Go/Javascript authors bug the crap out of me… >.>

@dokuzbir

Article owner wrote if you have, too many function calls in recurcive funtion, loop will be faster.

That is only if you don’t have TCO.

@dokuzbir

i couldnt find past article but that english article tells samething

Iterative vs. Recursive Approaches - CodeProject

Whoooo that site takes a long time to start returning data!

As we can clearly see, the recursive is a lot slower than the iterative (considerably) and limiting (stackoverflow).

The reason for the poor performance is heavy push-pop of the registers in the ill level of each recursive call.

Yeah this author seems to be lacking knowledge on this subject, these costs don’t exist with TCO…

too long/stack overflow

This also does not exist with TCO…

Yeah this article is… not well reasoned…

@bobbypriambodo

I think Haskell and OCaml are pretty much up there on the faster languages pool.

Haskell has a lot of overhead compared to OCaml because it LOVES thunks, it allocates thunks EVERYWHERE it seems, consequently it is always slower in comparison.

@bobbypriambodo

Given the same amount of time to work on a same problem with C++, Haskell, and OCaml, the performance would be roughly the same, since they all compile down to native code (no VM, runtime, etc.)

They’d be similar…

I’d say on average it would be C++ at 1x, C at 1.5x, OCaml at 1.5x, and Haskell at 3x for well written readable programs in each. C++'s metaprogramming can create pure magic with assembly so it’s hard to beat it when you are trying…

@bobbypriambodo

while Haskell and OCaml would suffer from garbage collection (whether it’s significant I don’t really know).

GC can be tuned in both GHC/Haskell and OCaml, and with the proper constructs in OCaml then you can run pretty well GC-less, though code starts looking more like C then. ^.^;

@bobbypriambodo

Having said that, I can argue that OCaml’s compilation time is blazingly fast, while I have heard (and in case of Haskell, experienced) scary stories about C++ and Haskell compilation times.

OCaml is the fastest optimizing compiler of any language out. ^.^

C++ can get scary because templates (though it is SO MUCH better than it was 10 years ago).
Haskell gets scary because it uses an HKT typing system, which requires program flow analysis, compared to OCaml that uses HPT’s, which are scope contained, significant differences (and HPT’s are overall more powerful than HKT’s too, though slightly more verbose, but not by much).

@easco

lisp machine

Mmmmm, tasty LISP Machines, I so wish they become common… ^.^

@idi527

Futhark is supposed to be fast and functional.

Oooo a new language to look at that I’ve not seen yet! Thanks!

(EDIT: Ah, it’s basically an ML’y dialect of OpenCL, not bad though.)

@dokuzbir

so our computers are not suited for FP languages right?

They are suited fine. ARM and x86 are so crazy-optimized that they do everything ‘well’ (not perfectly in all cases, but far far better than any average on about everything).