Mike Smith <mi...@smith.net.au> writes:

heh, I thought you'd get grumpy when I posted that :) Ok, without the -DNOPROFILE it's 44:03

I really had 2 points: 1) Dual Celeron's do work pretty well given a good workload

2) Your assertion that we need more memory bandwidth to go much faster on the buildworld - I disagree, or at least I think we have not wrung all the SMP performance out of build world that we should. One big problem with make -j N is that it does ok at parallelizing the compile of large subdirectories with lots of C modules since it starts many compiles at once. The link step seriallizes however, which means that the 2nd (& 3rd and 4th) cpus sit mostly idle. The same thing happens when building small subdirs with only one, or a few, c modules. And when the build moves between subdirs it seriallizes while it interprets the make file and sets up the parallel compiles etc.

The net result on my system is that the build runs at about 70% cpu utilization overall, ie I get a max of 140% of the single cpu. Actually less because of the SMP overhead. By some relatively simple tweaking of the build rules, starting multiple subdir makes in parallel, we can get much better parallelization since while one subdir is seriallizing, the others can be running on the other cpus. With my experimental version I'm getting the average cpu up to about 87% ie getting about 178% of the single cpu. Actually the last half of the buildworld runs at about 100% utilization. The first half (building the tools and some libs) is still seriallized quite a bit since I have not tinkered with that part yet.

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message