On Sun 22 Sep 2013 11:10:15 PM PDT, Gregory Szorc wrote: > On 9/22/2013 10:05 PM, Mark Hammond wrote: >> On 23/09/2013 2:46 PM, Gregory Szorc wrote: >>> On Sep 22, 2013, at 18:20, Mark Hammond <mhamm...@skippinet.com.au> >>> wrote: >>> >>>> On 23/09/2013 11:04 AM, Gregory Szorc wrote: >>>>> On Sep 22, 2013, at 16:35, Anthony Jones <ajo...@mozilla.com> >>>>> wrote: >>>>> >>>>>> On 21/09/13 17:58, Robert O'Callahan wrote: >>>>>>> I don't think that's necessarily true on Windows. If we can >>>>>>> find a way to generate Visual Studio projects and use those >>>>>>> to build, or do most of the build, we can probably go a lot >>>>>>> faster than using cl command-line invocations compiling one >>>>>>> file per invocation. >>>>>> >>>>>> It would be nice to see multiple files per cl invocation. That >>>>>> would likely be a significant win for Windows. The performance >>>>>> improvements are good for Linux but Windows build performance >>>>>> still lags many minutes behind the Linux. >>>>> >>>>> Not sure what you mean here. >>>> >>>> In my experience, a clobber build on Windows does not fully utilize >>>> the CPU - for most of the build, many cores are simply not being >>>> used. It might technically be "CPU bound", but it's certainly not >>>> "CPU efficient". >>>> >>>> I suspect Roc was suggesting there might still be opportunities to >>>> increase the parallelism of the build that would offer significant >>>> wins on Windows. >>> >>> The patches announced in the first post on this thread offer such a >>> solution. They work with GNU make and pymake and can saturate a 64+ >>> core machine. >> >> That's great - however, I was just responding to your comment that >> "clobber builds are mostly CPU bound today" and pointing out that, >> today, that comment doesn't match my experiences. > > Sorry, having composed that post on my mobile phone, the necessary > asterisks weren't written. There are numerous asterisks when it comes to > build system generalizations because, well, the build system is > complicated. I or any other build peer could explain things in detail in > every email thread complaining about build times, but then we wouldn't > have time to work on the actual build system! I'm optimistic the in-tree > build system documentation I announced a few days ago will eventually > grow this type of documentation so knowledge can be percolated so we > [the build peers] don't feel obligated to brain dump in every email > thread and to every armchair quarterback that shows up. > >>>> [I also see a clobber build spend > 5 minutes in various configure >>>> runs, which frustrates me every time I see it - so I minimize the >>>> shell ;] >>> >>> We don't have much love for configure either. However, it's only >>> contributing a few extra minutes to Windows builds compared with 15+ >>> minutes that pymake and make traversal is. I hope you understand why >>> fixing configure isn't at the top of the priority list at the >>> moment. >> >> I understand it isn't at the top of the priority list, but it's still >> worth keeping it in perspective - I see ~6 minutes of configure for ~30 >> mins total build time - 20% is significant in anyone's language. > > ~6 minutes for a configure?! I just did a configure from a clobber build > on Windows on my i7-2600K (2+ year old CPU) and it took 2:10. If you are > seeing 6 minutes configure times, you are running an ancient CPU and/or > not an SSD or you have something fubar with your setup (such as running > a VM inside a VM inside a VM Inception style). If your machine *is* > modern and you don't believe you are doing something silly, *please* > file a bug so we can get to the root cause.
My anecdote: about 2 years ago, I did a lot of building on Windows and tried very hard to use a VM (just one layer -- a Windows 7 Virtualbox VM inside Fedora x64.) The configure times were excruciating. 6 minutes sounds about right -- for the top-level configure only. If you add in the recursive configures (js/src, libffi, I can't remember what else), it was at least 30 minutes just in configure. This *was* a problem with the VM, btw -- building directly under Windows 7 was slow during configure, but not insanely so. The rest of the compile was probably a little slower inside the VM, but not by much. While investigating this, I stripped down a configure script to a miniscule subset of what it really did, and continued to see the order of magnitude problem inside the VM. (The script didn't do any compiling, just some sed invocations and maybe some directory traversals or something.) I have that script and the timings lying around here somewhere... _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
