Thank y'all for watching! ❤️ Do you want to see more optimization/performance stuff? Also don't forget that the first 1,000 people to use this link will get a 1 month free trial of Skillshare: skl.sh/thecherno12211

@martiananomaly

2 жыл бұрын

Nice

@mr.mirror1213

2 жыл бұрын

I want more optimization stuff so we can implement it in our own work

@art0nsec

2 жыл бұрын

I definitely would like to see more performance related stuff

@BlenderhilfeDe

2 жыл бұрын

this topic is so interesting and you explain it very good :) thx!

@karelnemec6770

2 жыл бұрын

Hi :), just stop asking and record additional video RIGHT NOW!!! :). Your skills are incredibly insane. Pleeease mooooooore... 😅

Man, I never thought you would pick my project! Definitely made my day!

@vale1286

2 жыл бұрын

Just a couple of comments: - I am puzzled by the slowdown in accumulate! I remember testing it against a raw for loop in simpler usecases and it even turned out a few % faster. Granted, it was on gcc so it could be MSVC related, but somehow that would be equally surprising :\ - I don't like the whole 100% object oriented theme of the project as well, but I decided to follow the original book in that regard because I wanted to do everything in a weekend, and changing the whole architecture would have taken way longer :)

@TheCherno

2 жыл бұрын

Glad you saw it! Was about to send you an email asking if you had these performance issues as well, I had a feeling it might be compiler/library-related. Thanks for sending in your code!

@vale1286

2 жыл бұрын

@Harry Byrne Well, the goal was to follow the original book and I wanted to be done within the weekend! So this was my attempt to get familiar with the topic in a reasonable amount of time :) I'd like to solve the big issues first (design a better scene model, get rid of all the unnecessary hierarchy and so on...) before getting on the GPU, which is a completely unexplored land for me!

@vale1286

2 жыл бұрын

@@riidefi1575 A unwanted copy of the shared_ptr would explain a lot (with the control block being copied for every ptr in the container...) But the lambda takes the arguments as const& so I think this is up to the library implementer to make sure things are forwarded correctly to the function, right? Maybe this is why I never had problems with gcc and clang libraries... definitely gonna check this out later on

@vale1286

2 жыл бұрын

​@Harry Byrne Yes, I am! I'll gladly take any help I can get :)

You can tell this is a physicist's code because they're used to wait weeks for simulation results... 😂

@colonthree

5 ай бұрын

Malappropriation of physics, then, as programming is also physics.

@TBButtSmoothy

5 ай бұрын

too much philosophy, not enough practicality@@colonthree

@mad_circuits

4 ай бұрын

Ahh, physicists bashing, I'm in. 😂

Fun fact! std::accumulate actually did have a bug in it that was fixed in C++20! (See the #if _HAS_CXX20 clause at 24:59). std::accumulate was originally meant to accumulate small objects, so it passes things by value. As of C++20 it moves the values since they could be large. I'd be curious to see the performance improvement just by compiling with C++20! As a side note, I'd say that this operation, finding the closest object, doesn't really accumulate anything, so although accumulate can do the job, I would argue that a for loop expresses the intent better anyway.

@scoreunder

2 жыл бұрын

As someone who does FP a lot, I feel like it does accumulate: it accumulates the minimum distance for a ray bounce. But maybe I'm just mind-poisoned by HOFs?

@mCoding

2 жыл бұрын

@@scoreunder Hahah I wouldn't say you're _poisoned_ by functional programming, perhaps enlightened? Of course, with higher order functionals, you can build very unexpected/general things out of some basic building blocks. But from a more grounded perspective, it seems unlikely that a highly optimized algorithm could remain optimized for an arbitrary functional as input. Personally, I find that if the lambda you pass in is larger in size than the algorithm itself, then it is highly likely you will find a performance hit waiting for you on the other end. I most often prioritize readability and I also find that when the intent of something becomes unclear (perhaps a _clever_ lambda to an algorithm) the optimizer will also not do very well. Don't get me wrong though, I'd love everyone take the opportunity to learn some category theory.

@fromgermany271

2 жыл бұрын

Why std::accumulate at all if you want to do std::for_each?? Typical „I don’t understand the new stuff, so I stick to the old“. He even thinks „range based loop“ is different from „old style for loop“. If so, he should get a working compiler.

@VastyVastyVoid

2 жыл бұрын

@@fromgermany271 I may be misunderstanding what you mean, but several modern Cpp books (notably Accelerated C++) stress the semantic value of std:: accumulate. In other words, std::for_each doesn't tell us the intent if the code; std:: accumulate does (it's a summation).

