Date   : Tue, 11 Nov 1997 08:45:09 +0100
From   : "Mark Usher" <insoft@...>
Subject: Fw: Speeding up BeebEm

Forward from W. Scholten <wouters@...>


> I have forwarded this conversation I was having with Mark Cooke to the
list
> as there will no doubt me many of you who know more than I do about this,
> and I'd appreciate some other views on the subject.
>
> MU>>I was looking at the code myself recently. Although I cannot profess
to
> MU>>being a C programmer, more a learner in that dept, (I've programmed
> though
> MU>>for many years), I think that if BeeBem was spawning threads instead
of
> MU>>looping as it does, it would produce a significant improvement as the
> MU>>processor would not be weighed down so much as it is at the moment.
>
> MC>There threading *might* be a gain is in emulating the hardware more
> MC>accurately by running (for instance) the via asynchronously, and
> similarly
> MC>for the CRTC.  However, this gains slightly in accuracy - but is a dead
> MC>loss if you try to keep things in sync with a motherboard crystal.
> MC>However, if you want to be more specific about how you think threads
> would
> MC>help (and which loops you're talking about in BeebEm) I would be
> MC>interested in your ideas. :)
>
> Like I said, I'm not an experienced C programmer, but I am quite
experienced
> when it comes to operating systems / general programming. I was looking
more
> at the way the emulator "gobbles up" my system resorces when it runs, and
> I'm running a 200MMX 512KB 128MB 9GB system here, at work I've a Pentium
II
> 512KB 64MB 4GB, and it's the same story. So I was trying to look at the
way
> it's programmed and think of ways in which the code can be optimized.
>
> Comments anyone ?

Yes. You need a lot more memory, say 1GB RAM, a faster processor (ask
Digital nicely for a beta version of the 21264 (at what, 700Mhz water
cooled? Or are they at 800 already?)

Further I suggest overclocking it at 900MHz and putting the whole damn
computer in the freezer to keep it cool.

Now your problems should be over (and run linux, which has a system
resolution of 1 ms on the alpha).

Btw, I assume the problem is under windoze, what about linux? I don't
remember experiencing any system hogging (been a while since I used it
though, and I have 'only' 32MB).

As to actually reducing the load, I haven't closely looked at the
source, but it simply runs as fast as it can, instead of using a
timer/alarm for exact 50Hz refresh. However, this gives problems anyway
under most *nix's; the free ones I know have system resolution of 10ms
(linux except on the alpha, FreeBSD), which means a minimal usleep time
of 20 ms. Thie means you can't explicitly give up processor time (you
just have to do busy waiting).

W.