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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.