You can with Rust features. It allows a library to conditionally compile certain parts of the code, and users of the library can decide which features to enable.

If a library only uses stdlib in code gated by #[feature(std)], users can disable that flag, and use the library in no_std contexts.

This is not in any way the problem.

The reason for having std be the feature instead of having no_std be the feature is because if a dependency unsets the default features because it does not rely on the std feature and then someone else still does rely on the std feature then everything will still work properly.

If no_std is the feature then if a dependency sets the no_std feature because it does not rely on the std features and then someone else does not set no_std because they do rely on the std features then there will be problems because there won't be any ability for the someone else to unset the no_std feature that was specified by the first dependency.

as with anything in that regard. profile, profile, profile. valgrind, check cache misses and profile. calculate theoretical throughput of a cpu you're working on, like actual bandwidth of reading/writing RAM, with and without caching, and that's your high post; to try to get as close as possible to those limits. If you want to start with that, you can do just that, simple reads/writes and profile and then introduce functions and structures instead and try to reclaim speed as much as possible. graphs over profiling always help, even better graphs over profiling on commits or PRs so you can tell how you're progressing. But that's just like my opinion, man. No right/wrong way, profiling always tells the truth in the end.

tl;dr; read ops for cpu; profile.

Hint for language designers: when you design a new language, put this stuff, and multidimensional arrays, in the standard library. Multiple incompatible versions of such types is as bad for number-crunching as would be multiple incompatible string types for string manipulation. You want your standard numeric libraries to work on the standard types.

This is part of why Matlab is so successful. You don't have to worry about this stuff.

If your vector is generic (using cpp syntax here): vec<3 float> then you can just put in vec<3, float4> and then solve 4 vector math problems at a time.

It helps tremendously if your interfaces already take N inputs at a time, so then instead of iterating one at a time you do 4 at a time.

I did a small experiment comparing 6 possible implementations of the n-body [0] update loop: https://godbolt.org/z/sfehEfPGT

The implementations are:

* AOS: a simple scalar implementation with coordinates stored in an array of structs * SOA: a simple scalar implementation with coordinates stored as a struct of arrays * float3: uses a struct of three floats as a vector type * float4: uses a struct of four floats as a vector type, ignores the last element * vec4: like float4, but using a generic SIMD abstraction (so basically what glam does) * floats3: attempts to do SOA with nice syntax. floats3 type has three arrays of floats and there are operations to extract and store a float3 type from a given index.

Since these abstractions are often used in games I'll start of looking at what the compiler produces when targeting Zen5 with -O3 -ffast-math:

* Zen5 O3 ffast-math:

    AOS:     gcc: 11119 ~SSE    clang:  3688 AVX512, but quite messy
    SOA:     gcc:  1283 AVX512  clang:  1202 AVX512
    float3:       11050 ~SSE    clang: 10894 ~SSE
    float4:  gcc:  8646 ~SSE    clang: 10815 ~SSE
    vec4:    gcc:  7913 ~SSE    clang:  8196 ~SSE
    floats3: gcc:  1284 AVX512  clang: 13351 ~SSE

Now let's also look at a different ISA, this time the RISC-V Vector extension:

* P670 2xVLEN O3 ffast-math:

    AOS:     gcc: 17445         clang:  3357 RVV
    SOA:     gcc:  3355 RVV     clang:  3334 RVV
    float3:  gcc: 17445         clang: 17449
    float4:  gcc: 25668 RVV128  clang: 17470 RVV128
    vec4:    gcc: 45091 RVV128  clang: 23111 RVV128
    floats3: gcc:  3333 RVV     clang: 17446

So if you are using such vector types to do computations in loops you are likely to end up preventing your compiler from optimizing it for modern hardware. In general writing simple SOA scalar code seems to vectorize best, as long as you make sure the compiler isn't confused by aliasing. But even the plain old AOS scalar code can be vectorized by modern clang, but not by gcc, and sadly also not the float3/float4 implementations, which should be very similar. Modern ISAs like NEON/SVE/RVV have more complex vector load/stores that allow you to retrieve data more efficiently even from a traditionally bad data layout like AOS. You can dress up the SOA code to make it a bit nicer, unfortunately my attempt with floats3 currently only works properly with gcc.

Below are the results when compiling without -ffast-math:

* Zen5 O3:

    AOS:     gcc: 11819 ~SSE    clang: 10788 ~SSE
    SOA:     gcc:  4146 AVX512  clang: 13734 AVX512
    float3:       11826 ~SSE    clang: 11499 ~SSE
    float4:  gcc:  8662 ~SSE    clang: 11810 ~SSE
    vec4:    gcc:  8575 ~SSE    clang:  7451 ~SSE
    floats3: gcc:  4148 AVX512  clang: 14367 ~SSE

    AOS:     gcc: 17464 RVV64   clang:  6122 RVV
    SOA:     gcc:  7140 RVV     clang:  6118 RVV
    float3:  gcc: 17445         clang: 17464 RVV64
    float4:  gcc: 25665 RVV128  clang: 19184 RVV128
    vec4:    gcc: 17463 RVV128  clang: 56868 RVV128
    floats3: gcc:  7140 RVV     clang: 17444

I'll try to experiment with some real world code, if I can find some that is bottle-necked by such types.

[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...