Date: Wed, 4 Jun 2014 08:33:48 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Jukka Ukkonen <jau789@gmail.com> Cc: freebsd-ppc@FreeBSD.org Subject: Re: Odd failures during parallel PPC builds Message-ID: <20140604083348.GA21340@FreeBSD.org> In-Reply-To: <538ED489.1000307@gmail.com> References: <5388B184.4050309@freebsd.org> <538992B4.8030209@gmail.com> <20140603021026.GD60685@FreeBSD.org> <538ED489.1000307@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140604083348.GA21340>