Hacker News new | past | comments | ask | show | jobs | submit login

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).



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!


How would you characterize/contrast Regent vs. Chapel? What do you see are the main drawbacks/benefits of each?


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 programming construct under the sun). Chapel offers a nice syntax, but it's semantically not so different from writing SHMEM or MPI or one of these other explicitly parallel programming models.

Regent does also support loop auto-parallelization, though it's not the focus of the language and not generally how people write idiomatic Regent programs. Regent fundamentally is a task-based programming model. "Task" is a fancy word for a function that can run in parallel. The key is that (a) tasks execute with sequential semantics, and (b) inside of a task, you can do basically whatever you want. The compiler doesn't need to analyze the code aside from verifying that you're passing data around correctly. This means the set of programs you can write in the "nice" subset of the language is much, much larger. The vast majority of Regent programmers never encounter any explicitly parallel programming constructs, there is no way to make code that deadlocks or races, etc. On the other hand, organizing programs in terms of tasks does still take effort and a degree of cognitive shift. You still have to divide the program into parts that can be parallelized, even if you're not responsible for parallelizing them.


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...


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


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...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: