|Multi-threaded compilers egouriou@CS.UCLA.EDU (Eric Gouriou) (1996-02-16)|
|Re: Multi-threaded compilers firstname.lastname@example.org (1996-02-16)|
|Re: Multi-threaded compilers Martin.Jourdan@inria.fr (1996-02-16)|
|Re: Multi-threaded compilers email@example.com (1996-02-16)|
|Re: Multi-threaded compilers firstname.lastname@example.org (1996-02-16)|
|Re: Multi-threaded compilers email@example.com (1996-02-16)|
|Re: Multi-threaded compilers firstname.lastname@example.org (1996-02-16)|
|Re: Multi-threaded compilers email@example.com (Michael Parkes) (1996-02-18)|
|[5 later articles]|
|From:||firstname.lastname@example.org (John B. Plevyak)|
|Date:||16 Feb 1996 23:32:53 -0500|
|Organization:||University of Illinois at Urbana|
We have considered parallelizing the Illinois Concert compiler because
it is relatively slow (it does not support separate compilation and
does a lot of interprocedural analysis and transformation).
We believe that it would be relatively easy to do so since the more
expensive passes are all either per-function or use worklists over
lockable data structures. However, we have not done so because:
1) we could could also increase the speed by putting more effort
into optimizing the algorithms instead. This would be more portable
2) even though our system *is* a development environment for
irregular parallel codes (like a compiler) it is not as mature
as the Common Lisp environments we use right now.
Generally speaking, parallel programs are not as portable as
sequential ones, nor are the development environments as mature.
Of course, we and many other are working on this.
As for parallel C/C++ compilers, I find "gmake -j4" on our four
processor Sparcs quite effective without requiring any changes
John Plevyak (email@example.com) (217) 244-7116 PGP KeyID: 0x051130BD
Concurrent Systems Architecture Group, Univ of Illinois at Urbana-Champaign
<A HREF="http://www-csag.cs.uiuc.edu/individual/jplevyak">My Home Page</A>
Return to the
Search the comp.compilers archives again.