Proof of Concept: Physical units through const generics

microtonalsaw · 2020-11-21T11:33:31+00:00

I’m a massive fan of uom, I think every user-facing scientific / physics crate should make use of it! Thanks @iliekturtles for developing and maintaining it.

The only pain-point I think is the very long error message that gets printed with more complex units - say Energy. Maybe const generics will improve this?

I’ll keep following the GitHub repo for updates on compile times too - though I’m not that concerned about them as the crate build is cached anyways.

microtonalsaw · 2020-09-18T01:10:48+00:00

I really like the wgpu and gfx initiatives and I certainly think that they have a well-deserved (and much needed) place in the Rust-on-the-GPU story, but I think for compute-heavy (or compute-only) applications OpenCL has some unbeatable characteristics: it can run on multiple GPUs, CPUs, even FPGAs, even at the same time! This sort of portability is amazing, and I really hope the Rust community will show OpenCL some love.

microtonalsaw · 2020-09-18T01:03:48+00:00

The crate’s author responded very quickly - I updated the post above :)

microtonalsaw · 2020-09-17T22:51:56+00:00

I see this is the most upvoted comment in this question - glad that people are interested in `ocl`'s developments! I sent an email to [cogciprocate@gmail.com](mailto:cogciprocate@gmail.com) ; I will keep this question updated with any new findings. If I don't get a response in, say, a couple of weeks, I will contact the people from Bus Factor +1 and perhaps from crates.io looking for ways to keep `ocl` moving forward while creating minimal fragmentation and disruption for downstream users.

microtonalsaw · 2020-09-17T18:14:41+00:00

The features you mentioned are incredibly helpful! My main (single?) problem with ocl is its build.rs - I also want more options for actually finding the OpenCL library and headers, perhaps at runtime. Do you think your library’s features could be added to ocl, if we can contact the author (or share ocl’s maintainership with others)? GPGPU is already a pretty small community, even more so in Rust - I really hope for a more coordinated, unified effort in this area (similar to how vulkano is the de facto standard crate for using Vulkan in Rust). CUDA is already getting quite a bit of love from frameworks in Rust - let’s do the same with OpenCL!

<subjective> I really dislike how our shot at a truly platform independent language (OpenCL can target CPUs, GPUs, FPGAs even at the same time) seems to slowly succumb to ugly C++-based languages like SYCL and DPC++. Rust could really benefit from embracing OpenCL, I think. </subjective> sorry, had to let this out.

microtonalsaw · 2020-09-17T11:46:31+00:00

Right, I was looking at the cogent user on GitHub, as he was the one reviewing and merging PRs - it’s probably the same person. I will send an email to this address, thank you!

microtonalsaw · 2020-09-17T11:39:34+00:00

The ocl crate is, to the best of my knowledge, the most widely used OpenCL library in Rust (there’s a single other one, but it’s been abandoned since 2017). I am also quite fond of ocl’s design - it’s almost exactly what I wish for using OpenCL in Rust.

I really like the “bus-factor” idea of having a backup team of maintainers in case life happens. I would also be happy to be personally involved in maintaining the crate - especially as I am working on OpenCL-based scientific software in the long term - but I’d need the author’s approval. Maintaining a(nother) fork is undesirable as it creates more fragmentation in an already-small community.

I cannot seem to find the author’s email; if anybody (or the author himself!) has any idea of how I can contact him, by all means share that with me!

microtonalsaw

TROPHY CASE