Peter, On 17/01/13 09:51, Peter Jones wrote:

I'm about to start a project that will target native applications on several platforms (Linux, Mac OS X, iOS, etc.) and Haskell being my new love, I'd like to use it if possible.

From what I can tell the GHC-iOS project has a working ARM cross-compiler that integrates with Xcode for building iOS applications. I'm curious if anyone has an application running on an actual iOS device (not just the simulator) and would care to comment about the performance of the run time system.

The status is that we have a working GHC-iOS compiler, and various attempts at Android but nothing easily useable - though I expect that to change very soon. Work is underway at the moment by quite a few people to finish off the rough edges of cross-compiling. So at this stage, if you want to use Haskell on mobile devices, you will still have to get your hands a bit dirty. The performance of the runtime system should be very good now that we have a "registerised" code generator using LLVM (GHC's generated code is based entirely on gotos and doesn't use normal calls and call stacks, and this necessitated specific changes to LLVM). I haven't done any great measurements, though. Just remember that mobile device CPUs are significantly slower than desktop PCs, though this gap is closing.

I've come across some comments in #haskell that have led me to believe that the Haskell RTS won't operate in anything less than 128MB of RAM. I suppose that's not terrible since most iOS devices have at least 512MB but I've not experienced that (xmonad seems to be very happy in 60MB total vsize).

I did a lot of work using GHC on a second generation iPod Touch and memory usage was far less than that. Memory usage was in the region of 10 to 30 MB for a fairly involved application (beginnings of a video game). I kept a close eye on memory usage, and I never had crashes because of it.

The other possible myth that I've heard is that profiling a Haskell program and improving space usage needs to be done on each platform and tuning for one platform can induce space leaks on another. This doesn't seem reasonable to me so I wanted to see if anyone has profiled/tuned on Linux/Mac OS X and run into any issues on an iOS device.

That's definitely not true. Speaking as a professional programmer, space leaks certainly are a problem in Haskell. Here's my opinion on them: Haskell has many amazing features that work together to make Haskell better than any other language (that I know of). Those features are mostly huge net gains, with the exception of one - laziness - because it comes at a significant price - space leaks. Some people think laziness is a net gain, some think it's a net loss. Some people have said "with experience, space leaks are not a problem" and I generally agree. Haskell is genuinely different, and that means a big learning curve, and space leaks add to that learning curve. (In my opinion, for someone new to programming, the learning curve of Haskell would be just a bit above average compared to imperative languages.) This is one of the reasons why Haskell hasn't become popular in spite of its merits. Though maybe that's changing - it came up 9th in a survey of favourite languages after the well-known languages. http://blog.sudobits.com/2012/03/28/top-10-most-popular-programming-language... Space leaks follow well-defined logic and the best defence against them is to understand why they happen and factor that into program design. That is, when you're writing a part of the program, you do need to think about what the space behaviour of that part will be. Having said that, space behaviour is, like everything else in Haskell, composable, so any complexity in space behaviour doesn't compound. That will cure most problems, but space leaks are sufficiently problematic that you do actually need to do profiling to make sure they aren't causing a problem. Profiling is relatively easy on a PC. So contrary to the myth, space leaks aren't random, and won't pop up on a new platform. You only need to test your program on one platform. Due to difficulty of profiling on a cross-compiled platform, however, you will need to write your program so it can be tested (and therefore profiled) on a PC.

Thanks in advance, and thanks for all the work on ghc-ios!

No worries, and I hope there's been something useful in this email! Steve