build wasm file is very big???

[cyanBone]

build wasm file is very big
golang is 2mb+
rust is 20k+

this is 9.5mb

[vshymanskyy]

After running wasm-strip, it reduces to 7.5 Mb
Next, after running wasm-opt -Os it gets to 3.4 Mb

Still quite big, as with AssemblyScript, Rust, and TinyGo I was able to generate useful wasm files of just 200...3500 bytes. See https://github.com/wasm3/wasm3-arduino/tree/master/examples_pio/Wasm_Advanced/wasm_apps

[kateinoigakukun]

Now, we're focussing on making produced binary work properly. But I think binary size is one of the most important things too.

Fat stdlib

As far as I investigated, Swift stdlib is so fat that weights about 8.8MB because it depends on ICU and libc. Other platform projects are facing on same problem too.

Fortunately, Swift6 will work on supporting more platforms, and core team know this problem. If they decide to implement a subset of stdlib to be more small, it can be helpful.

LTO approach

Most of stdlib parts are unused, so if linker omits unused code, the produced binary will be more small.

Here is a Swift LTO talk at LLVM meeting.
This presentation shows that effective LTO reduces 20% of binary size. I've not tried this method yet and I don't know whether this works as well for wasm target, but in theory it can.

Swift has many dynamic language feature, like dynamic casting, dynamic dispatch or etc.., so my concerns with this approach is that linker can't know what protocol are used.

For example,

1. ModuleA.swift has protocol P and conformance of P for String and String.foo method.

public protocol P {
  func foo()
}

extension String: P {
  func foo() {}
}

public func useP<T>(_ value: T) {
  (value as? P)?.foo()
}

2. main.swift import ModuleA but not use it.

import ModuleA

struct S: P {}
useP(S())

In this case, ModuleA's conformance and String.foo are included in produced binary because linker can't know whether the main.swift uses String: P conformance or not. (conformance metadata are always marked as llvm.used to reference them sequentially)

So, to achieve more reduction, we need to consider new optimization approach, like WMO or something LTO plugin that tells linker which protocols are used and omits unused conformances and functions.

[syrusakbary]

We are integrating SwiftWasm into Wasienv and realized that creating a file for a simple hello world is 42Mb (see attached file at the bottom of this comment).

You can follow the steps to compile easily Swift to Wasm easily here:

https://docs.wasmer.io/ecosystem/wasienv/compile-swift-to-wasm-wasi

How Wasienv works

This is what wasienv is doing under the hood:

• wasienv install-swift:
  1. Installs SwiftEnv (if is not already installed): git clone https://github.com/kylef/swiftenv.git (1)
  2. Installs SwiftWasm for SwitfEnv: swiftenv install https://github.com/swiftwasm/swift/releases/download/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-03-08-a/swift-wasm-DEVELOPMENT-SNAPSHOT-2020-03-08-a-osx.tar.gz (2)
• wasiswiftc example.swift -o example.wasm:
  1. Calls wasienv which swiftc (to get the swiftc) (3)
  2. Calls swift -target wasm32-unknown-wasi -sdk ${WASI_SYSROOT} (4)

Perhaps we are doing something wrong?

Simple Example - 42Mb

The file that wasiswiftc example.swift -o example.wasm generated for the following is 42Mb.

if CommandLine.arguments.count < 2 {
   print("Hello, WASI!\n");
} else {
    print("Hello, \(CommandLine.arguments[1])\n");
}

example.wasm.zip

[kateinoigakukun]

@syrusakbary Thanks for trying Swift for WASM!

Wasienv looks doing right. swift-wasm-DEVELOPMENT-SNAPSHOT-2020-03-08-a toolchain is already old.

Please try the lastest toolchain from here https://github.com/swiftwasm/swift/releases
Recently I worked on reducing binary size, and succeeded to make it around 10MB.
I know it's still very fat, so I'm working on dieting more.

[syrusakbary]

Cool, let me update the release and I'll put my findings after.

Thanks for the quick response!

[syrusakbary]

Nice!

I just got it running!! The file is now much smaller as you pointed (9Mb), and takes much less time to execute.
I also published a new version of Wasienv that uses the latest release:

wasienv install-swift
wasiswiftc example.swift -o example.wasm

🎉

Timings

While trying things out, I've been doing an analysis of the example.wasm execution in different runtimes.

I just compared wasmer and wasmtime for running a generated file, and Wasmer timings are much better (about 10x faster runtime speed once the file is compiled)

Wasmtime: 1s to execute

➜  wasienv git:(master) ✗ time wasmtime example.wasm
Hello, WASI!

wasmtime example.wasm  0.97s user 0.10s system 98% cpu 1.087 total

Wasmer: .2s to execute (5x faster)

➜  wasienv git:(master) ✗ time wasmer example.wasm
Hello, WASI!

wasmer example.wasm  0.12s user 0.08s system 96% cpu 0.215 total

[kateinoigakukun]

I tried to use wasmer instead of wasmtime, it saved 13min for test execution! It's really good news!
#451

[MaxGraey]

wasmtime has opt flags --optimize and -O2 btw which not good described in docs. Did you try it?

[syrusakbary]

Yup, tried them both, but the timings are exactly the same than without those flags (mainly because -O2 is already the default in wasmtime).

You can also try them locally, following instructions here: https://docs.wasmer.io/ecosystem/wasienv/compile-swift-to-wasm-wasi

But the timings are: .2s for Wasmer and 1s for Wasmtime (with opt flags turned on)

[MaxDesiatov]

I can confirm that running wasm-strip from wabt and wasm-opt -Os from binaryen (in this order, wasm-opt seems to choke on raw binaries produced by swift build without having wasm-strip run on them at first) reduced an 11M binary to 4.9M. Interestingly enough the same code built in release mode with swift build -c release was only reduced to 5.1M 🤔

Both became 1.5M when zipped, that's not great, but not terrible either, almost order of magnitude better than the raw binary 😄

[MaxDesiatov]

Whoever is interested, the detailed plan for improvements is available in this Swift Forums thread:

Phase 1

• swift driver changes for providing flags for LTO
• swift driver changes to invoke the clang linker driver properly for enabling LTO
• swift frontend changes to emit LLVM BC instead of object files

Measurements for this phase would be interesting as they would identify the benefits of extra IPO of the IRGen (generic, non-language specific optimizations)

Phase 2

• changes to LLD to add support setting multiple compiler pipelines for LTO
• changes to swift frontend to support multiple pipelines
• changes to swift frontend to emit SIB instead of IRGen
• changes to LLD to setup a swift pipeline if a SIB is encountered, call back into swift to SILGen
• changes to the pipeline to do IPO with language specific considerations - e.g. late monomorphisation of generics, late devirt of calls

Parts of phase 1 are currently in review as swiftlang#31146.