@fromgermany271

2 жыл бұрын

@@VastyVastyVoid I meant: he has a problem with std::accumulate and says „to slow“ and „classic loop is faster“. I say, accumulate changes a „sum“, that does not really fit to „parallel“. But I cannot see why a „sum“ should be needed at all. But in general saying „I don’t understand something in stdlib, so I just fall back to C-style“ is something not uncommon, but not applicable for talks.

I for one would love to see more optimisation stuff. I'm currently in the process of learning how to write high performance code, so learning how to self evaluate a program's performance via either code inspection or using tools to develop metrics will be huge for me. That said, I'm just happy to see a Cherno video in my sub box either way, so thanks for taking the time to create and upload this video.

@TimeFadesMemoryLasts

2 жыл бұрын

Btw. a really nice way that helps is to use a very slow chip that restricts you a lot, like for example an Arduino where you get hit hard if you code inefficiently.

@xeridea

2 жыл бұрын

A big part of optimization is similar to this video, finding slow parts, and cutting out unnecessary overhead. Giving the CPU less work. That and keeping cache sizes and layout in mind, which is easier to consider if using simpler methods with less abstraction. Modern desktop CPUs tend to max out at 32MB L3 cache, but it is better to try to stay within 8MB.

@epiicSpooky

2 жыл бұрын

It's mostly what you see here - use a profiler, because often there's something bad but hidden somewhere non-obvious. (It's often not worth even guessing like he did, start with the profiler to avoid biases.) Avoid unneeded copies. Avoid replicating the same expensive work. And in C/Rust, prefer stack over heap. It's much much further down the line that it makes sense to start worrying in more detail about cache implementation details. But don't forget readability is critical. Your future self will appreciate it.

@tadghhenry

2 жыл бұрын

@@TimeFadesMemoryLasts Sorry im missing something do you mean running with the whole ide or just the compiled code itself?

For the slowness of `std::accumulate` I'm sure it's down to the copy of the `std::shared_ptr` inside the HitRecord, which do atomic operations to keep the refcount up to date. In C++20, it's not copying it anymore. The best would be to not use shared pointer at all.

@DimiterStanev

2 жыл бұрын

That's what I thought too, and made a little proof myself, by cheating and making it (for a bit just plain pointer), then std::accumulate was still fine (C++17) - with 20 and std::move() on it - even better.

@yokebabjr3866

2 жыл бұрын

Yes and we could also have use std::reduce and use C++17 parallele algorithm to get the code vectorized easily

@sephorusFR

2 жыл бұрын

this should be pinned. std::accumulate is in no way the problem. Shared_ptr is.

@Narblo

2 жыл бұрын

Could be also the lambda call where here is just a loop. The jump may mess the cache unless the compiler is good enough to inline the lambda in

@DimiterStanev

2 жыл бұрын

@@Narblo It's not that, it's really lots of "lock xadd" (atomic inc/dec due to shared_ptr copying). Granted that was on my machine, with my RAM, my CPUs, etc. - it may be better on others, but maybe even much worse (with say NUMA configs). For in house game editor we had to disable one of the CPU's in it to avoid that, as we've been also guilty of over-using abit more of shared_ptr - though not like this.

Hello Yan, I would love to see you optimize this code. The fact alone that replacing one single function with a for loop can yield such a performance boost shows how good this code is. It is definitely a great starting point for a video about optimization. Given the fact that the accumulate function was written in order to be used in cases like this, it being so slow isn ´t something that a coder should have to worry about. It ´s a language related problem. You have already started talking about playing to the strengths of the hardware architecture. This performance boost was possible because the coder didn ´t know what the accumulate function actually does. You might even go as far as to explain the different features of 32 bit and 64 bit processors and assembly language and then go back to explaining how c++ as a language actually utilizes them. That would be highly informative, albeit really time consuming, but this very code example shows how easy it can be to go from a working piece of software to a really satisfying experience for both coders and users if you are aware of the inner workings of your tools. In short: Please do it. I love your content, by the way, and have been a subscriber for a long time. All the best to you and your loved ones from Germany.

@phantom_stnd

2 жыл бұрын

Its not the function, but the copy of the shared pointer that causes the slow down

@RucadiDev

2 жыл бұрын

@@phantom_stnd Exactly this.

@adamp9553

2 жыл бұрын

Only the really bottlenecks need to be optimized. I think Yan tackled that well enough via the profiler. And assembly is diminishing returns these days compared to intrinsics and modern compilers that automatically find intrinsic equivalents.

Please a optimization on this code! It would be very entertaining and educational for everybody! I personally would love to see that video!!!

In my experience, when changing a single part of the code can speed things up so much, the problem is almost always some kind of superfluous copy somewhere. Also, an additional optimization video would be really nice!

@skilz8098

2 жыл бұрын

Less unnecessary copying and more usages of move semantics or using references to objects definitely helps towards improving performance and efficiency making the code already pre-optimized.

The speed you analyzed the whole project is impressive! Raytracer is one of the projects that I want to do in the future. At the same time I really love optimization videos so I cannot wait to see the continuation :^)

