OneAPI Rust Compiler

[FCLC]

Request:

Integrate Intel OneAPI optimization, extensions and libraries into alternative/extension of the Rust compiler

Context:

Currently exploring moving some of our code base to Rust, but we've been using ICX/IFX, and before that ICC and Ifort for a while. Was hoping it may be possible for intel to support rust in the near future? Its compiler is also LLVM based.

[AlexeySachkov]

@pvchupin, could you please comment here?

[pengtu]

@FCLC: would you elaborate what parts of oneAPI you want to integrate with Rust:

1. Calling oneAPI performance libraries: oneMKL, oneDNN, oneVPL, ... from Rust?
2. Passing Rust data to SYCL program to perform offloading computations on XPU?
3. Writing offloading kernels in Rust and dispatching the kernels to XPU through Rust runtime interface with Level Zero?
4. Something else?

[FCLC]

@FCLC: would you elaborate what parts of oneAPI you want to integrate with Rust:

Shorter term would be using the intel LLVM backend from ICX/IFX as to build an intel rust compiler.

Being able to do everything within the intel development suite would be a nice efficiency increase as opposed to the current workflow of doing any legacy/intel lib dependant code in C/CPP/Fort while we move new code to rust.

Medium term the trajectory is moving any and all security/cryptographic code from C to rust.

Developer efficiency seems strong and runtime is as good if not better in most cases.

Longer term being able to directly deal with SYCL via rust for any and all heterogeneous compute is ideal.

[alexbatashev]

Medium term the trajectory is moving any and all security/cryptographic code from C to rust.

Most crypto is in the hardware these days. You don't get high performance otherwise. Not sure how much value rewriting existing code can bring here.

Longer term being able to directly deal with SYCL via rust for any and all heterogeneous compute is ideal.

Not sure this makes any sense. In SYCL programming model your data is shared across hundreds of threads by default, which is not really allowed by safe Rust. So, it does not help to make USM code safer (other than prohibiting USM), and SYCL accessors are managed by runtime anyway. Rust here does not provide any safety on top and Rust syntax is not simpler in any way than C++, metaprogramming lacks behind C++. Basically, for GPU offloading, Rust wouldn't give you any value over any other language out there.

[pengtu]

Shorter term would be using the intel LLVM backend from ICX/IFX as to build an intel rust compiler.

Can you share your thoughts on the features from Intel's LLVM backend you would like to add to RUST's LLVM compiler? In general, we upstream our changes to LLVM, such that they can be used by RUST's backend without forking a new RUST compiler.

[ScottBoyce]

To me this would be a nice feature as an alternative to Fortran and C++. I personally do not use MKL, but write numerical software that represent environmental systems, primarily in Fortran. I've not been happy with ifx and the forced transition to it, so I've been looking at pivoting development to Rust or GO. Most of my simulators are fine with single cpu execution but need fast array operations and easy vectorization.

Ideally there could be a front end that translates Rust, or even GO, to the Intel IR that is then optimized to the same extent as is attempted in Fortran. It also be interesting to add wrappers to something like a goroutine to MPI or some sort of cloud computing (not sure if there is an analogy to Rust, but that would open a lot more HPC options for it).

I think this is important as the White House made a recent executive order for people to avoid memory unsafe langauges and should start developing in memory safe languages, such as Rust.

https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf

https://www.infoworld.com/article/3713203/white-house-urges-developers-to-dump-c-and-c.html