Click here to Skip to main content
15,900,511 members

Welcome to the Lounge

   

For discussing anything related to a software developer's life but is not for programming questions. Got a programming question?

The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.

 
JokeRe: Indeed I was... Pin
Jeremy Falcon25-Jan-17 10:31
professionalJeremy Falcon25-Jan-17 10:31 
GeneralRe: Indeed I was... Pin
User 483504725-Jan-17 12:03
User 483504725-Jan-17 12:03 
GeneralRe: Indeed I was... Pin
CDP180225-Jan-17 13:00
CDP180225-Jan-17 13:00 
GeneralRe: Indeed I was... Pin
Nagy Vilmos25-Jan-17 12:20
professionalNagy Vilmos25-Jan-17 12:20 
GeneralRe: Indeed I was... Pin
PIEBALDconsult25-Jan-17 13:02
mvePIEBALDconsult25-Jan-17 13:02 
GeneralRe: Indeed I was... Pin
W Balboos, GHB26-Jan-17 0:35
W Balboos, GHB26-Jan-17 0:35 
GeneralRe: Indeed I was... Pin
Mark_Wallace26-Jan-17 1:11
Mark_Wallace26-Jan-17 1:11 
RantSystem.Numerics.Vectors sucks Pin
harold aptroot25-Jan-17 7:54
harold aptroot25-Jan-17 7:54 
The matrix4x4, plane and quaternion types are alright. Sort of. Except that they automatically encourage AoS layout. But the general purpose Vector and Vector<t> (why does the linkifier lowercase my T?) are horrible. At a first glance, those pages seem a little short (for SIMD anyway). That's because there are almost no functions to list.

But when you look at what's actually missing, it gets worse. A lot worse.

Before anyone comments "it's designed that way for portability" - yes, maybe, but that is no excuse for designing something that's useless on all architectures. There are ways they could have given us something that isn't useless, one suggestion is at the bottom.

No width-converting casts!

That's right, you can only reinterpret cast a vector (which is certainly a necessary operation, though it is made more necessary than necessary(?) here because they made signedness part of the type). Certainly, it is preferred to not widen your data, for obvious reasons: if you make the data twice as wide, half as much of it fits in a vector, half as much gets done per instruction. But often there's just no avoiding it, especially with 8 bit data, which you often have to process in 16-bit fixed-point, more about that later.

There are no shuffles either, which could have been used to "fake" width conversions, but are generally necessary for almost any SIMD task that isn't strictly vertical. Now I get it, having both shuffles and variable-with vectors is really hard, probably impossible in general. So here's the solution: don't have variable width vectors. Just let me pick 128 or 256 when I write the code, yes it won't auto-upgrade to a bigger width on newer platforms but it is necessary in order to have any code in the first place. There's no point in having fancy future-compatible things if you can't use them.

Also that means there can be no pshufb tricks, which I admit aren't actually common.. but when you need it, you need it. You can forget about compacting an array after filtering it, for example. Actually you can't even do the "extract mask" part of that technique.

No special instructions, with "special" meaning "anything that isn't just like repeating a C# operator for a bunch of elements". Ok, there is ConditionalSelect. But where is Multiply High? Add with Saturation? Sum of Absolute Differences? Mask of Sbyte Signs? Mask of float signs? Multiply and Add Packed Signed and Unsigned Bytes? Average? Approximate Reciprocal Square Root? The list goes on.

Many of these are useful in part to avoid widening - eg I might have (with a bad conscience) simulated a 16 bit multiply-high (which is an extremely common operation, a lot of SIMD code does fixed-point arithmetic) by widening to 32bit and using a "normal" 32x32 multiply (ie vpmulld - which has extra bad throughput on top of handling half the elements that a 16bit highmul would), but I can't even do that because .. did I mention no width-converting casts? So what am I going to do, waste half of my memory throughput on padding? What if the source format inherently doesn't have it, write a non-SIMD loop to convert? All that, remember, just to enable code that is already severely sub-standard.

Some operations, such as average or add-with-saturation, can be implemented if you really need them - but in a way that thoroughly sucks, both for code-clarity and performance, all while there is a nice fast instruction to do it that could have had a nice clear intrinsic function paired with it.

Reasonable support for fixed-point arithmetic and saturation are crucial, they are everywhere in multimedia computations, but System.Numerics.Vectors has essentially no support for them.

