[m-dev.] proposal: remove hlc_nest and hl_nest grades
zoltan.somogyi at runbox.com
Thu Aug 31 13:48:06 AEST 2017
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
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),
I would prefer not to delete them just yet. Otherwise ...
By the way, does anyone have a machine that is good for benchmarking?
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? 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.
More information about the developers