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

DissassemblyDiagnoser jit/arch info seems to be wrong #559

Closed
JosephTremoulet opened this Issue Sep 27, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@JosephTremoulet

JosephTremoulet commented Sep 27, 2017

I'm using build 0.10.9.313, running on .NET Core, with a config and BencmarkRunner invocation that look like so:

    class PreviewVs20Config : ManualConfig
    {
        public PreviewVs20Config()
        {
            // .NET Core 2.0
            Add(Job.Default.With(CsProjCoreToolchain.NetCoreApp20));

            // Daily preview build, 2.1.0-preview2-25616-02
            Add(Job.Default.With(CsProjCoreToolchain.From(new NetCoreAppSettings("netcoreapp2.1", "2.1.0-preview1-25719-04", ".NET Core 2.1.0-preview1-25719-04"))));

            // Show disassembly when run
            Add(DisassemblyDiagnoser.Create(new DisassemblyDiagnoserConfig(printAsm: true, printPrologAndEpilog: true, recursiveDepth: 0)));
        }
    }

    [Config(typeof(PreviewVs20Config))]
    public class Bench
    {
        [Benchmark]
        // (benchmark method here)

        static void Main(string[] args)
        {
            BenchmarkRunner.Run<Bench>();
        }
    }

and using a csproj set to compile for these target frameworks like so:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp2.0;netcoreapp2.1</TargetFrameworks>
    <RuntimeFrameworkVersion Condition="'$(TargetFramework)'=='netcoreapp2.1'">2.1.0-preview1-25719-04</RuntimeFrameworkVersion>
    <NETStandardImplicitPackageVersion Condition="'$(TargetFramework)'=='netcoreapp2.1'">2.1.0-preview1-25719-04</NETStandardImplicitPackageVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="BenchmarkDotNet" Version="0.10.9.313" />
  </ItemGroup>
</Project>

When I run the app (with dotnet run -c release -f netcoreapp2.1), the console output shows that I am running using x64 RyuJIT, as I'd expect:

BenchmarkDotNet=v0.10.9.313-nightly, OS=Windows 10 Redstone 2 [1703, Creators Update] (10.0.15063)
Processor=Intel Core i7-4790 CPU 3.60GHz (Haswell), ProcessorCount=8
Frequency=3507517 Hz, Resolution=285.1020 ns, Timer=TSC
.NET Core SDK=2.1.0-preview1-007228
  [Host]     : .NET Core 2.1.0-preview1-25719-04 (Framework 4.6.25718.02), 64bit RyuJIT
  Job-DGTXXY : .NET Core 2.0.0 (Framework 4.6.00001.0), 64bit RyuJIT
  Job-JYNJAP : .NET Core 2.1.0-preview1-25719-04 (Framework 4.6.25718.02), 64bit RyuJIT

but the generated disassembly-report.html file says "LegacyJit AnyCpu", which seems incorrect (at least the "LegacyJit part"):

<table>
<thead>
<tr><th colspan="2">Bench.TestMethod</th></tr>
<tr>
<th>LegacyJit AnyCpu  .NET Core 2.0</th>
<th>LegacyJit AnyCpu  .NET Core 2.1.0-preview1-25719-04</th>
</tr>
</thead>

/cc @adamsitnik

@adamsitnik

This comment has been minimized.

Show comment
Hide comment
@adamsitnik

adamsitnik Sep 27, 2017

Member

hello @JosephTremoulet

It's quite simple bug, you can ignore it and I am going to fix it tomorrow.

Our Jit enum has LegacyJit as the first (default) value, so if the user does not set Jit in explicit way and we use Jit property we get LegacyJit. It your case it's not affecting the asm, only the html shows wrong text.

Sorry for the inconvenience

Member

adamsitnik commented Sep 27, 2017

hello @JosephTremoulet

It's quite simple bug, you can ignore it and I am going to fix it tomorrow.

Our Jit enum has LegacyJit as the first (default) value, so if the user does not set Jit in explicit way and we use Jit property we get LegacyJit. It your case it's not affecting the asm, only the html shows wrong text.

Sorry for the inconvenience

@adamsitnik

This comment has been minimized.

Show comment
Hide comment
@adamsitnik

adamsitnik Sep 27, 2017

Member

As a workaround you can call Job.With(Jit.RyuJit) in your config.

Member

adamsitnik commented Sep 27, 2017

As a workaround you can call Job.With(Jit.RyuJit) in your config.

@adamsitnik adamsitnik self-assigned this Sep 27, 2017

@JosephTremoulet

This comment has been minimized.

Show comment
Hide comment
@JosephTremoulet

JosephTremoulet Sep 27, 2017

@adamsitnik thanks.

What about the architecture? I think the assembly was generated as AnyCpu, but for the disassembly output I think it's more germane that it was running on and compiled for x64.

JosephTremoulet commented Sep 27, 2017

@adamsitnik thanks.

What about the architecture? I think the assembly was generated as AnyCpu, but for the disassembly output I think it's more germane that it was running on and compiled for x64.

@adamsitnik

This comment has been minimized.

Show comment
Hide comment
@adamsitnik

adamsitnik Oct 14, 2017

Member

hi @JosephTremoulet

Sorry for the delay!

I have change the exported text, now it will be full information, exactly the same as in our summary:

image

Member

adamsitnik commented Oct 14, 2017

hi @JosephTremoulet

Sorry for the delay!

I have change the exported text, now it will be full information, exactly the same as in our summary:

image

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