4 ms·

I wonder how far we can take this sort of effort -- collect exact usage statistics for users and optimize software exactly for known usage patterns. Of course s

I wonder how far we can take this sort of effort -- collect exact usage statistics for users and optimize software exactly for known usage patterns. Of course some statistical technique would be needed to deal with the long tail of usage patterns -- surely some program branches are used extremely rarely (or not even seen in collected samples), but you still wouldn't want them to be extremely slow (slower than necessary) or crash just because they're rarely used. The cumulative usage of many of those long tail events can be large. Either (regularized) statistical inference of branches or something like assuming a baseline usage for every branch would be necessary. This is all significantly complex of course, so for anything that are not the consumer megaprojects of software (browsers and operating systems?), I wonder if those tools could be used as well. Perhaps there could be some automated, anonymized usage reporting that does all this work?

jeffbee 6y ago
Google collects profiles from user devices fleet-wide on both Android and ChromeOS. That's why code like this exists: https://github.com/google/perf_data_converter/tree/master/src/quipper https://github.com/google/perf_data_converter/tree/master/sr...
- mrdmnd 6y ago
  Fun fact, I wrote the first version of this code as a Google Intern. Imagine my surprise when I saw that they're still using it, and it's been developed and fleshed out!
  - mrdmnd 6y ago
    (as a historical aside, the name is "Quipper" because I kept trying to pronounce the project name (ChromeOS-Wide Profiling, or CWP) and ended up quite liking "Quip". The internal aggregation code, of course, is known as Bartlett.
hinkley 6y ago
Ages ago I had a conversation with a coworker about why was it that if databases collect statistics for optimizations, that data structures in programming languages don't do the same thing? This would come up a few more times in my career. The next time was a few years later when I was having to go through a code base removing premature optimizations for initial list size in a code base. The average length of our data had grown such that our lists were now bigger than the defaults would have been. That was added to my growing collection of "making code faster by removing code" examples. We talk about using better algorithms instead of tweaking code with micro-optimizations but then we never talk about tuning the better algorithms. So they default to the average case or worse.
- The_rationalist 6y ago
  I had seen such a statistically fine tuned data structure on github.com some time ago but can't find it. I wonder if in memory representations for compute such as apache arrow exploit this
- tjalfi 6y ago
  > Ages ago I had a conversation with a coworker about why was it that if databases collect statistics for optimizations, that data structures in programming languages don't do the same thing? Lus tables in LuaJIT, Hack arrays, and JavaScript arrays can use different representations depending on what is stored in them. NYU’s SETL project also did some work on automatically identifying what data structure should be used. IBM’s Hermes project was also working on this; I’m not sure whether they shipped it.

jeffbee 6y ago

Google collects profiles from user devices fleet-wide on both Android and ChromeOS. That's why code like this exists: https://github.com/google/perf_data_converter/tree/master/src/quipper https://github.com/google/perf_data_converter/tree/master/sr...

mrdmnd 6y ago
Fun fact, I wrote the first version of this code as a Google Intern. Imagine my surprise when I saw that they're still using it, and it's been developed and fleshed out!
- mrdmnd 6y ago
  (as a historical aside, the name is "Quipper" because I kept trying to pronounce the project name (ChromeOS-Wide Profiling, or CWP) and ended up quite liking "Quip". The internal aggregation code, of course, is known as Bartlett.

hinkley 6y ago

Ages ago I had a conversation with a coworker about why was it that if databases collect statistics for optimizations, that data structures in programming languages don't do the same thing? This would come up a few more times in my career. The next time was a few years later when I was having to go through a code base removing premature optimizations for initial list size in a code base. The average length of our data had grown such that our lists were now bigger than the defaults would have been. That was added to my growing collection of "making code faster by removing code" examples. We talk about using better algorithms instead of tweaking code with micro-optimizations but then we never talk about tuning the better algorithms. So they default to the average case or worse.

The_rationalist 6y ago
I had seen such a statistically fine tuned data structure on github.com some time ago but can't find it. I wonder if in memory representations for compute such as apache arrow exploit this
tjalfi 6y ago
> Ages ago I had a conversation with a coworker about why was it that if databases collect statistics for optimizations, that data structures in programming languages don't do the same thing? Lus tables in LuaJIT, Hack arrays, and JavaScript arrays can use different representations depending on what is stored in them. NYU’s SETL project also did some work on automatically identifying what data structure should be used. IBM’s Hermes project was also working on this; I’m not sure whether they shipped it.