Speed vs F#

How does Elixir speed compare to F# for non-web applications - say, something like a chess game player.

It depends. Erlang and elixir are not very good in doing only one thing at a time but shine in doing many things at the same time. So it totally depends on how you are able to parallelize the ai (which is the most compute intense part of chess games).

As a rule of thumb you do not choose erlang or any language on its hm VM for speed but for scalability and fault tolerance, which are both easy to achieve as long as one sticks to surrounding idioms.

Probably you want to stick with f# if you only want a single chess ai, but elixir when you want to have a server which gets connected from many clients and acts for all of them as the AI player or if you want to have a server which hosts chess games between humans.

2 Likes

I might eventually want to parallelize but until then would you estimate Elixir is 2, 5, 10, 20, 50 or 100 times slower than F#? I’m trying to choose a language that is reasonably fast and multi-paradigm with a modern light expressive syntax and able to leverage parallelism. So far it seems a choice between F# and Elixir.

1 Like

How we program multicores - Joe Armstrong

Our goal is that applications run 0.75 x N times faster on an N-core computer.

(… provided the solution design/implementation can exploit concurrency to a reasonable degree)

So while F#/CLR will likely beat a single BEAM process for sequential code execution, ultimately any F# application will be hampered by the additional complexity needed for the explicit (i.e. manual) handling of synchronization of concurrent activities (not to mention that typically synchronization isn’t an easy problem to solve effectively in CLR languages - or the JVM for that matter).

Also: Erlang and Deep Learning by Garrett Smith

Currently there is seems to be a lot of momentum in the Python community regarding Deep/Machine Learning - but that probably has more to do with a fairly low barrier of entry to the language and environment rather than it being “the right tool for the job” - but for the time being the sheer volume of available libraries is going to keep it going for a while.

However over the past few years a growing number of Python users have been looking for alternatives because of Python’s performance ceiling. Some have chosen Clojure which also seems to make sense for AI applications as the AI pioneers have often used LISP. But Clojure is based on the JVM and therefore can be subject to stop-the-world garbage collection which can be inappropriate in some environments.

In the BEAM there is no stop-the-world garbage collection as each BEAM process has it’s own heap. Therefore Erlang/Elixir could be suitable for AI applications, provided by-and-large concurrent algorithms and strategies are employed.

Springer: Handbook of Neuroevolution Through Erlang (2013)

3 Likes

It really depends on what you are doing. See Speed comparison with Project Euler: C vs Python vs Erlang vs Haskell.

Basically the OPs Erlang code started at 436% of C but was later brought down to 135%.

A bit off-topic, there is also Rust, a reasonably fast and modern language, with official bindings [0] to tensorflow. But then there is also Julia …

[0] https://github.com/tensorflow/rust

1 Like

I like to think of Elixir as the brain of an app - it excels at sending and receiving lots and lots and lots of messages, concurrently. When your app needs something that is computationally intensive, delegate to something that excels in that area; just like your brain tells vital organs what to do.

4 Likes

Some benchmarks …

1 Like

that’s totally what I had in mind when I wrote this blog post :smiley:

2 Likes

If you want multi-paradigm you have to stick to F#. Elixir is functional only.

If you want fast(good for CPU-intensive stuff) and multi-paradigm, then you could use OCaml, F# or Scala. Elixir is not multi-paradigm and the BEAM is not the best for CPU-intensive stuff.

To be perfectly honest I ignored the “multi-paradigm” requirement because in my mind it’s largely academic. While James O. Coplien makes a compelling case for multi-paradigm design his advice has been largely ignored and in reality “multi-paradigm” often turns into a liability.

  • Putting its OCaml heritage aside being functional and on the CLR destined F# to be labelled as “multi-paradigm” as it needed interact with the objects in its environment and those created by other CLR languages.
  • One could argue that being “multi-paradigm” didn’t do Scala much good. To a certain extent the same could be said about C++.
  • “multi-paradigm” is supposed to allow the selection of the optimal paradigm for solving the problem in the domain and expressing the solution in an effective manner. More often than not “multi-paradigm” simply allows developers to stay in their own comfort zone - regardless of whether the applied paradigm actually “fits” the problem. Hence the use of Scala as a “better Java” and C++ as a “better C”.

Sometimes it is just better to choose a tool with the “right constraints” - though it is possible to go off the deep-end - like Java being dogmatically class-oriented.

I’m not hating on F# - it would be my language of choice on the the CLR.

2 Likes

Erik Meyer wrote http://queue.acm.org/detail.cfm?id=2611829 on multi-paradigm.

Conclusion

The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative 
programming languages safer by only partially removing implicit side effects. Leaving one kind of 
effect is often enough to simulate the very effect you just tried to remove. On the other hand, 
allowing effects to be "forgotten" in a pure language also causes mayhem in its own way.

Unfortunately, there is no golden middle, and we are faced with a classic dichotomy: the 
curse of the excluded middle, which presents the choice of either (a) trying to tame effects 
using purity annotations, yet fully embracing the fact that your code is still fundamentally 
effectful; or (b) fully embracing purity by making all effects explicit in the type system and 
being pragmatic by introducing nonfunctions such as unsafePerformIO. The examples shown 
here are meant to convince language designers and developers to jump through the mirror 
and start looking more seriously at fundamentalist functional programming.
3 Likes

Very much this.

Although this is generically true, there are cases where the BEAM compiler can make really optimized CPU intensive things, but those are rare.

For note, Erlang is great as a dispatcher, managing multiple other processes in a variety of other languages, so you could easily have an F# process managed by the BEAM, or an OCaml, or C++, or Rust, or Java, or whatever.

2 Likes

We are doing a nice python interface as well. Not ready yet though.

2 Likes

I most definitely agree with this. While you might program in a functional style on an imperative language you are never really safe and can’t trust it.

3 Likes

Ooo, a first class interface? I’ve used a library someone made like ten years ago that I’ve kept updated, a first class one will be awesome. :slight_smile:

1 Like