<div class="gmail_quote">On 7 January 2012 03:46, Vladimir Panteleev <span dir="ltr"><<a href="mailto:vladimir@thecybershadow.net">vladimir@thecybershadow.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Friday, 6 January 2012 at 20:26:37 UTC, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/6/2012 11:16 AM, Brad Roberts wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, a counter example, it'd be a lot easier to write a memcpy routine that uses them<br>
without having to resort to asm code under this theoretical model.<br>
</blockquote>
<br>
I would seriously argue that individuals not attempt to write their own memcpy.<br>
</blockquote>
<br></div>
Agner Fog states in his optimization manuals that the glibc routines are fairly unoptimized. He provides his own versions, however they are GPL.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why? Because the C one has had probably thousands of programmers looking at it for the last 30 years. You're not going to spend 5 minutes, or even 5 days, and make it faster.<br>
</blockquote>
<br></div>
This assumes that hardware never changes. New memcpy implementations can take advantage of large registers in newer CPUs for higher speeds.<br>
</blockquote></div><br><div>I've never seen a memcpy on any console system I've ever worked on that takes advantage if its large registers... writing a fast memcpy is usually one of the first things we do when we get a new platform ;)</div>