Conversation

I've really warmed up to 's suggestion of using template instantiation for hot generic functions and an interpreter for cold generic functions. You often want an interpreter for your language anyway, so it's an elegant way to reduce code bloat.
4
40
Replying to and
Fully polymorphic code is pretty large too in machine code, and is full of indirect branches already. Byte code has the opportunity to be a lot smaller, and an interpreter could be nearly as fast while using up less instruction cache space
1
2
I rely heavily on LTO and dead code elimination in generic code for the Rust I write on microcontrollers (< 100kB ROM, < 10kB RAM). I don't think my code would appreciate embedding a full interpreter just because a few cold code paths couldn't be optimized out LOL.
2
1
Replying to and
Sure, there are definitely places where you don’t want to introduce dependencies on a runtime. Across a full blown OS on a desktop CPU, being able to make better use of memory and cache by sharing code is a big systemic optimization; for a single purpose controller not so much
1
2
On modern Android versions, apps start out using a multi-tier JIT compiler with an interpreter as the baseline. It saves the JIT profile information persistently and that's used to perform AOT compilation when the device is idle and during background installation of OS updates.
1
2
JIT compilation is constrained by memory usage since it creates dirty pages in memory, along with being limited by time since compilation wastes CPU cycles / battery life. It's willing to compile much more code with AOT compilation in the background based on the JIT profiles.
2
Show replies