Re: Compile-time v. execution-time tradeoff

> On 22 Feb 2016, at 02:21, Matthew Fluet <[email protected]> wrote:
> 
> On Sat, Feb 20, 2016 at 8:38 AM, Rob Arthan <[email protected]> wrote:
>> Thanks for the suggestions. The results are interesting ...
>> 
>>> On 17 Feb 2016, at 11:55, Matthew Fluet <[email protected]> wrote:
>> I am intrigued that the code generation time is far from
>> linear in the number of lines of code. However, as my test
>> is so untypical, I don’t feel there is much to worry about here,
>> unless you feel that the above timings are not satisfactory.
>> (In which case, I can let you have the ML to experiment with.)
> 
> I'd love to take a look at the SML source.

Thanks. I have sent it to you in a separate e-mail.

> 
> There are probably some non-linearities in the native codegen,
> especially non-linearity with respect to the length of basic blocks.
> We actually special case the "function" that initializes the global
> data --- it is essentially one very long basic block that does little
> more than allocate a bunch of objects; but, all of those moves look
> "tempting" to the peephole optimizer, with a lot of partial peephole
> pattern matches.  I could well imagine that your generated code might
> have a similar behaviour.

The bulk of the code the parser generator produces initialises
three large tables, so that might well be a source of the performance issue.
 
> 
> Here are a couple of other things that you might try, since you've
> narrowed things down to the codegen.
> 
> You could try "-native-optimize 0", which will disable most of the
> codegen specific optimizations.  But, like "-ssa-passes minimal", by
> skipping the optional optimization passes, there might be more work
> left for the required passes; e.g., without some peephole
> optimizations and copy propagation, there will be many extra
> temporaries for the register allocator to handle.

I tried -native-optimize 0 and it didn’t seem to make any significant difference.

> 
> You could also try the C codegen, rather than the native amd64 codgen.
> That is, compile with "-codegen c" or "-codegen c -cc-opt -O0".  The
> former would use the C codgen with a default set of flags, including
> "-O1", passed to gcc, while the latter would add in an additional
> "-O0" flag to gcc, which might speedup the time compiling with gcc.
> In either case, the "C code gen" time should be nearly zero (it is
> just writing a C file), but you would want to watch "Compile and
> Assemble" time, which will go up as it will be gcc doing the real work
> of lowering to native instructions.

It seems to be vital to use -O0 rather than -O1, particularly with clang
rather than gcc. With -O0, the overall time is comparable with
the native codegen: say 8.5 seconds overall compared with 6.5.
With -O1 that went up to 38.5 seconds. That was with gcc running
on Fedora 20 on my iMac inside a Virtual Box VM. With clang on
Mac OS X, the figures with -O0 are also comparable, but -O1 is far worse:
over 5 minutes for the example that takes 38.5 seconds on gcc.

For some of my grammars, using the C codegen crashes under clang
as follows:

/var/folders/zm/3wmsfd_5789fc0m379vwt3mw0000gn/T/fileCRuLHn.1.c:8791:2: fatal error: bracket nesting
      level exceeded maximum of 256
        BNZ (W32_0, L_5868);
        ^
/usr/local/mlton/latest/lib/mlton/include/c-chunk.h:64:12: note: expanded from macro 'BNZ'
        do {                                                            \
           ^
/var/folders/zm/3wmsfd_5789fc0m379vwt3mw0000gn/T/fileCRuLHn.1.c:8791:2: note: use -fbracket-depth=N
      to increase maximum nesting level
/usr/local/mlton/latest/lib/mlton/include/c-chunk.h:64:12: note: expanded from macro 'BNZ'
        do {                                                            \
           ^
1 error generated.
call to system failed with exit status 1:
gcc -std=gnu99 -c -fPIC -DPIC -I/usr/local/mlton/latest/lib/mlton/targets/self/include -I/usr/local/mlton/latest/lib/mlton/include -O1 -fno-common -fno-strict-aliasing -fomit-frame-pointer -w -m64 -I/usr/local/include -I/opt/local/include -I/sw/include -O0 -o /var/folders/zm/3wmsfd_5789fc0m379vwt3mw0000gn/T/filenIZmvb.o /var/folders/zm/3wmsfd_5789fc0m379vwt3mw0000gn/T/fileCRuLHn.1.c

The same examples work fine with gcc. Is that an issue for clang or MLton?

Regards,

Rob.

-- 
You received this message because you are subscribed to the Google Groups "MLton-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
MLton-user mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-user