Re: Computer architects leaving Intel...

mitchalsup@aol.com (MitchAlsup1) writes:

On Wed, 4 Sep 2024 17:53:13 +0000, David Brown wrote:
>

On 04/09/2024 18:07, Tim Rentsch wrote:
>

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>

Michael S wrote:
>

On Tue, 3 Sep 2024 17:41:40 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>

Michael S wrote:
>

3 years ago Terje Mathisen wrote that many years ago he read
that behaviour of memcpy() with overlappped src/dst was defined.
https://groups.google.com/g/comp.arch/c/rSk8c7Urd_Y/m/ZWEG5V1KAQAJ
Mitch Alsup answered "That was true in 1983".  So, two people of
different age living in different parts of the world are telling
the same story.  May be, there exist old popular book that said
that it was defined?

>
It probably wasn't written in the official C standard, which I
couldn't have afforded to buy/read, but in a compiler runtime
doc?
>
Specifying that it would always copy from beginning to end of
the source buffer, in increasing address order meant that it
was guaranteed safe when used to compact buffers.

>
What is "compact buffers" ?

>
Assume a buffer consisting of records of some type, some of
them marked as deleted.  Iterating over them while removing
the gaps means that you are always copying to a destination
lower in memory, right?

>
If all the records are in one large array, there is a simple
test to see if memcpy() must work or whether some alternative
should be used instead.

>
Such tests are usually built into implementations of memmove(),
which will chose to run forwards or backwards as needed.  So you
might as well just call memmove() any time you are not sure
memcpy() is safe and appropriate.

The ever-shallow David Brown first misses the point, then makes a
slightly incorrect statement, and finally makes a recommendation
that surely is familiar to every reader in the newsgroup.

Memmove() is always appropriate unless you are doing something
nefarious.
>
So:
# define memcpy memomve

Incidentally, if one wants to do this, it's advisable to write

  #undef  memcpy

before the #define of memcpy.

and move forward with life--for the 2 extra cycles memmove costs
it saves everyone long term grief.
>
When you need the nefarious activities of memcpy write it as a
for loop by yourself and comment the nafariousness of the use.

The point of my comment is that there is extra information
available in the scenario described, and it might be useful to
take advantage of that information not to make a low-level change
(eg, substitute memmove() for memcpy()) but to switch to a
different higher level strategy, such as using a semi-space
compactor (or other possibilities).

Simply replacing memcpy() by memmove() of course will always
work, but there might be negative consequences beyond a cost
of 2 extra cycles -- for example, if a negative stride is
better performing than a positive stride, but the nature
of the compaction forces memmove() to always take the slower
choice.

It's always useful to have more options to choose from when there
is more information, even if ultimately what path is chosen
is the zero-information path.