<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">For comparison, I have a Smalltalk-to-C compiler.</div><div class="gmail_default" style="font-family:monospace,monospace">Compiling practically everything together takes</div><div class="gmail_default" style="font-family:monospace,monospace">about 2 minutes on a laptop that currently runs Ubuntu 18.04</div><div class="gmail_default" style="font-family:monospace,monospace">but was originally shipped with Vista, and almost all of</div><div class="gmail_default" style="font-family:monospace,monospace">that time is in the C compiler.</div><div class="gmail_default" style="font-family:monospace,monospace">Ignoring lines that contain nothing but white space,</div><div style="font-family:monospace,monospace" class="gmail_default">and curly braces, the code expansion ratio is about</div><div style="font-family:monospace,monospace" class="gmail_default">4.2 lines of C for each line of Smalltalk, for</div><div style="font-family:monospace,monospace" class="gmail_default">650 kSLOC of C and 1.2M raw lines of C in total.</div><div style="font-family:monospace,monospace" class="gmail_default">This does not include hand-written support code.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">GCC has been able to do link-time optimisation (including</div><div style="font-family:monospace,monospace" class="gmail_default">cross-module inlining) by itself since the 4.5 release in</div><div style="font-family:monospace,monospace" class="gmail_default">2011. You need -flto -O3 both when compiling the individual</div><div style="font-family:monospace,monospace" class="gmail_default">files and in the link step.</div><div style="font-family:monospace,monospace" class="gmail_default">Clang also accepts the -flto option and a new variant</div><div style="font-family:monospace,monospace" class="gmail_default">-flto-thin which I have not yet tried.<br></div><div style="font-family:monospace,monospace" class="gmail_default">I believe the corresponding option in the Microsoft C</div><div style="font-family:monospace,monospace" class="gmail_default">compiler is /GL but it's years since I used MSVC.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">Two minutes is long enough to be annoying.</div><div style="font-family:monospace,monospace" class="gmail_default">But there is another issue.</div><div style="font-family:monospace,monospace" class="gmail_default">There was a machine I loved and a compiler that I trusted</div><div style="font-family:monospace,monospace" class="gmail_default">more than gcc. It only had about 4GB of memory, and trying</div><div style="font-family:monospace,monospace" class="gmail_default">to compile at high optimisation levels, the C compiler</div><div style="font-family:monospace,monospace" class="gmail_default">would run out of memory and crash. If I understand</div><div style="font-family:monospace,monospace" class="gmail_default">correctly, resource consumption at LTO time is the reason</div><div style="font-family:monospace,monospace" class="gmail_default">that Clang has -flto=thin.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">All things considered, generating a single file is not</div><div style="font-family:monospace,monospace" class="gmail_default">obviously useful for Mercury, even for distribution.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 14 Jun 2020 at 08:01, Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com">zoltan.somogyi@runbox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
2020-06-14 04:48 GMT+10:00 Massimo Dentico<<a href="mailto:m.dentico@virgilio.it" target="_blank">m.dentico@virgilio.it</a>>:<br>
>> Putting all<br>
>> the C code generated by the Mercury compiler into a single .c file<br>
>> will generate a huge .c file for any Mercury program of a nontrivial size,<br>
>> especially when compiled in a debug grade.<br>
> <br>
> Obviously this single C file would be for distribution only, not<br>
> for development.<br>
<br>
That would help, since a long compile time wouldn't be as much of as problem.<br>
<br>
> So no debug grade involved (I presume here that the<br>
> developers using the library would not be interested in learning<br>
> Mercury.)<br>
<br>
And this would help too, since debug grades generate much bigger .c files<br>
than non-debug grades.<br>
<br>
> I have read Henderson & Somogyi, "Compiling Mercury to high-level C<br>
> code" (2002) and I was under the impression that the ratio of lines of<br>
> C code produced for one line of Mercury code was not dramatically high.<br>
> Do you care/have time to explain why this is not (or is no more)<br>
> the case?<br>
<br>
No, the ratio is not too high, and hasn't changed all that much since that paper.<br>
I just checked: the compiler directory in the Mercury system has about<br>
500,000 lines of Mercury code (which occupies about 21 megabytes),<br>
which in the hlc.gc grade is translated into just shy of 2,600,000 lines of<br>
C code (which occupies about 110 megabytes). So the ratio is definitely<br>
not dramatically high. I was just drawing attention to the point that C compilers<br>
are tuned for acceptable compilation times on hand-written C code, and a<br>
single C source file containing over two million lines of code would be<br>
much, much bigger than anything they are usually asked to compile.<br>
<br>
As a compiler writer myself, I know that I prefer to avoid quadratic (or worse)<br>
algorithms when N is unbounded, but I don't mind using them when<br>
N tends to be naturally limited by the way people program. Since good<br>
programming practice frowns on such huge amounts of code in a single<br>
source file, I don't expect compiler writers to avoid algorithms that are<br>
quadratic in this respect.<br>
<br>
> Anyway I'm not particularly worried by this because I would like to use<br>
> Mercury only for the inference engine part of an application. The rest<br>
> will be in another language.<br>
<br>
This will help by keeping down N as well, so (depending on how big<br>
that inference part is) my warning may not apply to your use case.<br>
<br>
>> .......................................... This will mean that you<br>
>> wouldn't be able to compile that .c file with any C compiler options<br>
>> that call for the use of any algorithm whose complexity is O(n^2) or<br>
>> worse in the number of functions in the file. The last time I looked,<br>
>> this meant that even -O2 was off the table (though admittedly<br>
>> that was more than a decade ago). So the resulting executable<br>
>> code may be compact, but would also be quite slow.<br>
> <br>
> The assumption here is that -O3 is always beneficial.<br>
<br>
I was talking about the effect of losing -O2, not -O3. -O2 is useful<br>
much more often that -O3.<br>
<br>
> 3. the SQLite developers distribute an easy to use amalgamation file [4]<br>
> that is nearly 230,000 lines long and is 7.73 MiBs in size (version<br>
> 3.32.2).<br>
<br>
I did not know that, but note that this is still only about one tenth<br>
the size of the .c files of the Mercury compiler. Automatic tools such as<br>
the Mercury compiler can generate much more stuff (in this case C code)<br>
than programmers can do by hand.<br>
<br>
Zoltan.<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@lists.mercurylang.org" target="_blank">users@lists.mercurylang.org</a><br>
<a href="https://lists.mercurylang.org/listinfo/users" rel="noreferrer" target="_blank">https://lists.mercurylang.org/listinfo/users</a><br>
</blockquote></div>