3 ms·
The older machine as 32 GB of RAM and the newer has 64gb. This could potentially be an issue, but generally the build consumes no more than 6GB leaving a leavin
by sqeaky 10y ago
The older machine as 32 GB of RAM and the newer has 64gb. This could potentially be an issue, but generally the build consumes no more than 6GB leaving a leaving amount unused. Memory bandwidth is more likely.
But really I am building C++, all the parsing and re-parsing is stupidly CPU intensive. most 5400 rpm drives can feed the compiler fast enough to keep them saturated.
- slededit 10y agoThe remaining memory will be used as a crazy fast file cache. As far as 5400rpm drives that may be true if it was just a linear read, but the real problem is latency.
- sqeaky 10y agoThe rest of the RAM could be used as a file cache, but it is a moot point. 100% CPU use on each of the 4/8 cores/threads. Nothing but more CPU horsepower will significantly speed that up.
- slededit 10y agoIf you look at a detailed graph of CPU usage you should see a pumping action as the CPU goes full bore and then stalls out waiting for data. Filling in those stalls is what gives you the extra performance.
- sqeaky 10y agoWhat is your preferred tool for gathering this kind of detailed data?
- slededit 10y agoOn windows It's WPR and WPA. In sure Linux/Mac has similar system wide profilers. WPA will give you detailed wait analysis.
- sqeaky 10y agoI don't have windows. I will google for "systemwide profilers". Thank you. I doubt this will change anything, (because the compilation time decreased as CPU time was added) but the information could be helpful in other situations.
- deleted 10y ago[deleted]
- bonzini 10y agoWith a hot cache, your disk is only going to do writes (and waiting on those writes is the reason why they suggest a make -jN with N higher than the number of cores). All reads are going to be serviced from memory. All writes will also go to the cache and will be coalesced on close().