3 ms·

Parallelism in CS is a bit like security in CS. People know it matters in the abstract senses but you really only get into it if you look for the training speci

Parallelism in CS is a bit like security in CS. People know it matters in the abstract senses but you really only get into it if you look for the training specifically. We're getting better at both over time: just as more languages/libraries/etc. are secure by default, more now are parallel by default. There's a ways to go, but I'm glad we didn't do this prematurely, because the technology has improved a lot in the last decade. Look for example at what we can do (safely!) with Rayon in Rust vs (unsafely!) with OpenMP in C++. And there are things even further afield like what I work on [1][2][3]. [1]: https://legion.stanford.edu/ https://legion.stanford.edu/ [2]: https://regent-lang.org/ https://regent-lang.org/ [3]: https://github.com/nv-legate/cunumeric https://github.com/nv-legate/cunumeric

eyegor 3y ago
See also https://github.com/cupy/cupy https://github.com/cupy/cupy https://github.com/inducer/pyopencl https://github.com/inducer/pyopencl
winter_blue 3y ago
What's the difference between Legion and Regent, by the way? I noticed the Regent code is inside the Legion repo. Is Legion the system, and Regent the language? Can Legion be used without Regent, or vice versa?
- eslaught 3y ago
  Legion is a C++ runtime system. It exposes APIs in C++ and C. You can write code directly to it with C++ (and CUDA/HIP/SyCL if you want to use GPUs). But the only requirement is a C++ compiler and standard build system (Make/CMake). Regent is a programming language. The compiler for Regent generates Legion code. Semantically, Regent is mostly a simplification of Legion. There are fewer moving pieces, so fewer things you need to worry about. Many of the "gotchas" that exist in Legion are taken care of by the language/compiler so idiomatic code usually "just works". It also does GPU code generation for you so you don't need to hand-write CUDA/HIP/etc. The tradeoff is that you're using a new programming language, so you have to be willing to take that risk.
menaerus 3y ago
> Look for example at what we can do (safely!) with Rayon in Rust "Safely" for a certain kind of definition of safety: https://github.com/search?q=repo%3Arayon-rs%2Frayon+unsafe&type=code https://github.com/search?q=repo%3Arayon-rs%2Frayon+unsafe&t...
- SkiFire13 3y ago
  The point is that the "unsafe" code is written and checked once, and then everyone can benefit from that. It's the same concept as encapsulation applied to memory/thread safety.
- YoshiRulz 3y ago
  The library uses `unsafe` so the consumer doesn't have to. But more to the point, to say "it uses the `unsafe` keyword, therefore it can't be safe" would be disingenuous, or at least very ignorant. The "certain kind of definition of safety" you're looking for would be 'soundness'[1]: a library using `unsafe` is considered 'sound' iff calling into it from safe Rust can never corrupt memory. When people say Rust is better for memory safety than e.g. C++, it's not because you can't write a provably-safe library with C++—you can do that with some effort. It's because the Rust language differentiates compiler-asserted safety from programmer-asserted safety via the `unsafe` keyword, an opt-in. [1]: https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library https://rust-lang.github.io/unsafe-code-guidelines/glossary.... (edit: Sniped, but I believe I've expanded upon the sibling comment.)
  - menaerus 3y ago
    > "it uses the `unsafe` keyword, therefore it can't be safe" > ... would be disingenuous, or at least very ignorant. That's quite literally what it means - there is a "safe" Rust code that never uses the "unsafe" but the example given by the parent comment is just not the example of that. I am not sure why would my comment come out as ignorant - it's factual state of things. > it's not because you can't write a provably-safe library with C++ Hm, you really can't? Neither you can with safe or unsafe Rust. None of the compilers for those languages are formally verified.

eyegor 3y ago

See also https://github.com/cupy/cupy https://github.com/cupy/cupy https://github.com/inducer/pyopencl https://github.com/inducer/pyopencl

winter_blue 3y ago

What's the difference between Legion and Regent, by the way? I noticed the Regent code is inside the Legion repo. Is Legion the system, and Regent the language? Can Legion be used without Regent, or vice versa?

eslaught 3y ago
Legion is a C++ runtime system. It exposes APIs in C++ and C. You can write code directly to it with C++ (and CUDA/HIP/SyCL if you want to use GPUs). But the only requirement is a C++ compiler and standard build system (Make/CMake). Regent is a programming language. The compiler for Regent generates Legion code. Semantically, Regent is mostly a simplification of Legion. There are fewer moving pieces, so fewer things you need to worry about. Many of the "gotchas" that exist in Legion are taken care of by the language/compiler so idiomatic code usually "just works". It also does GPU code generation for you so you don't need to hand-write CUDA/HIP/etc. The tradeoff is that you're using a new programming language, so you have to be willing to take that risk.

menaerus 3y ago

> Look for example at what we can do (safely!) with Rayon in Rust "Safely" for a certain kind of definition of safety: https://github.com/search?q=repo%3Arayon-rs%2Frayon+unsafe&type=code https://github.com/search?q=repo%3Arayon-rs%2Frayon+unsafe&t...

SkiFire13 3y ago
The point is that the "unsafe" code is written and checked once, and then everyone can benefit from that. It's the same concept as encapsulation applied to memory/thread safety.
YoshiRulz 3y ago
The library uses `unsafe` so the consumer doesn't have to. But more to the point, to say "it uses the `unsafe` keyword, therefore it can't be safe" would be disingenuous, or at least very ignorant. The "certain kind of definition of safety" you're looking for would be 'soundness'[1]: a library using `unsafe` is considered 'sound' iff calling into it from safe Rust can never corrupt memory. When people say Rust is better for memory safety than e.g. C++, it's not because you can't write a provably-safe library with C++—you can do that with some effort. It's because the Rust language differentiates compiler-asserted safety from programmer-asserted safety via the `unsafe` keyword, an opt-in. [1]: https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library https://rust-lang.github.io/unsafe-code-guidelines/glossary.... (edit: Sniped, but I believe I've expanded upon the sibling comment.)
- menaerus 3y ago
  > "it uses the `unsafe` keyword, therefore it can't be safe" > ... would be disingenuous, or at least very ignorant. That's quite literally what it means - there is a "safe" Rust code that never uses the "unsafe" but the example given by the parent comment is just not the example of that. I am not sure why would my comment come out as ignorant - it's factual state of things. > it's not because you can't write a provably-safe library with C++ Hm, you really can't? Neither you can with safe or unsafe Rust. None of the compilers for those languages are formally verified.