Skip to content

Revise how constant SIMD vectors are defined #1762

Description

@gfoidl

Starting with .NET 5 the JIT emits code to read constant SIMD vectors from the data section which gives nice machine code and some related advantages like the ones listed in #1761 (comment).
See also dotnet/runtime#44115 for more context on that issue.

But changing the usage of constant vectors to the "inline variant" will regress pre .NET 5 targets, thus it seems best to keep current code with static readonlys, and update to the inline variant once .NET Core 3.1 will go out of support on 3rd Dec 2022 (the purpose of this issue is to have a remainder for that task).

Activity

  1. antonfirsov commented on Sep 14, 2021

    @antonfirsov
    Member

    3rd Dec 2022 is pretty far, ideally we will release ImageSharp 3.0 before that, and personally I wouldn't remove .NET Core 3.1 support without bumping ImageSharp's major version, so I'm afraid it's not anything for the near future.

    Would an inclined property be equivalent of "inline vector create"? Can we do a trick like following?

    #if NET5_OR_NEWER
    private static Vector256<float> Constant =>  Vector256.Create(0.707106781f);
    #else
    private static readonly  Vector256<float> Constant = Vector256.Create(0.707106781f);
    #endif

    I would only do it if there is measurable benefit justifying the increased complexity.

  2. gfoidl commented on Sep 14, 2021

    @gfoidl
    ContributorAuthor

    The trick seems to work (at least for simple cases, where it's easy for the JIT to inline the property).

    But, similar as you wrote, this makes the code awful to read. So I wouldn't do this now and keep the code that works for .NET Core 3.1 and .NET 5 onwards.
    Once .NET 3.1 support will be dropped, this issue should be addressed in a batch-change. Code remains clean now and then.

    wouldn't remove .NET Core 3.1 support without bumping ImageSharp's major version, so I'm afraid it's not anything for the near future.

    Agree.

  3. br3aker commented on Sep 14, 2021

    @br3aker
    Contributor

    I would only do it if there is measurable benefit justifying the increased complexity.

    There's no benefit, at least in microbenchmarking: #1761 (comment).
    While this does indeed produce better code it won't really change anything globally so I guess waiting for the end of core 3.1 is the way to go.

  4. added this to the Future milestone on Sep 14, 2021
  5. JimBobSquarePants commented on May 13, 2022

    @JimBobSquarePants
    Member

    We're .NET 6 now so if someone wants to update the code to reflect the new pattern you have my blessing.

  6. gfoidl commented on May 13, 2022

    @gfoidl
    ContributorAuthor

    I can look into this next week.

  7. JimBobSquarePants commented on May 13, 2022

    @JimBobSquarePants
    Member

    Awesome @gfoidl thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions