Getting explicit SIMD on stable Rust

hsivonen · 2017-01-31T16:52:54.298Z

It should in most ways act like a [T; n] array

Is that actually desirable from the point of view of making costs explicit in a systems language?

shufflevector

I thought exposing generic LLVM shuffling had been deemed out of scope for the initial release-channel SIMD feature, and initially only shuffles that map to specific instructions would be provided in a manner similar to C intrinsics even if underneath the API they generated shufflevector in the LLVM IR. Is this not so?

(Generic shufflevector is rather bad at making costs explicit. For example, LLVM uses shufflevector to view the higher or lower half of a NEON quadword register via its doubleword aliasing, but of course such viewing is only needed for type system purposes and there’s no instruction generated at all. OTOH, if you want a shuffle that the ISA doesn’t have a single instruction for, you get a non-obvious number of instructions.)

Anyway, I’d like to avoid slowdowns in getting SIMD to the release channel, so I’m worried about reopening the discussion regarding the types. Firefox is about to drop support for non-NEON ARM, so soon SIMD-in-release-channel-Rust will not only be SSE2-relevant for Firefox but NEON-relevant, too.

Aurora · 2017-01-31T21:35:36.899Z

scottmcm:

But I’m not convinced that either is “very hard to read”

That’s because you’re using a much better syntax

I was discussing, Simd([a.0.0, a.0.1, a.0.2]), which I find very hard to read. Simd(a.1, a.3, a.0, a.2) as in your example isn’t nearly as hard to read for me.

jethrogb · 2017-02-28T06:38:52.897Z

Looks like AVX512 will be available on regular server platforms: https://cloudplatform.googleblog.com/2017/02/Google-Cloud-Platform-is-the-first-cloud-provider-to-offer-Intel-Skylake.html Rust will need to support it.

nagisa · 2017-03-18T13:38:56.885Z

So, I’ve tried to implement memcmp and memcpy with what Rust currently has and couldn’t get a way to express the case that matters for implementing both of those: memory operands for some of the instructions. For example in SSE there’s pcmpeqb which admits an unaligned memory operand. That’s the missing piece for implementing memcmp between two differently aligned pointers.

Intel intrinsics do not cover this use-case (they all take vectors as well), and it might be hard to make LLVM emit such an instruction as well (to do that we’d need at least a way to do unaligned vector loads from the memory (i.e. load %vecty %ptr, align 1)).

burntsushi · 2017-03-18T13:53:45.807Z

@nagisa Could you unpack that? I don’t really grok what you’re saying. Examples would be super helpful.

burntsushi · 2017-03-18T13:55:33.864Z

@nagisa Additionally, why doesn’t something like this satisfy your desire for unaligned vector loads? Or what about the _mm_loadu_si128 intrinsic from SSE2?

nagisa · 2017-03-18T14:24:01.391Z

Oh, I guess I was wrong and pcmpeqb does not permit an unaligned pointer, my bad.

Additionally, why doesn’t something like this1 satisfy your desire for unaligned vector loads?

Terrible codegen in debug mode. _mm_loadu_si128 may be okay but is specific to architecture (i.e. its better to just write assembly then)

nagisa · 2017-03-20T17:29:01.101Z

So, in response to proposal to use [T; n] for representing SIMD. That forces our hand to only ever support uniform vectors, whereas there may be systems (esp. in the future: see RISC-V) which support non-uniform vectors just fine.

Additionally, why doesn’t something like this satisfy your desire for unaligned vector loads?

