KEMBAR78
Investigate what would be required to move some SIMD functionality out of the JIT and into managed code · Issue #102275 · dotnet/runtime · GitHub
Skip to content

Investigate what would be required to move some SIMD functionality out of the JIT and into managed code #102275

@tannergooding

Description

@tannergooding

Historically a number of types (such as Vector2, Vector3, and Vector4) have had their functionality implemented as Intrinsic in the JIT. This was done for many reasons, but primarily for performance of these types that are known to be used in perf critical workloads since the JIT needed to generate specialized instructions that were otherwise not accessible.

Since then, we've had a broad range of support exposed around platform specific hardware intrinsic APIs and it is now possible to implement many of these other APIs purely in managed code. However, this has not been done due to concerns that it may regress perf. This concern is particularly relevant in complex algorithms where the inliner may decide that it is out of budget and no longer tries to optimize this code.

It would be beneficial to actually prototype the work of moving some of these implementations out of the JIT and purely into managed code. This should let us see what in the JIT may still be getting pessimized and work towards fixing it. The long term benefits of moving the complexity into managed are then substantial:

  • The JIT becomes simpler/smaller
  • Multiple runtimes no longer need to do the work to optimize these additional APIs, they only need to support the xplat APIs
  • Users can more readily debug the code being executed and contribute improvements themselves
    • Such fixes/improvements are also much lower risk
  • Pain points that end users may encounter become more readily identifiable to the team, allowing fixes to be provided
  • etc

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions