1:22:33 - my suspicion is that clang was spilling registers, which is always something to check for. They provide an amazingly wonderful tool called llvm-mca to do analysis llvm-mca takes as input the machine code and generates the intra-cycle pipeline analysis that it perceives a given processor architecture will execute.. (Most importantly where and why it will stall) AVX-512 with 32 regs was always somewhat of a wild idea, so it wouldn't be surprising that clang was not optimized for it

I fail to understand Google’s obsession to come up with a language better than C++. It would have been more productive if people tried adopting latest of C++ and help shape its future. These three goals for carbon seems out directly from reasons for not-so-positive-response from Go. I personally like what people like Herb Sutter is doing with experiments like cppfront.

Enjoyed this talk. I don't think I have laughed out loud at a cpp presentation. The crowd was in a good mood, too.

Why is it so hard for people to explain CMake, this is perfect example, i just wasted an hour in this, gained zero.

That logging scheme were he doesn't store strings on the MCU but returns an identifier, and the local machines figures it out!! That is amazing 🔥🔥

Great content, still a bit over my head, but I will rewatch later.

You just convinced me why I should use Rust🦀 , thanks!

I thought the obvious solution was to just pick one or the other to make immovable, but then I guess the same problem happens when it comes time to destruct one or the other, since the order of destruction shouldn't matter. Certainly a vexing problem.

I love writing Library than writing Application, and almost all my application have a Libraries, so it make application so simple, and extensible, … and<operator>

48:00 there is some name shadowing for `new_coeffs` within `update_coeffs()`. I believe all but one on the first line should be something else, e.g. `new_storage`. Otherwise, thank you for this excellent talk!

Best C++ talk on Modules I have seen so far! Most talks are either too abstract or too optimistic.

I'd like to add NUMA awareness to the EM solve openEMS which is severely memory-bandwidth bound

I really hope this gets added, finally a reason to upgrade c++ to a new version c++ is supposed to be fast, with this it will make it run 8 to 16 times faster. currently the main issue with simd is platform dependency, so if the standard is able to provide us with this and be able to automatically switch intrinsic instructions based on the platform without us worrying that would be a really big favor to everyone. Also i disagree with this guy at 1:17:25 complaining about the == mask, anyone who has programmed with shaders would already know that every operator or instruction you do will be applied to every element, thats why its called single instruction multiple data, it also helps us make the code more seamless, organized and more similar to shading languages.

Its funny I always have considered python as the sister language to c++. They are just so complimentary in so many way.

The ironic thing about the example specifically is that most likely implementations of operator<< are not going to be noexcept anyway. I know it is not the point of the talk, but one must be careful what to wish for.

I remember when learning std::cout almost 20 years ago and thinking "how is this better than printf"

this looks like a Renesas mpu RZ/T1

if only the SML examples were written for humans and not boost contributers.

Thank you! Best talk I have seen on this topic😊

8:49.. if I'm correct the optimization actually meant should be loop invariant code motion (LICM) [and if to mention "common subexpression", common subexpression elimination (CSE) is something completely different]. Now, LICM would never do this particular code motion since it is not possible for a compiler to prove that this is an invariant with no side effects (it knows nothing about the pthread_* function implementation and it is definitely not a pure function)... maybe there should be a better example here (?)

One should also look at how Zig does it since they also have a data-oriented approach for their compiler which lead to a very fast compile time.

is there anywhere this has been uploaded without the horrific perpetual background coughing and footstamping?

What we will have to wait and see is if Carbon actually can achieve seamless C++ Interop. If we have both Carbon and CppFront offering a modern language and seamless C++ the future will be very exciting.

Undefined behaviour should have been SG13 ...

1:14:00ish - thinking in terms of preconditions - those requirements need to be machine-enforceable. That might be more painful to use, but think of Concepts - these kinds of tools ought to help, not hinder us.

In 2024, it seems this went nowhere.

It’s funny that he mentioned “community” as a Rust language feature he’d like to have in C++. Rust’s community is incredibly dysfunctional. That is a major reason I avoid Rust and prefer C++.

Thank you so much, this talk blew my mind on so many levels

so much thanks for the great talks

great talk 🚀🚀

I'm 15 minutes in and find this to be one of the best technical talks I've ever seen.

writing c++ isn't so bad, but getting an executable out of it makes me want to smash my keyboard. the learning curve for a newcomer is just insane.

Im going to disagree with memory exceptions never being useful. Ive written code where there was memory that could be freed without too much loss as it was the oldest item on the undo stack. I can also see its usefulness in discarding cached data, which can be recreated later at either computational expense or data transmission expense. This only works if the memory exception does not allocate memory and the location it is thrown does not corrupt the data.

Attiny13 is old, it would be nicer if you replace it with the modern tinyAVR series like ATtiny412 8 pin smd package

