4 ms·

I'd up vote this 100x if I could. From my experience dealing with large scale build systems (building 10k - 100m SLOC every 12 hours or so) nothing matters more

I'd up vote this 100x if I could. From my experience dealing with large scale build systems (building 10k - 100m SLOC every 12 hours or so) nothing matters more than IO throughput. Better network architecture, fatter pipes, faster drives, more RAM, bigger L3/L2/L1 caches will all almost always have more impact than more or faster cores. Most of the time, as you point out, multithreading only ameliorates the IO cost because it allows something in RAM or cache to be processed. If those additional threads need to hit network or disk, however, you're boned and get significantly less benefit. In many cases, you can get a bigger win by not multithreading and simply being smarter about your IO. Also worth reiterating, something raised both by you and the article: MEASURE! You know nothing about how to optimize your app or system until after you've very thoroughly measured, questioned the results, and re-assessd your assumptions. So often design assumptions made when writing your app or building your system turn out not to be true after measurement.

fleitz 16y ago
Sounds like something that would benefit highly from putting your builds on a RAM disk. If you assume 100M SLOC @ 100 bytes per line you're looking at only ~10GB of RAM. That's only an extra $160 per build machine. (2x4GB DDR3 sticks @ $80 each) I shaved ~10 minutes off a ~15 minute build and unit test time by putting the SQL DB on RAM and the source tree in RAM. SQL was by far the biggest win. The source tree only saved us about 30 seconds. If you're on Windows just tick the Advanced Write Optimization box on your drive and all your writes will go to RAM. I think there is something similar on Linux. It sounds like you're the type of person who probably already knows this :) L2/L3 cache is absolutely huge but the biggest wins by far IMHO are battery backed write cache. The really shitty thing is most BBWC controllers use 50% of the cache as read cache by default which is a total waste IMO. I find about 10% read cache is optimal on the controller. If you can't afford SSDs and still need to guarantee consistency.

fleitz 16y ago

Sounds like something that would benefit highly from putting your builds on a RAM disk. If you assume 100M SLOC @ 100 bytes per line you're looking at only ~10GB of RAM. That's only an extra $160 per build machine. (2x4GB DDR3 sticks @ $80 each) I shaved ~10 minutes off a ~15 minute build and unit test time by putting the SQL DB on RAM and the source tree in RAM. SQL was by far the biggest win. The source tree only saved us about 30 seconds. If you're on Windows just tick the Advanced Write Optimization box on your drive and all your writes will go to RAM. I think there is something similar on Linux. It sounds like you're the type of person who probably already knows this :) L2/L3 cache is absolutely huge but the biggest wins by far IMHO are battery backed write cache. The really shitty thing is most BBWC controllers use 50% of the cache as read cache by default which is a total waste IMO. I find about 10% read cache is optimal on the controller. If you can't afford SSDs and still need to guarantee consistency.