Re: GNU make 3.99.92 release candidate is available
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 Synthesishttp://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
RE: make check under Cygwin
Hello! I think the problem is abspath, which fails on Cygwin with DOS-style file names with a drive letter. Fixing that function on Cygwin is a priority for this release, if possible. The patch you suggest, OTOH, entirely disables support for DOS-style file names in the Cygwin build, which is a much worse alternative. Just a reminder. I have followed your suggestion and fixed this a month ago. Please try this: http://lists.gnu.org/archive/html/bug-make/2013-08/msg00031.html Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make check under Cygwin
From: Pavel Fedin p.fe...@samsung.com Cc: bug-make@gnu.org Date: Wed, 25 Sep 2013 16:12:10 +0400 Just a reminder. I have followed your suggestion and fixed this a month ago. Please try this: http://lists.gnu.org/archive/html/bug-make/2013-08/msg00031.html I didn't forget, I just don't like the way you suggested to fix that. Maintaining 2 separate branches for this, and a configure-time test on top of that, is not my idea of a clean and elegant fix. There must be a better way, since the only difference between Posix and Windows file names is the X: prefix of every absolute file name. If no one steps forward, I will try to find time to fix this soon. Stay tuned, and thanks for your contributions. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make 3.99.92 release candidate is available
On Wed, 2013-09-25 at 13:51 +0200, Boris Kolpackov wrote: 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. Nice! Are they running the same distro? Same kernel and libc versions anyway (that's about all make uses)? If you run make -d do you get essentially the same output for both? Maybe something in the environment or something in one of them is causing make to do a lot more work. 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. Maybe... you'd need to use perf to find out stuff like that I expect. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
