Re: Horrible compiletimes and memory usage while compiling a parser with X3
Larry Evans <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
On 11/02/2016 08:15 PM, teajay wrote: > Le 26/10/2016 à 19:03, Exagon a écrit : >> of course these are the numbers of my project, which has some more code under >> the hood, I I dont think the example of the problem will generate a binary >> as big as the one from my project was, but the source of the bad compile >> times and huge binarys can definetly be found in the small example I showed >> you. >> Greetings Exagon >> > > I managed to get the code compiled successfully with a reasonable > compile time and memory usage with the latest clang version. I didn't > have any success with gcc however. > > I tried to identify template instantiations loops using templight but > found nothing really bothering. > > I guess you ran into a case where spirit drove the compiler over the > edge, or into a bug. This can happen. Sometimes a new compiler helps get > the problem fixed. > > Regards, > Thomas Bernard I'm spitballing here, but maybe a redesign of spirit to use virtual functions (or dynamic polymorphism) as well as templates (or static polymorphism) would help. Currently, the static polymorphism design is at least one of the causes for large compile times (and, I would also guess, hard-to-read compiler error messages). IIRC (in one of Joel's ancient posts?), the the predecessor to spirit did use dynamic polymorphism, and, again IIRC, it was switched to static polymorphism to speed the run-time. However, the speed-up in run-time came at the cost of slow-down at compile time. What I'm proposing is analogous to current compilers supplying an optimization flag. For example, -O0 means no optimization (analogous to the proposed spirit dynamic polymorphism) and -O3 means strong optimization (analogous to the proposed spirit static polymorphism == the current spirit). Spirit users would develop their grammars using the dynamic spirit, and once it was debugged, they could switch to the static spirit. I would guess that the dynamic spirit could would have virtual functions to generate the code for the static spirit. This is analogous to bison taking a parse.yxx file and parse.tab.cxx. Of course there is the small matter of the, I would guess, somewhat large development effort in such a redesign ;) Whether that development effort is worth the saving in compile time's and development times of future spirit users is an open question, but worth consideration. -regards, Larry ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi