Dear Basile, thank you for your response. I think the options you mentioned can be very useful. I have not digged deeper into the web sources you mentioned but will. Since you asked, the project is with nonlinear gradient-based optimization. Consumer-code is run during a first run-time that generates code from it; e.g. the Jacobian of a model. This Jacobian code reserves memory in an application code, of which in turn gradients are generated. The issue here is that memory dimensions of the nested generated code affect the outer generated gradient code. Splitting of compile units has been done, but only as "onion layers" (from inner to outer), because every class is template and every implementation a specialization for the respective codegen type. However, precompiling inner onion layers will be worthless if during debug the innermost onion layer must be changed (e.g. when some integrand must be parametrized appropriately in order for some outermost NLP solution to satisfy certain stability properties). Then, potentially, due to the template-, memory-, and code-dependencies and -changes from inner- to outermost code layer, everything has to be codegenerated (and thus compiled) anew as every single line of product code can change. I did try making compile units, but again, they are invalid upon the change of a single line. And most of the code is one single NLP instance class template (of which fortunately for my application I can predict the template realizations), thus chunking into "many" small compile units appears difficult. The code is not long. 30kLOC base + 1k instance + maybe 10k generated. I once had a much bigger project of beyond 90LOC but back then I was at a different level (I refused using templates back in the day). The current code is rather short, elegant, but (arguably therefor) template- and meta-programming littered. Much would probably need to be headered and thus recompiled within each compile unit, potentially causing a trade-off in chunking of compile units. Hence my "excitement" to throw money at it (budget cap: 5k/year). Kind regards, Kai On Fri, Jan 24, 2025 at 1:55 PM Basile Starynkevitch < basile@xxxxxxxxxxxxxxxxx> wrote: > On Fri, 2025-01-24 at 13:01 +0100, Kai Song via Gcc-help wrote: > > Hello, > > > > I seek advice on good CPUs and CPU benches that allow me finding a good > CPU > > for compiling a single c++ compile unit with the G++ compiler. > > > > Background: > > - Many features in my code only work exclusively with G++, hence I do not > > care in other compilers. > > - I sometimes need recompilation for a single sign flip in the project > and > > that would take several minutes. Throwing (proportionately) money at it > in > > order to make that quicker could be advantageous. > > The phoronix.com website might give hardware suggestions > https://www.phoronix.com/ > > IBM is selling powerful Linux hardware. Maybe even renting some. Probably > https://www.supermicro.com/ and https://atos.net/ also > > (look of course at https://top500.org/ if you can afford a 1USM$ or 1M€ > super- > computer....) > > During development you might not need to enable most optimizations if you > do > have a reproducible and quick to run test. In other words, compile your > translation unit with g++ -O1 -g2 -Wall -Wextra for simple tests. > > If compile time is an issue, consider spliting large C++ source code into > smaller C++ files (e.g. if you have a 6KLOC C++ file split that into two). > > Once simple tests are passed, you could ssh to some powerful Linux server > and > compile and link (maybe once a day) your software product with -O3 -flto > -g1 and > run benchmarks remotely. > > It would be nice for us to understand what kind of software project you are > developing (it could be a competitor of > https://www.cea.fr/energies/tripoli-4 > ...), for what operating systems and how many millions of C++ code lines > (as > measured by Wheeler's https://dwheeler.com/sloccount/ utility). > > > regards > -- > Basile STARYNKEVITCH <basile@xxxxxxxxxxxxxxxxx> > 8 rue de la Faïencerie > 92340 Bourg-la-Reine, France > http://starynkevitch.net/Basile & https://github.com/bstarynk > & https://github.com/RefPerSys/RefPerSys/ > >
