Re: rep movsb vs. simpler instructions for memcpy/memmove (was: Why VAX ..)

On Wed, 12 Mar 2025 16:46:36 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

Michael S <already5chosen@yahoo.com> writes:

On Wed, 12 Mar 2025 11:28:36 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: 

My experiments were with the code in
<https://github.com/AntonErtl/move/>. 

>
Non of those are simple loops that I mentioned above. 

 
They are not.  If you want short code, rep movsb is unbeatable (for
memmove(), you have to do a little more, however).
 

 I posted performance results in
<2017Sep19.082137@mips.complang.tuwien.ac.at>
<2017Sep20.184358@mips.complang.tuwien.ac.at>
<2017Sep23.174313@mips.complang.tuwien.ac.at>
 
My routines were generally faster than rep movsb, except for pretty
large blocks (16KB).
 

>
Idiots from corporate IT blocked http://al.howardknight.net/ 

 
I feel with you.  In my workplace, Usenet is blocked (probably
unintentionally).  I have to post from home.
 

So, link to google groups 

 
Sorry, I cannot provide that service.  Trying to access
groups.google.com tells me:
 
|Couldn’t sign you in
|
|The browser you’re using doesn’t support JavaScript, or has
JavaScript |turned off.
|
|To keep your Google Account secure, try signing in on a browser that
|has JavaScript turned on.
 
I certainly won't turn on JavaScript for Google, and apparently Google
wants me to log in to a Google account to access groups.google.com.  I
don't have a Google account and I don't want one.
 

For me it works fine without login. But not without JS.
For those who are willing to use JS, the link:
https://groups.google.com/g/comp.arch/c/ULvFgEM_ZSY/m/ysPySToGAwAJ

But all I would do is try whether google groups finds the message-ids.
You can do that yourself.
 

GG only searches by contexts. It appears to have no idea about message
ids.

or, if posts are relatively recent, to
https://www.novabbs.com/devel/thread.php?group=comp.arch
would be helpful. 

 
The posts are from 2017; these message-ids are not random-generated.
 

Then GG is the only place to find it that I am aware of.
http://al.howardknight.net helped me to see that start of the message,
but not the full message.
And eternal-september is still struggling with restoration of its
archives after the crash of 9 months ago. More and more it looks like
they will never be restored.

I don't know why gnu memcpy is huge. I don't even know if it is
really *that* huge. But several KB is number that I had seen
stated by other people. 

 
I stated in one of these messages that I have seen an 11KB memmove in
glibc.  Let's see:
 
objdump -t /debian8/usr/lib/x86_64-linux-gnu/libc.a|grep .text|grep
'memmove' 00000000000001a0 g   i   .text  0000000000000047
__libc_memmove 0000000000000000 g     F .text  000000000000019f
__memmove_sse2 00000000000001a0 g   i   .text  0000000000000047
memmove 0000000000000000 g     F .text.ssse3    0000000000000009
__memmove_chk_ssse3 0000000000000010 g     F .text.ssse3
0000000000002b67 __memmove_ssse3 0000000000000000 g     F .text.ssse3
   0000000000000009 __memmove_chk_ssse3_back 0000000000000010 g     F
.text.ssse3    0000000000002b06 __memmove_ssse3_back ...
 
Yes, 11111 bytes for __memmove_ssse3.  Debian 8 is one of the systems
I used at the time.
 
Let's see how it looks in Debian 12:
 
objdump -t /usr/lib/x86_64-linux-gnu/libc.a|grep .text|grep
'memmove'|grep -v wmemmove 0000000000000000 l     F .text
00000000000000f6 __libc_memmove_ifunc 0000000000000000 g   i   .text
00000000000000f6 __libc_memmove 0000000000000000 g   i   .text
00000000000000f6 memmove 0000000000000010 g     F .text.avx
000000000000002f __memmove_avx_unaligned 0000000000000080 g     F
.text.avx      00000000000006de __memmove_avx_unaligned_erms
0000000000000010 g     F .text.avx.rtm  000000000000002d
__memmove_avx_unaligned_rtm 0000000000000080 g     F .text.avx.rtm
00000000000006df __memmove_avx_unaligned_erms_rtm 0000000000000020 g
   F .text.avx512   0000000000000009
__memmove_chk_avx512_no_vzeroupper 0000000000000030 g     F
.text.avx512   000000000000073b __memmove_avx512_no_vzeroupper
0000000000000010 g     F .text.evex512  0000000000000037
__memmove_avx512_unaligned 0000000000000080 g     F .text.evex512
00000000000007a0 __memmove_avx512_unaligned_erms 0000000000000020 g
  F .text  0000000000000009 __memmove_chk_erms 0000000000000030 g
F .text  000000000000002d __memmove_erms 0000000000000010 g     F
.text.evex     0000000000000034 __memmove_evex_unaligned
0000000000000080 g     F .text.evex     00000000000007bb
__memmove_evex_unaligned_erms 0000000000000010 g     F .text
0000000000000028 __memmove_sse2_unaligned 0000000000000080 g     F
.text  0000000000000552 __memmove_sse2_unaligned_erms
0000000000000040 g     F .text.ssse3    0000000000000f3d
__memmove_ssse3 0000000000000000 g     F .text  000000000000000e
__memmove_chk
 
So __memmove_ssse3 is no longer that big ("only" 3901 bytes); it's
still the biggest implementation, but many others are quite a bit
bigger than the 0x113=275 bytes of my ssememmove.
 
- anton