On sufficiently smart compilers
osa1.net
On sufficiently smart compilers
1–10 of 17 posts
Re: On sufficiently smart compilers
#2Tools already exist for doing run time traces of compiled programs and then optimizing accordingly. A lot of what they focus on is improving locality, moving portions of the executable that are run together near each other so improve the instruction cache hit rate. They also much more aggressively inline, to the point that the overall code size increases but hopefully so does performance.
You actually get a huge amount of perf gains just from improving locality, a lot of in-depth optimizations are possible but I am not sure what compilers now days actually do, it has been a long time since I worked on a compiler team!
Re: On sufficiently smart compilers
#3I'd like to see projects that can integrate the runtime information provided by a JIT VM. What if such a project used this information from the start? Then, the programmers might be able to use information like: This variable has only ever had an int in it, ever, over the entire lifetime of the app.
Such information might be problematic to integrate into a legacy project, but in a language which allowed for optional type annotation, such information could be fed into programmer tools and more easily analyzed. (Example: So, this code here where it's not an int -- do we really need to have this, or could we move the error checking elsewhere, so we can just say that's an int?)
Re: On sufficiently smart compilers
#4I'd like to see projects that can integrate the runtime information provided by a JIT VM. What if such a project used this information from the start? Then, the programmers might be able to use information like: This variable has only ever had an int in it, ever, over the entire lifetime of the app. Such information might be problematic to integrate into a legacy project, but in a language which allowed for optional…
Or you could use a language with static typing. It might be the line of work that I'm in, but I've never encountered a case where dynamic typing has really been helpful - more often it's been a source of errors, where non-obvious type coercion has been performed by the interpreter/runtime. I can only think of one case where dynamic typing was necessary, but I'll chalk that up to a really poorly designed COM API that I had to work with.
Re: On sufficiently smart compilers
#5I'd like to see projects that can integrate the runtime information provided by a JIT VM. What if such a project used this information from the start? Then, the programmers might be able to use information like: This variable has only ever had an int in it, ever, over the entire lifetime of the app. Such information might be problematic to integrate into a legacy project, but in a language which allowed for optional…
You could probably do this on native code with something like HP's Dynamo combined with the original symbols.
Re: On sufficiently smart compilers
#6Tools already exist for doing run time traces of compiled programs and then optimizing accordingly. A lot of what they focus on is improving locality, moving portions of the executable that are run together near each other so improve the instruction cache hit rate. They also much more aggressively inline, to the point that the overall code size increases but hopefully so does performance. You actually get a huge amou…
Got any links? I'd love to check out the tools you're talking about.
Re: On sufficiently smart compilers
#7> Unreliable optimizations and performance-critical software
This is why we will not have, and should not want, a "sufficiently smart compiler," but instead a "sufficiently predictable compiler." If the compiler is an enormously complex inference system, then tiny language-level changes can result in huge performance changes (see "space leaks" in Haskell, or "auto-vectorization" in basically anything). The solution isn't adding more knobs to the compiler; it's adding easier inter-language communication. Scripting languages like Matlab, Perl, Python, and R have been doing this right for decades: make a good effort at a specific domain (math, text, statistics), and make it easy to call into lower-level code for the key pieces.
Re: On sufficiently smart compilers
#8Tools already exist for doing run time traces of compiled programs and then optimizing accordingly. A lot of what they focus on is improving locality, moving portions of the executable that are run together near each other so improve the instruction cache hit rate. They also much more aggressively inline, to the point that the overall code size increases but hopefully so does performance. You actually get a huge amou…
Got any links? I'd love to check out the tools you're talking about.
Profile Guided Optimisation is the search term you're looking for. For one example: GCC does it (you may need to use gprof as well, can't really remember).
Re: On sufficiently smart compilers
#9I'd like to see projects that can integrate the runtime information provided by a JIT VM. What if such a project used this information from the start? Then, the programmers might be able to use information like: This variable has only ever had an int in it, ever, over the entire lifetime of the app. Such information might be problematic to integrate into a legacy project, but in a language which allowed for optional…
Or you could use a language with static typing. It might be the line of work that I'm in, but I've never encountered a case where dynamic typing has really been helpful - more often it's been a source of errors, where non-obvious type coercion has been performed by the interpreter/runtime. I can only think of one case where dynamic typing was necessary, but I'll chalk that up to a really poorly designed COM API that…
I've had the same experience -- that dynamic typing brings nothing to the party, and often actively gets in the way. I love C++'s extensible explicit static types (enums and structs), and when I don't have them in other languages, I miss them badly. I strongly suspect that dynamic typing is a fad, which will go away as languages change -- especially if programmers stop anthropomorphizing their code and assuming that it wants freedom and liberty. (Imagine if architects imagined that brick or structural steel wanted to be free!)
My experience is in healthcare, machine-language comprehension, enthusiast game development (roughly roguelike-ish -- I haven't ever scraped together the capital and the courage for graphics and music), a little genetic programming, and a little web development (where I outright used Hungarian notation to make Javascript less incomprehensible). What areas have you had experience in, where you've experienced the same?
Re: On sufficiently smart compilers
#10> Unreliable optimizations and performance-critical software This is why we will not have, and should not want, a "sufficiently smart compiler," but instead a "sufficiently predictable compiler." If the compiler is an enormously complex inference system, then tiny language-level changes can result in huge performance changes (see "space leaks" in Haskell, or "auto-vectorization" in basically anything). The solution i…
Space leaks are a bad example imo since they happen in other languages as well.