[Mono-list] cpblk?

Serge serge@wildwestsoftware.com
Sat, 25 May 2002 04:32:34 +0300


Hi Gonzalo!

> memcpy already takes care of copying in the fastest way posible.

That's right, but we still have a call, a ret, and a conditional or two ;-)
By inlining we can get rid of these things (especially if size is known up-front).
Moreover, due to JIT's dynamic nature it's possible to generate faster code at run-time.
For example, the following (generic) memcpy is faster on pre-Pentium x86s (Intel syntax):
  mov esi, $src
  mov ecx, $size
  mov edi, $dest
  shr ecx,1
  rep movsw
  adc cl,cl
  rep movsb

For const size==1 we could just mov al, [src]; mov [dest],al
etc.etc.
BTW, MS JIT uses similar optimizations for cpblk/initblk.

This is a small optimization of course, something similar to inlining TLS access, but why not :-)
In fact I'm more concerned about possible incompatibility, if people would rely on memmove-like
behaviour for cpblk in Mono.

Sergey


----- Original Message ----- 
From: "Gonzalo Paniagua Javier" <gonzalo@gnome-db.org>
To: <mono-list@ximian.com>
Sent: Saturday, May 25, 2002 3:27 AM
Subject: Re: [Mono-list] cpblk?


> * [ Serge <serge@wildwestsoftware.com>
> * Fri, 24 May 2002 21:29:54 +0200 ]
> > I think that the point is to use fast block move instructions if
> > available (say, MOVS on x86), especially in the cases where
> > size=const.  Hence non-overlapping behaviour in the specs.
> 
> Hi Sergey!
> 
> memcpy already takes care of copying in the fastest way posible. It has
> a threshold (may be 8, can't remember now) and if the number of bytes to
> copy is GE than the threshold, it uses movl. If not, it uses movb.
> 
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>