13 ms·
C++17 constexpr Compile-time Ray Tracer (2017)
- tapirl 8y agoso, c++ becomes greater?
- gnulinux 8y agoC++ has a whole scripting language embedded into itself. They're trying to reinvent lisp, of course a much less efficient lisp.
- jcelerier 8y ago> They're trying to reinvent lisp, of course a much less efficient lisp. yes, please show us all those high performance libraries written in lisp
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- ur-whale 8y agoIt's OK. Lispers live in a parallel universe, where performance issues are mere distractions from the higher level thinking.
- gnulinux 8y agoNot every performance issue needs lower level optimization. Most performance issues can be solved by (1) optimizing algorithms and (2) abstracting lower level code in FFI C functions. C++ helps for 2 but not for 1 because if you don't have a clear high-level understanding of your algorithm, system, pipeline, it's harder to optimize or maintain that optimized code.
- jcelerier 8y ago> C++ helps for 2 but not for 1 because if you don't have a clear high-level understanding of your algorithm, system, pipeline, it's harder to optimize or maintain that optimized code. I strongly disagree. C++ has very nice tools for abstraction: higher-kinded types, dependent types (to some extent), lambdas & function objects, overloads, etc. It's a pain to design a data flow in C, but in C++ for instance it can just be something like this : https://github.com/RaftLib/RaftLib/wiki/Linking-Kernels https://github.com/RaftLib/RaftLib/wiki/Linking-Kernels or this : https://ericniebler.github.io/range-v3/ https://ericniebler.github.io/range-v3/.
- brobdingnagians 8y agoGenuinely curious here, I don't know much Lisp, but dont Lisp macros tend to be powerful in the sense that they expand to more statements for runtime, whereas the purpose of C++ constexpr is to compile it down to one constant at runtime?
- pmarin 8y agoLisp macros expand at compile time. You can also generate code and execute it with eval like in many other languages like python.
- Filligree 8y agoLisp macros expand at compile time, but there's nothing special about the code running in them. Nothing at all stops you from doing arbitrary evaluation in one. Speed also isn't as much of an issue, because macros (and the functions they call) can be compiled before execution.
- brobdingnagians 8y agoAah, k, thank you!
- deleted 8y ago[deleted]
- gnulinux 8y agoYou can do arbitrary computation with lisp macros. But the magic you do it exactly the same way you do runtime computation.
- Koshkin 8y ago> less efficient lisp But C++'s variety of parentheses is larger!
- 0-_-0 8y agoIf LISP can do it with just one kind of parentheses that means it's more efficient. Can't argue with that...
- gnulinux 8y agoI'm not following you. Lisp can do it with just two sort of syntactic atoms: symbol and parenthesis. To me, it seems like lisp is an order of magnitude more elegant than C++ where you need to hack-in every additional feature by (1) standardizing a syntax after making sure it doesn't break anything (this takes years of committee meeting and convincing tons of angry people with opinions) (2) handling that special syntax in lexer+parser+static analyzer+code generator; whereas in lisp every new feature would be part of the program itself, so essentially you just need to implement some parts of static analyzer and code generator.
- mrfredward 8y agoLisp is certainly more elegant than C or C++. The axiomatic nature makes for beautiful programs, and small teams of bright people have had notable successes using Lisp. But in practical use, being axiomatic can be an enormous weakness. After all those much-derided committee meetings for C++, there is a standard, and having a standard allows people to collaborate without every team having to invent their own conventions and teach those conventions to everyone they work with. Old style C macros can be seen as an ugly way of providing lisp-like power. One of the problems with macros is people abuse them to do crazy non-standard things, and in doing so make code really opaque to others. So in C, having to invent a custom language to do something is a bug. In Lisp, it's a feature. That distinction has a lot to do with why the world is running so much C and C++ code even though a Lisp is more elegant.
- OskarS 8y agoWhat's that saying? "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Apparently applies to the compilers now, too!
- quickben 8y agoCan you show us some examples of this efficient lisp that's faster than anything already constexpr-ed? :P
- gnulinux 8y agoI didn't say "faster", I'm not claiming lisp is faster than C++, that's factually wrong. C++ is investing VERY heavily in metaprogramming since they finally figured out metaprogramming is important. Guess what, we knew this since 1960s and had an even better and elegant way of doing metaprogramming. It took ~60 years for us to realize the importance of a key feature of lisp and now we decided to make a hacked-on implementation of it. I'm personally pretty ok with C++, and it's not like this is community's fault given C++ originated from C. I'm just saying that the concept of "doing arbitrary computation in compile time" has been known since the dawn of computer science, and we had an extremely elegant and efficient way of doing it.
- quickben 8y agoThen I misunderstood the original comment, apologies. I agree with the utility of the approach. Given the narrow space the language can move, they actually placed the feature really well.
- gnulinux 8y agoStarting with C, we almost achieved what lisp can do in a few thousand lines of code in, what, 20 years. I don't consider this a success, especially since C++ standard is now one of the longest, subtlest technical documents in the industry. We created a monster.
- snarfy 8y agohttps://en.wikipedia.org/wiki/Jumping_the_shark https://en.wikipedia.org/wiki/Jumping_the_shark
- dzdt 8y agoYe gods. And I thought build times were long enough already!
- paulhilbert 8y agoSo this is basically misusing the compiler as an impractial script interpreter?
- gpm 8y agoI'm not sure if it counts as misuse, compile time evaluation is intended to be used to do computation at compile time. But "an impractical script interpreter" is certainly one way to view it.
- gnulinux 8y agoIt used to be a misuse (when metaprogramming was templates and then after the very first constexpr functions were introduced) since back then metaprogramming was intended to decide simple facts about the program and make inlining easier. But in this standard they actually made it so that pretty much all C++ stdlib can be constexpr and it is encouraged to "constexpr everything". So while this is not an abuse of C++ compiler, it's likely not a fantastic idea since C++ compilers tend to be slow.
- Koshkin 8y ago> misusing AKA hacking.
- abhishekjha 8y agoApparently it doesn't compile because of how the pow function is implemented. I am not able to figure out what the issue is right now.
- deleted 8y ago[deleted]
- blux 8y agoImpressive! Interesting as a benchmark to test the performance of different compiler implementations.
- hhmc 8y agoThere's seemingly a lot of negative responses to articles concerning constexpr in modern C++ (you can see some here in this thread). I suspect this is partially because there's a general outsized dislike of C++, and partially because typically these articles focus on toy problems where the capacity to run at compile time isn't actually beneficial, rather than cases where constexpr can provide some real benefit towards production code. Like any syntactic construct in a turing complete language constexpr presents a convenience - in this case the ability to rectify compile time generated data and runtime code paths/data. There are some practical cases I've seen where it can be a real improvement to hygiene (i.e. you can replace a compile time script/program generating data with one unified code base). e.g. 1. Perfect hash generation. Rather than using a separate gperf run you can generate your hashes during compilation of the relevant TU. 2. Format string lookup tables. For fast formatting you can push an index and positional arguments to a queue, and handle formatted string construction in another thread. Broadly speaking lookup tables in general can be generated at compile time rather than static data imported into code. 3. Complex starting conditions for physics simulations. If you have, say, some initial matrix that doesn't change between simulation runs - you can exercise existing code to generate this matrix at compile time rather than needing a separate process run or script. These approaches are not without their downsides - particularly if the translation units in question need to be recompiled often, or if you're using whole program optimisation - but the benefit of keeping generated data in lockstep with the code consuming it can be worthwhile. (That being said, I personally find articles like this incredibly edifying.)
- snarfy 8y agoI like to think of constexpr as a better, typesafe preprocessor. There are a lot of places constexpr can replace it.
- Arnt 8y ago4. Things you want to not run at runtime. If you can demand of the compiler that foo is run only at compile time, you can eliminate some performance outliers, with good protection against accidental later regressions. (I suppose this could apply to security too — anything run at compile time is definitely not vulnerable to crafty user input from a malicious user.) 5. My compiler is a rackmount somewhere; even if constexpr evaluation is somewhat slower than runtime code in a particular case, I may prefer to use the rackmount's plentiful power rather than the slim, light battery on the device where the final code will run.
- rq1 8y agoThere is no misuse of anything. Stop being so presumptuous and shortsighted, especially on hacker news. Is there some theoretical bounds or anything preventing the compilers to be faster or is it just implementation/optimization details? (GHC tends also to be quite slow.)
- intea 8y agoC++ compilation is massively slowed down by the sheer existence of the preprocessor. This could be drastically improved by the usage of modules which are coming soon(tm). Both MSVC and Clang already support them experimentally fwiw.
- Koshkin 8y agoTo be fair, what slows down compilation is not "the sheer existence" but the extensive use of large and complex #include files.
- geezerjay 8y agoIndeed. IIRC this topic is covered directly in Meyers' "Effective C++" book, including the trick to use pointers + forward declarations in headers to avoid including other headers.
- theoh 8y agoThe argument could be made that compile-time processing is highly appropriate for the static inputs of a program, and, at the other extreme, obviously can't be applied to the dynamic inputs. (Terminology from https://en.wikipedia.org/wiki/Partial_evaluation https://en.wikipedia.org/wiki/Partial_evaluation) Of course, the raytracer source code is the dynamic input of a compiler. The Futamura projection perspective suggests interesting options here for e.g. specializing raytracers in relation to particular scenes.
- tcbrindle 8y agoAuthor here. I wrote this on a rainy weekend last year and mostly forgot about it, so it was a bit of a surprise to see it pop up on HN this morning! Happy to answer any questions (including "why on earth would you do this?") :)
- rptr_87 8y agoThanks for the article. Seems nobody seems to have asked anything.. i'll start... Why on earth would you do this?
- tcbrindle 8y ago> Why on earth would you do this? Good question! :) It actually started out as a learning exercise -- I didn't (and still don't) know much about ray tracing, and so I thought it would be good to study a simple example by translating it from a language I didn't know (TypeScript) to one I was more familiar with. This involved writing a simple vec3 class, and it seemed natural to make that constexpr. Then as I went through I realised that many more functions could be made constexpr too. And then if I hacked together some (admittedly very poor) replacement maths functions, even more of it could be constexpr... At this point, it became a challenge to see whether I could make the whole thing run at compile-time. The only tricky part was avoiding virtual functions -- I'd originally naturally translated TypeScript "interface"s into C++ abstract classes. I ended up using two different approaches: firstly using std::variant and std::visit (the any_thing class in the source code), and secondly using a struct of function pointers (for the surfaces) -- because while virtual calls aren't allowed in constexpr code, calls via a function pointer are just fine. In the end, I was pretty satisfied that I'd managed to push constexpr as far as I could take it. I had intended to blog about it, but never got round to it ... and now 18 months later someone has saved me the job by posting it to HN anyway :)
- 1001101 8y agoGood way to spend the weekend, I totally get it :) I was thinking that constexpr has been around since 11 (17 has if-constexpr, but I didn't see any of those). Were there particular features of 17 that you were able to benefit from?
- sischoel 8y agoThere also was a talk at CppCon on compile time regular expressions in C++20: https://www.youtube.com/watch?v=QM3W36COnE4 https://www.youtube.com/watch?v=QM3W36COnE4
- oconnor663 8y ago> Believe it or not, this is actually decent performance The ARE YOU NOT ENTERTAINED of programming.
- sick_of_web_dev 8y agoFun project, but C++ sure is getting more ugly and arcane by the day. I think it's time it went away. I have great love for C but C++ has just always turned me off.
- jeffreyrogers 8y agoI felt this way too but was using C++ for work and have grown to like it. If you can use only the newer language features it is actually quite pleasant. You can avoid a lot of the pointer arithmetic and off by one errors that occur in C. I didn't realize how productive I was in the language until I found myself writing a small script I would normally have written in python in C++ instead.
- jordigh 8y agoD did this a long time ago too. https://news.ycombinator.com/item?id=7530692 https://news.ycombinator.com/item?id=7530692 https://web.archive.org/web/20151113173822/http://h3.gd/ctrace/ https://web.archive.org/web/20151113173822/http://h3.gd/ctra... It should be noted that this was done in very old D, before a lot of compile-time improvements that modern D has. I guess makes this feat more impressive for the time, while the same exercise today should be more pedestrian. It's really nice that D was built with this sort of application in mind instead of having it added 30 years later. It makes the language feel far more cohesive and inviting for this sort of thing. If C++ were able to discard old features, I might not be so scared of going back to it. The way it keeps growing without pruning does not make it feel very inviting.
- rrmm 8y agoThe annoying thing about C++ is you need a big huge book to tell you which features are safe and how to combine them and stay safe. Maybe if they started defining a 'modern c++' subset that you could limit it to via compiler flags and/or pragma's it would make life a bit easier when starting new codebases. Obviously you can always make a personal style choice on what to use, but then you have to find one. Anyone have a favorite set of recommendations for c++ feature usage? Also, if you start with 'X did this a long time ago.' You always end up in a LISP-hole. :P
- 0-_-0 8y ago> Maybe if they started defining a 'modern c++' subset... Here it is: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
- metabagel 8y agoGreat reference, although none of the hyperlinks on the page work for me. I tried Firefox, Chrome, and Edge. I also tried all of the older tagged versions.
- 8y ago
- hughw 8y agoIn awe.