It gets weirder: there aren't even bit-shifts. This one is just really random. Yes, per-lane-variable shifts are an AVX2 thing (but so what, they allow a bunch more stuff that has to be emulated), but shift-by-scalar should definitely exist. "Just write a multiplication or division" - yes well, that's just obfuscating the code. Plus, signed right shift works differently than signed division.

Meanwhile it's legal to request operations that cannot be implemented in a reasonable way, such as regular 8x8 or 64x64 multiplication. That just doesn't exist in SSE up through AVX2. I haven't looked at how it's emulated, but it can't be anything nice, because there is no nice way to do it. And then there are integer divisions and square roots.. The API falls victim to its overly orthogonality - which normally would be a nice property, but if the instruction set doesn't offer it, offering it in the API is not "being nice and filling the hole", it's setting a performance trap for unsuspecting programmers who aren't used to the peculiarities of the instruction set.

Here's what you can do with System.Numerics.Vectors:
  • compositions of nice clean purely-vertical maps
  • simple reductions
  • combinations of the above
Which is the sort of thing that the compiler could do (it doesn't, but it could, offline compilers are doing it - inb4 "JIT latency"), and will do* if you quickly make a C(++) dll project on the side and PInvoke that. As a bonus you can then also write proper SIMD code the way god Intel intended.

*: if you're using a new enough MSVC (so not 2010 or older), or if you use Clang/GCC/ICC/whatever, anything that has auto-vectorization.

How should it work instead of this mess? My first thought is, don't invent anything new, just put in the widely accepted sets of SIMD intrinsics for SSE through AVX2 under an X64 class, and the NEON intrinsics under an ARM class (and whatever else, though I don't imagine many would care about IA64 intrinsics for example). Add some nice feature-level checks too, instead of letting everyone always re-implement them on top of CPUID. This has problems (mainly readability, code with the usual SSE intrinsics looks uglier than the corresponding assembly code) and even a few "missing" bits itself, but they are at least problems that the community is used to and can deal with, not huge deal breakers.

Maybe there are better (better at what? you decide) ways to fix the System.Numerics.Vectors mess, so, let's discuss it.

I have probably forgotten things or made mistakes so I'll probably make some edits
GeneralRe: System.Numerics.Vectors sucks Pin
BillWoodruff25-Jan-17 18:09
professionalBillWoodruff25-Jan-17 18:09 
GeneralRe: System.Numerics.Vectors sucks Pin
harold aptroot27-Jan-17 2:47
harold aptroot27-Jan-17 2:47 
GeneralTWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
Kornfeld Eliyahu Peter25-Jan-17 7:23
professionalKornfeld Eliyahu Peter25-Jan-17 7:23 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
Marc Clifton25-Jan-17 7:31
mvaMarc Clifton25-Jan-17 7:31 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
Kornfeld Eliyahu Peter25-Jan-17 7:35
professionalKornfeld Eliyahu Peter25-Jan-17 7:35 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
OriginalGriff25-Jan-17 8:48
mveOriginalGriff25-Jan-17 8:48 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
Marc Clifton25-Jan-17 9:00
mvaMarc Clifton25-Jan-17 9:00 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
OriginalGriff25-Jan-17 9:19
mveOriginalGriff25-Jan-17 9:19 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
TonyManso25-Jan-17 12:19
professionalTonyManso25-Jan-17 12:19 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
OriginalGriff25-Jan-17 22:08
mveOriginalGriff25-Jan-17 22:08 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
OriginalGriff25-Jan-17 8:49
mveOriginalGriff25-Jan-17 8:49 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
#realJSOP25-Jan-17 7:49
professional#realJSOP25-Jan-17 7:49 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
PIEBALDconsult25-Jan-17 7:54
mvePIEBALDconsult25-Jan-17 7:54 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
Kornfeld Eliyahu Peter25-Jan-17 7:54
professionalKornfeld Eliyahu Peter25-Jan-17 7:54 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
OriginalGriff25-Jan-17 8:00
mveOriginalGriff25-Jan-17 8:00 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
Nelek25-Jan-17 11:00
protectorNelek25-Jan-17 11:00 
GeneralRe: TWCP OTD (The Who Cares Puzzle Of The Day) - 25th of January, 2017 Pin
Dan Neely26-Jan-17 2:38
Dan Neely26-Jan-17 2:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.


Straw Poll

Were you affected by the geomagnetic storms this past weekend?
Communication disruptions, electrified pipes, random unexplained blue-screens in Windows - the list of effects is terrifying.
  Results   489 votes