"...that Java was calling Haskell as C via it’s Foreign Function Interface (FFI), which in turn was executing correctly (including its Runtime System), and calling SDL’s C API also via the FFI. It meant all communication between Android, Java, Haskell and C was working fine..."
Is this efficient? Will end users notice any performance hit from all of these layers?
If that's the case, I wouldn't expect much of a performance hit from the layering given that (as I understand things)
===Java==
==C/C++==
is common for people writing games.
You'll certainly have a memory hit of the Haskell runtime (though I'm not sure how that compares to the size of other relevant things), and the performance differential between Haskell and whatever you would have been writing that code in otherwise (presumably C or Java) - which could be in either direction depending on the details.
I haven't tested this particular implementation but the performance should not be an issue. On Android all the non-java runtimes basically just use java (dalvik) to load up initially, because they have to. After the initial load java is out of the way unless you are using Android UI controls. This is using OpenGL and SDL so they probably aren't having any performance issues.
It is. It's also unavoidable with anything that doesn't compile to dalvik bytecode because none of the UI is exposed natively. If you want to see at a high level the horror involved check out this documentation from Xamarin:
I'm also really curious about the runtime performance of such a stack.
I like Haskell, but it's not what I reach for when I feel the compulsion to hoard memory carefully, and I'm very interested in precisely controlling memory on mobile devices.
Agreed. This isn't really a function of having too many layers involved though, Dalvik here is just bootstrapping and then gets out of the way.
Additionally, having dealt with memory issues on Android (particularly on 2.3 & below), Dalvik doesn't set the bar very high for an alternative runtime to be competitive in memory management.
That statement "Java was calling Haskell as C via its FFI" kind of confused me, but I admit I'm not all that familiar with how FFIs work.
But, wouldn't it be more accurate to say that "Java was calling native binaries compiled from Haskell source just as if they were compiled from C"? Because Java is linking to a binary library (a .so file) that's already been compiled from Haskell, right? Or am I misunderstanding how this works?
The potential for this has been around for a bit, though not a long time. It's great to see it getting some traction. iOS/ARM support was added in 7.8 which is now the standard with Haskell Platform. Now we need tools that target and deploy our apps to all platforms :)
Is this efficient? Will end users notice any performance hit from all of these layers?