Help: how to get smaller code size for a 'Hello world' example?

[TerryGuo]

Hi there,
I am building wasm 'Hello world' example from src/examples/wasm with command ~/tinygo/tinygo/bin/tinygo build -target wasm -o wasm.wasm main/main.go, the generated wasm file is pretty big 64KB. According to this Go Wiki, the size could be as smaller as 575 bytes. Perhaps I am doing something wrong. Any hints are welcomed.

[aykevl]

64kB? When I run make main, I get a 3.4kB file. I get something very similar when I run the command you gave. Are you sure you haven't modified the file?

This 3.4kB is still bigger than necessary as by default DWARF debug information is included which is not useful as there are no wasm debuggers yet (AFAIK). By adding -no-debug (see #378) I get a file of 966 bytes.

I think the 576 bytes as shown in the Go wiki is for a very minimal wasm file that only adds two numbers (see the add function in export/wasm.go).

@justinclift may have something to add here.

[justinclift]

Wow, yeah something doesn't seem to be working correctly. 😉

@TerryGuo Just to double check some initial things, when you run tinygo version what does it say?

[deadprogram]

$ make main 
rm -rf ./html
mkdir ./html
cp ../../../targets/wasm_exec.js ./html/
tinygo build -o ./html/wasm.wasm -target wasm -no-debug ./main/main.go
cp ./main/index.html ./html/
$ ls -l html/wasm.wasm 
-rwxrwxr-x 1 ron ron 966 may 25 21:25 html/wasm.wasm

I get same result as @aykevl using the latest dev branch of TinyGo + Go 1.12 on Ubuntu 16.04.

[TerryGuo]

Thanks all of you for your help. I just downloaded tinygo0.5.0.linux-amd64.tar.gz on my Ubuntu 19.04 and then used tinygo from bin folder of the package. Here are my environment information:

terry@tPad:~/tinygo/tinygo/src/examples/wasm$ ~/tinygo/tinygo/bin/tinygo build -o ./html/wasm.wasm --no-debug -target wasm ./main/main.go
terry@tPad:~/tinygo/tinygo/src/examples/wasm$ ls -lh html/wasm.wasm 
-rwxr-xr-x 1 terry terry 35K 5月  26 09:40 html/wasm.wasm
terry@tPad:~/tinygo/tinygo/src/examples/wasm$ ~/tinygo/tinygo/bin/tinygo version
tinygo version 0.5.0 linux/amd64
terry@tPad:~/tinygo/tinygo/src/examples/wasm$ go version
go version go1.12.5 linux/amd64

[justinclift]

Hmmm. Would you be ok to email that resulting wasm.wasm file to me? (justin@postgresql.org)

I'll take it apart and see what the heck it really is. 😄

[justinclift]

Another thing to check, just in case... if you check your main.go file, is it using println()?

eg:

$ cat main/main.go 
package main

func main() {
        println("Hello world!")
}

An older version of the file used fmt.Println(), which pulls in an extra library and increases the file size. Not sure if that's what's happening here, but without seeing the wasm file yet it's the only thing coming to mind as a potential cause. 😄

[justinclift]

Ahhh. Just realised, the 0.5.0 release which you're using has the fmt.Println() version of the code. It's our dev branch which has been changed to use println(), which gives the smaller file size.

This is making sense now. 😄

@TerryGuo Are you ok to compile TinyGo from the dev branch? Or just change your main.go to use println() instead. Either way should reduce the compiled Hello World file size for you.

[TerryGuo]

@justinclift Thanks for the help. You are totally right. After changing fmt.Println() to println, I can get 575 bytes for this "Hello world" example. I then checked the generated wasm file. Looks like the memset function is not optimized out even if it is not used. Do you happen to know the reason?
Here are the disassemble version of wasm file:

(module
  (type (;0;) (func (result i32)))
  (type (;1;) (func (param i32 i32 i32) (result i32)))
  (type (;2;) (func))
  (type (;3;) (func (param i32)))
  (import "env" "io_get_stdout" (func $io_get_stdout (type 0)))
  (import "env" "resource_write" (func $resource_write (type 1)))
  (func $__wasm_call_ctors (type 2))
  (func $_start (type 2)
    i32.const 0
    call $io_get_stdout
    i32.store offset=1024)
  (func $cwa_main (type 2)
    (local i32)
    i32.const 0
    call $io_get_stdout
    i32.store offset=1024
    i32.const -12
    local.set 0
    block  ;; label = @1
      loop  ;; label = @2
        local.get 0
        i32.eqz
        br_if 1 (;@1;)
        local.get 0
        i32.const 1040
        i32.add
        i32.load8_u
        call $runtime.putchar
        local.get 0
        i32.const 1
        i32.add
        local.set 0
        br 0 (;@2;)
      end
    end
    i32.const 13
    call $runtime.putchar
    i32.const 10
    call $runtime.putchar)
  (func $runtime.putchar (type 3) (param i32)
    (local i32)
    global.get 0
    i32.const 16
    i32.sub
    local.tee 1
    global.set 0
    local.get 1
    i32.const 0
    i32.store offset=12
    local.get 1
    local.get 0
    i32.store8 offset=12
    i32.const 0
    i32.load offset=1024
    local.get 1
    i32.const 12
    i32.add
    i32.const 1
    call $resource_write
    drop
    local.get 1
    i32.const 16
    i32.add
    global.set 0)
  (func $memset (type 1) (param i32 i32 i32) (result i32)
    (local i32)
    i32.const 0
    local.set 3
    block  ;; label = @1
      loop  ;; label = @2
        local.get 2
        local.get 3
        i32.eq
        br_if 1 (;@1;)
        local.get 0
        local.get 3
        i32.add
        local.get 1
        i32.store8
        local.get 3
        i32.const 1
        i32.add
        local.set 3
        br 0 (;@2;)
      end
    end
    local.get 0)
  (table (;0;) 1 1 funcref)
  (memory (;0;) 2)
  (global (;0;) (mut i32) (i32.const 66576))
  (global (;1;) i32 (i32.const 66576))
  (global (;2;) i32 (i32.const 1040))
  (global (;3;) i32 (i32.const 1024))
  (export "memory" (memory 0))
  (export "__wasm_call_ctors" (func $__wasm_call_ctors))
  (export "__heap_base" (global 1))
  (export "__data_end" (global 2))
  (export "__dso_handle" (global 3))
  (export "_start" (func $_start))
  (export "cwa_main" (func $cwa_main))
  (export "memset" (func $memset))
  (data (;0;) (i32.const 1024) "\00\00\00\00")
  (data (;1;) (i32.const 1028) "Hello world!"))

[justinclift]

No worries. 😄

With the memset() function, it's probably the code here:

tinygo/src/runtime/runtime_wasm.go

Lines 66 to 71 in 421ef04

	func memset(ptr unsafe.Pointer, c byte, size uintptr) unsafe.Pointer {
	for i := uintptr(0); i < size; i++ {
	*(*byte)(unsafe.Pointer(uintptr(ptr) + i)) = c
	}
	return ptr
	}

And yeah, no idea why it's not being optimised out either. 😦

As an experiment, you could remove the contents of the memset function in that source file to see if it makes a difference when compiled. It probably will. 😄

[TerryGuo]

Yeap, I will try with your suggestion. But it is a different topic. Thanks again for your great work to enable Tinygo support Webassembly. Close this one as my original question is addressed.

[aykevl]

See #137 for why memset is included.
Yes it should be optimized out, but somehow it is not. The trouble is that whether it is required is only know after compilation, at link time. So we somehow have to indicate that memset must not be optimized away by the compiler but should definitely be optimized away by the linker if the linker doesn't need it (called tree shaking or garbage collection).

Here is a proposal that would avoid the need for memset: WebAssembly/proposals#18