Continuing emulation conversation..

[veniamin-ilmer]

Continuing the conversation from here:
#31
Sorry I didn't realize there is a discussion section until you noted it.

I have a lofty dream of converting my 8088 emulator into a general "chip emulator" crate for tons of different types of chips. Since this would be used as a library, I didn't want to force the user to use any particular framework.
I spent a bit of time looking for alternative ways to declare the chips in a more general way, with a variety of ways.. Generators, reference counting, etc..
But after nonstop fighting the borrow checker and going through various annoying boilerplate code, I keep coming back to Stakker.. It might end up being required in order to use the chip crate.

Going over your comments:

Your main loop will spin between timers. But maybe that's okay considering how responsive you need it to be. Maybe sleeping to wait for the next timer would be too much overhead (i.e. a syscall, relatively slow). Also it would be quite easy to make this run in virtual time instead, which would avoid the spinning, but that is only useful if you're planning to run a hosted program to completion and then stop.

I am using Windows. And sleep sucks for anything less than a millisecond. I haven't found yield to do much better. I don't fully understand, how does virtual time work? Would it be able to schedule nanosecond delays?

In your submodules, I see what you're saying. Those are really impl CPU {...}, but written out by hand. Doesn't Rust allow you do split an impl CPU {...} across files? I thought it did (although I haven't tried recently). But anyway, you could use the closure format of ret_some_to!([cpu_actor], |this, cx, ...| ...) to direct the call wherever you need.

You can split up the impl across multiple files, however I don't like this because it then becomes confusing, which file holds which methods? That is why I like this more declarative approach where you have to specify the file every time you want to use a method.

I'm interested in seeing how your project develops, and what opportunities it provides for optimisation of Stakker. Also, when you have an idea of what kind of performance you're getting out of it, it might be interesting for promoting Stakker. I remember some guy who was absolutely certain that tokio channels would beat my inter-actor calls. What can you do? I'm counting branch instructions, and they're doing cross-core synchronization ...

I started out with running all the chips in multiple threads with message passing and mutex locks. The biggest problem is sending out a request for input, and then waiting for a response. I timed, this took a good 500 nanoseconds, regardless of the library used. That is too long. When "booting up" the 8088 bios runs a test to make sure the timer chip is running at the correct speed, relative to the cpu. Regardless of my attempts, the test kept failing. After I switched to Stakker, the timing issues all magically went away.
Each 8088 tick needs to have a 210 nanosecond delay, which it successfully hits with Stakker. I have not tried to overclock this to find out maximum performance.

If your application gets scheduled out, then when it comes back, Instant::now() will have leapt forwards. This means that in your code where you do cx.now() + duration, that time will also have leapt forwards. So this breaks the simulation if you want it cycle-perfect. In a normal application, if you get behind (too much load), you want to be tolerant to that and degrade performance gracefully (for example, if a timer is called late, you set the new timer relative to cx.now() to not add further to the load). But you don't have to do that here.

I am a little confused here.. Let's say I have a function:

fn run(&self, cx: CX![]) {
  //Do some work
  at!(cx.now() + duration, [cx], run());
}

I was under the impression that cx.now() would be the time run started. Is that not the case?
The reason I wrote cx.now() + duration, is that the next run must run after the duration, independent of how much time actually progressed.
If the code is taking too long to run, that it passed the duration, then that means I have reached beyond maximum possible performance. In this case, the emulation is running too slowly, and I hit the limit of what is possible to emulate.
Does this make sense?

[veniamin-ilmer]

The more I work with your crate the more I wonder why it isn't more popular.
This crate reduces a lot of headache which comes with self-references..

[uazu]

I think I must lack abilities in promotion. Or maybe it is hard to get the concepts across adequately so that people see the benefits. After 20+ years of working with different kinds of event systems in different languages and facing a variety of different problems, I've put all the lessons learned into Stakker. However this doesn't seem to catch many people's interest for some reason. Maybe they have not yet suffered enough using other approaches. For example I still see people using deadlock-prone approaches, e.g. coding actors using channels. Maybe if someone who is a better communicator comes along, they could help out.

[veniamin-ilmer]

I have a feeling the most difficult part to adapt to is functions returning data asynchronously instead of just "waiting" for it to return. Being forced into building a callback function could discourage people. I attempted to use generators/yield as a way to "call back" to the previous spot in code. Unfortunately generators/yield requires maintaining a mutable generator object, which is complicated to keep around and reference for the callback function.

[uazu]

I want to add actor coroutines someday, for the places where that is useful. (I have experience using Lua VMs as actors, and Lua coroutines to add sequential-style coding on top of actor method calls, so I have experience with how this works.)

But building on async/await means I lose the QCell-style borrow-checking. Generators are better, but nightly only, and don't have all the features required just yet either. I could write my own sequential-code-to-state-machine converter maybe ... that's what I was kind of thinking of. Or maybe accept the runtime cost of using async/await as it stands. But this is for another day.

[uazu]

Virtual time is when time provided to Stakker is disconnected from actual clock time (real time). Stakker just trusts whatever time you give it, and if everything uses cx.now() to get the time, the entire system can run with whatever time base you want, faster or slower, etc. So instead of using Instant::now() to synchronize with actual passing time, you can make time advance however you want. Some variations:

• Run time at a fixed multiple of real time, either slower or faster
• Instead of doing a sleep in the main loop, make time skip forwards, which means that the program will saturate the CPU and get though the job more quickly.

This is good for running long tests, meaning that the test will only consume however much CPU time it needs, rather than doing all the sleeps. (At work we have tests that in real time would take hours, but running in virtual time take very much less. The code under test can't tell the difference, because time is fully virtualised, i.e. the code thinks that hours have passed, but perhaps it was only 2 minutes on the realtime clock.)

For your purposes, I was suggesting running in virtual time, but limiting it to no faster than real time. So if the host CPU is fast enough, it will run the simulation in real time. But if you get scheduled out for a moment or the CPU is not fast enough, it will run slower than real time, but completely correctly (i.e. time acts consistently in the simulated environment).

I hope you can see that by running virtual time, we're simulating a perfect environment where there are no unexpected skips in time. However if you use Instant::now() and Window schedules your process out for 1ms (for example), then from the point of view of the simulator, it looks like time jumped forwards by a big step. A whole bunch of timers will all expire all at once, much later than their expected expiry times.

If you use the main loop I suggested then that provides the illusion of perfect time-keeping for the simulator, no matter what happens in the Windows environment (scheduling out, temporary high loads, etc). Then to make it go no faster than realtime, for the purpose of human interaction, the while loop spins to slow the simulation down if it is going too fast. (It would be possible to refine that main loop a bit to make it more efficient, and to better handle situations like the OS going into hibernation or whatever.)

[uazu]

I was under the impression that cx.now() would be the time run started. Is that not the case?
The reason I wrote cx.now() + duration, is that the next run must run after the duration, independent of how much time actually progressed.

Yes, that's right. cx.now() is the time passed to run. If you are happy to absorb time skips (e.g. due to being scheduled out, or OS going into hibernation) and just continue from there, then doing cx.now() + duration is correct. If you have various timers of different durations, after a big skip, they'd all expire at the same time. So this means that suddenly they'd all become synchronized. Whether this will break things or not depends on how sensitive the system is to weirdness like this. But in hardware with independent chips and clocks this would never happen, so in that sense it is unrealistic.