Fwd: [Haskell-cafe] Haskell for Physicists

Hey all, Following up on this, I'm presenting a position paper tomorrow on the use of EDSLs to improve productivity and lower cost when developing code for new high performance architectures (like GPUs). http://www.galois.com/blog/2009/10/13/domain-specific-languages-for-domain-s... It advocates for Haskell + EDSLs, much as we have been discussing in this thread. -- Don

Don Stewart
Hey all,
Following up on this, I'm presenting a position paper tomorrow on the use of EDSLs to improve productivity and lower cost when developing code for new high performance architectures (like GPUs).
http://www.galois.com/blog/2009/10/13/domain-specific-languages-for-domain-s...
It advocates for Haskell + EDSLs, much as we have been discussing in this thread.
I'm very interested in EDSL in high performance architectures. Can you give me some idea what the performance might be using code written in Haskell+EDSL compared to C/C++? I think, in high performance computing, the efficiency in the resulting binary code largely depends on the problem domain. Can haskell help a lot in optimizing the EDSL to machine binary? And what would be the efficiency in terms of space and time? Xiao-Yong -- c/* __o/* <\ * (__ */\ <

Of all the projects that are in the HackageDB, how many, or what % do you
say developed an EDSL?
daryoush
On Tue, Oct 13, 2009 at 3:06 PM, Xiao-Yong Jin
Don Stewart
writes: Hey all,
Following up on this, I'm presenting a position paper tomorrow on the use of EDSLs to improve productivity and lower cost when developing code for new high performance architectures (like GPUs).
http://www.galois.com/blog/2009/10/13/domain-specific-languages-for-domain-s...
It advocates for Haskell + EDSLs, much as we have been discussing in this thread.
I'm very interested in EDSL in high performance architectures. Can you give me some idea what the performance might be using code written in Haskell+EDSL compared to C/C++? I think, in high performance computing, the efficiency in the resulting binary code largely depends on the problem domain. Can haskell help a lot in optimizing the EDSL to machine binary? And what would be the efficiency in terms of space and time?
Xiao-Yong -- c/* __o/* <\ * (__ */\ < _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Daryoush Weblog: http://perlustration.blogspot.com/

On Tue, Oct 13, 2009 at 9:44 PM, Don Stewart
http://www.galois.com/blog/2009/10/13/domain-specific-languages-for-domain-s...
It advocates for Haskell + EDSLs, much as we have been discussing in this thread.
I am think that use of EDSLs for Physics (and similar science) are very arguable: To use EDSL domain expert need to know language in which DSL embedded, which is more difficult than learn just DSL. Not better, if EDSL use only subset of base language: 1. because you need to teach this subset (probably rewrite of write new tutorials, books etc..) 2. and if someone use few EDSL with different subsets of base language it can (and probably will) became mess. _So easiness in implementation results in burden for users_ I see such situation in Particle Physics where I am working. All basic software: ROOT, Geant4 are actually EDSLs based on C++ (and crippled C++: CINT). In my opinion this slowdown progress tremendously! I am know many physicists who don't know ever necessary basic of C++, although they use ROOT and Geant4. I am sure that what prevent them from learning C++ will prevent them from learning any other general purpose language. _So my strong opinion that solution is only DSL not EDSL_ Roman.

_So my strong opinion that solution is only DSL not EDSL_
Why do you think they will learn your DSL, if they don't learn any other language? And if your DSL includes general purpose stuff, like functions, control structures, data structures, you'll re-invent the wheel. Probably porly.

_So my strong opinion that solution is only DSL not EDSL_
Why do you think they will learn your DSL, if they don't learn any other language? I didn't said that they didn't learn any language. They learn languages, but only part that is necessary to do particular task. f.e. ROOT CINT(C++ interpreter) didn't distinguish object from pointer to object, i.e. statement h.ls(); works as well as h->ls(); independently of either h has type TH1F or TH1F*, so beginning ROOT user didn't need know what is pointer, memory management helps him. But early or latter one need to write more complicated code,
And if your DSL includes general purpose stuff, like functions, control structures, data structures, you'll re-invent the wheel. Probably porly. You didn't need to reinvent the wheel, because you DSL compiler can
On Fri, Dec 04, 2009 at 01:43:42PM +0000, Matthias Görgens wrote: then one need to spend months to reading big C++ books, and struggling with compilers errors, segfaults etc..^(1) (instead of doing assigned task!) or, what is more usually, trying Ad hoc methods for writing software. So people will learn DSL because: 1. DSL is simpler than general purpose language 2. DSL describe already known domain for user, (one probably don't need monads, continuations, virtual methods, template instantiation etc...etc...) so learning is easy, and didn't consume much time. produce Haskell code: DSL -> General Purpose Language -> Executable And ever if you do, it saves allot of time of experts. Roman. (1) In Haskell this probably will sound like: reading allot of small tutorials and articles, grokking monads, struggling with type-check errors, infinite loops, laziness, etc...

2009/12/4 Roman Salmin
_So my strong opinion that solution is only DSL not EDSL_
Why do you think they will learn your DSL, if they don't learn any other language? I didn't said that they didn't learn any language. They learn languages, but only part that is necessary to do particular task. f.e. ROOT CINT(C++ interpreter) didn't distinguish object from pointer to object, i.e. statement h.ls(); works as well as h->ls(); independently of either h has type TH1F or TH1F*, so beginning ROOT user didn't need know what is pointer, memory management helps him. But early or latter one need to write more complicated code,
On Fri, Dec 04, 2009 at 01:43:42PM +0000, Matthias Görgens wrote: then one need to spend months to reading big C++ books, and struggling with compilers errors, segfaults etc..^(1) (instead of doing assigned task!) or, what is more usually, trying Ad hoc methods for writing software. So people will learn DSL because: 1. DSL is simpler than general purpose language 2. DSL describe already known domain for user, (one probably don't need monads, continuations, virtual methods, template instantiation etc...etc...) so learning is easy, and didn't consume much time.
And if your DSL includes general purpose stuff, like functions, control structures, data structures, you'll re-invent the wheel. Probably porly. You didn't need to reinvent the wheel, because you DSL compiler can produce Haskell code: DSL -> General Purpose Language -> Executable And ever if you do, it saves allot of time of experts.
Roman.
(1) In Haskell this probably will sound like: reading allot of small tutorials and articles, grokking monads, struggling with type-check errors, infinite loops, laziness, etc...
There is other side. As Matthias Görgens mentioned earlier 1. One have to reinvent control structures. Multiple times. Lets assume that compiler would translate DSL to haskell code. But DSL's expressions which convert into haskell control structures are DSL's control structures. 2. There would be more than one DSL. If they are all EDSL there is no real problems with combining them in one program if necessity arises. Probably there would be ways to combine them if they are DSL but they will require expertise and most likely dirty hacks. 2.1 And all of them will have different conrol structures, abstraction mechanisms. 3. Turing tarpit. Users will constantly require more power and features in DSL. Most likely DSL designers wouldn't be great language designers so DSL will turn into utter mess. 4. One have all power (and libraries of host languages). Of course if he is able to utilize it. This is tradeoff between power and simplicity. If one have too much simplicity he is not able to solve difficult problems. If one have too much power at expense of simplicity he has to struggle with tool to have thing done. And it's possible to sacrifice simplicity and don't gain any power.
participants (6)
-
Alexey Khudyakov
-
Daryoush Mehrtash
-
Don Stewart
-
Matthias Görgens
-
Roman Salmin
-
Xiao-Yong Jin