Interesting benchmark performance (was RE: Pitiful benchmark perf ormance)

[Thomas Lindgren]

> The simplest method could be to make it a beam startup parameter rather than
> a constant. Then for weird applications the value could easily be tuned for
> max performance.

This could be sufficient if the system behaves in roughly the same way
all the time (eg, amount of concurrency or I/O is roughly the same),
though tuning (and possibly retuning) the system could be a chore if
you have to restart it to change the magic number.

(If performance is reasonably robust over #reductions, the need to
change the number is probably small, though.)

> It could be an interesting excercise. There appears to have been a large
> amout of effort put into all the BIFs to try to make them as fair as
> possible. Possibly this is heavier than making them all interruptible based
> on a time slice??

Basically, the problem is that a reduction need not be well-correlated
to a fixed elapsed time. When and if this is a problem, a cycle-based
time slice could be (more) useful.

Having BIFs being non-interruptible (or composed of "atomic pieces")
is however a nice property, and I think we should keep it that way as
far as possible. Basing rescheduling on elapsed cycles means we will
at least switch "soon after" completing a long-running BIF, rather
than completing a possibly large number of (costly?) reductions.

Digression: one approach for dynamically modifying the schedule in
regular Erlang could be the following. Assume we have a BIF
CostlyOp(). We can then wrap it as:

       ...
       T1 = erlang:now(),
       CostlyOp(),
       T2 = erlang:now(),
       erlang:bump_reductions(time_to_reds(time_sub(T2,T1))),
       ...

Where time_sub computes the elapsed time between T1 and T2, and
time_to_reds/1 converts elapsed time into 'average reductions'. The
drawbacks are code bloat, extra execution cost, imprecision (eg, no
knowledge of how much time remains in this slice) and the need to
manually place these wrappers.

			 Thomas
-- 
Thomas Lindgren					thomas+junk@REDACTED
Alteon WebSystems