FW: Announcing Finalists for the OpenJDK Community Innovator's Challenge
ted at tedneward.com
Thu Mar 20 19:35:25 PDT 2008
It's kinda sounding like trying to go all the way to mingw's gcc is not
necessarily a great place to end up. *shrug* Well, that's why this is a
research project--my hope is to get #1 done, first and foremost, and see
where we are after that.
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
> -----Original Message-----
> From: build-dev-bounces at openjdk.java.net [mailto:build-dev-
> bounces at openjdk.java.net] On Behalf Of Kelly O'Hair
> Sent: Thursday, March 20, 2008 10:58 AM
> To: Andrew Haley
> Cc: build-dev at openjdk.java.net; Steve Bohne
> Subject: Re: FW: Announcing Finalists for the OpenJDK Community
> Innovator's Challenge
> IME... shows you how old I am, not up-to-date on all these. ;^)
> I have heard that the gcc4 PCH works pretty well, but officially we
> are still using gcc3. The hotspot Makefiles might have done a little
> work toward using gcc4 PCH, and their source may actually be ready for
> use of PCH with any of the compilers due to the Windows PCH work.
> In the jdk Makefiles (not hotspot), I added a COMPILE_APPROACH variable
> that could be "normal", "parallel", or "batch".
> The "parallel" used the GNU make -p option but in a very limited way
> (Makefiles have to have pretty perfect dependency specifications for
> the -p option to work from the top down), effectively "parallel" does
> 'make -p *.o' for each library being built.
> The "batch" just did a 'gcc -c *.c' type compile (if the compile lines
> matched for all the files).
> I had hoped that the compilers might be smart enough to see the "batch"
> compile as an opportunity to automatically do PCH on all these files
> (with supplying the appropriate compiler automatic PCH options).
> Turns out most of the "automatic" PCH options just don't work, or
> I couldn't get them to work. I came to the conclusion that to get
> benefits from PCH, your source files need to be normalized with regards
> to the use of the #include files, which is a bigger effort for the
> jdk than I was willing to take on.
> Not surprisingly, on Solaris/Linux, the "batch" mode without PCH
> was the same speed as "normal", since these compilers just loop
> over their source files. But Windows does show a slight benefit
> of "batch" compiles over "normal", and little benefit of using
> "parallel", which was surprising to me.
> Again, maybe this just comes down to the cost of a fork/exec?
> The 'make -p' may just not be as beneficial when the process startup
> cost is higher?
> Andrew Haley wrote:
> > Kelly O'Hair wrote:
> >> Andrew Haley wrote:
> >>> Kelly O'Hair wrote:
> >>>> Excellent points Steve. And good summary.
> >>>> The hotspot nmake Makefiles are tied to the MS Visual Studio (VC)
> >>>> compilers,
> >>>> and I'm pretty sure nmake.exe is now only delivered with the VC
> >>>> It's not clear how you can match this build performance.
> >>>> However, it's also not clear how much of this benefit comes from
> >>>> Hotspot's
> >>>> use of VC pre-compiled headers (PCH). Windows builds with
> >>>> takes a few minutes, versus 20-35min builds on equivalent
> >>>> systems. So it's significant and something (the performance) that
> >>>> want
> >>>> to keep. If a GNU Makefile using VC/PCH can match nmake is an open
> >>>> question.
> >>> This is interesting. I guess the Linux build isn't using PCH too?
> >> The gcc compilers and Sun Studio compilers we have used in the past
> >> didn't have PCH capability or didn't have stable enough ones.
> >> It's been my experience that each PCH implementation is unique in
> >> way, varied implementation techniques, with varied performance
> >> The gcc we have used (version 3 based) did not have a good PCH
> >> (gcc 4 supposedly has one now?),
> >> and the Sun Studio Compilers just recently got a stable PCH system.
> > I haven't used it, but it's supposed to be pretty good. Apple use it
> > all the time.
> >> On Windows, none of the [ parallel make options ] options are
> available or show little
> >> benefit. So far PCH has been the best answer, which the Hotspot team
> >> has done but the rest of the jdk's native sources aren't quite as
> >> normalized as the Hotspot sources.
> >> Maybe the Windows issue is the higher cost of process
> >> Fewer processes with more work to do is a better Windows situation?
> >> I'm guessing of course...
> >>>> I have tried using parallel GNU make and batch compiles in the jdk
> >>>> builds, and seen benefits on Linux and Solaris, but not much with
> >>>> Windows.
> >>> Ah, that is important: IME builds scale almost linearly with the
> >>> of processors.
> >> What is IME?
> > In My Experience. :-)
> > Andrew.
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.21.7/1336 - Release Date:
> 3/20/2008 9:48 AM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1336 - Release Date: 3/20/2008
More information about the build-dev