4 ms·

My opinion, ensuring zero overhead and zero boilerplate code for calling external libraries will solve the SIMD problem. Anything worth vectorizing will be writ

My opinion, ensuring zero overhead and zero boilerplate code for calling external libraries will solve the SIMD problem. Anything worth vectorizing will be written in C/assembly.

JoshTriplett 11y ago
Rust has inline assembly these days. Between that and approaches like this, I certainly hope using FFI for performance won't always be necessary.
- stagger87 11y ago
  I don't think inline assembly solves the problem. If I optimize any worthwhile problem, I would be smart to do it in a way that is accessible from every modern language.
  - steveklabnik 11y ago
    Rust, being able to expose a C ABI and having roughly the same amount of runtime, is accessible from every modern language.
pcwalton 11y ago
On the contrary, much of the motivation for this is writing stuff like image decoding libraries in Rust. People often decode untrusted images, so it makes sense to use a memory-safe language to isolate crashes and prevent RCE vulnerabilities without the overhead of spawning a process per image. But image decoding makes great use of SIMD, so not having SIMD in the implementation language will result in a performance regression over the state of the art.
dbaupp 11y ago
Rust already guarantees zero overhead, and close to zero boilerplate, for FFI calls into C. However, there's no fundamental reason Rust can't be a viable replacement language for C for these sort of things. As one example, I think it would be great to have Rust used more in the numeric/scientific computing space, where a lot of code is written by non-expert programmers (i.e. don't mix well with C/C++ to get reliable software), so having a compiler looking out is possibly nice. Also, it should be possible to replace a C component with a Rust one in essentially a drop-in zero-overhead way since Rust can trivially expose a C-compatible interface.
exDM69 11y ago
> Anything worth vectorizing will be written in C/assembly. This isn't the way to go. Once you have to call an external function, you lose all compiler optimizations that might take place. If you write low level "primitive" operations (e.g. matrix multiply and inverse), you will get worse performance by doing external function calls rather than having your code made visible to the compiler so that it can be inlined and optimized. Additionally, you can't write assembler SIMD code that is portable from architecture to architecture. This can be done in C using extensions but not if you stick to the standard (and support MSVC). Quite a lot of SIMD code can be written portably without having to use architecture specific instructions. It's definitely a good thing that languages like Rust have native SIMD.

My opinion, ensuring zero overhead and zero boilerplate code for calling external libraries will solve the SIMD problem. Anything worth vectorizing will be written in C/assembly.

JoshTriplett 11y ago

Rust has inline assembly these days. Between that and approaches like this, I certainly hope using FFI for performance won't always be necessary.

stagger87 11y ago
I don't think inline assembly solves the problem. If I optimize any worthwhile problem, I would be smart to do it in a way that is accessible from every modern language.
- steveklabnik 11y ago
  Rust, being able to expose a C ABI and having roughly the same amount of runtime, is accessible from every modern language.

pcwalton 11y ago

On the contrary, much of the motivation for this is writing stuff like image decoding libraries in Rust. People often decode untrusted images, so it makes sense to use a memory-safe language to isolate crashes and prevent RCE vulnerabilities without the overhead of spawning a process per image. But image decoding makes great use of SIMD, so not having SIMD in the implementation language will result in a performance regression over the state of the art.

dbaupp 11y ago

Rust already guarantees zero overhead, and close to zero boilerplate, for FFI calls into C. However, there's no fundamental reason Rust can't be a viable replacement language for C for these sort of things. As one example, I think it would be great to have Rust used more in the numeric/scientific computing space, where a lot of code is written by non-expert programmers (i.e. don't mix well with C/C++ to get reliable software), so having a compiler looking out is possibly nice. Also, it should be possible to replace a C component with a Rust one in essentially a drop-in zero-overhead way since Rust can trivially expose a C-compatible interface.

exDM69 11y ago

> Anything worth vectorizing will be written in C/assembly. This isn't the way to go. Once you have to call an external function, you lose all compiler optimizations that might take place. If you write low level "primitive" operations (e.g. matrix multiply and inverse), you will get worse performance by doing external function calls rather than having your code made visible to the compiler so that it can be inlined and optimized. Additionally, you can't write assembler SIMD code that is portable from architecture to architecture. This can be done in C using extensions but not if you stick to the standard (and support MSVC). Quite a lot of SIMD code can be written portably without having to use architecture specific instructions. It's definitely a good thing that languages like Rust have native SIMD.