Jerome Vernet (Orange) wrote:
> I finally build a working PPC build for 10.4.7. Seems to be much slower
> than the 10.3 build. And the speed reported goes from 0.1 Mhz to 270 Mhz ;).
>
Unless I got the mhzactual math wrong (and that's quite possible), it
probably is the equivalent of
that speed, and it seems slower because it no longer responds to UI
events while it's stuck in a
very tight loop.
mhzactual= 0.001 * ( (float)(cpu68k_clocks-last_runtime_cpu68k_clx)) / ( (float)(elapsed-last_runtime_sample) );
So the 0.001 is to turn 1/5MHz elapsed cycles into milliseconds. The
elapsed - last_runtime_sample
are in milliseconds. The cpu68k_clocks/last_runtime_cpu68k_clx are in
cycles.
So the way the MHz actual code should work is that it gets the
cpu68k_clocks difference which is the number
of 5MHz cycles, and compares that to the number of milliseconds that
have passed, then based on
how much time has passed to execute that many cycles says this is the
equivalent of running at X Mhz.
Do I have the right formula there?
> I add some optimization flag to build.sh, but with -fast -mcpu=7450
> (turn on all optimization option on), Lisaem doesn't build (error on
> link, I think due to gcc bug).
>
Yes, be very careful with the generator core code. It seems to run out
of registers to spill if you
do that on intel. Not sure where it'll break on PPC. That's why that
code is marked with -O2
(I think.)
> So I only add -03 -mcpu=7450
>
> I also try -ftree-vectorize, some more speed up (may be ;))
>
> Some strange thing:
>
> *Power off doesn't work very well (some strange windows bugs happens:
> windows goes nearly full screen, Lisaem seem to hang but still respond
> slowly to menu command).
>
That is very very strange. Any chance you could turn on profiling and
let me know what you find?
I'm still a bit new to OS X. :-)
There are two things that happen at power off. One is that the printers
are flushed. You really
should only have a single printer, if you have more, this step will take
a lot of time. Even a single
printer will be a bit expensive at power off. (It's trying to see if
there's any data in the page frame
buffer, if there is, it will print it, or produce an image, after that
it deletes the printer object.)
The other is the contrast change. LOS will dim the screen slowly. It
turns out that the
ContrastChange method is much slower on OS X than on other platforms.
This is why this has a define around it in the beta 2007.03.15 beta 2 code at the bottom of void LisaWin::ContrastChange()
#ifndef __WXOSX__ // 2007.03.14 disabled for os x since it slows down shutdown a whole lot
force_refresh(); // win32 still has contrast-trails. :-(
20070216
#endif
On windows, if you launch lisaem and go and do other things, then come back to LisaEm, you get Contrast-trails until the next full refresh. I've not seen this on Linux and with OS X's double buffering, it never happens there.
By the way, the Right mouse button forces a screen refresh if you ever need it. Received on 2007-03-15 17:08:04
This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:14 EST