Hi John and all
On Sun, 15 Aug 1999, John Morrison wrote:
> Hi Thomas;
>
> Thomas Bocek wrote:
> > I made a little benchmark with the old source and with the new one:
> >
> > old: vga fillroutine ~7 sec
> > new: vga fillroutine ~5 sec
> >
> > The results aren't exact, because
> >
> > 1. made the test with a stop-watch
> >
> > 2. the old source crashed after 7 sec, and the screen was only 1/5 filled,
> > the new source crashes after the screen is 4/5 filled.
>
> OK, so if I were to extrapolate, the old one would finish in 35 seconds
> (barring a crash - HA), and the new one would finish in about 7 seconds
> (barring a crash), right? So, this means we've speeded up the
> calls-to-native code about 5 times, eh?
it's "only" about 40% faster: I marked the position of the (old source)
crash on my crt, and stopped the time, when the new source reached that
position.
But the clear screen seems to run much faster...
> If so, is performance creeping
> into the "acceptable for now" range (At least, until we do the
> JavaOS-style memory classes -- I'm also curious as to why the write32
> stuff is SLOWER -- can you try that one, too?)? If so, is the
> memory-management stuff now the hottest fire?
hmm a write32 is still about 10 times slower than a write8, but a write16
is about twice as fast as write8.
> With respect to the crash:
>
> (1) When my version hangs after displaying the checkmark, is that the
> crash's failure mode? I mean, is this the same "crash" you're getting?
> If so, I can try and debug it.
the checkmark seems to run fine (there's no switching to text console
yet), but the pixel fillscreen test crashes after a while. Usualy I get
the screen filled with <000000> (div by zero I think) or a jbHeap error.
> (2) Do you think it would help if I wrote something that, in the case of
> a detectable crash, reset the VGA display to text mode and spat out some
> debugging info? (Our own little BSOD! What color should I make the
> screen?)
hmm blue? doh, sorry I mean red.
> I could print out:
> (a) a diagnostic string
> (b) the native-code stacktrace (with "nm" you could see where in the JVM
> we were)
> (c) and maybe some other Java stuff (I'd have to think about how to do
> this, and fit it on one screen -- there could be quite a few Java
> threads -- too many to fit on one screen)
printing on screen is ok, we can change the mode to 80x50 or 116x50, so we
could see more.
> We don't have enough of a console/GUI/Window Mgr for me to do anything
> else, right?
a log would be nice... but still no hdc driver (still searching for a good
manual).
> Again, thanks for the help -- I appreciate how, er, hostile the
> debugging environment is at this point in time! I shall endeavor to
> make it less so.
[cut]
Thomas Bocek
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