Please do more of this!!

This has been an excellent bloody episode Cherno! Please continue with this guys project! so so so informative and practical!

I think it would be an amazing series, take this one codebase, one episode going deeper on why virtuals were bad in this case, de-OOPing it, a longer one bringing misc stuff closer to the metal, and the final one doing it on a GPU.

These aren't just code reviews, but absolute masterclasses as to why one approach wins over another. I've learnt so much in this 38 minutes than I've learn in the last 5 years!

@yohannes2kifle

2 жыл бұрын

What have you been doing the last 5 years? Did you have internet?

@simonbaxter8001

2 жыл бұрын

@@yohannes2kifle Too busy churning out products and applications! 😉

@svnhddbst8968

2 жыл бұрын

also learning the methodology of diagnosing inefficiencies. the way he does it here for a c program still applies to all languages "break down to verbose and deliberate to see which step is causing the problem".

Thank's Cherno! As always, great video. Definitely interested to see you further optimize the code and squeeze out a better performance. Also I would love to see you porting that to a compute shader.

Thank you for delivering such a masterpiece video, I love it so much and learned a lot! I am as motivated as you do, just planning to write my own raytracer using compute shader next month!

LOVE the optimization videos, please make more!

I love watching optimization. It helps my mind negotiate code decisions to do optimizations by default

I want a Cherno, who does such videos with the Rust language 🦀. But still love it.

This is exactly the content i wanted to see. Old school coder myself, i struggle a bit on learning modern c++ stuff on my free time, so it's great to see that raw quick comparison. The explanation and clarity from Cherno is hard to match on any other material you might find on the web. Loving it. ❤

OH my gosh I remember watching you and learning some programming from you when I was still in primary school. You made me pursuit programming and suddenly seeing one of your videos in my feed brought back a ton of memories of me trying to figure out Java as a tiny kid. Now I'm studying cybersecurity and software development, working my way through!

I'd love to see both of your own fully optimised version of this implementation as well as a GPU based "ray tracing in a weekend". I think they would both be fascinating.

Just amazing, keep up the work!

Keep going. Let's see how far you can take it!

Fantastic video. I would love to see you optimize step by step this code. Great Job Cherno :)

I love this optimization showcase :) would be delighted to see more

I would love to see you go through and refactor/optimize the code (get rid of the std usage where it's superfluous etc). Someone also mentioned C# and using that to achieve similar results would be really cool. Span was added not too long ago to help with stack-allocations without having to use unsafe and stackalloc.

Started following you recently because of a friend recommendation. I'd love to see more optimization videos. Loving your channel!!

Hey Cherno, first video I've seen, but I like your approach to code improvement. Hope you kept a similar style since then :D

Super informative, the stuff that I learned here I could implement in my own projects :) Would love to see another optimization video ( would not object to a series like this :D )

yess bro iron out this project in another video. love hearing you optimize stuff and seeing this sort of thing from you!! awesome vid man

This was a great video! As a person who just rewrote a pure C++ project in a more C-style C++ I can relate. I was taught that the explicitness of C is inherently bad and it was an eyeopener to realize this is not the case.

@danjohnson6800

5 ай бұрын

Very true! C is blazingly fast, C++ is well organized. There is a performance tradeoff in the organizing, forcing memory swaps etc., so would always do a back of the envelope performance calculation to be sure I wasn't wasting cpu. I started in C in '86 when we didn't have CPU to spare! So performance has always been in mind, and the success of many projects came down to that as they grew in size and complexity.

No, the optimization part is very interesting, helpful and useful. I think continuing down this road is a great course of action to help others to improve their own code bases / frameworks. It should help to give them insight towards their own approaches on how to analyze and profile their own code, what to look for, and how to optimize or improve its performance. Great Video!

Great video, really want to see more optimization stuff!

