what do you think about the sub project in the wiki: Parallel Compilation:
One approach is to make the front end multi-threaded. (I've pretty much abandoned this idea. There are too many mutable tree fields, making this a difficult project. Also, threads do not interact well with fork, which is currently needed by the code generation approach.) This will entail removing most global variables, marking some with __thread, and wrapping a few with locks. For the C front end, sharing will take place at the hunk level. The parser will acquire a lock on a hunk's key before parsing (or re-using) the hunk. Once the hunk has been registered the lock will be released. This will allow reasonably fine-grained sharing without possibility of deadlock. This sub-project will also require updates to the GC. The current plan is to have ggc_collect be a safe point; this works well with the C parser as it collects in each iteration of the main loop. The C++ parser does not do this, and will need to be modified. Additionally, the server main loop will either need not to hold GC-able data, or it will need a way to inform the GC of its activity. (Note that the GC work is completed on the branch. The C++ parser has not been modified to periodically collect, however.) ? On Fri, Sep 4, 2015 at 10:11 AM, Tom Tromey <t...@tromey.com> wrote: > Manuel> The overall goal of the project is worthwhile, however, it is unclear > Manuel> whether the approach envisioned in the wiki page will lead to the > Manuel> desired benefits. See http://tromey.com/blog/?p=420 which is the last > Manuel> status report that I am aware of. > > Yeah. I stopped working on that project when my manager at the time > asked me to work on gdb instead. > > I think the goal of that project is still relevant, in that C++ > compilation is still just too darn slow. Projects today (e.g., firefox) > still do the "include the .cc files" trick to get a compilation > performance boost. > > On the other hand, I'm not sure the incremental compiler is the way to > go. It is a complicated approach. > > Perhaps better would be to tackle things head on; that is, push harder > for modules in C and C++ and fix the problem at its root. > > Tom
