Faster wasm runtime by benaadams · Pull Request #51458 · dotnet/runtime

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

benaadams · 2021-04-18T13:54:05Z

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

ghost · 2021-04-18T13:54:11Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

benaadams · 2021-04-18T13:57:29Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

ghost · 2021-04-18T16:27:15Z

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Compile the wasm using -O3 rather than -Oz for a faster runtime
Use Link Time Optimization -flto for extra optimizations
Fix issues in JS and lay groundwork for closure compiler's --closure 1 which can greatly reduce the size of the JS and more than make up for the increase in the wasm (see: Faster, smaller wasm runtime #51446)

File	Branch	Uncompressed	Brotli
dotnet.wasm	main	2,220 KB	764 KB
dotnet.wasm	PR	2,338 KB	771 KB

Net Change		+118 KB	+7 KB

Optimizing Code | Link Times

Of course, for a final release build, it is usually worth linking with something like -O3 --closure 1 for full optimizations.

Trading off code size and performance

You may wish to build the less performance-sensitive source files in your project using -Os or -Oz and the remainder using -O2 (-Os and -Oz are similar to -O2, but reduce code size at the expense of performance. -Oz reduces code size more than -Os.)
Compiling with -Os or -Oz generally avoids inlining too.

Inspired by Is WebAssembly magic performance pixie dust? where they were seeing a ore than x2 perf degradation from -Os:

Another thing that the AssemblyScript folks pointed out to me is that the --optimize flag is equivalent to -O3s which aggressively optimizes for speed, but makes tradeoffs to reduce binary size. -O3 optimizes for speed and speed only. Having -O3s as a default is good in spirit — binary size matters on the web — but is it worth it? At least in this specific example the answer is no: -O3s ends up trading the laughable amount of ~30 bytes for a huge performance penalty

And its currently using -Oz which is even worse for performance than -Os

Author:	benaadams
Assignees:	-
Labels:	`arch-wasm`, `area-Build-mono`
Milestone:	-

eerhardt · 2021-04-19T15:22:39Z


 EMCC_DEBUG_FLAGS =-g -Os -s ASSERTIONS=1 -DDEBUG=1
-EMCC_RELEASE_FLAGS=-Oz --llvm-opts 2
+EMCC_RELEASE_FLAGS=-O3 --llvm-opts 3 -flto


(nit) not that it really matters, but the ordering here is different than what is in the wasm.proj file.

eerhardt · 2021-04-19T15:23:44Z

$(EMCC) $(EMCC_FLAGS) $(1) --js-library runtime/library_mono.js --js-library runtime/binding_support.js --js-library runtime/dotnet_support.js --js-library $(SYSTEM_NATIVE_LIBDIR)/pal_random.js $(BUILDS_OBJ_DIR)/driver.o $(BUILDS_OBJ_DIR)/pinvoke.o $(BUILDS_OBJ_DIR)/corebindings.o $(2) -o $(NATIVE_BIN_DIR)/dotnet.js $(3)

Does this need to pass --externs runtime/externs.js on it?

Refers to: src/mono/wasm/Makefile:105 in 7ea1fa3. [](commit_id = 7ea1fa3, deletion_comment = False)

benaadams · 2021-04-19T15:56:48Z

Does this need to pass --externs runtime/externs.js on it?

That needs to be passed via EMCC_CLOSURE_ARGS environment var; so added that in the RunWithEmSdkEnv.cs Task, doesn't seem to be a simple way to add an env var in vanilla MsBuild?

eerhardt · 2021-04-19T16:19:41Z

so added that in the RunWithEmSdkEnv.cs Task

I don't believe that Task gets called on non-Windows builds:

runtime/src/mono/wasm/wasm.proj

Lines 112 to 115 in 8f4a12d

 <TargetName="BuildWinWasmRuntimes"
Condition="'$(OS)' == 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimezones"> 

vs.

runtime/src/mono/wasm/wasm.proj

Lines 74 to 80 in 8f4a12d

 <TargetName="BuildWasmRuntimes"
Condition="'$(OS)' != 'Windows_NT'"
AfterTargets="Build"
DependsOnTargets="BuildPInvokeTable;BundleTimeZones"> 
 <ExecCommand="make -C $(MonoProjectRoot)wasm all SHELL=/bin/bash BINDIR=$(ArtifactsBinDir) MONO_BIN_DIR=$(MonoArtifactsPath) OBJDIR=$(ArtifactsObjDir) NATIVE_BIN_DIR=$(NativeBinDir) CONFIG=$(Configuration) PINVOKE_TABLE=$(WasmPInvokeTablePath) ICU_LIBDIR=$(ICULibDir) ENABLE_ES6=$(WasmEnableES6) ENABLE_METADATA_UPDATE=$(WasmEnableMetadataUpdate)"
IgnoreStandardErrorWarningFormat="true" /> 

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

radekdoulik · 2021-04-19T19:12:07Z

@radekdoulik is it possible to test the performance of this with your example in #50260 (comment); I'm not sure how to get a build that can be tested in your harness, I just seemed to make it angry in the console instead

I am updating my measurement code, so that it becomes more automated and less hassle to use. I will try to run it on your branch and also create PR which will add new sample, similar to src/mono/samples/wasm/browser, to run simple benchmark.

