Russell Coker: Firebuild
After reading B lint s blog post about Firebuild (a compile cache) [1] I decided to give it a go. It s non-free, the project web site [2] says that it s free for non-commercial use or commercial trials.
My first attempt at building a Debian package failed due to man-recode using a seccomp() sandbox, I filed Debian bug #1032619 [3] about this (thanks for the quick response B lint). The solution for me was to edit /etc/firebuild.conf and add man-recode to the dont_intercept list. The new version that s just been uploaded to Debian fixes it by disabling seccomp() and will presumably allow slightly better performance.
Here are the results of building the refpolicy package with Firebuild, a regular build, the first build with Firebuild (30% slower) and a rebuild with Firebuild that reduced the time by almost 42%.
real 1m32.026s user 4m20.200s sys 2m33.324s real 2m4.111s user 6m31.769s sys 3m53.681s real 0m53.632s user 1m41.334s sys 3m36.227sNext I did a test of building a Linux 6.1.10 kernel with make bzImage -j18 , here are the results from a normal build, first build with firebuild, and second build. The real time is worse with firebuild for this on my machine. I think that the relative speeds of my CPU (reasonably fast 18 core) and storage (two of the slower NVMe devices in a BTRFS RAID-1) is the cause of the first build being relatively so much slower for make bzImage than for building the refpolicy, as the kernel build process involves a lot more data. For the final build I moved ~/.cache/firebuild to a tmpfs (I have 128G of RAM and not much running on my machine at the time of the tests), even then building with firebuild was slightly slower in real time but took significantly less CPU time (user+real being 20mins instead of 36m). I also ran several tests with the kernel source tree on a tmpfs but for unknown reasons those tests each took about 6 minutes. Does firebuild or the Linux kernel build process dislike tmpfs for some reason?
real 2m43.020s user 31m30.551s sys 5m15.279s real 8m49.675s user 64m11.258s sys 19m39.016s real 3m6.858s user 7m47.556s sys 9m22.513s real 2m51.910s user 10m53.870s sys 9m21.307sOne thing I noticed from the kernel build tests is that the total CPU time taken by the firebuild process (as reported by ps) was more than 2/3 of the run time and top usually reported it as taking around 75% of a CPU core. It seems to me that the firebuild process itself is a bottleneck on build speed. Building refpolicy without firebuild has an average of 4.5 cores in use while building the kernel haas 13.5. Unless they make a multi-threaded version of firebuild it seems that it won t give the performance one would hope for from a CPU with 18+ cores. I presume that if I had been running with hyper-threading enabled then firebuild would have been even worse for kernel builds as it would sometimes get on the second thread of a core. It looks like firebuild would perform better on AMD CPUs as they tend to have fewer CPU cores with greater average performance per core so a single CPU core for firebuild will be less limited. I presume that the firebuild developers will make it perform better with large numbers of cores in future, the latest Intel laptop CPUs have 16+ cores and servers with 2*40core CPUs are common. The performance improvement for refpolicy is significant as a portion of build time, but insignificant in terms of real time. A full build of refpolicy doesn t take enough time to get a Coke and reducing it doesn t offer a huge benefit, if Firebuild was available in past years when refpolicy took 20 minutes to build (when DDR2 was the best RAM available) then it would be a different story. There is some potential to optimise the build of refpolicy for the non-firebuild case. Getting it to average more than 4.5 cores in use when there s 18 available should be possible, there are a number of shell for loops in the main Makefile and maybe some of them can be replaced by make constructs to allow running in parallel. If it used 7 cores on average then it would be faster in a regular build than it currently is with firebuild and a hot cache. Any advice from make experts would be appreciated.
I mostly like Debian the way it is. What
frustrated me in the past were flamewars that could have been
avoided. To me being respectful to each other is important, I don t
like flames and insults because I like solving problems and fighting
like this rarely helps that. The other attitude I don t like is to
blame people and complain instead of trying to help and be positive
(the difference between it sucks because it does not support
$foo instead of it would be so helpful if we had $foo because it
enables me to let me do $bar ).
For a long time, I had the feeling you were mostly alone working on APT and were just ensuring that it keeps working. Did you also had this feeling and are things better nowadays ?
I felt a bit alone sometimes 
The 
and got it running in a 
People often want to know what an application looks like before they install it. This is one of the reason why Christoph Haas started with the 
You better not leave confidential documents near your optical mouse. You never know where it s 
After a little searching through the lazyweb I found out that it s a 
[Sorry to my sponsorees who's package sponsoring requests were delayed again due to this mess.]
Advantages:
Advantages:
Advantages:
(Sorry for the quality of the photo. My real camera died yesterday.)
((Now I have to verify the complaints of a coworker that LXDE still doesn t install.))
Welcome back for the last part of the reviews. You may want to look at the previous parts : 
The Debian Python Modules Team is 
And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
(hint: pox-guest and piotr in python-modules are the same person)
