Subscribe to
Posts
Comments

Intel Parallel Programming Podcast: Real World Haskell

January 13th, 2009 by Don Stewart

This morning Don had the chance to talk with Michael Wrinn and Aaron Tersteeg from Intel’s Multicore Software Development podcast about Haskell and multicores, parallel programming, and functional programming in industry. Enjoy! Listen to the full interview (15 minutes).

5 Comments »

5 Responses to “Intel Parallel Programming Podcast: Real World Haskell”

  1. on 13 Jan 2009 at 13:15 America/New_York1 Aaron Tersteeg

    Don,
    Thank you for coming on the show and talking about Haskell and the great community. I look forward to staying in touch as the language evolves and Intel produces even more powerful chips to run your code.

    Cheers,
    Aaron

  2. on 14 Jan 2009 at 20:27 America/New_York2 Ian Duncan

    I know this isn’t exactly the place to ask, but I’m not sure where to do so, so I’ll go ahead and ask here. Would you guys be willing to post what you consider to be optimal solutions for the exercises in the book? I have several solutions that seem kind of mediocre, and there are a few exercises that really baffle me, so I’d love to see an expert Haskell programmer’s solution.

  3. on 19 Jan 2009 at 13:48 America/New_York3 Al Strelzoff

    I too enjoyed the podcast. I think ghc compiles to a stack machine, doesn’t it? How about fixing it so that instead, it compiles to a netlist of primitive functions. You could graph it if you wanted to (we probably don’t except for testing). Then suppose you wrote a mapper that mapped this netlist into an array of cores in some optimal (reasonable, not best) fashion. I realize this is a hard problem. And you might not retain Haskell lazy evaluation. Maybe the primitive functions could be related to OpenCL so that Haskell would be on top of OpenCL much like PyCuda is currently on top of Cuda. The idea would be to make a pure side effect free application language that would free the application programmer from worrying about underlying threads and blocks. Recursion would be retained (probably encouraged), but applied only at mapping time. Does this make any sense?

  4. on 19 Jan 2009 at 13:57 America/New_York4 Don Stewart

    @Al

    There’s been a lot of work already compiling Haskell (and Haskell-like languages) to hardware. Here’s just a sample:

    * Haskell on GPUs: http://www.cse.unsw.edu.au/~chak/papers/LCGK09.html
    * More Haskell on GPUs: http://tinyurl.com/79tb97
    * DSLs in Haskell for FPGAs: http://haskell.org/haskellwiki/Research_papers/Domain_specific_languages#Hardware_design
    * Cryptol: commercial cryptographic Haskell-like language that targets FGPAs: http://www.galois.com/blog/2008/12/24/cryptol-the-language-of-cryptography-now-available/
    * Bluespec: hardware design using a Haskell-like language. http://www.bluespec.com/

    And just for accuracy, GHC uses a spineless, tagless (now tagged) G machine, not a stack machine. You can see the details in the STG paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729

  5. on 15 Feb 2009 at 11:20 America/New_York5 Frederik

    Hi,

    I would really like to listen to this podcat but the blogtalkradio website seems to dislike users. Without some plugin installed and JavaScript enabled, you cannot enter the page at all. Nice, since there’s no flash for my platform. :/
    Is it possible to download the show somewhere else?

Leave a Reply