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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, May 25, 2002 3:27 AM Subject: Re: [Mono-list] cpblk? > * [ Serge <[EMAIL PROTECTED]> > * 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 - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
