That's not a very strong point -those benchmark sources usually look like "C in language X" and not like "idiomatic use of language X" - I'd bet they don't use immutable data structures and hand optimize code avoiding common patterns in functional programming for perf.

Which is my point - there are languages that can compile to similar code as C/C++ if you write similar code - but the idiomatic code is still slower because it doesn't map to hardware cleanly and have inherent overhead, this is why functional languages didn't catch on when we were heavily CPU bound, it was common for people to write ASM because they couldn't get good enough perf out of C compilers.

Now that we transitioned from vertical to horizontal scaling problem domain maps very nicely to functional languages (actor model/message passing style communication is practically transparent with immutable data function calls).

Instead of looking at "benchmark sources" you just seem to be guessing about how the programs are written.

I did look at the source and it seemed that way (imperative code using flat arrays) but I don't know enough OCaml to say with certainty.

I have worked with other functional languages (Clojure) and I have optimized GCed code and it mostly boils down to what I said - writing C/C++ like code in language X to get as close to hardware memory model (avoiding GC by pooling, increasing cache coherence, using value types or manually unfolding data structs, etc.)

I haven't seen a magical way for high level data structures based on trees (used for persistant strucutres) to outperform arrays

No, that won't happen, but a lot of the code that you write in a functional language can be optimized far better than another language, because the compiler has more, stronger guarantees about your code.

There's some truth to this, but "can be optimized" is not the same as "there exists a compiler that optimizes". Your statement gets repeated a lot (and similarly about the JVM: it has run-time information that compilers don't have, so can optimize better), and yet C++ and Fortran continue to come out on top.

Indeed, because C++ and Fortran get the money and time, and they're closer to the metal to begin with. Also, C++'s "Nasal Demons on UB" problem helps a lot.

But yes, OCaml is quite fast, and probably could be faster. Does it really beat C++ in all contexts? Probably not, but it's still pretty fast.