Understanding Compiler Optimization - Chandler Carruth - Opening Keynote Meeting C++ 2015
Vložit
- čas přidán 18. 12. 2015
- Understanding Compiler Optimization
Chandler Carruth
Opening Keynote Meeting C++ 2015
Slides: meetingcpp.com/files/mcpp/201... - Věda a technologie
![[柴犬ASMR]曼玉Manyu&小白Bai 毛发护理Spa asmr](http://i.ytimg.com/vi/0TsXQ7z2Dh4/mqdefault.jpg)
0:00: C++ performance based on compiler optimization
6:10: high level parts of compiler
9:10: LLVM's IR example, simple routine
10:22: LLVM's IR example, modelling data control flow
16:38: optimizer duties, cleanup
18:56: optimizer duties, canonicalization
22:26: optimizer duties, collapse abstractions
23:40: 3 key abstractions (function calls, memory, loops)
25:48: function calls abstraction, inlining
27:40: function calls abstraction, call graph
36:18: function calls abstraction, variadic functions
40:28: memory abstraction
44:20: memory abstraction (partitioning, isolating, other)
50:51: loop abstraction
54:30: loop abstraction, canonicalization
58:50: loop abstraction, loop unroll
1:04:00: loop abstraction, invariant control flow
1:09:00: loop abstraction, questions from audience
1:30:58: optimizing combined abstractions
1:35:30: const not optimized
1:37:52: conclusion and questions
Thanx :)
Thanks!
Thank you.
Kudos to whatever genius decided to put the dot pattern at the back of the stage, so that any camera motion is distracting at best, and nauseating at worst.
Yes, I hate that wall so much :/
I didn't notice until you pointed it out :/
When he asked the crowd if they are excited about C++ I was totally with him. :D
How can you tell a C developer versus a C++ developer?
The C++ developer is hyped for both, the C developer hates anything that is not C
@@ChristopherGray00 Usually c++ people complain about how bad C is all day and how you're a mongrel for not using C++
This cellular background makings me dizziness.
That wagon-wheel effect
+Kirill Shvesov Yea
Thanks for pointing it out. Now I'm dizzy :)
is making me dizzy*
Holy shit! This.
The first suggested video linked to this one is "Don't help the compiler" haha.
1:45:41 "once you have code that is clean on the sanitizers, then you know you have a compiler bug" "If we don't sanitize for it, we aren't going to optimize based on it"
That guarantee makes me feel warm and fuzzy inside.
Chandler dude when someone asks you a question, please stop walking, and surely don't give him your back while walking. Also when there is a question in the public, please repeat the question so everyone knows what you are answering to....It is abc in public talking. Except that, brilliant lecture.
I think he has learned that by now, video is from 2015.
@@MeetingCPP haha well seen
I know this is five years old but looking through this comment section is a bit sad. It’s a pretty good talk.
8 years later this person build carbon language
Bruh are you Indonesian?
@@BossGxngOfficial sure
@@budiardjo6610 nyari teman dengan interested yang sama agak susah soalnya
The slides going out of sync made this really hard to follow.
Very interesting talk. I am not familiar with fortran so I did not exactly follow what he said at 1:20:59 . As for sanitizers, yes ubsan is cool but it is runtime. This is the type of stuff I want to catch with static analysis.
What a fantastic talk.
This is pretty hard to follow because the slide shown doesn't sync with the slide he's talking about. E.g. around 1:03:00 is pretty bad.
+Jean-Francois Caron Well, slides aren't recorded, so at some point it wasn't that easy to get it synced. But you can download the slides from Meeting C++.
thank you very much sir
Wow ! So great. You help me a lots.
20:40 Doesn't that discard potential branch prediction hint from the programmer who might know if it is going to be more likely for the 'if' condition to be true?
I have been wondering, what kind of information we could provide within our source code, for example through annotations, that could help the compiler to optimize better or to allow completely new optimizations? We could add new annotations as we find more useful information for compilers. What kind of information the developer knows of how his code should work that the compiler could use?
The top priority that comes to mind for me is hot/cold splitting of both branches and especially data. We have a lot in the way of indicating hot/cold branching paths with most compilers although they tend to be compiler-specific, such as 'likely' and 'unlikely' in GCC, '__assume' in MSVC, and 'noinline' and 'forceinline' available in most compilers.
The trickier part is hot/cold splitting of data (and it tends to make the bigger difference in most domains). Consider an example like this:
struct Particle
{
// hot fields constantly accessed in critical loops
__hot float x=0.0f, y=0.0f, z=0.0f, w=0.0f;
// cold field only accessed in non-performance critical UI areas
__cold uint32_t q = 0;
};
Ideally in a such a scenario, storing a collection of particles such as in std::vector would not store all particle fields in a contiguous interleaved format like 'xyzwqxyzwqxyzwq', since 'q' would not be accessed in those critical loops. Loading it into a cache line would just be loading irrelevant data into it and wasting it. Instead it should store the data like: 'xyzwxyzwxyzw....' with an array for the cold field(s) like 'qqqqqq....' in parallel. Things of this nature, or even being able to store an SoA representation of such a structure without collapsing it into multiple structures.
@@darkengine5931 thanks this was very helpful :)
with o2 or o3 flag, the compiler isn't leaving out optimizations that you could otherwise specify with annotations, the idea is that it already does all of that for you, providing optimizations without the sacrifice of safety (as long as you are not using o3 then maybe)
Ada's strict type system specifies intent, which hints possible optimizations to the compiler.
very descriptive :)
Thanks
You didn't have to re-upload. Just add the tag "yt:stretch=16:9" to the original video.
+Nameguy didn't work & would also stretch the slides...
Around 8 minutes in, the AST is mentioned, and dismissed as uninteresting for this subject.
Isn't the AST a great place for optimizations?
AST is Front End level representation of a program, it is a good place to do language specific optimizations. LLVM Intermediate Representation level has no language specific (although it inherits some notions like memory model from C/C++11) and this is good from compiler architecture level.
Here you see Clang AST, but what if you want to create other than C-like programming language? In this case you will have to create another Front End which produces its own AST so to be able to benefit from generic optimizations and machine code generation (this is already implemented in LLVM) it may translate it to LLVM IR and voila, you have a complete working compiler for a huge variety of target machines from Intel, AMD, ARM, and so on.
Пеш Любоп
Thanks!
1:35 "they get ever smaller" he doesn't know
Awesome point 4:30
What was the bug at 18.40?
The arguments to the phi-node are flipped!
i think i don't understand why must they be flipped to be right?
I had fun learning something new but that's about the extent of it. I would not remember any of the details after a week, except for some key takeaways which could have been like 5 slides. Great talk nonetheless.
To help dem lost culture in germanies: The Goldilocks principle is derived from a children's story "The Three Bears"
in which a little girl named Goldilocks finds a house owned by three
bears. Each bear has its own preference of food and beds. After testing
all three examples of both items, Goldilocks determines that one of them
is always too much in one extreme (too hot or too large), one is too
much in the opposite extreme (too cold or too small), and one is "just
right".[1]
✅
It sucks that we can't unite and put our collective effort on researching better optimizations, tools and methods that allow those optimizations etc.
How many devices we have that run C/C++ coded kernel and software? If those devices are battery powered, then saving CPU is having even more benefits. All major software and hardware giants should donate to this research, or participate at least somehow.
Interesting question is what is theoretically possible, or what can we know for sure is or isn't possible, if we would have like exabyte of ram and exa instruction per second CPU and couple of days time to wait for the compiler to optimize. Perhaps in the future we compile the production quality version by sending our sources to supercomputer that does the optimization. While this sounds funny right now, there are still lots of thought behind these lines that hold truths. Anyway, bug free coding to you all =)
those dots on the wall make me dizzy
The prerequisite for this talk: Assembly language.
The Intermediate Representation may resemble assembly language, but it is not. It is abstract, representing operations on values but not machine-level operations on memory locations and physical registers.
"The keyword inline has nothing to do with optimization"...
Say that again?
it tells the compiler the symbol or function can appear in multiple translation units and not to freak out, it does not tell the compiler to inline it.
It sometimes gives a hint to the compiler but the compiler is free to ignore it (or decide to inline something you didn't mark inline)
The only guarantee is inline allows repeating the definition in multiple translation units
@@jonesconrad1 But it allows it, so it has something to do with it, a lot actually #ThatsWhyPeopleUseInlinePrimarily
Compiler and language builders are doing something wrong if they consider "const" as not helpful. It is information and can be a guarantee something does not get modified. That the "constness" can be casted away for out of program "API reasons" is no excuse. Having such a cast anywhere else in the code is just as bad as a non-atomic memory access in a multi-threaded application and would just be a bug.
People link libraries, and especially there, knowing a provided argument will not change during a library call is gold. There is no other way to optimize that case with the same guarantee that the argument will not change.
It is not the first time I seen this attitude among language and compiler builders and it annoys me quite a bit.
(Not counting const_cast) I believe you're mixing up "const" with "immutable". When I have a const reference to something, there's a guarantee that I won't change it, but there's no guarantee that nobody else will change it. See stackoverflow.com/questions/4486326/does-const-just-mean-read-only-or-something-more I think what you want is a language that takes immutability into account, so you'd want something like functional languages or Rust.
I believe you could make an argument that that's a language level issue and not really the compiler's fault
@@Verdagon Rust pretty much ignores immutability when compiling because LLVM is so buggy when you have so many consts. Yes really. It used to but then they had to disable it because of LLVM bugs
@@Verdagon stackoverflow.com/questions/57259126/why-does-the-rust-compiler-not-optimize-code-assuming-that-two-mutable-reference/57259339#57259339
the alk gave me idea about compiler innerworking....................
Claiming that C++ is the fastest with least overhead and totally forgetting about C.... Not saying that C is completly superior but it is still quite relevent in these aspects...
Well, C++ is superior, as it has access to a different feature set, that isn't available to C. While C is a subset of C++...
I disagree. In theory it can be but in practice it isn't due to way C++ is normally used. The way C++ classes tend to be organically made plays havoc with the cache and is very anti-data-oriented.
Saying that C is a subset of C++ is completly wrong. They are different languages with different grammar. Expressions can be valid in one but illegal in the other. And BECAUSE of the bigger "feature set" it starts with a disadvantage for optimization, given that nowadays this is not really an issue. Still if C++ would be superior in every aspect then C would not be the number 1 language in embedded development( at least this is what I last saw in usage polls). Still I don't say C is generally superior, I just say C++ is not generally better than C nor is C a subset of C++. They evolved differently.
Spot C programmer.
C++ is a mix of high level Java like programming mixed with the possibility of using pure C anytime you desire. That is what makes it so powerful.