Can LLILC help to increase F# code performance?

105 views
Skip to first unread message

Paul Jurczak

unread,
Apr 14, 2015, 7:15:39 AM4/14/15
to fsharp-o...@googlegroups.com
I just stumbled upon LLILC and I'm curious if it can help to increase F# code performance when it's done and ready. Are there any other options to compile F# to binary in order to increase performance?

Mauricio Scheffer

unread,
Apr 14, 2015, 7:21:35 AM4/14/15
to fsharp-o...@googlegroups.com
I've never used it but I think it's worth mentioning that Mono has had a LLVM backend for quite some time now. 
I wonder how LLILC compares to it.


--
Mauricio

On Tue, Apr 14, 2015 at 12:15 PM, 'Paul Jurczak' via F# Discussions <fsharp-o...@googlegroups.com> wrote:
I just stumbled upon LLILC and I'm curious if it can help to increase F# code performance when it's done and ready. Are there any other options to compile F# to binary in order to increase performance?

--
--
To post, send email to fsharp-o...@googlegroups.com
To unsubscribe, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource
---
You received this message because you are subscribed to the Google Groups "F# Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Fabian

unread,
Apr 14, 2015, 7:39:35 AM4/14/15
to fsharp-o...@googlegroups.com
Typically, native code is not actually much faster at run-time but rather the start-up time is shorter. Even an AOT'ed C# or F# code would still be doing array bounds checks, etc. When you really want raw performance on things like inner loops that are being called 100s of millions of times, then you are a bit out-of-luck with a managed language.

That said, if you properly use structs as opposed to classes you already can avoid a lot of GC overhead and indeterminism. For the majority of cases, you'll find F# easily fast enough; we do HPC on GPUs and distributed grids and it is virtually never an issue that F# itself is too slow. Especially, that you can parallelise it quite easily. When we feel like some particular piece of code really needs raw performance, we tend to write the algorithm on GPU (from within F#), that said, all data transformation is still done in idiomatic F# code without mutable state, etc. without ever having performance issues. 

The specifically designed GPU code, is usually very different, of course and much, much more difficult to write and maintain than normal F# code.
Reply all
Reply to author
Forward
0 new messages