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

I know, right?!

@@MattGodbolt It's like in the old Rowan Atkinson sketch, "The School Master", but in reverse 😉

Glad you like it!

At the point where you're thinking about likely vs unlikely, you're really already thinking about branch prediction. If you want the compiler to know without having to think about it, that's where profile-guided optimization comes in. Unfortunately the tools for that in practice are pretty scant.

In the original version this wouldn't have helped, as it was a 50/50 chance for each of the branches. Only if as you say it would have made the programmer rethink it.

It's a path tracer though. A path tracer barely has to deal with mutable state beyond the image it outputs at the end. It spends almost the entire time as well as 99% or so of the code purely reading data in an immutable fashion. So I actually think it's a poor example of highlighting differences in these styles, especially from a code and maintenance perspective. Particularly with a small and simple path tracer like this, you could probably even write it very procedural and just use a dozen global variables and the end result would still be quite easy to maintain (maybe even easiest to maintain). There just isn't much mutable program state at all. Where the code would vary so much more between these while still keeping the project reasonably small would be something like a text editor or CAD software where the user can edit all sorts of stuff, undo/redo operations, save and load, etc. For example, the object-oriented approach to the undo system might use the Command pattern with a whole bunch of command objects that provide virtual undo/redo methods, the functional version immutable/persistent data structures, and the DOD style maybe some very efficient diff/delta system over the data (maybe with hashes and memcmps over memory blocks) to store changesets.

github.com/mattgodbolt/pt-three-ways

The code is on GitHub at github.com/mattgodbolt/pt-three-ways

Correct, although the same could be said of the 'object-oriented' (class-oriented) approach. That one can also be described by a Hindley-Milner-esque type system. Of course, at the end of the day 'functional programming' first and foremost means 'that functions are used as first-class values', regardless of whether immutability, sum types, monoids, functors etc end up being used.

if you are poor, select only the main peak of the distribution, fixed, always, 1 ray per pixel

wrap the triangle with a sphere collision ray tracing volume, center of mass centered, for ray intersection check boost

It comes with Linux kernel. Look up Linux perf tutorial to get started.

Yeah, I felt like the DoD section was the weakest and obviously where Matt had the least experience. But he also missed the single greatest optimization that such a codebase could have with DoD by still keeping his triangle points in interleaved XYZ AoS format (he did mention that, but that's like the biggest and number one optimization afforded with DoD that he neglected) when he's sequentially looping through them. It's often easy enough to get order of magnitude improvements over OO in those cases with a serious DoD mindset, and sometimes 100x or faster without algorithmic improvements, in simple loopy code over data like his path tracer. I also wanted to facepalm a bit when he didn't even bother to profile the code until he had written it all and not only then, but only after he noticed something weird in the benchmarks. Also maybe this is a bit contentious, but from my standpoint, DoD is more top-down design than bottom-up as he described. It's OO that's bottom-up, not the other way around. DoD gets to the heart of the design requirements of the software by looking at it from a data-centric (information-centric, i.e.) standpoint. It organizes the data for efficient access and then builds the minimum layer of functionality and abstractions on top. The code it tends to produce tends to be minimalist and highly-tailored for the problem at hand. It's OO where I tend to find programmers start going really bottom-up and sometimes moving far, far away from the business requirements by building all sorts of monstrous libraries and frameworks before they start actually building the software and writing and using anywhere from tens to thousands of times more code than actually required for the problem at hand.

Of course: it's a talk, and it wasn't designed to be anything but a demonstration of techniques and styles. If it was even slightly serious, then some kind of BV-hierarchy would be the first thing to do... but anyway! Hope it was interesting. To get the stats I used Linux `perf`

Lol, no.

Zip is inner product. Cartesian product is outer product where you visit all the possible combinations.

@@IsmeGenius My understanding of zip is you parallel combine pair of input ranges, producing an output range. Whereas inner product parallel combines pair of input ranges, then reduces into a single element for output.

What else should Cartesian product be called even in python it's called product in the itertools library