Re: Compile-time v. execution-time tradeoff

On Mon, Mar 7, 2016 at 8:26 AM, Rob Arthan <[email protected]> wrote:
>
>> 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.

Thanks.  I was able to reproduce your results, including the increase
in native codegen time on the concatenated program.

> 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.

Interesting.  It does seem to suggest that some aspect of the source
SML code and MLton's compilation strategy is yielding a pathological
case for subsequent low-level optimization.

> 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?

Looks like an issue for clang.  The error message notes the
"-fbracket-depth=N" flag (to clang, which you could pass via mlton's
"-cc-opt" flag).  I wouldn't have thought that the C standard puts an
upper limit on bracket nesting level, but it does leave a lot of
things up to the implementation.

-- 
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