<div dir="ltr"><div><div><div>The match optimizer is very careful to avoid inlining code that doesn't benefit from the current match tree, so there is very little tail duplication.<br></div>I think it's the subsequent inlining and optimization from gsc/gcc that results in the blow up, as the code really cannot be optimized further,<br></div><div>But yeah, layers of language will do that to you.<br></div><div><br></div>Note that in general I don't do optimizations that gsc already does, but we can't reasonably expect gsc to understand and properly optimize match/syntax-case expansions.<br><br></div>-- vyzo<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 19, 2018 at 9:15 PM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe the problem is that Gerbil is doing some inlining of sorts (for example tail duplication in the matcher) and then passing this to gsc which will also do some inlining of the functions in the code, and probably gcc also with the -O2 option.<br>
<br>
Its understandable that this layering of languages will cause code bloat.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marc<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> On Mar 19, 2018, at 3:05 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
><br>
> Sure, I'd like to get to the bottom of this because it's such an ugly failure mode!<br>
><br>
> For now, I changed the gerbil compiler to emit an inlining-limit declaration in meta phases (that's where the syntax-case monsters reside).<br>
><br>
> -- vyzo<br>
><br>
> On Mon, Mar 19, 2018 at 9:02 PM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:<br>
> I think you should figure out which of the configure options<br>
><br>
>   --enable-single-host<br>
>   --enable-c-opt<br>
>   --enable-gcc-opts<br>
><br>
> are the most useful/beneficial for the kind of code generated by Gerbil.  I suspect that --enable-single-host is the most performance-enhancing option, and --enable-c-opt only gives a marginal speed increase at the cost of a much higher C compile time.<br>
><br>
> If you do try the various combinations, please report your results here.  I’d like to know if my intuition is correct.<br>
><br>
> Marc<br>
><br>
><br>
><br>
> > On Mar 19, 2018, at 2:56 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
> ><br>
> > My gambit is configured with  --enable-single-host --enable-c-opt --enable-gcc-opts.<br>
> > I have 8G on my current laptop, but I run without a swap; the death occurs at around 6G.<br>
> > It's not only the memory usage though, it takes forever too. clang on travis didn't OOM, but it took 15min on the file.<br>
> ><br>
> > I think it might be a case of really bad interaction between the various optimizers in the 3 compilers involved. The gerbil emitted code is already heavily optimized to perform match tree linearization (I have a shiny new optimizer that optimizes match and syntax- case expansions).<br>
> > That means you can't reasonably inline anything other than single use procedures within the optimized blocks.<br>
> ><br>
> > -- vyzo<br>
> ><br>
> ><br>
> > On Mon, Mar 19, 2018 at 8:41 PM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:<br>
> > The default inlining-limit is 350, so the expansion from 100 is quite possible.<br>
> ><br>
> > But the problem here is that gcc chokes on the compilation of the C file.  So… what are the compilation options passed to gcc?<br>
> ><br>
> > - are you using --enable-single-host ?<br>
> > - are you using a higher level of optimization such as -O2 or -O3 rather than the default -O1 ?<br>
> ><br>
> > These will definitely increase the pressure on the C compiler.  Also, some versions of gcc do a better job at compiling large C files.  The file lib/_io.c in the Gambit distribution is about 90kloc and I have never gotten an OOM error from gcc while compiling it, even though I use a “make -j 8” (8 C compilations in parallel).  I do have 16 GB of RAM on my machine… how much RAM do you have on yours?<br>
> ><br>
> > Marc<br>
> ><br>
> ><br>
> ><br>
> > > On Mar 19, 2018, at 2:31 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
> > ><br>
> > > It's 140kloc without the inlining declaration and just 22Kloc with the declaration.<br>
> > ><br>
> > > -- vyzo<br>
> > ><br>
> > > On Mon, Mar 19, 2018 at 8:27 PM, Marc Feeley <<a href="mailto:feeley@iro.umontreal.ca">feeley@iro.umontreal.ca</a>> wrote:<br>
> > > Out of curiosity, what is the number of LOC of C with and without the inlining-limit?<br>
> > ><br>
> > > I’m just wondering if this should be classified as an issue, or if the inliner is just doing its work as expected.<br>
> > ><br>
> > > Marc<br>
> > ><br>
> > ><br>
> > ><br>
> > > > On Mar 19, 2018, at 2:23 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
> > > ><br>
> > > > It seems it's the inliner going haywire -- if I add a (declare (inlining-limit 100)), then it compiles in 20s.<br>
> > > ><br>
> > > > -- vyzo<br>
> > > ><br>
> > > > On Mon, Mar 19, 2018 at 7:29 PM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
> > > > The attached file results in a 140kloc monster that results in gcc dying with OOM after several minutes of effort, and I would like to understand why.<br>
> > > > Any ideas?<br>
> > > ><br>
> > > > -- vyzo<br>
> > > ><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>