The lack of support of native SIMD in .NET is a long pending issue that has lots of side effects: • .NET applications can't really compete with a native C++ application that is using some SSE2/NEON implicit instructions to speed up things. While SSE2 has been quite common on CPU for several years now, as well as on ARM mobile platforms. • There are several relevant use cases in the industry (At least, in the domain I know so far, Profit and Loss Risk Applications and Trading Systems, Game industry - both for Graphics and Audio applications - that would benefits a *lot* native support of SIMD in .NET, instead of having to develop an inefficient wrapper to a vectorized library. • From the visible part of the iceberg, there are several open source projects that are running their own Vectorized types but are not able to efficiently communicate between them. • Current workarounds to move vectorized calculations in a native DLL are annoying because we cannot really use fine grained API - that would lost a bit the benefits of SSE2 registers allocs on x86/x64 - so we are stuck to develop specific coarse grained APIs that don't always fit well with the layout of data in the original .NET App • With the rise of mobile applications, It is getting even more critical to have SIMD on .NET (the current generated code on ARM when using floating points calculations is verbose and unfortunately not really efficient)I know that the team in charge of it has been evaluating it/working on it for some years now (For example from this comment on connect: https://connect.microsoft.com/VisualStudio/feedback/details/716162/-net-simd, I remember also a developer of your team on some 'user voices' forum making that he would love to implement it) but the demand for such a feature is probably not high (few .NET programmers really care about performance), the amount of work required to correctly implement it has to be balanced with the visible benefits, and with things to prioritize for supporting new CLR/platforms, SIMD .NET has been always delayed until now.While we don't know what are your exact plans to hypothetically support it, I'm opening this issue in the belief that It will be closed once It is shipped! :)We would also love to hear more about your choices on how you would expose it. Among the things I'm concerned: • How would be exposed builtin vectorized types? - float4/int4/double2…etc? matrix support like float4x4 ? (that would translate to some float4 instructions would be nice as well). Quid of float3 types that don't map directly to a type but that could be helpful (though a HLSL compiler for example is able to use the remaining w float to store it when calculating, but afair, SSE2 is less practical with that) • How accessing shuffle instructions would work?, would be pretty handy to be able to express them like in HLSL, 'myfloat4.xxzx' • How would work to manage aligned and unaligned loading into SIMD vectors? • A breaking change in the CLR to support it at the IL bytecode level would be even fine, If it makes JIT & offline compiler analysis easier and faster • Auto-vectorized is less critical SIMD support builtin in .NET would help .NET platform to be much more attract full for lots of developers & applications!
Visual Studio/Team Foundation Server/.NET Framework Tooling Version
Steps to reproduce
Operating System Language