4 ms·

Metaprogramming for madmen

134 points by leeoniya 13y ago

makmanalp 13y ago
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 https://www.youtube.com/watch?v=2NBG-sKFaB0) - the previous post (http://fgiesen.wordpress.com/2012/02/13/debris-opening-the-box/ http://fgiesen.wordpress.com/2012/02/13/debris-opening-the-b...)
- leeoniya 13y ago
  > 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.
  - bitwize 13y ago
    "Predikktor"? :)
  - d23 13y ago
    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.
    - leeoniya 13y ago
      i dont know any more than the wiki entry, which is not difficult to digest :) http://en.wikipedia.org/wiki/Branch_predictor http://en.wikipedia.org/wiki/Branch_predictor
  - pjc50 13y ago
    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).
- gwern 13y ago
  > 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.)
- epsylon 12y ago
  For the curious, Farbrausch have a released a lot of their demos and tools source code on GitHub: https://github.com/farbrausch/fr_public https://github.com/farbrausch/fr_public (Also, take a look at the rest of Fabian's blog, it's extremely good.)
enneff 13y ago
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 http://blog.golang.org/cover
- pdw 12y ago
  GCC can do it as well, compile your code with --coverage and `gcov -c` will tell you how often each branch was taken.
camperman 12y ago
This brings back fond memories of trying to get a 4k under the magic 4096 bytes. You get really good at reusing data.
steele 12y ago
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/ http://www.theprodukkt.com/. More info on it here. http://en.wikipedia.org/wiki/.kkrieger http://en.wikipedia.org/wiki/.kkrieger & makmanalp posted a youtube video.

134 points by leeoniya 13y ago

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 https://www.youtube.com/watch?v=2NBG-sKFaB0) - the previous post (http://fgiesen.wordpress.com/2012/02/13/debris-opening-the-box/ http://fgiesen.wordpress.com/2012/02/13/debris-opening-the-b...)

leeoniya 13y ago
> 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.
- bitwize 13y ago
  "Predikktor"? :)
- d23 13y ago
  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.
  - leeoniya 13y ago
    i dont know any more than the wiki entry, which is not difficult to digest :) http://en.wikipedia.org/wiki/Branch_predictor http://en.wikipedia.org/wiki/Branch_predictor
- pjc50 13y ago
  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).
gwern 13y ago
> 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.)
epsylon 12y ago
For the curious, Farbrausch have a released a lot of their demos and tools source code on GitHub: https://github.com/farbrausch/fr_public https://github.com/farbrausch/fr_public (Also, take a look at the rest of Fabian's blog, it's extremely good.)

enneff 13y ago

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 http://blog.golang.org/cover

pdw 12y ago
GCC can do it as well, compile your code with --coverage and `gcov -c` will tell you how often each branch was taken.

camperman 12y ago

This brings back fond memories of trying to get a 4k under the magic 4096 bytes. You get really good at reusing data.

steele 12y ago

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/ http://www.theprodukkt.com/. More info on it here. http://en.wikipedia.org/wiki/.kkrieger http://en.wikipedia.org/wiki/.kkrieger & makmanalp posted a youtube video.