[Swift-devel] Scala

[Michael Wilde]

Yes, the OpenMx project might have a use for that, Erin.

We'll be developing more Swift interfaces to it first; Rmpi might be 
needed later if the need comes up for finer-grained parallelism.

- Mike

On 10/25/09 4:23 PM, Hodgess, Erin wrote:
> Would you be interested in Rmpi, by any chance, please?
> 
> I'm doing a little bit of work on that at the moment.
> 
> Thanks,
> Erin
> 
> 
> Erin M. Hodgess, PhD
> Associate Professor
> Department of Computer and Mathematical Sciences
> University of Houston - Downtown
> mailto: hodgesse at uhd.edu
> 
> 
> 
> -----Original Message-----
> From: swift-devel-bounces at ci.uchicago.edu on behalf of Michael Wilde
> Sent: Sun 10/25/2009 12:37 PM
> To: Mihael Hategan
> Cc: swift-devel; Ian Foster
> Subject: Re: [Swift-devel] Scala
> 
> You make some good points here Mihael. Im going to drop off this thread
> while I mull it over further. There is some user demand from the
> R/OpenMx community to also pursue an host-language embedding of Swift
> semantics. That might be a good place to explore this (which *does* have
> funding). R has the library packages "Snow" and "Snowfall" which do
> something similar and have proven useful and popular - perhaps a good
> model to examine and perhaps integrate Swift into.
> 
> - Mike
> 
> 
> On 10/25/09 12:31 PM, Mihael Hategan wrote:
>  > On Sun, 2009-10-25 at 11:00 -0500, Michael Wilde wrote:
>  >
>  >> Swift-as-a-library seems to me to have potential similar to MPI to
>  >> achieve great success - wider that Swift-as-a-language - while not
>  >> eliminating the benefits and continued support and improvement of the
>  >> current system.
>  >
>  > Btw, I have reasons to believe this is not true. CoG+Java (and then the
>  > python cog + python) already provide the tools necessary to achieve most
>  > of this. A parallel parameter sweep would look like this (boilerplate
>  > removed):
>  >
>  > Task[] tasks = new Task[params.length];
>  > for(int i = 0; i < params.length; i++) {
>  >   tasks[i] = buildAndSubmitTask(params[i]);
>  > }
>  > for(int i = 0; i < tasks.length; i++) {
>  >   tasks[i].waitFor();
>  > }
>  >
>  > There is also a scheduler to take care of scheduling, with an API and
>  > many other things. All documented, with examples, a hefty FAQ, papers,
>  > posters, etc.
>  >
>  > Didn't work. I suspect because complexity is not in how hard it is to do
>  > something, but how hard it is to distinguish the right solution from the
>  > sea of potential solutions. In which case a "canned" solution works
>  > better.
>  >
>  > And frankly I wouldn't use it either. If something goes wrong from a
>  > programming standpoint, throubleshooting each "workflow" is a pain,
>  > because there is no clear separation between the domain specific problem
>  > and the library. In debugging, I wouldn't be able to separate the two.
>  > Whereas in Swift as it is, it's much easier to distinguish between a
>  > runtime-swift bug and having written your script wrong. The library is a
>  > carrot in a soup. Swift is layered.
>  >
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>