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

Support 32bit benchmarks for .NET Core #310

Closed
AndreyAkinshin opened this Issue Nov 30, 2016 · 6 comments

Comments

Projects
None yet
2 participants
@AndreyAkinshin
Member

AndreyAkinshin commented Nov 30, 2016

No description provided.

@adamsitnik

This comment has been minimized.

Show comment
Hide comment
@adamsitnik

adamsitnik Dec 26, 2016

Member

I did some tests today.

It's possible to get x86 working, but only for Windows.
Issue in CoreCLR for porting x86 to Linux.

Getting it working on Windows today: I have noticed that dotnet cli which we rely on has huge limitation (dnx did not have it!): every project.json based project targets x64 by default. We can not tatget x64 from x86 programs, so as long as we don't set up "platform": "x86", in the project that contains benchmarks it's impossible to get it working (bad image exception) ;) We can do this for auto-generated project.json, but not for the one that contains benchmarks.

I will wait with further work until Roslyn 2.0 goes RTM. Then I plan to move from dotnet cli as our build engine to Roslyn. We should be able to get it working then.

Member

adamsitnik commented Dec 26, 2016

I did some tests today.

It's possible to get x86 working, but only for Windows.
Issue in CoreCLR for porting x86 to Linux.

Getting it working on Windows today: I have noticed that dotnet cli which we rely on has huge limitation (dnx did not have it!): every project.json based project targets x64 by default. We can not tatget x64 from x86 programs, so as long as we don't set up "platform": "x86", in the project that contains benchmarks it's impossible to get it working (bad image exception) ;) We can do this for auto-generated project.json, but not for the one that contains benchmarks.

I will wait with further work until Roslyn 2.0 goes RTM. Then I plan to move from dotnet cli as our build engine to Roslyn. We should be able to get it working then.

@adamsitnik

This comment has been minimized.

Show comment
Hide comment
@adamsitnik

adamsitnik Feb 23, 2017

Member

@AndreyAkinshin tried that today with the new "msbuild" based dotnet cli. IMHO It's still too many workarounds to give it a go

<PlatformTarget>x86</PlatformTarget>
<RuntimeIdentifier Condition=" '$(PlatformTarget)' == 'x86' ">win7-x86</RuntimeIdentifier>

so it works only for Windows and in order to execute the project you need to call dotnet run which rebuilds the project again, which does not work good for us (we perform dotnet $pathToDll which does not compile it again)

Member

adamsitnik commented Feb 23, 2017

@AndreyAkinshin tried that today with the new "msbuild" based dotnet cli. IMHO It's still too many workarounds to give it a go

<PlatformTarget>x86</PlatformTarget>
<RuntimeIdentifier Condition=" '$(PlatformTarget)' == 'x86' ">win7-x86</RuntimeIdentifier>

so it works only for Windows and in order to execute the project you need to call dotnet run which rebuilds the project again, which does not work good for us (we perform dotnet $pathToDll which does not compile it again)

@adamsitnik adamsitnik changed the title from LegacyJitX86Job doesn't work in CoreCLR projects to Support 32bit benchmarks for .NET Core Feb 23, 2017

@adamsitnik adamsitnik added enhancement and removed bug labels Feb 23, 2017

@adamsitnik adamsitnik modified the milestones: v0.10.10, v0.10.x Aug 26, 2017

@AndreyAkinshin

This comment has been minimized.

Show comment
Hide comment
@AndreyAkinshin

AndreyAkinshin Aug 27, 2017

Member

@adamsitnik, please check the appveyor build, it's red after your last commit.

Member

AndreyAkinshin commented Aug 27, 2017

@adamsitnik, please check the appveyor build, it's red after your last commit.

@adamsitnik

This comment has been minimized.

Show comment
Hide comment
@adamsitnik

adamsitnik Aug 28, 2017

Member

@AndreyAkinshin sorry!

btw the reason for fail:

Previously we were hardcoding x64 for .NET Core benchmarks. Now it's configurable.

But when the Platform is not specified we take the default value. The default is AnyCpu, but it's overwritten by EnvResolver, which registers the host process platform as the default (Register(EnvMode.PlatformCharacteristic, RuntimeInformation.GetCurrentPlatform);)

The problem here was that for this particular test we had classic .NET test runner, 32bit, which was trying to build and run 32bit .NET Core process on the machine without 32bit .NET Core sdk.

I was not sure if we should still register the host platform as default, but I decided to not break the behavior and leave it the way it is and just set the platform in explicit way for this particular test.

Member

adamsitnik commented Aug 28, 2017

@AndreyAkinshin sorry!

btw the reason for fail:

Previously we were hardcoding x64 for .NET Core benchmarks. Now it's configurable.

But when the Platform is not specified we take the default value. The default is AnyCpu, but it's overwritten by EnvResolver, which registers the host process platform as the default (Register(EnvMode.PlatformCharacteristic, RuntimeInformation.GetCurrentPlatform);)

The problem here was that for this particular test we had classic .NET test runner, 32bit, which was trying to build and run 32bit .NET Core process on the machine without 32bit .NET Core sdk.

I was not sure if we should still register the host platform as default, but I decided to not break the behavior and leave it the way it is and just set the platform in explicit way for this particular test.

@AndreyAkinshin

This comment has been minimized.

Show comment
Hide comment
@AndreyAkinshin

AndreyAkinshin Aug 28, 2017

Member

An idea about the "x86 vs x32" .NET Core problem: we can detect all available dotnet.exe (e.g. via where dotnet, it should be available on all modern versions of Windows). Next, we can check the architecture of each dotnext.exe (e.g. like this, it works perfectly for C:\Program Files\dotnet\dotnet.exe and C:\Program Files (x86)\dotnet\dotnet.exe on my Windows 10). Finally, we can use dotnet.exe which is matched to the user config (or print a message that says something like "sorry, we didn't find appropriate runtime").
@adamsitnik, what do you think?

Member

AndreyAkinshin commented Aug 28, 2017

An idea about the "x86 vs x32" .NET Core problem: we can detect all available dotnet.exe (e.g. via where dotnet, it should be available on all modern versions of Windows). Next, we can check the architecture of each dotnext.exe (e.g. like this, it works perfectly for C:\Program Files\dotnet\dotnet.exe and C:\Program Files (x86)\dotnet\dotnet.exe on my Windows 10). Finally, we can use dotnet.exe which is matched to the user config (or print a message that says something like "sorry, we didn't find appropriate runtime").
@adamsitnik, what do you think?

@AndreyAkinshin

This comment has been minimized.

Show comment
Hide comment
@AndreyAkinshin

AndreyAkinshin Aug 28, 2017

Member

I copy-pasted the last comment to #534, let's continue this discussion there.

Member

AndreyAkinshin commented Aug 28, 2017

I copy-pasted the last comment to #534, let's continue this discussion there.

alinasmirnova added a commit to alinasmirnova/BenchmarkDotNet that referenced this issue Sep 22, 2018

alinasmirnova added a commit to alinasmirnova/BenchmarkDotNet that referenced this issue Sep 22, 2018

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