I am looking for a fast memcpy() that will work well on 
32-bit machines for both Linux and Windows. 

On 04/27/10 04:20 PM, Peter Olcott wrote:
> I am looking for a fast memcpy() that will work well on
> 32-bit machines for both Linux and Windows.

What's wrong with the standard one?

-- 
Ian Collins

On Apr 27, 7:20=A0am, "Peter Olcott" <NoS...@OCR4Screen.com> wrote:
> I am looking for a fast memcpy() that will work well on
> 32-bit machines for both Linux and Windows.

That is perhaps a question for comp.lang.asm.x86 group. Scan the posts
there, no doubt someone has published something. We just discuss safe
and conformant C++ programming techniques here.

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:83n785Fb0lU1@mid.individual.net...
> On 04/27/10 04:20 PM, Peter Olcott wrote:
>> I am looking for a fast memcpy() that will work well on
>> 32-bit machines for both Linux and Windows.
>
> What's wrong with the standard one?
>
> -- 
> Ian Collins

Is it smart enough to copy 32 bits at a time, even when the 
memory is not aligned on a 32 bit boundary? 

On 2010-04-27, Peter Olcott <NoSpam@OCR4Screen.com> wrote:
>
> "Ian Collins" <ian-news@hotmail.com> wrote in message 
> news:83n785Fb0lU1@mid.individual.net...
>> On 04/27/10 04:20 PM, Peter Olcott wrote:
>>> I am looking for a fast memcpy() that will work well on
>>> 32-bit machines for both Linux and Windows.
>>
>> What's wrong with the standard one?
>>
>> -- 
>> Ian Collins
>
> Is it smart enough to copy 32 bits at a time, even when the 
> memory is not aligned on a 32 bit boundary? 
>

If you aren't sure, it would be trivial to write a wrapper
that would copy the first %32 bits manually then copy the
remaining (32-bit aligned) memory using memcpy.

But I would expect any library memcpy to already do this.

-- 
Andrew Poelstra
http://www.wpsoftware.net/andrew

On Tue, 2010-04-27, Peter Olcott wrote:
>
> "Ian Collins" <ian-news@hotmail.com> wrote in message 
> news:83n785Fb0lU1@mid.individual.net...
>> On 04/27/10 04:20 PM, Peter Olcott wrote:
>>> I am looking for a fast memcpy() that will work well on
>>> 32-bit machines for both Linux and Windows.
>>
>> What's wrong with the standard one?

> Is it smart enough to copy 32 bits at a time, even when the 
> memory is not aligned on a 32 bit boundary? 

Why don't you check for yourself?
The one in OpenBSD is; I've read it.

Also don't forget the one builtin to your compiler; the one that knows
a whole lot more about the arguments than a library function does.
Depending on what you're doing, even a perfect library function can be
much slower.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

Peter Olcott wrote:
> I am looking for a fast memcpy() that will work well on 
> 32-bit machines for both Linux and Windows. 
> 
> 

Use the library one.

It's going to be memory bus limited on any modern system, even if all it 
does is load and store single bytes.  (BTW the Windows one is actually 
pretty good)

Andy

On 27-04-2010 06:20, Peter Olcott wrote:
> I am looking for a fast memcpy() that will work well on
> 32-bit machines for both Linux and Windows.
>
>
I tested various memory copy routines during my studies. One of the best 
approach was mixing fixed and floating point instructions - 3 times 
faster that standard loop. It is worth to try SSE unit.

Regards

Marek

On Apr 27, 11:42=A0pm, Andrew Poelstra <apoels...@localhost.localdomain>
wrote:
> On 2010-04-27, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> > "Ian Collins" <ian-n...@hotmail.com> wrote in message
> >news:83n785Fb0lU1@mid.individual.net...
> >> On 04/27/10 04:20 PM, Peter Olcott wrote:
> >>> I am looking for a fast memcpy() that will work well on
> >>> 32-bit machines for both Linux and Windows.
>
> >> What's wrong with the standard one?
>
> >> --
> >> Ian Collins
>
> > Is it smart enough to copy 32 bits at a time, even when the
> > memory is not aligned on a 32 bit boundary?
>
> If you aren't sure, it would be trivial to write a wrapper
> that would copy the first %32 bits manually then copy the
> remaining (32-bit aligned) memory using memcpy.
>
> But I would expect any library memcpy to already do this.
>
> Andrew Poelstrahttp://www.wpsoftware.net/andrew

Exactly... people have thought of all these issues decades ago... not
just 32 bits at a time, but various things that can only be done in
machine code inexpressible in C++, as well as loop unrolling and
inlining, using known alignment and size information etc....  Best
idea, forget all about it - especially if this probably ties in to
your other thread which I got the impression was about trying to use
memcpy() to outperform compiler-generated copy constructors or
something...?

Cheers,
Tony

I beat std::string by a factor of 125-fold once, thus I 
expect that improvements can be made to memcpy() at least on 
my platform.

