RE: [pooma-dev] RFA: delete_test1 Modifications

[James Crotinger]

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:address@hidden]
> Sent: Thursday, May 24, 2001 7:33 PM
> To: James Crotinger
> Cc: address@hidden
> 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  <address@hidden>
>
>       * 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
> address@hidden
>