4 ms·

Haskell on Android

153 points by psibi 12y ago

efnx 12y ago
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 :)
ErikRogneby 12y ago
"...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?
- implicit 12y ago
  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.
  - ianlevesque 12y ago
    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.
- ianlevesque 12y ago
  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.
  - ErikRogneby 12y ago
    "unless you are using Android UI controls." is a pretty big caveat.
    - ianlevesque 12y ago
      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: http://developer.xamarin.com/guides/android/under_the_hood/architecture/ http://developer.xamarin.com/guides/android/under_the_hood/a... Still, it performs better than you'd expect.
- dllthomas 12y ago
  It sounds like it's layered: =========JAVA========== ==C (SDL)== ==Haskell== Rather than: ===JAVA==== ==Haskell== ==C (SDL)== 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.
  - chrisdone 12y ago
    Haskell runtime is about a meg in size. Rather, most memory use will come from additional libraries and garbage generated, I expect.
- kyllo 12y ago
  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?
taylorfausak 12y ago
> To the inexperienced, this may look just like any green screen. But it meant much more. Reminds me of "Black Triangles": http://rampantgames.com/blog/?p=7745 http://rampantgames.com/blog/?p=7745

153 points by psibi 12y ago

efnx 12y ago

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 :)

ErikRogneby 12y ago

"...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?

implicit 12y ago
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.
- ianlevesque 12y ago
  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.
ianlevesque 12y ago
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.
- ErikRogneby 12y ago
  "unless you are using Android UI controls." is a pretty big caveat.
  - ianlevesque 12y ago
    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: http://developer.xamarin.com/guides/android/under_the_hood/architecture/ http://developer.xamarin.com/guides/android/under_the_hood/a... Still, it performs better than you'd expect.
dllthomas 12y ago
It sounds like it's layered: =========JAVA========== ==C (SDL)== ==Haskell== Rather than: ===JAVA==== ==Haskell== ==C (SDL)== 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.
- chrisdone 12y ago
  Haskell runtime is about a meg in size. Rather, most memory use will come from additional libraries and garbage generated, I expect.
kyllo 12y ago
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?

taylorfausak 12y ago

> To the inexperienced, this may look just like any green screen. But it meant much more. Reminds me of "Black Triangles": http://rampantgames.com/blog/?p=7745 http://rampantgames.com/blog/?p=7745