This was one of the craziest C++ videos I've ever watched. Took me 4 hours to watch and (partially) understand what's going on. I am genuinely captivated by the ideas presented and the mindset behind these elegant solutions. Many thanks to Mr. Hagins for this great presentation.

This was interesting, great light talk!

Yet current state of Swift in 2024: - average performances (not even close to replace c/c++ perf wise). - overly complex type / generic / protocol / existential system. Not only making the program difficult to reason about but make compiling take so much longer, and you will spend most of your time fighting the type system instead of being productive. (try to serialize heterogeneous arrays just to give it a try). Arrays of existential which are supposed to give some flexibility actually uses twice more memory than concrete types and hinder performance with additional indirections. Also existentials do not conform to their own protocol and they stated this case is probably not solvable (so much for the "we think we can solve all issues" at the end of the conf). - broken compiler / debugger / autocompletion / diagnostics. You can't even print the value of a variable most of the time and it takes forever just to get a single value. We are back using print everywhere as breakpoints are so slow and so buggy. If you make mistakes in your code, (even worst in swiftUI), the compiler analysis will either give up, point to the wrong line or give you an unhelpful message. - Over complex concurrency with Actors that nobody gets correctly (also because of lack of documentation as usual with Apple) and which is brought up constantly on Swift Forums. - broken Macro system with huge performance issues. For the last two: some will say "it's new and we should be patient" but that's what we have been hearing since the beginning of Swift. And things *never* get fixed. We haven't been able to get reliable basic stuff like debugging or refactoring in 10y now. Just to name the latest one: Xcode 14 -> Xcode 15, same code, takes twice the time to compile. Still not fixed. The fun part of the talk is how McCall points all the issues of C/C++ but not WHY people have putting up with them for so long: performance. You want to replace C/C++, your language should be as performant as them. If not, you can solve every safety problems you want, it won't. People who don't need performance already switched to other programming languages with managed memory. What will replace C/C++? Zig, Odin, Jai, Rust, to name a few. The difference? Those languages are built bottom up and not top down with dogmatic principles like Swift or Haskell. You take Odin for example, not even 1.0, already battle tested in production with a huge and successful app showing incredible performance. Unlike Odin, Zig, Jai, who are created by performance expert from day 1, most programming languages are created by programming language theoreticians. That's their expertise: theory, not making products which is the end goal of all programming languages. Pragmatism vs Theory, pick your camp. I am a Swift programmer since day 1, but I am getting tired to wait for them to deliver on all their broken promises. So looking for alternatives.

Reminds me a lot about what Zig & Jai tries to do.

1:05:10 How could `p` change? I get that the number that `p` points to could change, but how could the pointer itself change to something else? It's not a reference to a pointer, just a pointer, it's just a local variable in the function.

Slides here: raw.githubusercontent.com/boostcon/2011_presentations/master/tue/spirit_qi_in_the_real_world.pdf

Nice presentation and style

The key to getting good auto factorization - use a static size (preferably cache line aligned) frame to iterate unknown size data , finish off any remaining items at the end in a separate loop, this way most of the ops are vectorized and only the unpadded remained is done in scalar.

Anyone else get the feeling that C++ is conceding that Fortran got this (more) right after all (with ALLOCATABLE and POINTER)?

"int main(int argc, char**argv)" is NOT what "don't repeat yourself" is about. First of all, there is not even any _repetition_ here. This _definition_ exists _exactly once_ in each program (the _declaration_ is implicit in the C standard itself). Bad example! Bad!

99% "service level indicator" is laughable. If a piece of hardware running at a measly 1 MHz would be expected to fail every _tenth of a millisecond_ . It would _literally_ not have enough time to be brought to power before it halts.

meanwhile, a CPU will execute _quadrillions_ of instructions each day and not fail _one_ A CPU will likely go through its entire life not misexecuting even one instruction. A heart has _worse_ availability, considering at a very old age it misses cycles.

'_' is not a wild card. It means 'i dont need the data' , rust will complain is you do not use a variable unless it starts with _

What is precisely meant by no interaction between NUMA nodes if only talking to L3 cache at kzbin.info/www/bejne/nGG9fHWrqMZneasfeature=shared&t=2005, in terms of effect on memory bandwidth?

I would love a typescript-idea for C++. It would be so great. We can add things like compiletime reflection in a much easier way.. we can add things like the meta language Herb talked about previously. We can finally get rid of the extreme verbosity of the language. All the while maintaining full compatibility with normal real C++. I'm all for it. Also default package managers please! Please please for the love of everything please. Few things i'd like to see: noexcept by default (and specify when you do want it), lightweight exceptions by default which are syntactic sugar for error code returns, const by default unless you specify something isn't const. Don't make me write a const and non-const version of the same function. Dont make me write a ton of overloads for copy and move.