Odd failures during parallel PPC builds

[Alexey Dokuchaev]

On Wed, Jun 04, 2014 at 11:10:49AM +0300, Jukka Ukkonen wrote:
> On 2014-06-03 5:10, Alexey Dokuchaev wrote:
> >I normally do not build in parallel since it makes no sense on my single
> >CPU Mac mini G4, but I can loop buildworld with some -jX value to see if
> >I can catch anything.
> 
> It seems that almost every process waits for disk on occasion
> just to read in the compiled file and header files at least.
> So, having a few compiler processes active at the same time
> usually makes sense because another compilation can proceed
> while one ends up waiting for the disk. When the compiled files
> are small and the compilation does not require a lot of memory
> as is often the case with C library functions etc. the number of
> parallel jobs can obviously be a bit larger.

"make buildworld" takes around 12 hours on Mac mini G4, with 1G RAM and
tmpfs-backed OBJDIR.  I've played with couple of -jX values, it made no
observable difference.  The box is slow; and FreeBSD is not taking it to
its full potential. :(

Our libc seems to lack altivec-optimized routines on PowerPC, which is
unfortunate.  This is known to PowerPC port maintainers:

  http://lists.freebsd.org/pipermail/freebsd-ppc/2003-June/000042.html

Motorola's code is of low interest probably, due to its license (GPL?) and
the fact that it's written in assembly; I haven't check all Apple's code,
(http://www.opensource.apple.com/source/xnu/xnu-1504.9.37/osfmk/ppc/), but
e.g. bcopy.s is also written in assembly.

But there are C routines for string operations by Konstantinos Margaritis,
some of them are dual licensed (LGPL/BSD) IIRC (http://freevec.org/), but
not all.  I don't think it's hard to reimplement most of them from scratch
under BSD license though.

> When compiling large C++ files the number of jobs has to be kept low
> to avoid pointless paging on a system with limited physical memory.

Right; actually, these days building into tmpfs might no longer be optimal,
as code base had grown large enough to utilize a lot of swap space on a 1G
RAM box.

./danfe