www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - intel-intrinsics v1.0.0

reply Guillaume Piolat <first.last gmail.com> writes:
"intel-intrinsics" is a DUB package for people interested in x86 
performance that want neither to write assembly, nor a 
LDC-specific snippet... and still have fastest possible code.

Available through DUB: 
http://code.dlang.org/packages/intel-intrinsics


*** Features of v1.1.0:

- All intrinsics in this list: 
https://software.intel.com/sites/landingpage/IntrinsicsGuide
#techs=MMX,SSE,SSE2 Use existing Intel documentation and syntax

- write the same code for both DMD and LDC, in the last 6 
versions for each. (Note that debug performance might suffer a 
lot when no inlining is activated.)

- Use operators on SIMD vectors as if core.simd were implemented 
on DMD 32-bit

- Introduces int2 and float2 because short SIMD vectors are useful

- about 6000 LOC (for now! more to come)

- Bonus: approximated pow/exp/log. Perform 4 approximated pow at 
once.


<future>
The long-term goal for this library is to be _only about 
semantics_, and not particularly codegen(!). This is because LLVM 
IR is portable, so forcing a particular instruction is undoing 
this portability work. **This can seem odd** for an "intrinsics" 
library but this way exact codegen options can be choosen by the 
library user, and most intrinsics can gracefuly degrade to 
portable IR in theory.

In the future, "magic" LLVM intrinsics will only be used when 
built for x86, but I think all of it can become portable and not 
x86-specific. Besides, there is a trend in LLVM to remove magic 
intrinsics once they are doable with IR only.
</future>


tl;dr you can use "intel-intrinsics" today, and get quite-optimal 
code with LDC, without duplication. You may come across early 
bugs too.
http://code.dlang.org/packages/intel-intrinsics

(note: it's important to bench against vanilla D code or arrays 
ops too, in some case the vanilla code wins)
Feb 05
next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat 
wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.
Neat. Question: On Github it's stated that implicit conversions aren't supported, with this example: __m128i b = _mm_set1_epi32(42); __m128 a = b; // NO, only works in LDC Couldn't this be solved through something like this: struct __m128 { float4 value; alias value this; void opAssign(__m128i rhs) { value = cast(float4)rhs.value; } } -- Simen
Feb 05
parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 6 February 2019 at 07:41:25 UTC, Simen Kjærås wrote:
 struct __m128 {
     float4 value;
     alias value this;
     void opAssign(__m128i rhs) {
         value = cast(float4)rhs.value;
     }
 }

 --
   Simen
The problem is that when you emulate core.simd (DMD 32-bit on Windows require that, if you want super fast OPTLINK build times), then you have no way to have user-defined implicit conversions. and magic vector types from the compiler float4 / int4 / short8 / long2 / byte16 are all implicitely convertible to each other, but I don't think we can replicate this.
Feb 06
prev sibling next sibling parent reply NaN <divide by.zero> writes:
On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat 
wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.

 Available through DUB: 
 http://code.dlang.org/packages/intel-intrinsics
Big thanks for this, it's been a massive help for me. cheers!
Feb 08
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 8 February 2019 at 12:22:14 UTC, NaN wrote:
 On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat 
 wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.

 Available through DUB: 
 http://code.dlang.org/packages/intel-intrinsics
Big thanks for this, it's been a massive help for me. cheers!
You're welcome! I'd be interested to know what you are making with it, to feed the "users" list! https://github.com/AuburnSounds/intel-intrinsics/blob/master/README.md
Feb 08
parent NaN <divide by.zero> writes:
On Friday, 8 February 2019 at 12:39:22 UTC, Guillaume Piolat 
wrote:
 On Friday, 8 February 2019 at 12:22:14 UTC, NaN wrote:
 On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume 
 Piolat wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.

 Available through DUB: 
 http://code.dlang.org/packages/intel-intrinsics
Big thanks for this, it's been a massive help for me. cheers!
You're welcome! I'd be interested to know what you are making with it, to feed the "users" list! https://github.com/AuburnSounds/intel-intrinsics/blob/master/README.md
Im the guy from #graphics who's writing a software rasterizer. I'll let you know when I put it on github.
Feb 08
prev sibling parent reply Crayo List <crayolist gmail.com> writes:
On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat 
wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.

 [...]
This is really cool and I appreciate your efforts! However (for those who are unaware) there is an alternative way that is (arguably) better; https://ispc.github.io/index.html You can write portable vectorized code that can be trivially invoked from D.
Feb 12
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 13 February 2019 at 04:57:29 UTC, Crayo List wrote:
 On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat 
 wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.
