[pooma-dev] RFA: delete_test1 Modifications

James Crotinger JimC at proximation.com
Fri May 25 18:31:08 UTC 2001


That's fine. Like I said, it doesn't matter here as this is just a test.
Julian commented out the corresponding code in algorithm.h so we're not
using this optimization in real code anyway.

	Jim

> -----Original Message-----
> From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
> Sent: Thursday, May 24, 2001 7:33 PM
> To: James Crotinger
> Cc: pooma-dev at pooma.codesourcery.com
> Subject: Re: [pooma-dev] RFA: delete_test1 Modifications
> 
> 
> On Thu, May 24, 2001 at 04:17:54PM -0700, James Crotinger wrote:
> > copy doesn't have the same semantics as memmove and so it 
> is potentially
> > faster (it can only copy overlapping regions if the 
> destination is before
> > the source, which is the case in the shift-up copies, which 
> almost always
> > involve overlapping regions). However, I did a lot of 
> testing with KCC on
> > the SGI and found that for larger moves, memmove was 
> faster. This is why I
> > put a test into the delete_shiftup algorithm to use copy 
> only if the length
> > of the copy was less than 100 (a good round number). 
> Someone (named julianc)
> > has since commented out that code without leaving a comment 
> in the source as
> > to the reason. Looking at the log I see that it was due to 
> VC++ not having a
> > proper std::advance. This should have just been coded 
> around. At any rate, I
> > didn't add this complication lightly. Now perhaps KCC has 
> since written copy
> > to use memmove so I don't know if my investigations from 
> early 2000 are
> > still valid.
> > 
> >   Jim
> > 
> > > For those skipping intermediary emails, the discussion is whether
> > > memmove() is faster than copy().
> > > 
> > > Attached is a program that constructs a vector, copies 
> its contents to
> > > another vector, and then checks the copy for correctness.  On
> > > Linux/gcc3.0 and Irix6.5/KCC, I cannot find any significant speed
> > > difference between std::copy and std::memmove for vectors 
> of doubles.
> > > Given this result, may we use std::copy() everywhere since it is
> > > guaranteed to compile? 
> 
> OK, I am not going to argue with your timing data even though I cannot
> reproduce them.  Let's just end up with a program that compiles and
> uses std::memmove.
> 
> OK to commit this patch?
> 
> Compiling src/Utilities/tests/delete_test1.cpp showed that the vector
> type `Array_t' was declared to store doubles but actually stored
> integers.  Also, arguments for a call to std::memmove() was modified
> to permit compilation.
> 
> 2001 May 24  Jeffrey D. Oldham  <oldham at codesourcery.com>
> 
> 	* delete_test1.cpp (Array_t): s/vector<double>/vector<int>/
> 	(delete_shiftup_test2): Modify memmove operands to 
> permit compilation.
> 
> Tested on       sequential Linux using gcc 3.0 by compiling 
> the program
> Approved by     ???you???
> 
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010525/11263189/attachment.html>


More information about the pooma-dev mailing list