- 234comments
- 242comments
- 40comments
- 3comments
- 65comments
- 264comments
- 12comments
- 43comments
- 76comments
- 52comments
- 181comments
- 51comments
- 245comments
- 4comments
- 14comments
- 53comments
- 195comments
- 19comments
- 169comments
- 22comments
- 90comments
- 32comments
- 3comments
- 16comments
- 181comments
- 151comments
- —discuss
- 19comments
- —discuss
- 303comments
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. :)
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...)
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.
"Predikktor"? :)
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 dont know any more than the wiki entry, which is not difficult to digest :)
http://en.wikipedia.org/wiki/Branch_predictor
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).
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.)
For the curious, Farbrausch have a released a lot of their demos and tools source code on GitHub: https://github.com/farbrausch/fr_public
(Also, take a look at the rest of Fabian's blog, it's extremely good.)
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.
Details: http://blog.golang.org/cover
GCC can do it as well, compile your code with --coverage and `gcov -c` will tell you how often each branch was taken.
This brings back fond memories of trying to get a 4k under the magic 4096 bytes. You get really good at reusing data.
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/.
More info on it here. http://en.wikipedia.org/wiki/.kkrieger & makmanalp posted a youtube video.