So I tried using this and with optimisations LLVM fell back to using both unaligned loads and stores, rather than just unaligned loads, like I was intending. Explicitly crafting the IR to make LLVM translate correspondingly aligned loads and stores resulted in the intended instructions being emitted. That suggests that we might at least want to introduce some intrinsic to do arbitrary aligned loads and stores, where its possible to specify alignment independent of the data type (or we might eventually gain #[repr(align(N))] which would probably help with this).

comex · 2017-03-20T18:22:31.616Z

Note that there is already std::ptr::read_unaligned as of a few months ago (albeit not stable); the current implementation uses memcpy, but changing it to be intrinsic-based would be ‘just’ an implementation patch. That doesn’t address custom alignments other than 1, though.

gnzlbg · 2017-03-21T15:10:12.503Z

For those interested, there is a Final Comment Period ongoing to stabilize cfg_target_feature in this issue: https://github.com/rust-lang/rust/issues/29717

Since this has been discussed here a lot, I thought some of you might be interested.

burntsushi · 2017-03-21T17:26:07.327Z

Also, I’ve been slowly but steadily working on the SIMD RFC. I recently took a detour to prove that the simd crate could compile on top of our proposal: https://github.com/BurntSushi/simd/tree/stdsimd

jethrogb · 2017-03-28T04:45:40.882Z

Can we use this somehow? https://github.com/intelxed/xed/tree/master/datafiles

burntsushi · 2017-03-28T13:37:10.462Z

Seems like that might be useful if we were implementing a code generator?

valarauca · 2017-03-28T16:45:27.000Z

I implanted a basic on to retro-fit into the Rustc but it broke everything fairly horribly (uses GCC and LLVMINT)

GitHub

valarauca/gen-simd

gen-simd - Generate simd for the rust-lang project

gnzlbg · 2017-05-04T11:54:57.248Z

Since there was interest to stabilize cfg_target_feature/target_feature to allow other RFCs to advance, I wrote a pre-RFC to fix their semantics on stable and nightly Rust before stabilization:

Pre-RFC: stabilization of target_feature compiler

This pre-RFC proposes a path to stabilize cfg_target_feature and target_feature. It proposes the minimal set of functionality required to allow other RFCs to progress, and sketches some implementation work that needs to happen before that. Recall: target features Some CPUs of the x86 architecture family support bit manipulation algorithms directly as single hardware instructions (e.g. via BMI/BMI2/TBM/ABM instruction sets). Many CPUs of the ARM architecture family support SIMD algorithms via…

Since target feature is required for the SIMD RFCs, it would be great if the pre-RFC could get some eyes from the interested parties to make sure that the proposed semantics don’t hinder any SIMD-related work.

gulbanana · 2017-06-04T05:23:20.282Z

it might be worth looking into how SIMD is being done for webassembly. they’ve chosen the approach of vector types and ‘general’ operations, rather than directly exposed intrinsics - that might only be a good choice in the browser environment, but still, it’d be nice if rust SIMD could compile to wasm SIMD.

here’s the design discussion: https://github.com/WebAssembly/simd and chromium implementation in progress: https://bugs.chromium.org/p/v8/issues/detail?id=6020&desc=2

elahn · 2017-07-27T03:55:37.596Z

Great work on the RFC so far, @burntsushi. I found it very easy to read and understand.

github.com

BurntSushi/rfcs/blob/simd-redux/text/0000-simd-redux.md

- Feature Name: simd-redux
- Start Date: 2017-03-13
- RFC PR:
- Rust Issue:

# Table of contents

* [Summary][summary]
* [Terminology][terminology]
* [Motivation][motivation]
    * [Vendor independent interface][vendor-independent-interface]
    * [Vendor dependent intrinsics][vendor-dependent-intrinsics]
    * [A brief survey][a-brief-survey]
* [Detailed design][design]
    * [Vendor dependent intrinsics][vendor-dependent-intrinsics-1]
    * [Vendor independent interface][vendor-independent-interface-1]
        * [A World Without][a-world-without]
* [How We Teach This][how-we-teach-this]
* [Drawbacks][drawbacks]
* [Alternatives][alternatives]

This file has been truncated. show original

ruudva · 2017-10-24T08:29:03.906Z

Now that target_feature has been stabilized and exposing intrinsics is well under way, we can start thinking about the higher-level API.

A few engineers at Google have been working on a SIMD library for C++ that shares similar goals:

Support multiple architectures.
Don’t hide the cost of expensive operations.
Get 80–90% of the performance of hand-written platform-specific code, at 10–20% of the cost.

In particular there is an overview of operations that are efficient on all platforms.

The current API is the result of insights gathered over many years, and I think we should take inspiration from it.

burntsushi · 2017-10-24T11:10:23.303Z

@ruudva Here are my brief thoughts:

Probably should start a new thread. Stable SIMD still has a long way to go, and it’d be good to not start mixing them up.
At this point, I’d suggest that folks just try and start building a library. I imagine this will produce valuable feedback.

hsivonen · 2017-11-01T12:14:43.925Z

I’m happy to learn that stdsimd has progressed to the point where non-x86 support has started.

I see that unlike simd, stdsimd doesn’t have distinct types for boolean vectors and instead operations that return lane-wise booleans return a vector of signed integers of the same lane width and lane number as in the input type.

(I also observe that since the start of this thread, WebAssembly SIMD has lost distinct boolean vector types.)

Yet, I don’t see stdsimd analogs for the all() and any() methods that boolean vectors had in simd and that WebAssembly SIMD still has. What’s the plan for those operations in stdsimd?

(Arguably, those operations hide cost a bit, since they involve more instructions on ARMv7 than on x86/x86_64/Aarch64. Still, they are the sort of operations that the library should provide instead of everyone having to figure them out individually–especially on ARMv7.)