Re: which way is faster?
- From: "Wolfgang Kern" <nowhere@xxxxxxxx>
- Date: Fri, 11 Jan 2008 14:53:02 +0100
Wannabee skrev:
....
Windoze seem to occupy all the cache anytime, so we are lucky if we
got one free line for our tests.
No. You get a whole timeslice, which can be very long if you run in
realtime mode. The reason why windows seems so slow, is the constant
paging of memoryhungry programs, plus (I guess) I/O sheduling.
Window is simply slow because hardrives, and I/O are slow.
Haven't KESYS and L'unix to deal with the same hardware as windoze ?
And because certain windows apps, does not pay any attention
to avoid this problem. (Bittourment for instance, windows itself, and also
Opera is dog slow in this regard). Windows is often just I/O bound.
Given that you only talk to memory, windows is not at all significantly
slow.
The kernel is _not_ faster then user apps. I think we should confirm it.
The problem with an 'event-driven' OS is that an IRQ may direct trigger
a huge program part assigned to it and blocking other events and threads
(well known as the hour-glass and the frozen mice) for some time.
Write an app, in dos that floats a 256*256 bitmap across a 32 bit
formated, vesa canvas. Then I write one using only GDI. Then we can
compare the framerate. It would also be interessting to see for other
reasons.
Ye olde DOS is awful slow on this, because it needs to detour with
INT10h for every dot or has to use the little 32 KB frame at A0000
and switch the pages of this all the time, ...
I never heard of speed comparisons between dos and windows. (Even
I guess they exist).
...but with any 32-bit DOS-extension like KEMM (still found in DEMOs)
and flat framed VRAM, the screen memory can be written as fast as
the Bus allow (beside AGP- and HW-specific accelleration yet).
....
nearly all my cycles are taken by drawing.
even writing a single char to a graphic screen cost more then
counting the entire string.
A solid graphic character needs ie: 16*8 = 128 dots to draw,
and foreground background colours are the obstacles here ;)
So it is faster to 'fill' the background rectangle with lines, if
required at all, and output the characters in transparent mode
(at least faster on KESYS).
I need to compare my code with windoze one more time.
My screen routines write direct unbuffered to the VRAM and the
last upgrade on text display show an average of 33 cycles per dot,
but it still works on single characters and I think to improve
this and work on whole strings, so it may end up below 30.
Didnt understand anything after "but".
btw, did you like the youtube link I posted?
(yes in 3rd reading. Yes. Good idea. Write it a whole scanline at the time
will remove a Bunch of cache misses. I guess you are just toying with me
now eh? ).
Not yet :)
I like to save on the call/ret pair for every character and loop on
string size in the core instead, even this slow single characters then.
....
:) boot an old DOS6.00 and run your code under test there ?
the problem with timing in windoze is just a windoze-problem ...
we measure cache penalties and page faults, and our code could perform
that fast, that we don't even see any difference.
Well. I did manage to time your 40 cycles code to 48 cycles.
(and if we remove the overhead from that)?
which one do you have in mind here, the 32 bit ASCIIh2bin ?
yes, the BCD(BCH) packing could be improved here.
If you want lets do the bitmap test I noted above,
and see what comes out?
Fine, even I don't have Vendor specific accellerating DirectX-drivers
for it, I'll time a bitmap of this size using the DEMO-KESYS under DOS,
but I need to create a 256KB picture in 32-bit format first,
because KESYS isn't a game console it's standard is 8-bit colour.
I assume we both use 1024*768,32 (@100Hz, if this is relevant at all).
__
wolfgang
.
- Follow-Ups:
- Re: which way is faster?
- From: //\\\\o//\\\\annabee
- Re: which way is faster?
- References:
- which way is faster?
- From: shikamuk
- Re: which way is faster?
- From: Wolfgang Kern
- Re: which way is faster?
- From: //\\\\o//\\\\annabee
- Re: which way is faster?
- From: Wolfgang Kern
- Re: which way is faster?
- From: //\\\\o//\\\\annabee
- Re: which way is faster?
- From: Wolfgang Kern
- Re: which way is faster?
- From: //\\\\o//\\\\annabee
- which way is faster?
- Prev by Date: what is rsrc.rc?
- Next by Date: Re: which way is faster?
- Previous by thread: Re: which way is faster?
- Next by thread: Re: which way is faster?
- Index(es):
Relevant Pages
|