[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
>