Fwd: [Haskell-cafe] Haskell for Physicists

Dan Piponi dpiponi at gmail.com
Sat Oct 3 16:02:20 EDT 2009


Yesterday I was at a talk by Pat Hanrahan on embedded DSLs and GPUs at
the nvidia GPU conference:
http://www.nvidia.com/object/gpu_technology_conference.html

Pat argued that the only way forward to achieve usable computing power
for physics on heterogeneous computers (eg. multicore+GPU) is through
the use of embedded DSLs to allow physicists to express algorithms
without reference to underlying architecture, or even details like
data structures. His main example involved using Scala to generate C
code for scramjet simulation (ie. we're not talking toy simulations
here). He actually mentioned Haskell at one point. I strongly agree
with Pat. Unfortunately I can't find slides, or many details of the
project, online.

It seems to me that Haskell is both an excellent host language for
embedding small languages and is also a particularly good language for
expressing algorithms for code generation. I think this should be the
#1 selling point for Haskell for physicists.

The only point I vaguely disagreed with was that Pat seemed to think
that dynamic types were essential. For the types of problems he was
describing it seemed to me that static types were precisely what you
needed.
--
Dan

On Sat, Oct 3, 2009 at 4:23 AM, Khudyakov Alexey
<alexey.skladnoy at gmail.com> wrote:
> В сообщении от 30 сентября 2009 23:42:57 Casey Hawthorne написал:
>> On Wed, 30 Sep 2009 21:24:11 +0200, you wrote:
>> >I?m a physicist, so I think they would be attracted by something like
>> >
>> >Haskell: high level physics modelling  at  Fortran speeds
>> >
>> >Haskell: mathematics beyond numerical calculus
>>
>> And,
>> easier to make use of multi-core machines than threaded Fortran.
>>
> Yes this is good selling point. Fortran (and C++ too) programs heavily rely on
> global state. And thus are very difficult to parallelize. Frequently only
> possibility is process-level parallelism. This however has problems too.
>
>
>> I suppose one could have a Haskell parser convert Fortran to monadal
>> code.
>>
>> Then, a parser to convert, hopefully, most of the resulting code to
>> pure code.
>>
> This is interesting but very challenging task. Conversion fortran-> monadic
> code is trade of one mess for another. Since local state and global state are
> ubiquitous it's difficult to factor out pure functions. Another problem is that
> fortran functions are usually BIG.
>
> Most likely this will require manual intervention.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>


More information about the Haskell-Cafe mailing list