> On 8/22/12 6:10 AM, Robert Kaiser wrote: >> [...] >> esp. given that basic file I/O is often costly (from watching my CPU >> usage, a lot of the build time is spent in I/O wait when using spinning >> disks - SSDs improve that hugely).
On Wed, 22 Aug 2012 12:29:24 -0700, Gregory Szorc wrote: > Yes, I/O wait can significantly reduce build times. I recommended > at [1] that aside from a modern CPU, investing in an SSD is the > best thing you can do for build times. If a build machine doesn't > have an SSD, it's effectively throwing away CPU cycles in I/O > wait. It's true that the build system today wastes a lot of CPU > cycles due to inefficient use of all available cores (lack of wide > parallelism due to recursive make). But, the efficiency should > rise drastically with our build system improvements. That will > make the impact of an SSD even more pronounced. On my MBP (with > 8GB), building with an SSD reduced overall build time by a few > minutes, with libxul linking going from ~55s to ~5s. That's > without any build system changes! There is no doubt in my mind > that SSDs are worth the investment. > > [1] http://gregoryszorc.com/blog/2012/07/29/mozilla-central-build-times/ This sounded good to me, so before searching for an SSD, I did some experimentation. Although suggested in Gregory's blog, I want to say more clearly that if you have a filesystem designed for performance and enough page cache then an SSD will not make any significant difference to warm build times. The filesystem will perform the I/O asynchronously and so I/O is not the limiting factor in build times. On this test system with a 1.6GHZ 4-core i7 and 16GB RAM, a gcc 4.5.3 64-bit debug build from scratch takes 23-24 minutes, whether on a tmpfs ramdisk or magnetic disk with ext4 data=ordered. libxul link times are 14s on each disk. I/O does have an effect on some filesystems. The home partition here is mounted with data=journal so that sqlite does not need fsync for consistency. data=journal also turns off delalloc which on its own affects performance. Switching from data=ordered to data=journal increased binutils-2.22 gold libxul link times from 14s to 76s. The effect was a little less dramatic with bfd links, which increased from 28s to 54s. The system has the default journal size of only 128M, which I imagine could be relevant for data=journal when writing 0.5GB of libxul.so. Linux 3.3.8. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
