Skip to content
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

Make wasm-interpreter work like wasm-aot #1769

Merged
merged 5 commits into from Aug 12, 2021

Conversation

naricc
Copy link
Member

@naricc naricc commented Aug 10, 2021

This mostly unifies wasm-aot and wasm-interpreter, so they work largely the same way. It resolves some on-going issues with the existing wasm-interpreter toolchain.

@naricc
Copy link
Member Author

naricc commented Aug 10, 2021

@adamsitnik

@Lxiamail
Copy link
Member

@naricc are we done with this PR?

src/BenchmarkDotNet/ConsoleArguments/ConfigParser.cs Outdated Show resolved Hide resolved
@@ -96,14 +96,7 @@ protected void GenerateProjectInterpreter(BuildPartition buildPartition, Artifac

protected override string GetBinariesDirectoryPath(string buildArtifactsDirectoryPath, string configuration)
{
if (Aot)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change and I would like to be sure that we are not breaking anything. Have you tested both AOT and non-AOT toolchains?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, before wasm-intepreter mode was using a simplified custom app builder I built into BDN, because that was the best thing that could be done at the time.

Wasm-aot used all the app bundling stuff from the the runtime source directory, which put things in a different place than the one I coded into BDN.

With this change, both wasm-interpreter and wasm-aot will use the app builder from the runtime source dir, so the files will end up in the same place.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tested both AOT and interpreter configurations.

Copy link
Member

@adamsitnik adamsitnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you @naricc !

@@ -175,9 +175,6 @@ public class CommandLineOptions
[Option("wasmEngine", Required = false, HelpText = "Full path to a java script engine used to run the benchmarks, used by Wasm toolchain.")]
public FileInfo WasmJavascriptEngine { get; set; }

[Option("wasmMainJS", Required = false, HelpText = "Path to the main.js file used by Wasm toolchain. Mandatory when using \"--runtimes wasm\"")]
public FileInfo WasmMainJs { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep in mind that once we delete this parameter and you update BDN in dotnet/performance everything that is still using this argument is going to get an error from the BDN config parser

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I am aware. We have made changes in dotnet/performance so nothing is using it.

@naricc
Copy link
Member Author

naricc commented Aug 12, 2021

@adamsitnik If you would be so kind as to merge it when the builds are green :)

@adamsitnik adamsitnik merged commit 74e3c4f into dotnet:master Aug 12, 2021
@Lxiamail
Copy link
Member

create PR dotnet/performance#1918 to have perf repo depends on this new version of bdn.

@AndreyAkinshin AndreyAkinshin added this to the v0.13.2 milestone Aug 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants