[m-dev.] making .trans_opt files in parallel

[Zoltan Somogyi]

2022-12-13 20:22 GMT+11:00 "Julien Fischer" <jfischer at opturion.com>:
> On Tue, 13 Dec 2022, Zoltan Somogyi wrote:
>> They allow intermodule inlining of small but possibly often-used
>> predicates and functions. Whether that is "much value" is in the eye
>> of the beholder. I happen to think it is borderline useful. I agree that
>> the termination and other analysis results in .trans_opt files were
>> much more useful for writing papers than they are in practice :-(
> 
> I can think of two exceptions to that: the analysis results from
> trailing and the minimal model tabling analysis proved very useful in
> reducing the overheads of those two things.

Agreed, but then, I don't usually use either trailing of minimal model grades,
despite implementing large parts of the latter.

>> I have turned your dependency description into an actual dot file,
>> and converted that to a PDF; these are attached. The cluttered and
>> unreadable nature of the PDF shows that these are not really usable
>> for visualization for programs of this scale.
> 
> Given that you converted it into a PDF, I'm not suprised. Converting
> into an SVG (gzipped version attached) and loading it into a web
> browser, looks (somewhat) better.
> 
> (In practice, more work would need to be done on generating the dot
> files in the first place, e.g. labelling the edges.)

As you say, that is somewhat better, but not enough. It still has the
same two flaws. First, it insists on showing you the whole forest,
instead of allowing you to look at just the trees you are interested in.
Yes, you can zoom in, but you can't delete the irrelevant arrows crossing
through the area of interest. Second, there is no way to query *why*
a particular edge is present, i.e. why module A imports module B.
When you want to know which way of breaking a cycle would be best,
you want to pick the edge(s) with the dependencies whose optimization
or not have the least performance impact.

I suppose the first problem could be addressed by breaking the job
into two parts: computing the strongly connected components
of the imports graph, and then generating a separate dot file for each scc.
It would be better if you could do this interactively, but statically would do.
As far as the second problem goes, the dot manpage on my system says
dot supports tooltips on svg files, but its documentation *seems* to say
that it has limitations that would preclude our use case. The edge attribute
section includes this:

tooltip="text" is a tooltip string for client‐side imagemaps effective
when edges have a URL.

I have no idea why the need for a URL, or what the URL would be for.
Does anyone know?

Zoltan.