Hi Paul, Paul D. Smith <psm...@gnu.org> writes:
> I'm not sure I fully understood the situation. > > This comment makes it sound like same version of make (same code) is 50% > slower on the new system. Is that what you meant? Yes, the same make binary is 50% faster on 2-generations old Xeon compared to the current one. On the old system 3.99 is quite a bit faster than 3.82 (don't remember the actual numbers, i think it was about 30-40%). On the new box this difference is completely wiped-out; both versions take about the same amount of time. > Obviously there's not much we can do ourselves, if it's not a differnce > in the make code. You'll have to do some testing. Use perf, or compile > with gprof support, or similar, and try to figure out where the slowdown > is happening. I will try to find some time. > If it's truly that the same make binary takes 50% longer on one system > than the other, especially on do-nothing builds, I would suggest > checking out the filesystem and disk differences. I don't think disks matter (and the new box has SSDs) since everything is presumably cached by the kernel. The filesystems are different (ext3 vs ext4), though, again, assuming the directory entries are cached, there shouldn't be any differences. > The only really variable thing in a do-nothing make build is the > amount of time it takes to stat all the files. Well, make also has to do a lot of memory-intensive processing (entering files into caches, creating all the dependency structures, pattern matching, etc). It could be some bad CPU cache interaction. That was my first thought since everything on this machine is faster, CPU, disks, memory. Boris -- Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
