sphere_dance icon indicating copy to clipboard operation
sphere_dance copied to clipboard

Why is the 1280_720 version bigger than the 1920_1080 version?

Open jhyt67ujhgtyu opened this issue 5 years ago • 1 comments

As seen in the download page, ochre_1280_720_v_1.exe = 3.97K and ochre_1920_1080_v_1.exe = 3.91K. As far as I can tell the code is the same. (Question was originally asked here)

jhyt67ujhgtyu avatar Jul 11 '20 09:07 jhyt67ujhgtyu

Even if the disassembly was exactly the same aside from the constants and file timestamps, the readme mentions crinkler is used to compress the executable further - which could mean minor size differences (57 bytes in this case) could form from more/fewer byte sequences being identical/different, altering how compressable the executable effectively is.

Also, the optimizer will handle some expressions involving some constants slightly differently:

pub fn small_stride(y: usize) -> usize {
    y * 1280
}

pub fn large_stride(y: usize) -> usize {
    y * 1920
}

godbolt disassembly:

example::small_stride:
        shl     rdi, 8
        lea     rax, [rdi + 4*rdi]
        ret

example::large_stride:
        imul    rax, rdi, 1920
        ret

VS x64 disassembly w/ bytes shows that small_stride is 1 byte larger than large_stride (4+4+1=9 vs 7+1=8):

small_stride:
48 C1 E1 08          shl         rcx,8  
48 8D 04 89          lea         rax,[rcx+rcx*4]  
C3                   ret  

large_stride:
48 69 C1 80 07 00 00 imul        rax,rcx,780h  
C3                   ret  

These differences in this simple test case go away if using opt-level = "z" (optimize for size?) as Cargo.toml currently does: https://github.com/janiorca/sphere_dance/blob/6db8b8c3ecc98948d14770ba21d5614cc7b71539/Cargo.toml#L14

But it's possible similar differences survive in this project in more complicated expressions.

MaulingMonkey avatar Sep 14 '20 23:09 MaulingMonkey