I mean, if you are being serious, there are tons of reasons to use the C API. I heavily use intrinsics in C++ templates. Clever use of templates allows me to write a function once which can compile to SSE/AVX/AVX-512 and different data types (float/double) and different arch (x86/x64). In most situations this will be faster than assembly since I can inline everything wherever I want. When the need arises I will drop down to assembly to try to get any last perf gains, but otherwise I found that clang/icc/msvc are pretty good at generating assembly.
As another example, this morning I needed to perform a small convolution in an inner loop. Since I'm targeting x64 under the msvc compiler I can't write an external assembly function and have it inlined into the inner loop. Therefore I was left with just using the raw intrinsics from intrin.h for like, 10 lines of code. The simplicity of the convolution means the compiler will have no problems generating optimal code.
> I simply meant that the bare xxxintrin.h stuff is annoying enough that if you're using it directly you might as well write assembly.
The compiler is aware of many of those intrinsics and can perform optimizations around them. Hand rolling all of that in Assembly would be quite the chore. Using these intrinsics is, IMO, considerably easier.
Rust chose to adopt the vendors' naming schemes exactly as they were defined, instead of inventing their own. The idea was that these intrinsics are official, well-understood and people will build higher-level abstractions on top of them anyway.
To elaborate a bit, the intention is to first stabilize the platform-dependent low-level intrinsics just as specified by each vendor, under the "arch" namespace in the standard library (e.g. `use std::arch::x86_64::whatever`, which is quite self-explanatorily nonportable). This will hit stable Rust as of the next release, on June 21. Future work will focus on building a more portable, more Rust-like, higher-level API on top of these intrinsics under the "simd" namespace in the standard library; you can see the current state of this work at https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/s... .
> Sometimes you may want to use SSE41 even with AVX2 is available.
I'm glad this is an option. I feel like a lot of libraries assume you always want the widest SIMD width possible, when this is very likely to cause performance issues for many cases.
That's not what 'noise' looks like to me, or well, it's not the white noise I'd associate with TV, more like err, a semirandom generated height map of sorts. Still, that amount of detail requires billions of datapoints, generating those quickly is beneficial. I can imagine games like Elite: Dangerous and No Man's Sky use those a lot for the trillions of planets they have.
The author of that is a good friend! I was showing him my SIMD C++ noise library and that inspired him to make that (which is much much better than the thing I had hacked together in c++)
Doing SIMD accelerated 1D noise is probably pointless, as it will be so fast. I could add scalar versions of 1d though.
I'm up for 4D potentially if anyone has some use cases.
Yeah I understand that being the stated reason I've just not seen it actually done very often as the performance/memory use is an issue. I've been surveying some people though and a couple people are actually using it, looks like!
Another interesting usecase is generating seamlessly tiling noise [1]. Admittedly this is usually done in advance where slower performance is fine, but fully or mostly procedural games could really benefit from it. Combining this with prime number-sized layered textures [2] gets you a very organic looking texture with only an upfront rendering cost, making it plausible to generate high resolution unique textures for everything in a game on the fly.
23 comments
[ 2.9 ms ] story [ 57.0 ms ] threadTBH I find assembly kernels generally more readable as long as one keep a few comments in there to explicit register allocation.
I absolutely agree that once wrapped up there are good reasons to use a language-level interface instead of asm for most things.
The compiler is aware of many of those intrinsics and can perform optimizations around them. Hand rolling all of that in Assembly would be quite the chore. Using these intrinsics is, IMO, considerably easier.
I'm glad this is an option. I feel like a lot of libraries assume you always want the widest SIMD width possible, when this is very likely to cause performance issues for many cases.
Those are the only two times I have bumped into this kind of noise but I'm sure there are a few more uses.
Some examples:
http://libnoise.sourceforge.net/examples/complexplanet/index...
There is also value noise, white noise (what you are thinking of), cellular noise. It is an interesting field!
value noise and white noise are computationally easy enough that it probably doesn't make sense to simdify them. probably!
Doing SIMD accelerated 1D noise is probably pointless, as it will be so fast. I could add scalar versions of 1d though.
I'm up for 4D potentially if anyone has some use cases.
[1] https://gamedev.stackexchange.com/a/23639 [2] https://news.ycombinator.com/item?id=2419347