Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chapel 1.32

chapel-lang.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Chapel 1.32

#21

Post by eslaught »

atemerev wrote: post #11
jfkfif wrote: post #5

I really like Legion as an alternative for HPC applications, among many others ( https://legion.stanford.edu/ )

Legion is great! I like that its developers really get HPC. But it is C++, with all of its baggage. (Update: There is also Regent language on top of C++ API, looks interesting).

I should also note that there is Pygion if you want to use Python. Not a lot of great reference material right now, but there's the paper:

https://legion.stanford.edu/pdfs/pygion2019.pdf

And code samples:

https://github.com/StanfordLegion/legion/tree/stable/binding...

Re: Chapel 1.32

#22

Post by cscheid »

meisel wrote: post #15
atemerev wrote: post #10

Earlier quoted context omitted.

Working in heterogeneous computing environments (and having first-class facilities for that), while still being easy enough to immediately start adapting numerical code from any reference implementation.

What are these first class facilities? Just curious

Roughly, the sets of computational problems that people used (use?) MPI for. Things like numerical solvers for sparse matrices that are so big that you need to split them across your entire cluster. These still require a lot of node-to-node communication, and on top of it, the pattern is dependent on each problem (so easy solutions like map-reduce are effectively out). See eg https://www.open-mpi.org/, and https://courses.csail.mit.edu/18.337/2005/book/Lecture_08-Do... for the prototypical use case.

Re: Chapel 1.32

#23

Post by [deleted] »

atemerev wrote: post #19
eslaught wrote: post #14

Earlier quoted context omitted.

Hey, I'm the creator of Regent. Feel free to ask me questions.

Cool! I wondered how production code would look like, then I found this: https://github.com/stanfordhpccenter/soleil-x/blob/master/sr... , and was thoroughly impressed. I wonder if it would be possible to easily set it up on our university's HPC cluster (which is not a supercomputer, but still has SLURM and everything there).

[deleted]

Re: Chapel 1.32

#24

Post by rohany »

jfkfif wrote: post #5

I really like Legion as an alternative for HPC applications, among many others ( https://legion.stanford.edu/ )

Legion has been used to develop distributed, drop-in replacements for libraries like NumPy and SciPy Sparse -- https://github.com/nv-legate/cunumeric/, https://github.com/nv-legate/legate.sparse

Re: Chapel 1.32

#25

Post by eslaught »

codekilla wrote: post #20
eslaught wrote: post #17

Earlier quoted context omitted.

Chapel's killer feature, in my opinion, is being able to take something that looks like a simple loop and turn it into distributed code (via domain maps). To the extent that you can write your program in terms of that feature, you can get very clean programs. But once you step outside of that feature, you've basically back to full-on parallel programming (i.e., explicit PGAS programming with nearly every parallel pro…

Thanks, this is helpful. It seems like (based on your reply) there are people successfully using Regent for scientific computing (I'm assuming); do you think the language is a viable choice for industry, or are there particular milestones you're looking reach?

Yes, we're focus mostly on scientific computing. One of our major apps is S3D, which we ported to Regent from Legion C++ [1]. This has been the first time the domain scientists have been able to modify the code themselves; previously the C++ was too much for them. There are other examples of Regent apps elsewhere in this thread.

If by "industry" you mean in areas related to HPC, then Regent is likely to be applicable to what you want. The further you get away from HPC, the less likely that would be. You probably wouldn't use Regent to write a web server, though it's not impossible....

Right now my biggest item is making sure we support all the DOE supercomputers, which means adding support for Intel GPUs. (Regent currently supports NVIDIA and AMD.)

[1]: https://theory.stanford.edu/~aiken/LegionRetreat22/slides/ch...

Re: Chapel 1.32

#26

Post by bradcray »

meisel wrote: post #15
atemerev wrote: post #10

Earlier quoted context omitted.

Working in heterogeneous computing environments (and having first-class facilities for that), while still being easy enough to immediately start adapting numerical code from any reference implementation.

What are these first class facilities? Just curious

My answer would be that Chapel supports a partitioned global namespace such that a variable within the lexical scope of a given statement can be referenced whether it is local to that CPU's memory, stored on a remote compute node, or stored within a GPU's memory (say). The compiler and runtime implement the communication on the programmer's behalf and take steps to optimize away unnecessary communication. Other key features include first-class support for creating parallel tasks in high-level ways, including parallel loops.

Re: Chapel 1.32

#27

Post by codekilla »

eslaught wrote: post #25
codekilla wrote: post #20

Earlier quoted context omitted.

Thanks, this is helpful. It seems like (based on your reply) there are people successfully using Regent for scientific computing (I'm assuming); do you think the language is a viable choice for industry, or are there particular milestones you're looking reach?

Yes, we're focus mostly on scientific computing. One of our major apps is S3D, which we ported to Regent from Legion C++ [1]. This has been the first time the domain scientists have been able to modify the code themselves; previously the C++ was too much for them. There are other examples of Regent apps elsewhere in this thread. If by "industry" you mean in areas related to HPC, then Regent is likely to be applicable…

Thanks, yes, I was thinking along the lines of HPC type applications in industry.

Re: Chapel 1.32

#28

Post by andyferris »

atemerev wrote: post #13
moelf wrote: post #12

Earlier quoted context omitted.

Julia? not only it's 1-index, it's also very imperative

Julia is great, but not HPC-friendly.

This is interesting. I've had good experiences, but admittedly haven't done problems with huge amounts of communication. Is there some fundamental issue? Lack of supporting libraries?

Re: Chapel 1.32

#29

Post by jfkfif »

atemerev wrote: post #19
eslaught wrote: post #14

Earlier quoted context omitted.

Hey, I'm the creator of Regent. Feel free to ask me questions.

Cool! I wondered how production code would look like, then I found this: https://github.com/stanfordhpccenter/soleil-x/blob/master/sr... , and was thoroughly impressed. I wonder if it would be possible to easily set it up on our university's HPC cluster (which is not a supercomputer, but still has SLURM and everything there).

please email us at hpccenter@stanford.edu, and ask to be put in touch with someone at PSAAP. I would be happy to help!

Re: Chapel 1.32

#30

Post by potatoboiler »

andyferris wrote: post #28
atemerev wrote: post #13

Earlier quoted context omitted.

Julia is great, but not HPC-friendly.

This is interesting. I've had good experiences, but admittedly haven't done problems with huge amounts of communication. Is there some fundamental issue? Lack of supporting libraries?

I wonder if the JIT model prevents predictable benchmarking/optimization, making long-term robustness difficult? It might also make using MPI difficult. But this is mostly speculation on my part.
Post reply on HN