Great video and fun to watch. Would definitely like to see the optimization part of this. Especially considering how much faster you got it going so soon after you started looking into it.

Incredibly interesting! If you do end up making a follow up video, then I personally would like to see your take on CPU cache coherency.

That was really sick, seeing which code impacts performance in what way is awesome! Definitely would be a great idea to investigate further optimizations and/or create the fastest ray tracer yourself !!!

Inspirational! I'd love to see your optimization process

That was a very interesting code review to watch! Man your understanding on this topic is impressive, keep on the quality work

glad to hear other people from Italy!

I would love that additional video, I love optimization/profiling videos!

Another core review yaaaaaaaaaaaaay love you

Bakko: It's multithreaded 😎 Cherno: 👁👄👁

Go faster!! See how much improvements you can make! Would love to see that! And also I would have also loved to know what was the time using the improved code with the sampling rate and bounce set to the original, 500 and 50 I think...

Yes, please continue digging into this.

Thank you Cherno for your great video! I also recently followed this ray in the weekend tutorial and it's really cool! I'd be glad to see your tutorial about how to run this on GPU!

Great content! I loved this. :-) I always enjoy learning new things after profiling a bit of code.

It will good to see you optimize that further.

"raytracing in a weekend" is actually how long it takes to render the full image on an average computer

@Exotic69420

6 ай бұрын

😂😂😂😂😂🎉

I would love to see you further improving this code!

This Videos are amazing. Thanks to watching them I learn a bit of how to optimise my code and I don't even use C++.

great video! would definitely like to see you go further with it.

Optimizations would be great to see, there is so much you can learn out of that!

Ofc we do chernno. Everything u do is amazing and so informative ❤❤❤ tnx a lot for ur time

The optimization episodes are fun lol more please

I'm always happy to see these go into "Cherno fixes your code", which is actually my preferred series.

Taking the step to running on the GPU would be very interesting. I'd definitely watch a video (or series) of you coding up a more optimized implementation.

I love unique pointer wrapping array, but only if this is necessary. Normally I would use a vector, but when I'm implementing something much lower level. In my codebase you'll see some `std::unique_ptr` and I use it to implement a vector of a runtime defined structure. Mainly to contains all uniforms for a list of objects to render, or to initialize a structure of buffer objects for opengl.

Totally +1 on the optimization thing ,the difference is HUGE, thanks a lot for this great quality content

Yes! You should do an entire series on this! Like the lowest level you can reasonably get. Math and all would be awesome!

More optimizing of ray tracing. I appreciate how you got the language overhead out of the way and made the logic closer to the metal.

I'd be interested in the optimization part. It would be interesting to dig in to see what exactly was slowing it down before.

Interesting! I love optimization / performance stuff!

Would like to see a follow-up video on optimizing the code, including checking the assembly and if the compiler doesn't make use of SIMD already, then also something about that for the hot path.

best video of the series so far, loved it :D

yes definitely want to see you optimize the heck out of this code specifically

I would love to see this project be even more optimized and more optimization stuff in general! It's so satisfying seeing code be optimized ^^

I'd love to watch this sort of stuff based on UE4's blueprint system. Really informative, dude! Love it :)

Very cool code review and profiling, super interesting and useful!

Love to see how far you can get this perfomance wise

Fascinating. Want to see your raytracing implementation.

YES I would like to see you fix it to the MAX like you partially did today!

With 7.5 minutes of rendering time, the objective "Raytracing in a weekend" had already been achieved by a large margin 😊

Wow I loved this, please continue the optimization.

I would love for a series revolved around optimization of generic code (not just HAZEL)!

Not sure how everyone else feels, but I like watching when you go in-depth in these reviews. Either just doing a proper review that takes an hour or doing these optimizations that take an hour. It's a really good way to learn when we actually understand what's wrong with it. Also, actually getting to see the optimized code being written is good when we aren't super familiar with the language but understand the concepts.

I would definitely be interested in seeing more optimization stuff in this project. Also we should be aware of how c++ actually commonly implements the language features we use.

This was helpful a lot! I'm currently writing a game about spaceships and gravity and stuff, and by removing some inheritance and other object oriented stuff from my simulation low level and math layer I instantly doubled the performance.

Make it as fast as you can!!!! Love seeing the mechanics of the optimization.

Honestly, this is the best KZread video you've made so far.

You should do a video on how to navigate VS, like shortcuts and what not. Your ability to navigate VS like it's vim is impressive

"I could have *written* a ray tracer in that amount of time..." GOLDEN! :)

