This is an amazing insight into how demos are written. Farbrausch stuff has always been inspirational to me.
It's very interesting is the sort of extreme version of the idea that data model and code are inherently tied: Especially in functional programming circles it's a maxim that you design your data models first, specifically for your task, and then the rest of the code is pretty much pattern-matching around that. This takes that coupling and makes it even tighter, to serve a higher purpose. I almost feel like given enough time, this could be a JIT: an executable that adaptively strips code and self-minifies over time as you run it. :)
> an executable that adaptively strips code and self-minifies over time as you run it
i wonder if a lot of the dead code paths are already eliminated at runtime by the branch predictors in modern CPUs/GPUs. of course it would make no difference for size on disk (which can be argued is mainly useful for code golf and edu these days), but it would be cool to get that feedback in some format without needing to exert any additional effort.
Branch predictors do not modify the code in memory. Dead code is still there; if you have a branch that is always taken, the predictor may remember that, but the wasted bytes following it are still using up your cache.
You can usually get the linker to either remove dead code or assist in its removal, though. "Nearly" dead code is the big pain (e.g. options that are never set but could be).
Do you know much about branch prediction? It seems pretty darn interesting. I'm just curious as to how something like that would work with a path that potentially has side-effects. I don't really know how things work very well at that level, so perhaps I'm misunderstanding something.
> I almost feel like given enough time, this could be a JIT: an executable that adaptively strips code and self-minifies over time as you run it. :)
Yes, their tool is getting pretty similar to superoptimization and profile-guided optimization.
(Of course, you don't really want to self-minify over time: what if a new request comes in from a user exercising stripped functionality? You'd have to have some sort of fallback way to retrieve the original unoptimized code.)
Fun read. I didn't realize this was from 2012, but it helps explain that jarring click into the first link for .kkrieger, lol http://www.theprodukkt.com/.
This is how Go's test coverage tool works, except in the Go case it was easy to do because there are libraries for reading and writing Go source code in the standard library.
It's very interesting is the sort of extreme version of the idea that data model and code are inherently tied: Especially in functional programming circles it's a maxim that you design your data models first, specifically for your task, and then the rest of the code is pretty much pattern-matching around that. This takes that coupling and makes it even tighter, to serve a higher purpose. I almost feel like given enough time, this could be a JIT: an executable that adaptively strips code and self-minifies over time as you run it. :)
Also check out: - kkrieger (windows only 96kb 3D FPS, video here: https://www.youtube.com/watch?v=2NBG-sKFaB0) - the previous post (http://fgiesen.wordpress.com/2012/02/13/debris-opening-the-b...)