Re: Sjavac build times
Sorry folks. I have now learned that OpenJDK mailer strips attachments. Here's the chart: http://cr.openjdk.java.net/~alundblad/build-times/build-times.png -- Andreas On Fri, Feb 19, 2016 at 10:06:17PM +0100, Andreas Lundblad wrote: > I spent some time measuring the build times of the java modules with > different settings. > > Attaching a chart of the result. > > Red bars: > - Plain old javac. Sjavac disabled. > > Green bars: > - Sjavac, without breaking up each module into multiple javac invocations. > (This is the default setting.) > > Blue bars: > - Sjavac where each module is split into three parallel javac invocations. > (Note that even without this parallelism the build still parallelises on a > module level.) > > > I did the measurements on my laptop (4 core, i7 @ 2.8 GHz). I measured the > "make clean-java; make java-only" so there should have been no native > compilations going on in the background. > > I don't think there are any surprises in the chart. Since we're (most of the > time) compiling many modules in parallel we get full CPU utilization without > splitting each module into smaller parts. When splitting into smaller parts, > we get lots of implicit compilation for each part, so we're just wasting lots > of cycles. IF however, one were to do this experiment on a, say, 32 core > machine, one might actually get a small speedup by splitting (because even > when we have lots of modules being compiled in parallel, we have cores to > spare). But I'm not sure considering how small most of the modules are. > > -- Andreas
Re: Sjavac build times
The openjdk mailing list server eats attachements. Can you put it on cr.openjdk.java.net instead? /Erik On 2016-02-20 01:27, Andreas Lundblad wrote: Thought I attached the chart. Here's another attempt. -- Andreas On Fri, Feb 19, 2016 at 10:06:17PM +0100, Andreas Lundblad wrote: I spent some time measuring the build times of the java modules with different settings. Attaching a chart of the result. Red bars: - Plain old javac. Sjavac disabled. Green bars: - Sjavac, without breaking up each module into multiple javac invocations. (This is the default setting.) Blue bars: - Sjavac where each module is split into three parallel javac invocations. (Note that even without this parallelism the build still parallelises on a module level.) I did the measurements on my laptop (4 core, i7 @ 2.8 GHz). I measured the "make clean-java; make java-only" so there should have been no native compilations going on in the background. I don't think there are any surprises in the chart. Since we're (most of the time) compiling many modules in parallel we get full CPU utilization without splitting each module into smaller parts. When splitting into smaller parts, we get lots of implicit compilation for each part, so we're just wasting lots of cycles. IF however, one were to do this experiment on a, say, 32 core machine, one might actually get a small speedup by splitting (because even when we have lots of modules being compiled in parallel, we have cores to spare). But I'm not sure considering how small most of the modules are. -- Andreas
Re: Sjavac build times
Thought I attached the chart. Here's another attempt. -- Andreas On Fri, Feb 19, 2016 at 10:06:17PM +0100, Andreas Lundblad wrote: > I spent some time measuring the build times of the java modules with > different settings. > > Attaching a chart of the result. > > Red bars: > - Plain old javac. Sjavac disabled. > > Green bars: > - Sjavac, without breaking up each module into multiple javac invocations. > (This is the default setting.) > > Blue bars: > - Sjavac where each module is split into three parallel javac invocations. > (Note that even without this parallelism the build still parallelises on a > module level.) > > > I did the measurements on my laptop (4 core, i7 @ 2.8 GHz). I measured the > "make clean-java; make java-only" so there should have been no native > compilations going on in the background. > > I don't think there are any surprises in the chart. Since we're (most of the > time) compiling many modules in parallel we get full CPU utilization without > splitting each module into smaller parts. When splitting into smaller parts, > we get lots of implicit compilation for each part, so we're just wasting lots > of cycles. IF however, one were to do this experiment on a, say, 32 core > machine, one might actually get a small speedup by splitting (because even > when we have lots of modules being compiled in parallel, we have cores to > spare). But I'm not sure considering how small most of the modules are. > > -- Andreas
