1

Another one of my rather ambiguous question today, sorry.

Currently I have written some half decent software that has a 'roll your own' RESTful client, which pulls data from twitter. This data is then visualized with a number of particle systems using Open FrameWorks (a framework that works with c++).

My plans for this were to run the software indefinitely on my VPS, and build some kind of front end GUI allowing users to explore the pretty particles and so on. Between the JSON library I am using, C/C++, OpenFrameworks, and freaking Xcode4 I have produced way too many SIGBIRT and GDB errors to care for. I have go to the ends of the virtual world to fix them, and re wrote everything over and over. I even managed to SIGBIRT the openframeworks draw circle method, HAH!

(TL;DR starts here) Ok so anyway I am starting from scratch, looking for a powerful language that can crunch maths and blast through a good set of particles, and run quite well over the longest periods of time. Right now I am thinking about haskell, any ideas?

Thanks in advance all!

rykardo
  • 175
  • 3
  • 14
  • ...what does `SIGBIRT` stand for btw? – hvr Sep 12 '11 at 17:08
  • Haha, I just realized I spelt SIGABRT incorrectly (I spelt the way it sounds it my head as I read the error). I don't know the actual acronym but it occurs when there is an abnormal abortion from whatever process one is trying to run. See http://en.wikipedia.org/wiki/SIGABRT – rykardo Sep 12 '11 at 22:04

2 Answers2

5

Haskell's (or more specifically GHC's) number crunching speed is approaching that of C++ but it's a little way behind. However, it's certainly not terrible, and Haskell's advantages in parallelism may become important. That is, if you write it in straight Haskell first, there's a good chance that it'll be easy to refactor it to run in parallel now or in the future. That isn't so true of C++.

The 'vector' package (on Hackage) would be a good choice for arrays suitable for number crunching. It supports mutable arrays in case that sort of approach is needed. However, if you're prepared to go more on the bleeding edge and your algorithm can be parallelized, you might want to look at the 'repa' package, and for extreme performance on a GPU, take a look at 'Accelerate' (which works but is still categorized as experimental).

The crashes you mention sound like they could be an indication of a bit of complexity in your problem. Where Haskell does well is in managing the complexity of... well, anything. So, if the problem is complex, then Haskell will serve you very well.

The foreign function interface in Haskell is well designed, though you will need to write C glue between Haskell and C++. So, that's another option for your number crunching.

For the web interface, take a look at 'yesod' which is seeing very active development and advertises itself as doing RESTful.

blackh
  • 161
  • 1
  • Hey thanks for the advice, and the heads up on 'vector' and 'Accelerate'. Both of these look ideal for the challenges I have set into this project. After digging into Haskell a bit further I see I can probably transfer my entire c++ software into pure Haskell with out too much trouble. Anyway thanks again, can't wait to get stuck in! – rykardo Sep 12 '11 at 05:56
2

AFAIK, number crunching speed is not Haskell's strongest point - it's a highly abstract language, far from the 'metal'; its strength in a numeric processing context lies in the "mathiness" of its semantics - Haskell code often reads much like a Mathematical proof, and many of its concepts are borrowed from various fields of Mathematics.

For plain old number crunching, C++ is probably still your best choice, as it allows you to stay close to the hardware and optimize tight loops at the machine level, while offering higher-level programming constructs to manage complexity.

OTOH, if you have a library in place for the heavy lifting, and you merely need to write the glue to make the various parts work together, then go with whatever you're most comfortable with - python, C#, java, haskell, C++, ... - as long as they have bindings for all your libraries, you're good. If you don't have a library, then you might also consider writing the performance critical parts in C, and then pull them into your favorite high-level language - this is trivial in C++, slightly harder in python or haskell, and pretty damn inconvenient in java.

tdammers
  • 20,353
  • 1
  • 39
  • 56
  • 3
    Have you *tried* writing number crunching code in Haskell? (I didn't, but) I'd be careful with such statements. Purely numerical code - especially when using number types that map to hardware numbers - seems like the perfect opportunity for GHC's numerous optimizations and the LLVM backend to produce C-grade assembly code. Of course, that's assuming you know how to optimize Haskell code. –  Sep 11 '11 at 14:49
  • @delnan: Fair point. I haven't myself, but both the documentation and people I've talked to seem to back up the idea that C++ is the only viable option for hardcore number crunching. GHC has made huge leaps lately though, so it might be an option after all. – tdammers Sep 11 '11 at 15:01
  • @tdammers [This](http://stackoverflow.com/questions/6964392/speed-comparison-with-project-euler-c-vs-python-vs-erlang-vs-haskell) is a motivating example where Haskell can actually beat C. – fuz Sep 11 '11 at 18:04
  • Thanks for the conversation guys! I have begun working with Haskell and nearly got my RESTful client pulling all the data I need (Haskell syntax is a little mind boggling but I am starting to see how sweet it is!) I can for-see myself write some C exerts, but I would like to experiment and try write it in pure Haskell first. Any thanks all for the good advice! – rykardo Sep 12 '11 at 05:50