Given that the advantages of colony are (to my mind) entirely in the realm of run-time (what would a colony do at compile time that could not be achieved with a constexpr std::map?), when added to the issues caused by constexpr you highlight, I don't see a use case for a constexpr colony.

-----Original Message-----
From: SG14 [mailto:sg14-bounces_at_[hidden]] On Behalf Of Matt Bentley via SG14
Sent: Wednesday, 03 March, 2021 19:00
To: sg14_at_[hidden]
Cc: Matt Bentley <mattreecebentley_at_[hidden]>
Subject: [SG14] Questioning the validity of constexpr-everything - at least in reference to colony

There's been a question come up in LEWG surrounding whether, like std::vector, colony should be made constexpr ie. all it's member/non-member functions should be constexpr.

The problem is there hasn't been a lot of thought put into the side-effects of constexpr function calling, and the field is still pretty new - only GCC & clang >= v10 support it so far, and GCC10 doesn't appear to fully support constexpr vector as yet - at least in the version I'm using - so there isn't any real field experience as to how this affects things in the real world.

Having done some testing myself, running benchmarks on the colony test suite with a constexpr version of colony vs original under GCC10 with
-O2 -march=native -std=c++20, there is a consistent 2% speed decrease, and other benchmarks show similar results.

This could be due to a number of things:
1. Storing results of functions in code causes increased cache usage whereas (at least for some results) simply doing the calculation on the CPU would be faster than pulling it from memory.
2. Cache effects of storage of function results interfering with locality of actual code.
3. Early bad optimisation from the compiler.

My concerns are as follows: constexpr functions
(a) shift the responsibility of storage of pre-calculated results from the programmer to the compiler, and removes the ability for the programmer to think about the cache locality/optimal storage of precalculated results
(b) shift the decision of whether or not to evaluate at runtime/compile-time to the compiler, where in some cases doing it at compile-time and storing the result may decrease performance (see Doom 3 BFG edition technical notes for their experience with pre-calc'ing meshes vs calculating them on the fly on modern CPUs:
https://fabiensanglard.net/doom3_documentation/DOOM-3-BFG-Technical-Note.pdf)
(c) may dramatically increase code size/file size in some cases if the return results of constexpr functions are large
(d) may dramatically increase compile times
(e) do not provide guarantees as to how long the results of functions are stored in memory, or where they are stored. Are they stored until use and then popped off the heap? Or are they on the stack and stay there for the lifetime of the program?

Given this I am reluctant to make colony constexpr at this stage.

It is possible that I simply don't understand enough about the technology and the compiler design, but I would like SG14 feedback on this.

Thanks,
M

_______________________________________________
SG14 mailing list
SG14_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg14

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.