Thanx :)

Thanks!

Thank you.

Yes, I hate that wall so much :/

I didn't notice until you pointed it out :/

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++

That wagon-wheel effect

+Kirill Shvesov Yea

Thanks for pointing it out. Now I'm dizzy :)

is making me dizzy*

Holy shit! This.

Bruh are you Indonesian?

@@BossGxngOfficial sure

@@budiardjo6610 nyari teman dengan interested yang sama agak susah soalnya

I think he has learned that by now, video is from 2015.

@@MeetingCPP haha well seen

+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++.

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.

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!

+Nameguy didn't work & would also stretch the slides...

The arguments to the phi-node are flipped!

i think i don't understand why must they be flipped to be right?

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.

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

(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

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.