"Andreas Raab" <Andreas.Raab at gmx.de> is widely believed to have written:

> John wrote:
> > > I was thinking about this.
> > > What if you did some samples to decide how long the primitives ran.
> > >
> > > Say start with an array of flags to indicate if we should
> > > check the clock for the primitive in question. If we don't
> > > know the state of the flag then collect a few samples of
> > > duration, then based on the numbers set the flag as required.
> 
> Bad idea. Consider BitBlt - if you draw a string all the prims complete
> quickly because the glyphs are very small. And then you have large area
> image copy operations which can take quite a bit of time.
Absolutely - bitblt operations have an enormous spread of time-taken. It
was one of the major things we hacked for the realtime stuff at
Interval; make it possible to interrupt the blit at the end of a
scanline and to restart later.


> 
> Tim replied:
> > I think the neat thing about using Slang pragmas to encode
> > the checks in the prims themselves is that adding the cost
> > of a clock check to a prim that is almost certainly long
> > running is a negligable cost. Leaving the check out of a
> > known quick prim is likely to be big saving.
> 
> And that's the wrong way around because you're making the optimization
> (omitting the check) the default.
I certainly didn't mean it that way; my expectation would be for a
default (ie no pragma in the slang, a likely default for old code not
'updated' yet) to mean 'add the check' for safety's sake.

> 
> BTW, in my understanding there should be no need _at_all_ to flag primitives
> explicitly or measure the runtime. Part of the idea behind the pluginization
> process was that we would have all the indexed primitives be quick and all
> the external ones be slow[**] - in other words, once the pluginization were
> complete we should be able to simply omit the entire check in primitive
> response and add it to #primExternalCall. If there were still some indexed
> primitives that needed the check (primitiveBecome comes to mind) then those
> should explicitly implement them (or be called by name).
> 
> So how's that? Let's just move the clock check over to #primExternalCall and
> add a few extra checks for slow-running indexed prims?
I think that would make an excellent heuristic.

I suspect there are some indexed prims that might need checks if one
were to be really pedantic about it. For example, prim117, the
look-up-the-named-prim primitive pretty much has to be indexed (I don't
think we could make it look itself up could we?) and can take a very
long time if a plugin is not loaded. Does it happen often enough to
matter? Probably not.
As Andreas says, just about all the currently-index prims that take a
long time could be recharacterised as named. become:, fullGC, a lot of
IO & Display prims, etc would be well tackled this way. There are a few
interesting cases where the normal case is fast but something like a GC
can be involved; I'd imagine that we could make the GC code set an
appropriate flag - primMakePoint is an example. Surely there are some
other awkward cases that would require manual intervention but so what.

If possible I'd like to see the triggering of GCs removed from
primitives as much as possible. Much nicer to fail the primitive and let
the image work out the response; thus the developer can define the
memory policy rather than the VM builder.

This would be nice. I think we could get down to less than 200
(even 100?) indexed prims quite easily and reduce the size of the
primtable. Many of the IO/Display prims could be moved into a
platformPlugin - maybe helping with a good headless solution.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
How many of you believe in telekinesis? Raise my hands....