"tonydee" <tony_in_da_uk@yahoo.co.uk> wrote in message 
news:a310a9d7-0bf0-4178-afb5-cb4b6adc9d5e@j36g2000prj.googlegroups.com...
On Apr 27, 11:42 pm, Andrew Poelstra 
<apoels...@localhost.localdomain>
wrote:
> On 2010-04-27, Peter Olcott <NoS...@OCR4Screen.com> wrote:
> > "Ian Collins" <ian-n...@hotmail.com> wrote in message
> >news:83n785Fb0lU1@mid.individual.net...
> >> On 04/27/10 04:20 PM, Peter Olcott wrote:
> >>> I am looking for a fast memcpy() that will work well 
> >>> on
> >>> 32-bit machines for both Linux and Windows.
>
> >> What's wrong with the standard one?
>
> >> --
> >> Ian Collins
>
> > Is it smart enough to copy 32 bits at a time, even when 
> > the
> > memory is not aligned on a 32 bit boundary?
>
> If you aren't sure, it would be trivial to write a wrapper
> that would copy the first %32 bits manually then copy the
> remaining (32-bit aligned) memory using memcpy.
>
> But I would expect any library memcpy to already do this.
>
> Andrew Poelstrahttp://www.wpsoftware.net/andrew

Exactly... people have thought of all these issues decades 
ago... not
just 32 bits at a time, but various things that can only be 
done in
machine code inexpressible in C++, as well as loop unrolling 
and
inlining, using known alignment and size information etc.... 
Best
idea, forget all about it - especially if this probably ties 
in to
your other thread which I got the impression was about 
trying to use
memcpy() to outperform compiler-generated copy constructors 
or
something...?

Cheers,
Tony 

"Andy Champ" <no.way@nospam.invalid> wrote in message 
news:IOCdnbbiCq283krWnZ2dnUVZ8nVi4p2d@eclipse.net.uk...
> Peter Olcott wrote:
>> I am looking for a fast memcpy() that will work well on 
>> 32-bit machines for both Linux and Windows.
>
> Use the library one.
>
> It's going to be memory bus limited on any modern system, 
> even if all it does is load and store single bytes.  (BTW 
> the Windows one is actually pretty good)
>
> Andy

This one looks pretty good, and it is standard C/C++
   http://www.danielvik.com/2010/02/fast-memcpy-in-c.html 

Peter Olcott wrote:
> "Andy Champ" <no.way@nospam.invalid> wrote in message
> news:IOCdnbbiCq283krWnZ2dnUVZ8nVi4p2d@eclipse.net.uk...
>> Peter Olcott wrote:
>>> I am looking for a fast memcpy() that will work well on
>>> 32-bit machines for both Linux and Windows.
>>
>> Use the library one.
>>
>> It's going to be memory bus limited on any modern system,
>> even if all it does is load and store single bytes.  (BTW
>> the Windows one is actually pretty good)
>>
>> Andy
>
> This one looks pretty good, and it is standard C/C++
>   http://www.danielvik.com/2010/02/fast-memcpy-in-c.html

And you believe that nobody on the compiler team hasn't already read 
this? In the 1980s?


We aren't doing Motorola 68000 anymore.


Bo Persson

"Bo Persson" <bop@gmb.dk> wrote in message 
news:83rdbsFpjlU1@mid.individual.net...
> Peter Olcott wrote:
>> "Andy Champ" <no.way@nospam.invalid> wrote in message
>> news:IOCdnbbiCq283krWnZ2dnUVZ8nVi4p2d@eclipse.net.uk...
>>> Peter Olcott wrote:
>>>> I am looking for a fast memcpy() that will work well on
>>>> 32-bit machines for both Linux and Windows.
>>>
>>> Use the library one.
>>>
>>> It's going to be memory bus limited on any modern 
>>> system,
>>> even if all it does is load and store single bytes. 
>>> (BTW
>>> the Windows one is actually pretty good)
>>>
>>> Andy
>>
>> This one looks pretty good, and it is standard C/C++
>>   http://www.danielvik.com/2010/02/fast-memcpy-in-c.html
>
> And you believe that nobody on the compiler team hasn't 
> already read this? In the 1980s?


Yes I am sure that no one read this February 2010 article in 
the 1980's

>
>
> We aren't doing Motorola 68000 anymore.
>
>
> Bo Persson
>
> 

On Apr 28, 5:47=A0pm, "Peter Olcott" <NoS...@OCR4Screen.com> wrote:
> "Andy Champ" <no....@nospam.invalid> wrote in message
>
> > Use the library one.
>
> This one looks pretty good, and it is standard C/C++
> =A0 =A0http://www.danielvik.com/2010/02/fast-memcpy-in-c.html

This is maybe faster than on some embedded system with junky C runtime
librares. You better do some tests and compare with assignment
operator of C++ compiled with some modern compiler on Windows and
Linux. For these you originally asked that thing. I bet it loses.

On Apr 28, 11:20=A0pm, "Peter Olcott" <NoS...@OCR4Screen.com> wrote:
> I beat std::string by a factor of 125-fold once, thus I
> expect that improvements can be made to memcpy() at least on
> my platform.

It's not a meaningful comparison.  The design compromises in strings
are massively more complicated than a memcpy (e.g. dynamic memory
allocation vs embedded short strings or better suited capacity
resizing defaults, reference counting).  You won't have outperformed
std::string because anything was simply overlooked in its
implementation.

Cheers,
Tony