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

[Julien Fischer]

On Tue, 13 Dec 2022, Zoltan Somogyi wrote:

> 2022-12-13 16:00 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
>>> What we want to specify is effectively a dag; if module B is reachable
>>> from module A, then module A may depend on B.trans_opt; otherwise,
>>> it may not. Each no_trans_opt pragma would put only one constraint
>>> on the dag, and there would be no easy way to check that two such
>>> pragmas in different modules basically rule out both A using B.trans_opt
>>> and B using A.trans_opt, which would not be a correctness problem,
>>> but may be a performance problem.
>>>
>>
>> Yes, I don't really mind that.
>
> That is certainly a valid position.
>
>> (I don't think .trans_opt files provide
>> much value as it is, correct me if I'm wrong.)
>
> 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.
(That's not an argument in favour of the .trans_opt file BTW; the lack
of support in mmc --make makes them rather useless in practice.)

...

>> Nodes (module names) may appear multiple times. It may be convenient to
>> reverse the order of the edges so that the imported module is written on
>> the left. As in dot, we may also allow grouping and/or nesting, say:
>>
>>     foo <- {
>> 	bar,
>> 	baz <- quux
>>     }
>>
>> I wrote a quick program see what it looks like on the standard library
>> (attached).
>
> 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.)

Julien.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graph.svg.gz
Type: application/gzip
Size: 170588 bytes
Desc: 
URL: <http://lists.mercurylang.org/archives/developers/attachments/20221213/ae23a9e4/attachment-0001.gz>