-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Arm build changes #5789
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
Arm build changes #5789
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5789 +/- ##
==========================================
- Coverage 68.35% 68.32% -0.04%
==========================================
Files 1131 1131
Lines 241210 241292 +82
Branches 25039 25053 +14
==========================================
- Hits 164887 164860 -27
- Misses 69819 69928 +109
Partials 6504 6504
Flags with carried forward coverage won't be shown. Click here to find out more.
|
@@ -16,7 +16,7 @@ | |||
</ProjectReference> | |||
|
|||
<NativeAssemblyReference Include="MatrixFactorizationNative" /> | |||
<NativeAssemblyReference Include="FastTreeNative" /> | |||
<NativeAssemblyReference Condition="'$(TargetArchitecture)' != 'arm64' And '$(TargetArchitecture)' != 'arm'" Include="FastTreeNative" /> |
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 wonder if we can create a helper property in Directory.Build.props $(TargetsArm)
or similar. Then we don't need this duplicated everywhere.
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.
Yep, good idea. I'll go ahead and do that.
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.
Ok I have added this. Take a look and see if it was what you were thinking. @safern can you take a look as well since you know msbuild really well? Directory.Build.props
lines 30 - 37.
@@ -4,7 +4,8 @@ | |||
<TargetFramework>netstandard2.0</TargetFramework> | |||
<IncludeInPackage>Microsoft.ML.FastTree</IncludeInPackage> | |||
<PackageDescription>ML.NET component for FastTree</PackageDescription> | |||
<DefineConstants>$(DefineConstants);USE_FASTTREENATIVE;NO_STORE;CORECLR</DefineConstants> | |||
<DefineConstants>$(DefineConstants);NO_STORE;CORECLR</DefineConstants> | |||
<DefineConstants Condition="'$(TargetArchitecture)' != 'arm64' And '$(TargetArchitecture)' != 'arm'">$(DefineConstants);USE_FASTTREENATIVE</DefineConstants> |
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 don't think this is going to work. We only put 1 managed Microsoft.ML.FastTree.dll in our NuGet package.
We will either need to build the C# code twice, and include each in a RID-specific section of the NuGet package.
Or we will need to continue building the C# code once, and then have a switch at runtime whether we are running on ARM or not.
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.
Good point. I think that having the runtime switch is better. Instead of checking if we are running on arm or not I'll just check if the native dll is present or not. That way even blazer would work with this.
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.
Alright, I have added a runtime switch for this. It uses a delegate to pick between the native/managed version so it shouldn't have any performance impact, but if you could take a look I would appreciate it. I am gonig to run the benchmark tests before/after as well.
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.
So the benchmarks are basically identical speedwise before and after these changes. I had our benchmark run 30 times and the mean of the current code and the new code are within .15 seconds of each other on my local machine. So there shouldn't be noticeable performance impact from doing it this way.
test/Microsoft.Extensions.ML.Tests/Microsoft.Extensions.ML.Tests.csproj
Outdated
Show resolved
Hide resolved
test/Microsoft.ML.AutoML.Tests/Microsoft.ML.AutoML.Tests.csproj
Outdated
Show resolved
Hide resolved
Directory.Build.targets
Outdated
</ItemGroup> | ||
|
||
<Copy SourceFiles = "@(NativeAssemblyReference->'%(FullAssemblyPath)')" | ||
<PropertyGroup> | ||
<ShouldCopyx64>false</ShouldCopyx64> |
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'm not sure I understand the value of these properties. What other target architectures do we have beside x86, x64, arm64, or arm?
These properties appear to only be used in the below Copy, and as far as I can tell, that condition is always true.
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.
Oh, I see now, this is to support copying LdaNative
and MatrixFactorizationNative
assemblies on arm, but not the other native files.
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.
Correct. I figured we could also use this same pattern when we get to blazer WASM. Though I guess we can't really copy any native files there... so maybe this was a bit overkill.
"%CMakePath%" "-DCMAKE_BUILD_TYPE=%CMAKE_BUILD_TYPE%" "-DCMAKE_INSTALL_PREFIX=%__CMakeBinDir%" "-DMKL_LIB_PATH=%MKL_LIB_PATH%" -G "Visual Studio %__VSString%" %__ExtraCmakeParams% -B. -H%1 | ||
if /i "%3" == "arm64" (set __ExtraCmakeParams=%__ExtraCmakeParams% -A arm64) | ||
if /i "%3" == "arm" (set __ExtraCmakeParams=%__ExtraCmakeParams% -A arm) | ||
"%CMakePath%" "-DCMAKE_BUILD_TYPE=%CMAKE_BUILD_TYPE%" "-DCMAKE_INSTALL_PREFIX=%__CMakeBinDir%" "-DMKL_LIB_PATH=%MKL_LIB_PATH%" "-DARCHITECTURE=%3" -G "Visual Studio %__VSString%" %__ExtraCmakeParams% -B. -H%1 |
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.
Why do we need both -DARCHITECTURE
and -A
above? Can we just use 1 command line arg to set the archiecture?
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.
So the -A
doesn't work on the Unix Makefile Generator, but that is how you set the architecture correctly for visual studio. I needed a way in the cmakelists file to be able to exclude native projects for both generators, and thats how I ended up with the -DARCHITECTURE
. I'm sure there is a way I could use only the -A
in visual studio and not need the -DARCHITECTURE
, I just haven't been able to figure it out yet. We will always need -DARCHITECTURE
for the Unix generator, its just if we can remove it from the visual studio one.
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.
Have you looked how it is done in other repos? For example dotnet/runtime
?
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'm checking that out right now. They pass the -arch
flag. Thats a custom flag. I'm still investigating how they plumb it internally.
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.
That eventually turns into this /p:TargetArchitecture=$arch
. Still looking into how thats passed to the native side of things.
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.
So it actually looks like they do the same thing.
https://github.com/dotnet/runtime/blob/e4b4807e2fae2164d9116fbcdd49ba9044461e7e/eng/native/gen-buildsys.cmd#L34 they set the -A
same way I do.
https://github.com/dotnet/runtime/blob/e4b4807e2fae2164d9116fbcdd49ba9044461e7e/src/coreclr/build-runtime.cmd#L450 they a flag -DCLR_CMAKE_TARGET_ARCH
which is used the same why I am using the ARCHITECTURE
flag. They do more complex stuff with it than we do since they target so many things, but its the same idea.
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.
Sounds good. Thanks for verifying.
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.
Just one minor question remaining. After answering that, this LGTM.
Nice work here!
* arm testing * initial commit with build working on arm64 * windows changes * build fixes for arm/arm64 with cross compilation * cross build instructions added * renamed arm to Arm. Changed TargetArchitecture to default to OS architecture * fixed some formatting * fixed capitilization * fixed Arm Capitilization * Fix cross-compilation if statement * building on apple silicon * removed non build related files * Changes from PR comments. Removal of FastTreeNative flag. * Changes from pr comments. * Fixes from PR comments. * Changed how we are excluding files.
…#5796) * Raised the limit of recursions in the creation of the CodedInputStream in the OnnxTransformer (as the default value in the Google.Protobuf). Otherwise some models cannot be loaded (ex. TF2 Efficentdet). * Updated arcade to the latest version (#5783) * updated arcade to the latest version * updated eng/common correctly * Fixed benchmark test. * Use dotnet certificate (#5794) * Use dotnet certificate * Update 3.1 SDK Co-authored-by: Prashanth Govindarajan <[email protected]> Co-authored-by: Michael Sharp <[email protected]> * Arm build changes (#5789) * arm testing * initial commit with build working on arm64 * windows changes * build fixes for arm/arm64 with cross compilation * cross build instructions added * renamed arm to Arm. Changed TargetArchitecture to default to OS architecture * fixed some formatting * fixed capitilization * fixed Arm Capitilization * Fix cross-compilation if statement * building on apple silicon * removed non build related files * Changes from PR comments. Removal of FastTreeNative flag. * Changes from pr comments. * Fixes from PR comments. * Changed how we are excluding files. * Onnx load model (#5782) * fixed onnx temp model deleting * random file path fixed * updates from pr * Changes from PR comments. * Changed how auto ml caches. * PR fixes. * Update src/Microsoft.ML.AutoML/API/ExperimentSettings.cs Co-authored-by: Eric Erhardt <[email protected]> * Tensorflow fixes from PR comments * fixed filepath issues Co-authored-by: Eric Erhardt <[email protected]> Co-authored-by: Michael Sharp <[email protected]> Co-authored-by: Matt Mitchell <[email protected]> Co-authored-by: Prashanth Govindarajan <[email protected]> Co-authored-by: Eric Erhardt <[email protected]>
Changes that allow building for arm/arm64/apple silicon, as well as cross targeting to those same architectures.
Tests don't pass on those architectures yet, this is just enabling building. Anything that doesn't depend on x86/64 SIMD or IntelMKL works correctly.