X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: Performance enhancement for gettimeofday()? Date: Sat, 6 Jan 2007 01:32:07 -0500 Organization: Aioe.org NNTP Server Lines: 105 Message-ID: References: NNTP-Posting-Host: IVw7K97ih4IohxRqyKkqFw.user.aioe.org X-Complaints-To: abuse AT aioe DOT org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 X-MSMail-Priority: Normal To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie 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, 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