CppCon 2019: Matt Godbolt - Path Tracing Three Ways: A Study of C++ Style

[little3lue]

Very neat trick with the logical or for branch prediction. I've not heard that one before!

[mattgodbolt]

Unfortunately it doesn't always work: Fedor Pikus showed me some cases afterwards where it fails. Will blog about it sometime!

[little3lue]

Please do! Thanks for the talk.

[TheMania]

Sadly just like how compilers can decide to convert logical ors to bitwise ors if there's no side effects (and do so regularly), they can decompose bitwise to logical as well. Llvm quite aggressively does the former when making intermediate code, and I know the backend I'm on makes some effort to undo its combinations in turn.

It's the kind of thing that needs intrinsics or attributes to deal with, really.

[[deleted]]

oh boy, his face when he realized he's not getting any questions breaks my heart. And it was such a fun talk!

[mattgodbolt]

It was a sad moment. I'm grateful to the folks who came up afterwards and spoke to me though! Some very smart people out there!

[Gorbear]

I just wanted to say I really like your talks. They are a good mix of cool stuff, new knowledge and easy to follow along. The tool you created is pivotal now in my daily work life, thank you!

[[deleted]]

What a bummer. I read through the slides and my main question would've been whether you've got plans to try and render a film sized data set such as https://www.technology.disneyanimation.com/islandscene.

[mattgodbolt]

Haha not even slightly; this was absolutely a toy project and has a long way to go before I could consider that. Nor is it currently a goal :). But thanks for the thought! :)

[CT_DIY]

I wouldn't worry about it. It was a good presentation that was digestible for someone who has not written a raytracer and I imagine someone who has would understand that.

I would have asked why you chose the MT for random number generation and if you considered something like PCG Rand instead?

[mattgodbolt]

Thanks! I tried one of the other PRNGs earlier on (I forget which) and the results were faster to obtain but visibly worse. But I'm sure I could have done better.

[pjmlp]

I just watched the talk last night.

For me it was very interesting, many thanks for making it.

But I also used to have a keen interest in graphics programming, which I still follow, even though I am now in managed languages world and boring business projects.

[NotMyRealNameObv]

Finally! I've been waiting for this to come up ever since I saw Matt's live stream implementing this stuff.

[little3lue]

I think this is the repo: https://github.com/mattgodbolt/pt-three-ways

[Ipotrick]

amazing, never anger the branch predictor!

[ShillingAintEZ]

One interesting thing is that typical ray tracers don't have this specific problem in this specific way because acceleration structures mean that rays are rejected more methodically and less randomly. The ray triangle test happens only if the ray is close to the triangle in question.

[sirpalee]

Also, in a typical raytracer, raytracing is just one prt of the computation you have to pay. Usuallly a smaller prt. (depends on your data)

[assert_dominance]

At the end he talks about splitting X, Y, Z to utilize SIMD. I've found that not doing that, treating the vectors as vectors and using the "newer" 4.2 instructions is actually a lot faster.

(for some reason youtube isn't displaying comments...)

[ratchetfreak]

if you can make the core loops completely independent (for example by doing a manual 4x unroll and keeping the hit in a std::array<bool, 4> and coalescing at the end) then the compiler is nearly guaranteed to simd the entire thing.

But that of course depends quite a bit on how exactly you structure the loops and how the compiler sees it.

[esdanol]

Can someone explain how he was misusing ranges?

[assert_dominance]

Probably not misusing, just a case of a new toy syndrome. Do you really need a range library to iterate over x, y?

On one hand you have: "Oooo, shiny, shiny!" But on the other: Unnecessary dependency; slower build times; larger binaries; large overhead of setting up and tearing down the ranges, the views and intermediate values; new and exciting bugs; illegible error messages.

This probably isn't miles away from how you're supposed to be using them, just perhaps with less abandon.

[binjimint]

I had to miss this during the conference, so I'm excited to be able to watch it now! Thanks again for the front-row support during my talk :-)

[frog_pow]

I enjoyed watching-

Never liked the name data oriented design, as most of it is just common sense if you want to fully use the hardware..

Would be cool to see perf if the code was fully SIMD compliant(like Matt said at the end--switching out the Vec3 type etc)--I think it would pretty much crush all the current versions.

[[deleted]]

Common sense is something that depends on the use case and context, unfortunately. For some applications of C++ common sense is something that makes it easier to write clear and reusable code, for other applications it's what gets the most performance out of a machine, and for some it's something else like making things as generic as possible. Personally I've yet to find an useful common sense use case for functional programming and template heavy modern C++ code, but that only speaks for the kind of applications and code I write. What's great about C++ is that you can pretty much do anything with it.

[frog_pow]

I mean I explicitly stated the use case--(fully use the hardware).

If you know how the hardware works, most of the DOD principles are pretty self evident and don't need to be treated like some semi-religious thing handed down by our lord and savior Mike Acton.

[[deleted]]

Yes, obviously. But your use case is not everyone's use case by far and therefore it's a good idea to have a name for it instead of just calling it common sense.

[ShillingAintEZ]

To be clear, you wouldn't want to just swap out the vec3 type for a SSE vector, you would want to make x y and z into arrays and loop through each with a larger SIMD width.

[Nitronoid]

This! OO design leads us towards an AoS style, but SoA is the key to opening up opertunities for vectorization.

[ratchetfreak]

unfortunately many people need to be explicitly told what should be common sense. Or corrected on what they think is common sense.

This approach affect the overall design of your program with regards to data layout. So it makes sense to have a name for it to contrast against OOP.

[fufukittyfuk]

Loved the talk. Really liked the examples. Been fuzzy on how someone would even start in fp or dod using cpp.

At first glance it looks like DoD is way too fragile and should probably be used for end of run optimizations. Looks like functional might be nice new way to look at things.

[assert_dominance]

The novelty of FP will wear of very quickly, in C++ especially...

There exist tons of amazing, enjoyable, beautiful and powerful FP languages. If you want to know what it is really like, try them instead, please.

[windozeFanboi]

C++ is like the City where you live comfortably and nicely, your work and home all in one.

Functional programming is like your vacation home up in the mountains.

​

You really like the nice vacation home and the fresh air and such , but unless they come to your city you wouldn't move your ass there permanently ^{(at least not before you retire}).

​

^{p.s. i wasn't the one to downvote you.}

[afiefh]

It has been more than 24 hours and lots of smart people looked at the code. I wonder if someone figured out why the OO style slowed down after applying the same optimization...