Re: [qvtd-dev] M4 commits

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

Waits are certainly reduced by better scheduling and at the moment, I've disabled some optimizations to stress the wait scheduling logic.

However some waits are unavoidable.

a) the run-time deferred invocation resolves a wait for a transitive access to some *:1 property, but requires that all input objects and all *:N property accessed objects exist.

b) waiting for input objects or *:N content requires an accumulator. Possibly just a lazy allInstances(). Better an accumulated-instances. Optionally a re-computed-instances.

Consider the superClass resolution of example2. All classes must be created, contained and named before any superclass can be resolved. The invocations must therefore be delayed. The iterator for the invocations is accumulated from the lasses of root classCSws, wierdly-contained classCSes, packaged classCSes, packaged-packaged classCSes, ... The recursive traversal of the packageCSes needs to accumulate the values for later.
In this example allInstances() could work, but incurs more overheads than accumulating what has already been intelligently vetted. Retraversing can be accurate but also incurs more overheads.

Wait accumulators are also unavoidable for multi-headed mappings whose invocation can only iterate sensibly and lazily on one input. The others must be eagerly available in some accumulator.

----

I've only had time to promote the 'neutral half' of ewillink/480567 and I'm not totally confident that it's a coherent half. Please wait till you see the repackaged commits for the other helf before assessing/merging.

    Regards

        Ed Willink

On 16/12/2015 16:36, Adolfo Sánchez-Barbudo Herrera wrote:

Hi Ed,

From a scheduling point of view, couldn't not "simply" those mappings producing those "further requirements" be called before B is executed ?. If it were required, coundn't they even be called before A is executed ?

It sounds like as if a new runtime mechanism is solving a lazy/not-clever-enough scheduler.

On the other hand, I'm glad to hear that M4 will have a stable version of the scheduler on which I can work. I'm looking forward to merge my asanchez/mtc3 branch. Although I expect a fair amount of conflicts to look at, I'll give it a try tomorrow to see what's the outcome.

Regards,

Adolfo.

On Wed, Dec 16, 2015 at 2:41 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi

My presentation at York had one major flaw. It assumed that a call graph built by considering producers and consumers of region heads was satisfactory for both control and data flow. It isn't.

If A provides something for B (data flow), it is convenient to call B from A (control flow). BUT if B has a further required value that A cannot satisfy, the call of B must be deferred until the further requirement of B is satisfied. A must therefore place its output in a temporary buffer within a suitable ancestor until all the directly referenced inputs of a B invocation are available. This problem for a single headed input is the same as occurs for multi-headed input. The solution can be therefore shared and is now on ewillink/480567, but one test fails intermittently; bug partially understood.

QVTi does not support a mapping that executes by assigning to or accumulating in a buffer. It is possible to fudge a "x : Set(X)" guard variable and then do "x := x->union(more);" but it's a but klunky. Better to introduce an updateable middle guard "where (x : Set(T))" that can be updated by a bottom assignment "x += more;". The new form of an assignment uses a new ConnectionAssignment AS class. The new form of guard variable is distinctive since the middle/where guard had no variables in QVTi.

The intermittency might be fixed today, but the general clean up and review certainly won't be, so I'll try to cherry pick all the ConnectionAssignment support changes for M4 so that M4 can be used as a stable development platform for the new scheduler.

    Regards

        Ed Willink


_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev

_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev