You might take a look at beam, the Erlang vm, historically at least the way it does scheduling is by counting "reductions" instead of counting actual runtime of processes, and counting something like that as a proxy for time might be less painful

hmm interesting

I'd imagine you could tune this as it went. Have a variable n that represents the number of steps to run. Run n steps. Check the time. If > deadline decrement if < deadline increment. Of course that isn't fool proof. If you can have a random task that takes the full deadline and it is completely unpredicatable, that might be bad. But if that is the case, you probably want to be looking at different processes getting their “fairshare” so if they exceed a deadline they might not get scheduled right away again. I can imagine various other ways if you can do things like async timers. But what you are talking about is cooperative scheduling. So looking into that literature might help.

yeah. right now I've implemented what is essentially a https://en.wikipedia.org/wiki/Round-robin_scheduling, and now I'm trying to see if I can optimize it by changing the n steps between checks intelligently. Going from every step to checking every 10 steps speeds up calculating a fibonacci number by about 10%

hmm, can you identify tasks discretely?

like maybe the solution is to run tasks and learn “weights” for each of them?

yes, each task gets an ID. I can also use the function and args used to start the task as potential identity

What are the "workloads" of the tasks?

Oh fib, nvm

It's possible I've been doing too much network programming lately, but it strikes me as analogous to trying to size the TCP congestion window to maximize in-flight packets (consecutive tasks) while avoiding drops (missed deadlines). So - in terms of strategy - you might be able to crib from TCP congestion control/avoidance stuff like additive-increase/multiplicative-decrease to converge on a # tasks per cycle. Or slow start/fast recovery, random early detection, etc. if you need to account for intermittent slowdowns or bursty tasks.

e.g. something like

init:
  m = n = 1

loop forever:
  i = 0
  while i < m: 
    # run m tasks without pausing
    run task[i++]
  while i < n and rand(n) > i: 
    # run up to n-m tasks with some probability of early interruption (presumes rand cheaper than checking deadline)
    run task[i++]
  while !deadline: 
    # run single tasks until deadline
    run task[i++]
  if i < n: 
    # deadline was caught by an early interrupt, multiplicative decrease on low end, cap high end to current
    m = max(m/2,1); n = i
  else: 
    # could've done more work, additive increase on low end, multiplicative on high
    m += (n-m)/2; n *= 2 # or more conservative: m++; n = i

  yield

can checking the deadline be made cheaper, somehow, so you don't need to do all of this?

@U3JH98J4R the tasks are arbitrary, but I'm testing this with fib rn

@U015879P2F8 that's super interesting, I'll look into TCP congestion

@U02N27RK69K I'm not sure, the deadline check code is fairly simple:

(let [start (js/performance.now)]
      (fn check-time []
        (- ms (- (js/performance.now) start))))