He mentioned not liking the usage of unique_ptr for a buffer, and preferring vector instead. vector gives you a size, which is nice and a bit less implicit, and resize() is a bit more terse. Though there is an overload of make_unique for arrays that takes an array size (e.g. make_unique(1024) or what not). It didn’t look like that was used in the given code, but it’s fairly terse too. One big difference in some contexts is that unique_ptr is a much more lightweight template than vector. I had some heavily templated code with a fixed but dynamically sized array where switching from vector to unique_ptr cut the compile time in half. This code didn’t look to be heavily templated so it likely doesn’t matter, but it’s useful to know.

Suuuuper keen to see how you further optimise this and to see your GPU version.

This code is amazing with its great description of the task through OOP structures and logic, but at the same time it is a great example of overusing OOP

Since you asked for opinions about the unique_ptr array, here's how I handle it. If I'm needing an array where I need to push/pop from the back only, I use std::vector. If I'm needing a buffer, I make a buffer class and still use the std::unique_ptr as the data holder. This allows me to focus on adding functionality without having write all the extra code like deleting the copy ctor and copy assignment operators, nor would I have to write the move ctor or move assignment operator, nor would I have to write a destructor. With std::vector, you get copy and move for free, but then you have to write the two lines to delete the copy ctor and copy assignment operator. As for wrapping a naked pointer, you have to write all those yourself including destructor. Not using std::unique_ptr for a heap allocated array is more work compared to a naked pointer, even if utility wrappers like this isn't the bulk of your program.

Reason std::accumulate is slow here: -Use of std::shared_ptr (gets copied before C++20) -Use of std::optional (requires branching and (often) uses very, very padded memory like types double in size) -Lambdas are not always inlined -Likely no vectorization because of function call to lambda I would also try manual vectorization (with raw arrays or std::vector) out of curiosity. Probably could render like 40+ frames/second.

@XiaoGou469

2 жыл бұрын

also, use AVX vectorization.

It's actually very interesting to look at optimisation stuff.

Great video as always! I've learnt it the hard way with my 3D "engine" that things like shared pointers, optionals, std::functions(they are pretty heavy and use heap allocation) - all these std:: things can be very perfomance heavy. Lol, there's even a c++ weekly episode about std::pair being 300 times slower than simple pair struct with two public members. So yes - don't overengineer your programm - keep it simple where you can!

@lotrbuilders5041

2 жыл бұрын

I’ve yet to see any example where std::unique pointer causes performance degradation. Any examples?

@slava0117

2 жыл бұрын

@@lotrbuilders5041 Oh I'm sorry! My bad - should have wrote only about shared ptrs. I had perfomance issues with unique pointers because I was replacing them too often causing a lot of heap allocations and deallocations!

Yes please optimize it further! I learned so much just by watching this video. I'm very new to C++ but I already feel like starting a ray tracing project!

I THINK the problem with using accumulate here is it returns by value instead of by reference, so thats a LOT of copies being made

The render result looked really good. Would love to see you make it even faster.

33:52 Yesssss you king

Seeing this get more optimized would be pretty great

I would love it if you decide to make an additional optimization video. It is really important to optimize the code while doing project oneself.

Hey Cherno. Question: I know this channel is mainly focused on C++, but I was wondering if you are also accepting code that is made in for example C# and uses like some wrapper for OpenGL? Edit: I finished the Video and yes watching you make this RayTracer faster would be cool.

@TheCherno

2 жыл бұрын

Of course - I've got quite a bit of C# experience as well, and anything graphics related is always good!

@YoTengoUnLCD

2 жыл бұрын

@@TheCherno hey man, how about rust?

@iXNomad

2 жыл бұрын

@@YoTengoUnLCD rust is dead, it shall never excel c++. It's just overhyped.

@YoTengoUnLCD

2 жыл бұрын

@@iXNomad who asked?

@iXNomad

2 жыл бұрын

@@YoTengoUnLCD it's a joke

i would really love to see you optimizing this code further!

The problem is not std::accumulate. It is the fact that iterating an accumulate with std::optional make s a "copy" of it every pass of the accumulate. Accumulate should be used with trivial copy/move elements, or ensuring the elements handle properly the move.

Go for that full optimation of that Code, would be awesome to watch!

Very interesting video. I would like to see more videos where code is checked for issues related to speed, crashing, freezing, etc. A lot of us are just hacking stuff together with no real understanding of why problems occur such as a window freezing for 10 seconds while performing an operation.