5 ms·

"Yes he does. And so do countless of other people. For example, I just gave a talk where I describe an afternoon optimization session giving me a 1000x and and

"Yes he does. And so do countless of other people. For example, I just gave a talk where I describe an afternoon optimization session giving me a 1000x and and 8000x improvement for a data-conversion and a query task, respectively. " Please be concrete about what exact data you think he does and countless others have. "Was the compiler helpful? Probably, I didn't measure with and without. But the vast majority of the improvement was not the compiler. And I don't see how the compiler could have come up with the changes (moving from a layered architecture of Model Objects -> ORM -> SQLite to a hexagonal architecture with an optimized data representation and completely different access procedure for the one data type that mattered)." First, you've actually said "i have no idea if the compiler would have fixed this, because i didn't run it". That means what you have is not actually data. It's an assumption. If you want to prove it out, that's data. You actually have to do the science if you want to say you've done the science. Second, Compilers do actually come up with such optimized data representations, memory layouts, loop walking, you name it (see, for example, https://hal.inria.fr/hal-01425546 https://hal.inria.fr/hal-01425546) Had you written it in a language that allowed for semantic changes of the kind you are talking about, we could make an optimizing compiler do it. 15 years ago I saw a compiler that did automatic splitting and distribution of COM objects to split up a game to run half on a server and half on a client. We can do this stuff. You'd just have to use something other than C/C++. Which is why more and more people are moving towards those kinds of languages ever day, and why more and more invasive "extensions" to C/C++ get made every day. Your particular example used to be the domain of dataflow, ETL, and stream compilers, all of which, yes, could reorganize your entire hierarchy to be better if you let them. As mentioned, this isn't about the capabilities of optimizing compilers, but about "what tradeoffs am i making in choosing my tools and languages". I don't think it's reasonable to, for example, program in qbasic and then say "optimizing compilers suck at reorganizing my data layout". Well, yeah. "On the other hand, the performance critical parts have gotten more critical. That means that the "make everything a bit faster, but without any guarantees" that optimizing compilers are great at providing is simply not that useful any more for a lot of workloads." Again, you strongly are lacking in actual data.

