[m-dev.] proposal: remove hlc_nest and hl_nest grades

[Julien Fischer]

Hi Zoltan,

On Thu, 31 Aug 2017, Zoltan Somogyi wrote:

> On Thu, 31 Aug 2017 13:25:57 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>> Are there any objections to removing support for the hlc_nest( and
>> hl_nest* grades?  (i.e. high-level C with GCC nested functions).
>>
>> While they were (presuambly) useful in the past for evaluating various
>> design decisions in the MLDS backend, they haven't been used (or even
>> documented) for quite a while now.
>>
>> Additionally, GCC's support for nested functions was a bit flakey last I
>> looked, so I can't really see anyone ever wanting to use these grades in
>> anger.
>
> I haven't used them in anger at all; when I did use them, it was just to check
> they still worked (a long time ago).
>
> However, if they do work right now, it would be best to see how fast they are
> compared to their non-nested versions. IF they are faster, and IF there is still
> some prospect of gcc resolving the flakiness (about which I know nothing),

Back (at uni) we used to test them regularly; there was series of
problems with those grades and the early GCC 4.x releases.  (I have no
idea what the current state is ...)

> I would prefer not to delete them just yet. Otherwise ...
>
> By the way, does anyone have a machine that is good for benchmarking?

I'll discuss this with you off-list.

> I would do the test above, but my laptop does thermal throttling in a way
> that is bad for timing repeatability. I have seen two successive runs of
> the exact same task (in tools/speedtest) return times as different as 20s and 30s.
> This means that to get any information, I need a lot of runs (to average out
> the variability), and even then, the results I get are not very precise.
>
> Do the Java and C# backends use nested functions?

No.  (The internal option that enables nested functions is named
gcc_nested_functions with good reason.)

> If not, and if we *do* delete the hlc_nest grades, then we should
> simplify the MLDS backend. At the moment, we always generate MLDS code
> with nested functions, which ml_elim_nested.m then hoists out. Having
> the code generator generate the functions in their non-nested form
> directly would be simpler and faster, partly because it wouldn't have
> to cater to ml_elim_nested.m's limitations.

That's one of the reasons I suggested removing them.  In fact, IIRC
ml_elim_nested.m is actually a bit of a performance bottleneck on
large programs.

Julien.