benaadams · 2021-04-20T00:54:19Z

I don't believe that Task gets called on non-Windows builds:

Added to the Makefile also

radekdoulik · 2021-04-20T10:07:31Z

From my understanding the Makefile and the BuildWinWasmRuntimes target are duplicates of each other. cc @radekdoulik

Yes, indeed. I plan to unify that, hopefully soon. Opened #51553.

radekdoulik

I have measured the Json timings.

measurement	main/interp	PR branch/interp
Json, non-ASCII text serialize	8.2714ms	8.2941ms
Json, non-ASCII text deserialize	11.6825ms	11.6508ms
Json, small serialize	0.2389ms	0.2436ms
Json, small deserialize	0.3678ms	0.3731ms
Json, large serialize	67.8831ms	69.4267ms
Json, large deserialize	101.1538ms	102.4038ms

They are very close, probably just measurement errors. Not sure whether the change is too small or whether the Json [de]serialization is not affected by changes in this PR.

Any suggestion for an area where it might show larger difference?

jeromelaban · 2021-04-20T12:37:59Z

This change might have more impact with AOT enabled (-flto does, not sure about -O3). Note that -flto also has a very large impact on build time if not -flto=thin at link time.

I'm also wondering if this may help more the GC itself, what happens if you make lots of allocations during benchmarks?

radekdoulik · 2021-04-20T12:40:13Z

I think for impact on AOT we would need to also modify src/mono/wasm/build targets?

radekdoulik · 2021-04-20T12:44:34Z

I have opened draft PR with the simple benchmark sample I used to measure the times #51559

steveisok · 2021-06-28T11:49:17Z

@lewing @radical do you think this is something we can/want to take?

radekdoulik · 2021-11-22T11:09:46Z

I am sorry @benaadams that this fall off the radar. We switched to -O2 meanwhile for release builds and the build targets are also finally unified for win and linux/mac.

@radical, I think the flags can be overridden with EmccLinkOptimizationFlag property, right?

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Faster wasm runtime
7ea1fa3

benaadams requested a review from marek-safar as a code owner April 18, 2021 13:54

benaadams mentioned this pull request Apr 18, 2021
Faster, smaller wasm runtime #51446
Closed

CoffeeFlux added arch-wasm WebAssembly architecture area-Build-mono labels Apr 18, 2021

marek-safar requested review from lewing and radekdoulik April 19, 2021 09:51

eerhardt reviewed Apr 19, 2021
View reviewed changes

Feedback
111ea17

runfoappBot mentioned this pull request Apr 19, 2021
Symlinks left on disk by Installer runs breaks job log upload on Linux #51502
Closed

radekdoulik reviewed Apr 20, 2021
View reviewed changes

terrajobst added the community-contribution Indicates that the PR has been added by a community member label Jul 19, 2021

danmoseley assigned lewing Sep 15, 2021

marek-safar assigned radekdoulik and unassigned lewing Nov 22, 2021

radekdoulik closed this Nov 22, 2021

ghost locked as resolved and limited conversation to collaborators Dec 22, 2021

Uh oh!

Conversation

benaadams commented Apr 18, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Apr 18, 2021

Uh oh!

benaadams commented Apr 18, 2021

Uh oh!

ghost commented Apr 18, 2021

Uh oh!

eerhardtApr 19, 2021

Choose a reason for hiding this comment

Uh oh!

eerhardt commented Apr 19, 2021

Uh oh!

benaadams commented Apr 19, 2021

Uh oh!

eerhardt commented Apr 19, 2021

Uh oh!

radekdoulik commented Apr 19, 2021

Uh oh!

benaadams commented Apr 20, 2021

Uh oh!

radekdoulik commented Apr 20, 2021

Uh oh!

radekdoulik left a comment

Choose a reason for hiding this comment

Uh oh!

jeromelaban commented Apr 20, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

radekdoulik commented Apr 20, 2021

Uh oh!

radekdoulik commented Apr 20, 2021

Uh oh!

steveisok commented Jun 28, 2021

Uh oh!

radekdoulik commented Nov 22, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Uh oh!

Conversation

benaadams commented Apr 18, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Apr 18, 2021

Uh oh!

benaadams commented Apr 18, 2021

Uh oh!

ghost commented Apr 18, 2021

Uh oh!

eerhardtApr 19, 2021

Choose a reason for hiding this comment

Uh oh!

eerhardt commented Apr 19, 2021

Uh oh!

benaadams commented Apr 19, 2021

Uh oh!

eerhardt commented Apr 19, 2021

Uh oh!

radekdoulik commented Apr 19, 2021

Uh oh!

benaadams commented Apr 20, 2021

Uh oh!

radekdoulik commented Apr 20, 2021

Uh oh!

radekdoulik left a comment

Choose a reason for hiding this comment

Uh oh!

jeromelaban commented Apr 20, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benaadams commented Apr 18, 2021•
edited
Loading

jeromelaban commented Apr 20, 2021•
edited
Loading

benaadams commented Apr 18, 2021•
edited
Loading

jeromelaban commented Apr 20, 2021•
edited
Loading

benaadams commented Apr 18, 2021•
edited
Loading

jeromelaban commented Apr 20, 2021•
edited
Loading