mpweiher 9y ago
> First, you've actually said "i have no idea if the compiler would have fixed this, because i didn't run it" No I did not. Please don't distort what I wrote (which appears to be the only way you have of 'making' your point) What I did write was "I didn't measure with and without", meaning I didn't do the cross check of what the total improvement would have been without the normal compiler optimizations, because both the original and the final were run with standard -Os optimizations, and because I have a fairly robust intuition in terms of the bounds of the effect. For shits and giggles, I now did the cross check. The difference between -O0 and -Ofast was in the noise. Sometimes the -O0 was faster, sometimes the -Ofast was faster, slightly skewing towards -Ofast and with times varying by around 10%. So let's be generous and assume that it wasn't noise, that it was 10% in the direction of the -Ofast option. Heck, let's double it to 20% just to be on the safe side. That's 20% vs. 1000x. Compared to the total, the contribution of the compiler optimizations vs. the manual optimizations is 2:10000. Or 99.98% vs 0.02%. Compare Proebsting's Law. The rest of your post is full of "had you" and "might have" and "could have". And you berate others for not delivering data. Hmm... And then you go off and cite research that did something that seems vaguely keyword-related to the things I described, but is actually nothing at all like it. Again, my example is CSV -> ( Object Model : ORM (CoreData) : SQL Database (SQLite) ) Transformed to CSV -> ( Optimized binary data model ) -> fwrite() And now tell me what concrete, existing optimizing compiler (production preferred, research might be OKish) is going to do that transformation and get me my 1000:1 performance improvement. No "there was a research compiler that did some data layout transformations somewhere", but concretely, a compiler that will take that first solution and automatically generate the second solution with the 1000:1 perf. improvement. Please also take into consideration that the CoreData ORM and SQLite DB are not available in source, but only via shared library / API. The original is described here: https://www.objc.io/issues/4-core-data/importing-large-data-sets-into-core-data/ https://www.objc.io/issues/4-core-data/importing-large-data-... My modified version is described in the talk: https://www.youtube.com/watch?v=kHG_zw75SjE https://www.youtube.com/watch?v=kHG_zw75SjE Code: https://github.com/mpw/issue-4-importing-and-fetching https://github.com/mpw/issue-4-importing-and-fetching Sample data sets: https://vbb-gtfs.jannisr.de/2017-05-10 https://vbb-gtfs.jannisr.de/2017-05-10 > Had you written it in a language ... If my grandmother had wheels, she'd be a bus. Starting an argument (or a logical deduction) with a false premise is not exactly useful. Sorry, if your idea of the power of optimizing compilers is "you need to first rewrite the code", then I can just rewrite the code to be fast and leave out the middle-man. Your argument here is ridiculous beyond the pale. > 15 years ago I saw a compiler... And I saw a UFO. This is your strong "actual data"? Yes, research compilers can sometimes do funky stuff in research settings. Same for JITs. I very much remember that special issue of the IBM system's journal on Java performance. It featured a bunch of reports from the researchers touting performance numbers, and then one real world report from the San Francisco project that reported their performance "challenges". See Jitterdämmerung: http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html > ...that did automatic splitting and distribution of COM objects to split up a game to run half on a server and half on a client. And how is this relevant to the example at hand, except in "proving" (which it doesn't, by the way) that compilers can do crazy transformations (which so isn't the point)? Was this a production compiler? Was it general purpose? Is it still around today? The point is not what compilers can do. It is how useful that is in practice. And yes, there exists code outside of Google data centers. > ...qbasic and then say "optimizing compilers suck at reorganizing my data layout" Nobody said that, except you. You need to stop making up straw-man arguments that you can then demolish, but rather deal with actual facts.

mpweiher 9y ago

> First, you've actually said "i have no idea if the compiler would have fixed this, because i didn't run it" No I did not. Please don't distort what I wrote (which appears to be the only way you have of 'making' your point) What I did write was "I didn't measure with and without", meaning I didn't do the cross check of what the total improvement would have been without the normal compiler optimizations, because both the original and the final were run with standard -Os optimizations, and because I have a fairly robust intuition in terms of the bounds of the effect. For shits and giggles, I now did the cross check. The difference between -O0 and -Ofast was in the noise. Sometimes the -O0 was faster, sometimes the -Ofast was faster, slightly skewing towards -Ofast and with times varying by around 10%. So let's be generous and assume that it wasn't noise, that it was 10% in the direction of the -Ofast option. Heck, let's double it to 20% just to be on the safe side. That's 20% vs. 1000x. Compared to the total, the contribution of the compiler optimizations vs. the manual optimizations is 2:10000. Or 99.98% vs 0.02%. Compare Proebsting's Law. The rest of your post is full of "had you" and "might have" and "could have". And you berate others for not delivering data. Hmm... And then you go off and cite research that did something that seems vaguely keyword-related to the things I described, but is actually nothing at all like it. Again, my example is CSV -> ( Object Model : ORM (CoreData) : SQL Database (SQLite) ) Transformed to CSV -> ( Optimized binary data model ) -> fwrite() And now tell me what concrete, existing optimizing compiler (production preferred, research might be OKish) is going to do that transformation and get me my 1000:1 performance improvement. No "there was a research compiler that did some data layout transformations somewhere", but concretely, a compiler that will take that first solution and automatically generate the second solution with the 1000:1 perf. improvement. Please also take into consideration that the CoreData ORM and SQLite DB are not available in source, but only via shared library / API. The original is described here: https://www.objc.io/issues/4-core-data/importing-large-data-sets-into-core-data/ https://www.objc.io/issues/4-core-data/importing-large-data-... My modified version is described in the talk: https://www.youtube.com/watch?v=kHG_zw75SjE https://www.youtube.com/watch?v=kHG_zw75SjE Code: https://github.com/mpw/issue-4-importing-and-fetching https://github.com/mpw/issue-4-importing-and-fetching Sample data sets: https://vbb-gtfs.jannisr.de/2017-05-10 https://vbb-gtfs.jannisr.de/2017-05-10 > Had you written it in a language ... If my grandmother had wheels, she'd be a bus. Starting an argument (or a logical deduction) with a false premise is not exactly useful. Sorry, if your idea of the power of optimizing compilers is "you need to first rewrite the code", then I can just rewrite the code to be fast and leave out the middle-man. Your argument here is ridiculous beyond the pale. > 15 years ago I saw a compiler... And I saw a UFO. This is your strong "actual data"? Yes, research compilers can sometimes do funky stuff in research settings. Same for JITs. I very much remember that special issue of the IBM system's journal on Java performance. It featured a bunch of reports from the researchers touting performance numbers, and then one real world report from the San Francisco project that reported their performance "challenges". See Jitterdämmerung: http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html > ...that did automatic splitting and distribution of COM objects to split up a game to run half on a server and half on a client. And how is this relevant to the example at hand, except in "proving" (which it doesn't, by the way) that compilers can do crazy transformations (which so isn't the point)? Was this a production compiler? Was it general purpose? Is it still around today? The point is not what compilers can do. It is how useful that is in practice. And yes, there exists code outside of Google data centers. > ...qbasic and then say "optimizing compilers suck at reorganizing my data layout" Nobody said that, except you. You need to stop making up straw-man arguments that you can then demolish, but rather deal with actual facts.