This is really cool and I appreciate your efforts! However (for those who are unaware) there is an alternative way that is (arguably) better; https://ispc.github.io/index.html You can write portable vectorized code that can be trivially invoked from D.
ispc is another compiler in your build, and you'd write in another language, so it's not really the same thing. I haven't used it (nor do I know anyone who do) so don't really know why it would be any better
Feb 13
parent reply Crayo List <crayolist gmail.com> writes:
On Wednesday, 13 February 2019 at 19:55:05 UTC, Guillaume Piolat 
wrote:
 On Wednesday, 13 February 2019 at 04:57:29 UTC, Crayo List 
 wrote:
 On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume 
 Piolat wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.
This is really cool and I appreciate your efforts! However (for those who are unaware) there is an alternative way that is (arguably) better; https://ispc.github.io/index.html You can write portable vectorized code that can be trivially invoked from D.
ispc is another compiler in your build, and you'd write in another language, so it's not really the same thing.
That's mostly what I said, except that I did not say it's the same thing. It's an alternative way to produce vectorized code in a deterministic and portable way. This is NOT an auto-vectorizing compiler!
 I haven't used it (nor do I know anyone who do) so don't really 
 know why it would be any better
And that's precisely why I posted here; for those people that have interest in vectorizing their code in a portable way to be aware that there is another (arguably) better way. I highly recommend browsing through the walkthrough example; https://ispc.github.io/example.html For example, I have code that I can run on my Xeon Phi 7250 Knights Landing CPU by compiling with --target=avx512knl-i32x16, then I can run the exact same code with no change at all on my i7-5820k by compiling with --target=avx2-i32x8. Each time I get optimal code. This is not something you can easily do with intrinsics!
Feb 13
next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Wednesday, 13 February 2019 at 23:26:48 UTC, Crayo List wrote:
 On Wednesday, 13 February 2019 at 19:55:05 UTC, Guillaume 
 Piolat wrote:
 On Wednesday, 13 February 2019 at 04:57:29 UTC, Crayo List 
 wrote:
 However (for those who are unaware) there is an alternative 
 way that is (arguably) better;
 https://ispc.github.io/index.html

 You can write portable vectorized code that can be trivially 
 invoked from D.
ispc is another compiler in your build, and you'd write in another language, so it's not really the same thing.
That's mostly what I said, except that I did not say it's the same thing. It's an alternative way to produce vectorized code in a deterministic and portable way.
While you didn't say it was the same thing, you did say it's an alternative that 'is arguably better'. Adding another compiler using another language is arguably worse, so there are tradeoffs here, which Guillaume may have felt were undercommunicated (I know I did). That said, it *is* a good alternative in some cases, and may well be worth pointing out in a thread like this. -- Simen
Feb 14
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 13 February 2019 at 23:26:48 UTC, Crayo List wrote:
 On Wednesday, 13 February 2019 at 19:55:05 UTC, Guillaume 
 Piolat wrote:
 On Wednesday, 13 February 2019 at 04:57:29 UTC, Crayo List 
 wrote:
 On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume 
 Piolat wrote:
 "intel-intrinsics" is a DUB package for people interested in 
 x86 performance that want neither to write assembly, nor a 
 LDC-specific snippet... and still have fastest possible code.
This is really cool and I appreciate your efforts! However (for those who are unaware) there is an alternative way that is (arguably) better; https://ispc.github.io/index.html You can write portable vectorized code that can be trivially invoked from D.
ispc is another compiler in your build, and you'd write in another language, so it's not really the same thing.
That's mostly what I said, except that I did not say it's the same thing. It's an alternative way to produce vectorized code in a deterministic and portable way. This is NOT an auto-vectorizing compiler!
 I haven't used it (nor do I know anyone who do) so don't 
 really know why it would be any better
And that's precisely why I posted here; for those people that have interest in vectorizing their code in a portable way to be aware that there is another (arguably) better way. I highly recommend browsing through the walkthrough example; https://ispc.github.io/example.html For example, I have code that I can run on my Xeon Phi 7250 Knights Landing CPU by compiling with --target=avx512knl-i32x16, then I can run the exact same code with no change at all on my i7-5820k by compiling with --target=avx2-i32x8. Each time I get optimal code. This is not something you can easily do with intrinsics!
I don't disagree but ispc sounds more like a host-only OpenCL to me, rather than a replacement/competition for intel-intrinsics. Intrinsics are easy: if calling another compiler with another source language might be trivial, then importing a DUB package and start using it within the same source code is even more trivial! I take issue with the claim that Single Program Multiple Data yields much more performance than well written intrinsics code: when your compiler auto-vectorize (or you vectorized using SIMD semantics) you _also_ have one instruction for multiple data. The only gain I can see for SPMD would be use of non-temporal writes, since they are so hard to use effectively in practice. I also take some issue with "portability": SIMD intrinsics optimize quite deterministically (some instructions get generated since LDC 1.0.0 -O0), also LLVM IR is portable to ARM, whereas ispc will likely never as admitted by its author: https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.html My interests on AVX-512 are subnormal: it can _slow down_ things on some x86 CPUs: https://gist.github.com/rygorous/32bc3ea8301dba09358fd2c64e02d774 In general the latest instructions sets are increasingly hard to apply, and have lower yield. The newer Intel instruction sets are basically a scam for the performance-minded. Sponsored work on x265 yields really abnormally low results, rewriting things with AVX-512: https://software.intel.com/en-us/articles/accelerating-x265-with-intel-advanced-vector-extensions-512-intel-avx-512 As to compiling precisely for the host target: we are building B2C software here so don't control the host machine. Thankfully the ancient SIMD instructions sets yield most of the value! Since a lot of the time memory throughput is the bottleneck. I can see ispc being more useful when you know the precise model of your target Intel CPU. I would also like to see it compare to Intel's own software OpenCL: it seems it started its life as internal competition.
Feb 14
prev sibling parent reply Ethan <gooberman gmail.com> writes:
On Wednesday, 13 February 2019 at 23:26:48 UTC, Crayo List wrote:
 And that's precisely why I posted here; for those people that 
 have interest in vectorizing their code in a portable way to be 
 aware that there is another (arguably) better way.
All power to the people that have code that simple. But auto-vectorising in any capacity is the wrong way to do things in my field. An intrinsics library is vital to write highly specialised code. The tl;dr here is that we *FINALLY* have a minimum-spec for x64 CPUs represented with SSE intrinsics. Instead of whatever core.simd is. That's really important, and talks about auto-vectorisation are really best saved for another thread.
Feb 14
parent reply Crayo List <crayolist gmail.com> writes:
On Thursday, 14 February 2019 at 16:13:21 UTC, Ethan wrote:
 On Wednesday, 13 February 2019 at 23:26:48 UTC, Crayo List 
 wrote:
 And that's precisely why I posted here; for those people that 
 have interest in vectorizing their code in a portable way to 
 be aware that there is another (arguably) better way.
All power to the people that have code that simple. But auto-vectorising in any capacity is the wrong way to do things in my field. An intrinsics library is vital to write highly specialised code. The tl;dr here is that we *FINALLY* have a minimum-spec for x64 CPUs represented with SSE intrinsics. Instead of whatever core.simd is. That's really important, and talks about auto-vectorisation are really best saved for another thread.
Please re-read my post carefully!
Feb 14
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 14 February 2019 at 21:45:57 UTC, Crayo List wrote:
 On Thursday, 14 February 2019 at 16:13:21 UTC, Ethan wrote:
 On Wednesday, 13 February 2019 at 23:26:48 UTC, Crayo List 
 wrote:
 And that's precisely why I posted here; for those people that 
 have interest in vectorizing their code in a portable way to 
 be aware that there is another (arguably) better way.
All power to the people that have code that simple. But auto-vectorising in any capacity is the wrong way to do things in my field. An intrinsics library is vital to write highly specialised code. The tl;dr here is that we *FINALLY* have a minimum-spec for x64 CPUs represented with SSE intrinsics. Instead of whatever core.simd is. That's really important, and talks about auto-vectorisation are really best saved for another thread.
Please re-read my post carefully!
I think ispc is interesting, and a very D-ish thing to have would be an ispc-like compiler at CTFE that outputs LLVM IR (or assembly or intel-intrinsics). That would break the language boundary and allows inlining. Though probably we need newCTFE for this, as everything interesting seems to need newCTFE :) And it's a gigantic amount of work.
Feb 14
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 14, 2019 at 10:15:19PM +0000, Guillaume Piolat via
Digitalmars-d-announce wrote:
[...]
 I think ispc is interesting, and a very D-ish thing to have would be
 an ispc-like compiler at CTFE that outputs LLVM IR (or assembly or
 intel-intrinsics). That would break the language boundary and allows
 inlining. Though probably we need newCTFE for this, as everything
 interesting seems to need newCTFE :) And it's a gigantic amount of
 work.
Much as I love the idea of generating D code at compile-time and look forward to newCTFE, there comes a point when I'd really rather just run the DSL through some kind of preprocessing (i.e., compile with ispc) as part of the build, then link the result to the D code, rather than trying to shoehorn everything into (new)CTFE. T -- You have to expect the unexpected. -- RL
Feb 14
parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 14 February 2019 at 22:28:46 UTC, H. S. Teoh wrote:
 trying to shoehorn everything into (new)CTFE.
Couldn't help but find a similarity between http://www.dsource.org/projects/mathextra/browser/trunk/blade/BladeDemo.d and ispc
Feb 14
prev sibling parent Ethan <gooberman gmail.com> writes:
On Thursday, 14 February 2019 at 21:45:57 UTC, Crayo List wrote:
 Please re-read my post carefully!
Or - even better - take the hint that not every use of SIMD can be expressed in a high level manner.
Feb 14