[chuck-users] now v.s. actual time

[Stephen Sinclair]

On Thu, Oct 9, 2008 at 8:55 PM, Tom Lieber <lieber at princeton.edu> wrote:
> With code like:
>
>  while(notdone) {
>    dowork();
>    pause_dur => now;
>  }
>
> tweaking pause_dur until the computationally heavy code runs without
> skipping is the same as benchmarking it to figure out how long it
> takes to execute, and it's safe.
>
> I don't think system calls, even ones like reading files, should take
> a shred out of the shreduler until they finish, though I admit that's
> personal preference. Deterministic parallel code like ChucK's is hard
> to come by.
>
> But code like this:
>
>  me =< now; // step outside time
>  doallwork();
>  me => now; // step back
>
> just can't happen.
>
> Allowing shreds to step outside time would solve all the problems
> brought up in the thread, but it would weaken some of the data
> consistency guarantees ChucK's cooperative multishredding gives you.
> Even if ChucK could interleave execution of your Neo shred with that
> of those still enslaved by the virtual machines, Neo would have to be
> frequently interrupted in the middle of whatever he was doing to
> prevent audio underflows. And since he doesn't know when he'll be
> interrupted, his data won't necessarily be consistent.

Hm, are you talking about introducing "real" parallelism? (i.e., pthreads)
I didn't really mean to imply that in anything I wrote, at least.
I agree that doing it properly would be difficult and error prone.
Probably the "out of time" shred would need to be forced not to access
any common objects, at the very least, and communicate by other means
than global variables.  (this would be equivalent to OSC, as you
mention at the bottom.)

> If it were a local variable in a for-loop, fine; but what if it were a
> variable global to the file, or a static variable in a class used by
> other shreds? ChucK code is written with the assumption that if
> doesn't let time pass, no data can change beneath its feet.
>
> My recommendation: use multiple ChucKs with message-passing (OSC,
> whatever). I hear Prof. Cook does it, and he seems like an all right
> guy.
>
> ---
>
> By the way, I'm sorry, but I still can't figure out what this would be
> expected to do:
>
>  realnow => now;

The problem that was brought up on the forum was how to do a bunch of
intensive computation before starting the audio synthesis running,
without causing problems.  I think I took the liberty of generalizing
the question into how can we do a lot of computation _anywhere_ in a
chuck program without stalling the other shreds and causing havoc with
the dac.

My suggestion was to advance time throughout the lengthy computation,
to make sure every other shred can get a chance to do its stuff.
Kassen noticed that we have no way of knowing at what point during the
lengthy computation we should advance time, without making a guess as
to how long the computation will take.

The 'realnow' suggestion is to make it possible to tell what time it
is in real time.  In logical time, a bunch of computation takes no
time at all, but of course in the real world time is passing.  So
looking at the difference between realnow and now would tell you how
much time you've used doing computations.  In principle at the
immediate beginning of a function, realnow and now are equal.  After a
few instructions, realnow has advanced, but now is still the same.  So
chucking realnow to now makes logical time advance to the state of
real time.

In other words, if a function takes 3 ms to complete, you could make
sure not to interrupt other shreds by,

while (...) {
  longfunction();
  realnow => now;
}

This would ensure that logical time advances during the computation,
while not forcing you to guess the actual time that longfunction()
takes to execute.

Note that none of this means changing anything in the shreduler.

And yes, using multiple chucks with OSC is something else I suggested
on the forum.  You could even use another more optimized language to
do the tough computations and pass back the results.  OSC is great
because it makes it easy to introduce inter-process procedure calls.

Steve