Re: Fwd: [Haskell-cafe] Haskell for Physicists
Don Stewart d...@galois.com 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-specific-problems/ 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
Re: Fwd: [Haskell-cafe] Haskell for Physicists
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 xj2...@columbia.edu wrote: Don Stewart d...@galois.com 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-specific-problems/ 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Haskell for Physicists
В сообщении от 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Haskell for Physicists
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.sklad...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Haskell for Physicists
And note we are pushing precisely on the use of DSLs in or on Haskell for *portability* of the domain-scientists code in a number of areas right now: * data parallel algorithms (targetting cpu , gpu) Accelerate: http://hackage.haskell.org/package/accelerate-0.6.0.0 Obsidian http://www.cse.chalmers.se/~joels/writing/dccpaper_obsidian.pdf * control systems code: Atom: http://hackage.haskell.org/package/atom * cryptography Cryptol: http://www.galois.com/technology/communications_security/cryptol * avionics verification: http://www.galois.com/blog/2009/05/15/edsls-for-unmanned-autonomous-verification-and-validation/ * financial modelling Paradise: http://www.londonhug.net/2008/08/11/video-paradise-a-dsel-for-derivatives-pricing/ FPF: http://lambda-the-ultimate.org/node/3331 * operating systems: http://www.barrelfish.org/fof_plos09.pdf In all cases we're looking at high level code, the possibility of multiple backends, and constrained semantics enabling extensive optimization and analysis. And -- we're generating code, so there's no benefit to having the language hosted on the JVM or .NET -- Haskell should *own* this space. This may be Haskell's killer app now that DSLs are going mainstream. We have mature technology for good DSLs. Far more resources than Scala. Why isn't Haskell completely dominating this space? I believe it is lack of training and outreach. We need a Write you a DSL for great good! -- Don dpiponi: 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Haskell for Physicists
dons: And note we are pushing precisely on the use of DSLs in or on Haskell for *portability* of the domain-scientists code in a number of areas right now: * data parallel algorithms (targetting cpu , gpu) Accelerate: http://hackage.haskell.org/package/accelerate-0.6.0.0 Obsidian http://www.cse.chalmers.se/~joels/writing/dccpaper_obsidian.pdf Another good example: Cell DSL, for Maple users: A Domain-Specific Language for the Generation of Optimized SIMD-Parallel Assembly Code http://www.cas.mcmaster.ca/~kahl/Publications/TR/Anand-Kahl-2007a_DSL/ a domain-specific language embedded into Haskell that allows mathematicians to formulate novel high-performance SIMD-parallel algorithms for the evaluation of special functions. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Haskell for Physicists
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 2009/9/30 ed...@ymonad.com Hi, I will give a seminar to physicists at USP (Universidade de São Paulo, Brazil) university and they asked me for a good title, something that can attract physicists. Anyone has some suggestions? (Will be a seminar about the use of Haskell to substitute C or Fortran in a lot of tasks, and how it can be used in some problems instead of Matlab, Mathematica, etc.) Thanks, Edgar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Haskell for Physicists
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. 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. -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
