[Haskell-cafe] Distributing Haskell on a cluster

Alberto G. Corona agocorona at gmail.com
Mon Mar 16 11:21:22 UTC 2015


As usual, I could suggest  a really crazy alternative: It could be possible
to design your code as an EDSL that can emit his own source code, in the
same way that web formlets emit HTML rendering.

In this case, instead of HTML rendering, the rendering would be the source
code of the closure that you want to execute remotely. Then you can compile
it at the emitting node or at the receiver.

The advantage is that you may remotely execute any routine coded using the
EDSL. Hiding the mechanism behind a few primitives of the EDSL.

The disadvantage is that you can not use IO routines with liftIO. You need
an special lifting mechanism that produces also the source code of the IO
routine.

I´m doing some research on this mechanism with the Transient monad.

2015-03-16 1:54 GMT+01:00 felipe zapata <tifonzafel at gmail.com>:

> I haven't considered that idea, but it seems the natural solution.
>
> Many thanks
>
> On 15 March 2015 at 20:31, Ozgun Ataman <ozgun.ataman at soostone.com> wrote:
>
>> Anecdotal support for this idea: This is exactly how we distribute
>> hadron[1]-based Hadoop MapReduce programs to cluster nodes at work. The
>> compiled executable essentially ships itself to the nodes and recognizes
>> the different environment when executed in that context.
>>
>> [1] hadron is a haskell hadoop streaming framework that came out of our
>> work. It's on github and close to being released on hackage once the
>> current dev branch is finalized/merged. In case it's helpful:
>> https://github.com/soostone/hadron
>>
>> Oz
>>
>> On Mar 15, 2015, at 8:06 PM, Andrew Cowie <andrew at operationaldynamics.com>
>> wrote:
>>
>> Bit of a whinger from left-field, but rather than deploying a Main script
>> and then using GHCi, have you considered compiling the program and shipping
>> that?
>>
>> Before you veto the idea out of hand, statically compiled binaries are
>> good for being almost self-contained, and (depending on what you changed)
>> and they rsync well. And if that doesn't appeal, then consider instead
>> building the Haskell program dynamically; Hello World is only a couple kB;
>> serious program only a hundred or so.
>>
>> Anyway, I know you're just looking to send a code fragment closure, but
>> if you're dealing with the input and output of the program through a stable
>> interface, then the program is the closure.
>>
>> Just a thought.
>>
>> AfC
>>
>> On Mon, Mar 16, 2015 at 9:53 AM felipe zapata <tifonzafel at gmail.com>
>> wrote:
>>
>>> Hi all,
>>> I have posted the following question on stackoverflow, but so far I have
>>> not received an answer.
>>>
>>> http://stackoverflow.com/questions/29039815/distributing-haskell-on-a-cluster
>>>
>>>
>>> I have a piece of code that process files,
>>>
>>> processFiles ::  [FilePath] -> (FilePath -> IO ()) -> IO ()
>>>
>>> This function spawns an async process that execute an IO action. This IO
>>> action must be submitted to a cluster through a job scheduling system (e.g
>>> Slurm).
>>>
>>> Because I must use the job scheduling system, it's not possible to use
>>> cloudHaskell to distribute the closure. Instead the program writes a new
>>> *Main.hs* containing the desired computations, that is copy to the
>>> cluster node together with all the modules that main depends on and then it
>>> is executed remotely with "runhaskell Main.hs [opts]". Then the async
>>> process should ask periodically to the job scheduling system (using
>>> *threadDelay*) if the job is done.
>>>
>>> Is there a way to avoid creating a new Main? Can I serialize the IO
>>> action and execute it somehow in the node?
>>>
>>> Best,
>>>
>>> Felipe
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150316/2d81280f/attachment.html>


More information about the Haskell-Cafe mailing list