Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #41396

Re: CMOVE/CMOVE>

From anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups comp.lang.forth
Subject Re: CMOVE/CMOVE>
Date 2015-08-19 08:40 +0000
Organization Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID <2015Aug19.104049@mips.complang.tuwien.ac.at> (permalink)
References (1 earlier) <2015Aug18.180551@mips.complang.tuwien.ac.at> <c3289222-a562-44db-a30a-1f8d58d0fc6b@googlegroups.com> <cc2c79a3-48ce-400e-b3b6-4474c9c47917@googlegroups.com> <70231de3-da52-405a-a20d-a578e9783f12@googlegroups.com> <mr0d1a$ke7$1@dont-email.me>

Show all headers | View raw


"Alex McDonald" <blog@rivadpm.com> writes:
>on 18/08/2015 18:41:19,  wrote:
>> > On Tuesday, August 18, 2015 at 10:10:22 AM UTC-7, Michael Barry wrote:
>
>>>
>>> Isn't it true that the decision can be made based simply on whether sourc
>> e start is less than destination start, regardless of count? Mine does
>> tha t, but CMOVE> and CMOVE have equivalent performance, which might
>> mot always be the case.
>> 
>> Yes, it is only necessary to compare the start addresses.
>
>No, because if there's an overlap then there may be advantages in using
>larger than CHAR sized moves. When there is an overlap, CMOVE> should
>always do a character by character move (for instance, on the x86 REP
>MOVS BYTE); otherwise much larger units can be CMOVE>d if there is no
>overlap (REP MOVS DWORD or QWORD or MOVDQU thru XMM registers, etc). The
>difference in performance can be considerable.

If you implement MOVE, you can use larger granularity for either
direction (of course, you need to take care of the remainder at the
start and/or end).  I would hope that on an IA-32/AMD64 CPU the CPU
does that for you if you use REP MOVSB and the parameters are
appropriate.  Unfortunately, it seems that doing it in software is
faster, at least for microbenchmarks, and this has lead to glibc's
memmove() having 11KB of code.  This is likely to be slower in
applications due to I-cache misses, but as long as it produces good
microbenchmark results...

Even for CMOVE or CMOVE> you can usually use a larger granularity even
for the overlap case; the granularity for CMOVE must just be at most
TO-FROM for CMOVE and FROM-TO for CMOVE>.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 08:44 -0700
  Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 16:05 +0000
    Re: CMOVE/CMOVE> november.nihal@gmail.com - 2015-08-18 09:34 -0700
      Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 16:41 +0000
    Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 09:59 -0700
      Re: CMOVE/CMOVE> Michael Barry <barrym95838@yahoo.com> - 2015-08-18 10:10 -0700
        Re: CMOVE/CMOVE> hughaguilar96@gmail.com - 2015-08-18 10:41 -0700
          Re: CMOVE/CMOVE> "Alex McDonald" <blog@rivadpm.com> - 2015-08-18 23:55 +0100
            Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-19 08:40 +0000
              Re: CMOVE/CMOVE> "Alex McDonald" <blog@rivadpm.com> - 2015-08-19 12:15 +0100
        Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 11:35 -0700
          Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-18 11:36 -0700
            Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-20 04:39 +1000
          Re: CMOVE/CMOVE> "Elizabeth D. Rather" <erather@forth.com> - 2015-08-19 09:15 -1000
          Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-28 22:39 +1000
            Re: CMOVE/CMOVE> Coos Haak <chforth@hccnet.nl> - 2015-08-28 15:06 +0200
              Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-29 17:15 +1000
                Re: CMOVE/CMOVE> Coos Haak <chforth@hccnet.nl> - 2015-08-29 13:24 +0200
                Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-31 11:38 +1000
                Re: CMOVE/CMOVE> "Elizabeth D. Rather" <erather@forth.com> - 2015-08-29 07:59 -1000
                Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-30 13:00 +1000
            Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-28 07:33 -0700
            Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-28 07:36 -0700
              Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-29 02:23 +1000
            Re: CMOVE/CMOVE> mhx@iae.nl - 2015-08-28 11:41 -0700
              Re: CMOVE/CMOVE> "HAA" <someone@microsoft.com> - 2015-08-29 17:30 +1000
        Re: CMOVE/CMOVE> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-19 08:04 +0000
      Re: CMOVE/CMOVE> "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-19 02:48 -0400
        Re: CMOVE/CMOVE> Mark Wills <markwills1970@gmail.com> - 2015-08-19 00:49 -0700
    Re: CMOVE/CMOVE> Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-19 02:58 +0200

csiph-web