-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Allow CpuMath to reference C# Hardware Intrinsics APIs. #542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Need to multi-target CpuMath for netstandard and netcoreapp3.0. Also, since we are going to move CpuMath into its own NuGet package, remove the dependency from CpuMath to the ML.Core project. Add a build parameter to enable building against .NET Core 3.0's Runtime Intrinsics APIs. Fix dotnet#534
src/Native/build.proj
Outdated
</ItemGroup> | ||
<ItemGroup Condition="'$(UseIntrinsics)' == 'true'"> | ||
<NativePackageAsset Include="$(NativeAssetsBuiltPath)\$(NativeLibPrefix)CpuMathNative$(NativeLibExtension)" | ||
RelativePath="Microsoft.ML.CpuMath\runtimes\$(PackageRid)\lib\netstandard2.0" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't put native files under lib. .NETCore will not like this. For native libraries that must be constrained by both tfm and RID use nativeassets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, perfect. I was unaware of this and looked on the docs, but didn't find it.
Thanks for the info. I'll make the switch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I poked the doc issue on it.
|
||
<PropertyGroup> | ||
<TargetFramework>netstandard2.0</TargetFramework> | ||
<IncludeInPackage>Microsoft.ML</IncludeInPackage> | ||
<Configurations>Debug;Release;Debug-Intrinsics;Release-Intriniscs</Configurations> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who sets this configuration?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note: "Release-Intriniscs" could probably be "Release-Intrinsics".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@briancylui - nice catch.
@ericstj - the idea is that this build switch is turned off by default. While developing his feature, @briancylui can switch VS to use these 2 new configurations using the configuration manager to build/run tests locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, and you aren't going to turn it on in CI or official build yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For sure, "no" for official build. I don't want to affect the official product until we are ready to affect it (3.0 doesn't even have a preview out yet, so getting it into customers hands isn't a critical concern for me).
We will eventually turn CI on for it, especially as we move closer to wanting to put it in the official product.
Hi @eerhardt ! So, I might have expected that there would be some factoring out of There's something just a little unsettling about having this sort of multiplicative effect of "doubling" the number of targets, since it seems like a similar doubling would occur every time we have a situation where we want to exploit special functionality in some .NET non-Standard (in this case .NET Core 3.0 I guess?). Is this really the best way? |
This is definitely a temporary measure to unblock @briancylui while still allowing the existing devs and users to develop and consume the NuGet packages as they do today. Typically, the way multi-targeting works is that a .csproj would just have to say The issue lies in that we need to target Now the question becomes: How to set
It felt like VS Configurations were the most natural way to enable this (just like Debug vs. Release builds - all they really do is change some msbuild properties, which then affects what the compiler does).
I agree doubling each time is not a great experience. Eventually, when we officially support .NET Core 3.0, these configurations will go away, and the C# intrinsics will be compiled by default. |
All right that sounds fine @eerhardt ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @eerhardt and @briancylui
src/Native/build.proj
Outdated
@@ -78,9 +78,9 @@ | |||
</ItemGroup> | |||
<ItemGroup Condition="'$(UseIntrinsics)' == 'true'"> | |||
<NativePackageAsset Include="$(NativeAssetsBuiltPath)\$(NativeLibPrefix)CpuMathNative$(NativeLibExtension)" | |||
RelativePath="Microsoft.ML.CpuMath\runtimes\$(PackageRid)\lib\netstandard2.0" /> | |||
RelativePath="Microsoft.ML.CpuMath\runtimes\$(PackageRid)\nativeassets\netstandard2.0" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't nativeassets be under x86
, x64
, or arm
folders (rather than netstandard2.0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CpuMathNative native binaries are under both RID
and TFM
folders. Both RID
and TFM
can be used to decide which asset to be picked. NuGet supports pivoting on both of these properties.
runtimes\$(Rid)\nativeassets\$(Tfm)
The idea is that on netcoreapp3.0
, we won't even need this native binary, because it will no longer be called. All of the logic in it will be replaced with C# intrinsic methods.
So, when running on a non-netcoreapp3.0 platform (like .NET Core 2.1, or netfx), use the CpuMathNative native binary for the appropriate RID
. But when running on netcoreapp3.0
, we use a placeholder _._
file to tell NuGet no asset should be picked (since we don't need a native asset on this TFM).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I missed the rid
section, which covers the bitness of the architecture
👍
* Allow CpuMath to reference C# Hardware Intrinsics APIs. Need to multi-target CpuMath for netstandard and netcoreapp3.0. Also, since we are going to move CpuMath into its own NuGet package, remove the dependency from CpuMath to the ML.Core project. Add a build parameter to enable building against .NET Core 3.0's Runtime Intrinsics APIs. Fix dotnet#534 * Respond to PR feedback.
* Allow CpuMath to reference C# Hardware Intrinsics APIs. Need to multi-target CpuMath for netstandard and netcoreapp3.0. Also, since we are going to move CpuMath into its own NuGet package, remove the dependency from CpuMath to the ML.Core project. Add a build parameter to enable building against .NET Core 3.0's Runtime Intrinsics APIs. Fix dotnet#534 * Respond to PR feedback.
Need to multi-target CpuMath for netstandard and netcoreapp3.0. Also, since we are going to move CpuMath into its own NuGet package, remove the dependency from CpuMath to the ML.Core project.
Add a build parameter to enable building against .NET Core 3.0's Runtime Intrinsics APIs.
Fix #534