If I want to speed up my compile time (suppose large C++ projects in Visual Studio), what hardware upgrade is going to be most effective?
>CPU moar cores
>CPU moar hertz
>faster SSD
>more RAM
>inb4 GPU
>>55446432
moar cores
moar hertz
>>55446479
Or his bottleneck is io. Why don't you check what your bottleneck is op?
>>55446432
In order of most effectiveness
-More CPUs
-Faster CPUs
-More RAM
-Faster RAM
-Better compiler
-Better project design
-Healthier diet
-Faster Storage
cores are useless
Compilation only runs in a single thread
C++ templates fucking destroy the compile times
>>55447395
>cores are useless
No
>Compilation only runs in a single thread
Yea, compilation of one source file takes one thread, did you ever do anything above Hello World level?
>C++ templates fucking destroy the compile times
Kinda
>>55446432
Maybe check if you're actually using all the cores.
>>55447395
go back to java, you clearly dont know shit.
op, i assume you have enabled multithreaded compilation already?
>>55446432
The best thing you can do is fix the source code and build system - shitty project structure, code design or slow build system can have orders of magnitude differences on build times.
>>55446432
Don't Compile shit in Visual studio.
>>55447505
>Yea, compilation of one source file takes one thread, did you ever do anything above Hello World level?
The C++ #include mechanism works by actually recursively copying the text of #included source files into the main file, and this is all done during the preprocessing stage, before any compilation actually occurs. So, all compilation is "of one source file".
>>55447599
holy shit, are you actually saying that it will include, idk 500 LOC from interface definitions? jesus muh compile times. im not gonna consider templates and inline files. not being a retard and using includes, pragmas, pch and such isnt hard
Win+R -> perfmon.exe
Monitoring Tools -> Performance Monitor
Right click in panel -> Add Counters
Processor -> Percent User Time -> All instances.
If total flatlines at 1/total_cores then more mhz.
If total is 100% then more cores and more mhz.
PhysicalDisk -> % Disk (Read|Write) Time -> All instances.
If 100%, faster disk.
Memory -> Available MBytes. Should be at least hundreds
Memory -> Page Faults / sec. Spikes of thousands or tens of thousands usually due to not enough memory
>>55447692
>Useful post on /g/
Where's Maki?
>>55447686
It will if you have a 1990s ghetto-tier compiler. In the real world all the headers are precompiled and cached, so changing .c/.cpp files is painless while editing .h files, specially ones in a large library, will flush the whole cache and cause all objects to be recompiled.
More herz and larger cache.
>>55447726
true, but id say making the assumption that people are using recent tools is fair to make, especially given that op explicitly mentions VS, i dont believe anyone uses any version prior to VS05 because of legacy project or company restrictions, more so now that compilers finally are getting C++0x/1y conformant
>>55447599
You don't use #include for other .cpp files, just headers. If you have for .cpp files, you can run a C++ compiler on each one and then link them together. Large C++ programs have many source files, and can easily parallelize their computation.
>>55447777
Yeah I guess the main reason for long compile times is building a shitty project or a large one for the first time.
It's been a few years since I did any C++ and a decent sized project though, does latest VC++ have reasonable cache invalidation rules?
>>55447794
From what I remember linking was always a cunt, single-threaded too which is painful if you're statically linking tons of libs into a release build all the time.
>>55447844
dont know about the latest, im still using VC13, and it does alright, rarely i have to do a complete rebuild if the cache is somehow out of date, which takes me about 20 min to completely rebuild build all the configurations with static analysis included. only a few seconds for rebuilds that only touches a dozen files or so
>>55447794
Don't headers #include their .cpp implementation files? So you end up with .cpp implementation files included in headers, with all that included in the main file.
>>55447994
No it's the reverse, an object is compiled from a source code file. That code can #include other files, which in turn #includes more files. These includes contain the definition of the stuff in other object files so that the different objects can talk to / understand one another. (a.cpp will #include b.h if it wants to use objects from b.cpp)
Many objects are linked together to make a program or library.
>>55448040
Apologies for the sloppy technical language there. Re-reading that it's fucking disgusting, I wouldn't put up with it and neither should you.
Can't be fucked correcting myself though.
>>55448040
>>55448060
And that's what I'm saying. You compile main.cpp, which #includes a.h and b.h. a.h #includes a.cpp, and b.h #includes b.cpp. So the preprocessor ends up merging a.h, a.cpp, b.h, b.cpp into main.cpp.
>>55446432
Gentoo is what you're in need of OP
>>55447844
I'm not sure if linking can be multithreaded, but I do know is not the most computationally intensive of tasks.
>>55447599
If this were true, 'make' wouldn't have a flag to run across multiple jobs (The -j flag)
>>55446432
1. Compile in a tmpfs instead of on a disk
2. Use more cores for compiling
3. Get a CPU with more throughput (number of cores * performance per core)
>>55447599
You're a fucking retard who has never developed either C or C++ programs and should stop posting about a subject you're clueless about
seriously kys
>>55448204
>but I do know is not the most computationally intensive of tasks.
Eh, depends on your linker and linker settings. LTO and supercompilation are both really expensive
>>55448092
no. you are fucking retarded. read up before spewing bullshit. cpp files become compiled translation units with a number of "holes" that are the >>call sites for functions in other translation units<< these holes are then filled in by the linker.
>>55448263
>seriously kys
i couldnt agree more
>>55447583
This
>>55448092
>a.h #includes a.cpp
Incorrect.
The file a.h contains forward declarations to functions in a.cpp, but no definitions. Same for b.h and b.cpp.
main.cpp compiles to main.o with references to functions it has no idea where they are located, or what they do.
a.cpp is compiled to a.o, and b.cpp is compiled to b.o.
All three of these operations can be done simultaneously.
A linker will finally combine main.o, a.o, and b.o to some program.exe, resolving the references, or giving an error if, for example, main called a function that doesn't exist.
>>55448276
Yeah, but you don't use LTO in release builds, and there are some new LTOs that are cheap but effective in LLVM...
>>55446432
Consider setting up a parallelized build system using multiple machines, using technologies as FastBuild which has a CMakish syntax IIRC.
>>55448619
>you don't use LTO in release builds
in what world?
>>55448811
Wait, I meant debug builds (at least not the heavy LTO). DERP.
>>55448811
I think he meant to say “in debug builds”
>>55448811
Maybe he meant other than release builds.
>>55448811
i think microsoft calls this 'whole program optimization' for those of you who, like me, were wondering wtf LTO was.
Can someone explain to the the benefit of having separate "release" and "debug" build options? Is this a MS thing only?
What's the point?
>>55449072
It's not an MS only thing. Debug means you spend less time on optimizations, and you might have debug symbols in the binary to make it easier to work with a debugger. This is the binary you use when you are just trying to get the product working. Release is the binary you ship to the customer. It has all of the optimizations possible added to it, since compile time matters less for the final product.
>>55448092
All you do is compile source files. But sometimes, if you need source files to interact with each other you write a file with declarations, a header. Now; a.cpp will need a.h because without it it doesn't know that a is a class that contains variable named width, so it for eg. will throw an error of unnknown identifier. File b.cpp defines HOW methods of b class do something, but it requires some form of interaction with class a, so you include a.h that informs b.cpp that class a exists and has a method GetWidth. b.cpp doesnt care HOW (a.cpp) GetWidth works, it cares WHAT it is, a method of a returning int, taking no params.
Then both files are compiled separately and in b.o, the outcome of compilation of b.h, compiler places a note saying "hey, here I used a::GetWidth”
Then linker links all the other .o files into executable, replacing all notes from compilers with actual instructions to go to method from other object. Or it throws an error, because you told b.cpp there is a GetWidth function, it counted on you, but you forgot to define somewhere (doesn't matter where, it can be in xyz.cpp)
Getters are actually a bad example because you generaly want them inlined. Inlining is just compiler taking the call to a function and replacing it with the definition, this allows it to better optimize the .o. So you make a file with a different extension tgan the one your build process compiles (so instead of .cpp it's eg. .inl) and include it at the end of the header. Now when b.cpp includes a.h it also includes definition of a::GetWidth, now when b.cpp calls it compiler doesnt make a note for linker or generate procedures to jump to the method, it just copies and pastes it.
Templates' definitions (.tpp) also need to be known to all the functions that call them. In this case compiler doesnt just paste it, but makes a whole new function, so it needs to know what goes on inside the templated function.
>>55446432
IncrediBuild
>>55447726
>In the real world all the headers are precompiled and cached, so changing .c/.cpp files is painless while editing .h files, specially ones in a large library, will flush the whole cache and cause all objects to be recompiled.
>yfw you have to work with a 150+ file *.hpp only project
>>55446432
write better code.
minimize need for recompiling for any change.
>>55449072
it can be the difference between an 800mb executable and 8mb executable.
>>55446432
use a better compiler instead of that piece of shit.
G++
>2016
>not torrenting RAM
