5 ms·

I'm reminded of Courgette: https://www.chromium.org/developers/design-documents/software-updates-courgette https://www.chromium.org/developers/design-documents/

by i336_ 10y ago

I'm reminded of Courgette: https://www.chromium.org/developers/design-documents/software-updates-courgette https://www.chromium.org/developers/design-documents/softwar... It's used to deliver unbelievably small Chromium OS updates. To quote the link above: Full update: 10,385,920 bsdiff update: 704,512 Courgette update: 78,848 The reason it's not being used here is because Courgette's disassembler/symbol resolver only works on x86/x86_64/ARM assembly language. But it got me thinking - how much bulk does binary code take up in an Android APK? If it's noteworthy, a JVM disassembler could produce really interesting results. If it's mostly images and sounds then things are pretty much as optimized as they already are. (I have no idea myself.)

masklinn 10y ago
> But it got me thinking - how much bulk does binary code take up in an Android APK? It's going to depend greatly on the type of packages, and the most problematic (bulky) ones are games, where the vast majority of the package is assets.
KMag 10y ago
> a JVM disassembler Note that Dalvik bytecode is very very different from the Java bytecode read by JVMs. For one, Dalvik is a register machine (like LuaJIT's internal bytecode) and the JVM is a stack machine (like Python bytecode).
- i336_ 10y ago
  Oooh, that might be one of the reasons why LuaJIT is so fast. I did some reading about Forth some time ago, and learned that modern CPUs have minor struggles with stack-based interpreters. I understand it's almost negligible but has a small impact. (Forth is stack-based.)
  - masklinn 10y ago
    There are many reasons why LuaJIT is false, Mike Pall has talked pretty extensively about it (e.g. http://lambda-the-ultimate.org/node/3851 http://lambda-the-ultimate.org/node/3851). I don't recall being register-based coming up as a first-order reason, though it may have allowed optimisations which a stack-based machine would not allow (e.g. the JIT doing register hinting and renaming).
    - i336_ 10y ago
      What do you mean by "LuaJIT is false"? Thanks heaps for that link though, reading through that thread has been really interesting.
      - masklinn 10y ago
        > What do you mean by "LuaJIT is false"? Meant to write "LuaJIT is fast", but was probably thinking about something else and the fingers went haywire, sorry about that. > Thanks heaps for that link though, reading through that thread has been really interesting. Pall has written in other venues (mostly LuaJIT mailing lists but I think I remember comments of his on reddit or HN, though I might be mistaken), comments of his are always interesting reads.
        i336_ 10y ago
        Ah, I've had the same kinds of finger-"autocorrect" issues myself. Thanks! I've been trying to find more info about Mike, he seems to be a really private/mysterious type. What he writes about is definitely interesting though.

by i336_ 10y ago

masklinn 10y ago

> But it got me thinking - how much bulk does binary code take up in an Android APK? It's going to depend greatly on the type of packages, and the most problematic (bulky) ones are games, where the vast majority of the package is assets.

KMag 10y ago

> a JVM disassembler Note that Dalvik bytecode is very very different from the Java bytecode read by JVMs. For one, Dalvik is a register machine (like LuaJIT's internal bytecode) and the JVM is a stack machine (like Python bytecode).

i336_ 10y ago
Oooh, that might be one of the reasons why LuaJIT is so fast. I did some reading about Forth some time ago, and learned that modern CPUs have minor struggles with stack-based interpreters. I understand it's almost negligible but has a small impact. (Forth is stack-based.)
- masklinn 10y ago
  There are many reasons why LuaJIT is false, Mike Pall has talked pretty extensively about it (e.g. http://lambda-the-ultimate.org/node/3851 http://lambda-the-ultimate.org/node/3851). I don't recall being register-based coming up as a first-order reason, though it may have allowed optimisations which a stack-based machine would not allow (e.g. the JIT doing register hinting and renaming).
  - i336_ 10y ago
    What do you mean by "LuaJIT is false"? Thanks heaps for that link though, reading through that thread has been really interesting.
    - masklinn 10y ago
      > What do you mean by "LuaJIT is false"? Meant to write "LuaJIT is fast", but was probably thinking about something else and the fingers went haywire, sorry about that. > Thanks heaps for that link though, reading through that thread has been really interesting. Pall has written in other venues (mostly LuaJIT mailing lists but I think I remember comments of his on reddit or HN, though I might be mistaken), comments of his are always interesting reads.
      - i336_ 10y ago
        Ah, I've had the same kinds of finger-"autocorrect" issues myself. Thanks! I've been trying to find more info about Mike, he seems to be a really private/mysterious type. What he writes about is definitely interesting though.