Mail Archives: djgpp/2007/01/06/02:17:17
<Gordon DOT Schumacher AT seagate DOT com> wrote in message
news:OF67F16F38 DOT 763FE5DE-ON8725725A DOT 0000AA4C-8725725A DOT 000183B2 AT seagate DOT com...
>
> This might seem like a strange place to be focusing on for performance...
> but it turns out that the GNU Pth library uses gettimeofday() from inside
> the "put a thread to sleep for x time" functions and that is something
> which can get called from performance-critical code (and profiling tells
> me is being done in the application I'm working on).
>
> It was spending much of its time in the __dpmi_int function (no surprise),
> and I figured out that better than 90% of those calls were coming from
> gettimeofday().
Why so many calls? Isn't it a design problem with Pth to consume lots of
CPU to set an alarm?
> So I started pondering whether there was a way to fix
> the library routine to not have to make a real-mode transition.
>
> Most of the data returned by the DOS int 21/2C and 21/2A functions can be
> obtained directly from the CMOS, with nothing more than port I/O: that
> will give us everything except the "hundredths" of a second field.
DOS or Windows? IIRC, PM port I/O is priviledged. Does anyone know if this
would affect Windows?
> For
> that field, what about installing a interrupt handler to simply increment
> a counter every timer tick, and reset it to zero when the counter reaches
> 91 (signifying five seconds have elapsed)?
>
Together with your second post,
<Gordon DOT Schumacher AT seagate DOT com> wrote in message
news:OFF86BAC20 DOT A8BCA0CB-ON8725725A DOT 005C40FB-8725725A DOT 005CCBAF AT seagate DOT com...
> In fact, it would not even need to be done with an interrupt handler. The
> first time the function is called, the int21/2C function could be called
> in order to determine the hundredths value that DOS is using. Then the
> clock() function could be called to align those two values, and thereafter
> the clock() function could be used instead.
>
I like the basic idea. But, I think you'd need a faster timer. And, I'm
unsure of interactions with various DOS's and Windows. (I did find one XP
potential problem, explained near the end).
You didn't say what timer: IRQ 0 (int 08h) or IRQ 8 (int 70h)
IRQ 0 by default is 18.0265Hz.
IRQ 8 by default is 1024Hz.
For "hundredths" of a second, wouldn't you want a timer of 100Hz or greater?
Basically, if you used 18.0265Hz, you'd get "eighteenths" of a second or
almost "twentieths" of a second. So, the "hundredths" timer would update,
be stale for the next 4 reads, update, be stale for the next 4 reads,
update, etc.
clock() gets its ticks from 40:6ch which are saved from IRQ 0 (int 08h or
18.0265Hz). clock has the define CLOCK_PER_SEC which is 91. I'm not sure
why that value is used or the period it generates is used, but it does
produce a period of about 5 seconds using the 18.0265Hz clock.
Getting values from memory (40:6ch) is quick, and the PM memory protection
issues were solved. Getting values from CMOS is slightly slower, and I'm
unsure of the Windows priviledge issues of CMOS port I/O here. Getting
values from repeated DOS calls through the DPMI host probably is slower.
> I can, indeed, also fix this inside of the Pth library (or for that
> matter inside my application so as not to call pth_nap at all) but it
> seemed like the ideal solution would be to fix the library so that
> everyone wins with the performance boost.
>
I may not be the person to respond on this issue. I've seen a number of
posts on the intracacies of getting DJGPP to work on XP (and you didn't say
what OS). I use DOS mostly (and Win98). So, anything which affects DOS
affects me. I think alot of others are using XP. I suspect whatever you
create needs to work with MS-DOS,DR-DOS,FreeDOS, the various versions of
Windows, etc...
For example, someone attempted to use 40:1a and 40:1c to speed up
_bios_keybrd() read for OpenWatcom:
http://groups.google.com/group/openwatcom.contributors/msg/ca944968d2a3485d?hl=en
I thought this would also be a good idea for DJGPP since I like
_bios_keybrd() and use it. But, someone else attempted to access the bios
timer at 40:6c like you intend and as is done in clock() for DJGPP. He
found out that XP doesn't update BIOS variables unless a DOS interrupt is
called:
http://groups.google.com/group/comp.os.msdos.djgpp/msg/30ac39382eb3560e?hl=en
http://groups.google.com/group/comp.os.msdos.djgpp/msg/67916cf4c1c73b7e?hl=en
> Also did anyone have any thoughts on my ideas for improvements to pipe()?
>
Sorry, not I.
I had hoped someone much more familiar with the issues you bring up would
respond to you first...
Rod Pemberton
- Raw text -