HVM VS rust-gpu

Reminds me of HVM[0]

[0]https://github.com/HigherOrderCO/HVM

Really interesting to see how new lang concepts and refinements keep popping up this last decade, between Vale, Gleam, Hylo, Austral...

Linear types really opened up lots of ways to improve memory management and compilation improvements.

I have a tangential question that is related to this cool new feature.

Warning: the question I ask comes from a part of my brain that is currently melted due to heavy thinking.

Context: I write a fair amount of Clojure, and in Lisps the code itself is a tree. Just like this F# parallel graph type-checker. In Lisps, one would use Macros to perform compile-time computation to accomplish something like this, I think.

More context: Idris2 allows for first class type-driven development, where the types are passed around and used to formally specify program behavior, even down to the value of a particular definition.

Given that this F# feature enables parallel analysis, wouldn't it make sense to do all of our development in a Lisp-like Trie structure where the types are simply part of the program itself, like in Idris2?

Also related, is this similar to how HVM works with their "Interaction nets"?

https://github.com/HigherOrderCO/HVM

https://www.idris-lang.org/

https://clojure.org/

I'm afraid I don't even understand what the difference between code, data, and types are anymore... it used to make sense, but these new languages have dissolved those boundaries in my mind, and I am not sure how to build it back up again.

Impressive presentation but I find two things missing in particular:

* GRIN [1] - arguably a breakthrough in FP compilation; there are several implementation based on this

* HVM [2] - parallel optimal reduction. The results are very impressive.

[1] https://link.springer.com/chapter/10.1007/3-540-63237-9_19

[2] https://github.com/HigherOrderCO/HVM

Purity has nothing to do with memoization. Haskell's semantics never "rewrite under a lambda" (unlike, e.g. HVM). Calling (\_ -> e) () twice will (modulo optimizations) always perform the computation in e twice.

The most recent exploration of this, that I'm aware of is HVM (another intermediate language / runtime), although this one is not actually based on the lambda calculus, but on the interaction calculus.

Then, actually unrelated but worth mentioning: HVM. Finally, something new on the functional front that isn't dependent types!

If you are into functional PL, how about https://github.com/HigherOrderCO/HVM? You could experiment if you could schedule that on a GPU?

In the interest of seeking ways of optimizing my code, I stumbled upon http://www.rntz.net/datafun/ as a means to do incremental computations of fixpoints while avoiding redundant work. And also the idea of automatic parallelism achieved by using Interaction Nets as a model of computation https://github.com/HigherOrderCO/HVM.

Sounds cool, but this requires yet another language to learn[0]. As someone who only has limited knowledge in this space, could someone tell me how comparable is the compute functionality of rust-gpu[1], where I can just write rust?

[0] https://github.com/Hugobros3/shady#language-syntax

[1] https://github.com/EmbarkStudios/rust-gpu

I don't do anything related to data science, but I feel like doing it in Rust would be nice.

You get operator overloading, so you can have ergonomic matrix operations that are typed also. Processing data on the CPU is fast, and crates like https://github.com/EmbarkStudios/rust-gpu make it very ergonomic to leverage the GPU.

I like this library for creating typed coordinate spaces for graphics programming (https://github.com/servo/euclid), I imagine something similar could be done to create refined types for matrices so you don't do matrix multiplication matrices of invalid sizes

Do you mean rust-gpu?

And https://github.com/EmbarkStudios/rust-gpu/tree/main/examples with the wgpu runner (here it runs the compute shader)

I don't know how major they are considered, but Embark Studios is doing quite a bit of Rust in the open source space, most notably (IMO) rust-gpu and kajiya

The examples in the rust-gpu repository are a good place to start

There's another project that's similar that's being used by an actual game company: https://github.com/EmbarkStudios/rust-gpu

They see specific advantages here that would outweigh that negative. It's not my space (I play games, but know next to nothing about graphics programming), but there's at least one argument in the other direction.

Could this approach work for compute shaders (GPGPU) as well? So far, I think https://github.com/EmbarkStudios/rust-gpu is the state of the art in that area, but it adds a specific Rust compiler backend for generating SPIR-V rather than leaving that up to the driver. That seems more complicated than it needs to be... but maybe it has advantages too? Thoughts?

https://github.com/embarkstudios/rust-gpu Allows you to create shaders (kernals) in Rust.

Also Embark Studios (formers DICE people) is doing a lot of work with Rust, all open source like Rust GPU https://github.com/EmbarkStudios/rust-gpu