X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: Eli Zaretskii Newsgroups: comp.os.msdos.djgpp Subject: Re: Memory accessing performance Date: Fri, 21 Dec 2001 09:48:07 +0200 Lines: 27 Message-ID: <3C22E937.2E7D1336@is.elta.co.il> References: <001f01c18995$b8043360$1400a8c0 AT alex> NNTP-Posting-Host: 192.116.55.139 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1008921054 18584375 192.116.55.139 (16 [61365]) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Alex Oleynikov wrote: > > I've got a question related to memory accessing performance when using DPMI. > Currently I am developing an application which talks to PLCs via Modbus > protocol and I need to create a map of Modbus registers in my program. > Every register is two bytes of data and there are quite a few of them (up to > 50000). First thing that comes to the mind is to use dynamic arrays of short > integers, but wouldn't it be much slower compared to 32-bit integers? (since > the compiler generates a 32-bit code which is more efficient accessing > 32-bit memory locations, right?). I don't understand your concerns: it sounds like you have an array of 100KB of data, and you want to access it as fast as possible? If so, I don't see any problem: just allocate 100KB of memory at the beginning, and then access the array as usual. malloc already takes care of a proper alignment for the allocated memory, so the memory accesses will be as fast as they get. There's no penalty for memory access in DPMI mode; assuming that your machine has enough memory to not start paging when you allocate 100KB, it's just you, the CPU, and the bare metal, with nothing in between. > Those registers must be updated about > every 250ms, so I'd rather sacrifice size to gain performance. How does this update process work? That is, how do you talk to the device itself? Depending on how you do it, the actual bottleneck might be communicating with the device, not updating 100KB of your program's memory.