Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: Memory copy timings Message-ID: <3510@goanna.cs.rmit.oz.au> Date: 4 Aug 90 08:12:42 GMT References: <144@smds.UUCP> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 29 In article <144@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes: > A number of memcpy versus "his macro" results have posted. ... > None of the postings mentioned checking unaligned moves, ... > This is not entirely realistic. I don't see why. Whatever method you are using for doing bulk moves (BLT instruction, TRT instruction, bcopy(), memcyp(), memmove(), ...) having things aligned is likely to help. Any programmer who cares enough about the performance of block transfer to be wondering whether memcpy() is fast enough should really have taken care of alignment first. This also applies to fread(), fwrite(), and (on systems with a POSIX interface, such as DEC are promising RSN for VMS) read() and write(). On all the UNIX systems where I've tried the comparison, I've found that making read/write buffers be "well" aligned (the alignment that malloc() guarantees is fine) was usefully faster than having them be misaligned. Most of the time, the best way to speed up block transfer is not to do it at all, but to twiddle your pointers around. Which is why MVS and VMS offer "locate" mode transput as well as "move" mode, a distinction reflected at the PL/I language level. This is also the point of , anyone have a PD implementation of fio? -- Distinguishing between a work written in Hebrew and one written in Aramaic when we have only a Latin version made from a Greek translation is not easy. (D.J.Harrington, discussing pseudo-Philo)