Re: Fastest memmove in C

Hi Álvaro,

Based on the article. This research has been tested with various hardware.
The code automatically detects the hardware and based on the size of memory
to be copied it will choose one of 3 routines.

Regarding license I don't much problem with "Code Project Open License". Why
not contact the author. He sounds like a good techie person.

Álvaro wrote
>2) from the description, the code is probably tailored to specific
compilers.  Even if it's faster now in some mainstream compilers, it won't
be in yesterday or tomorrow's ones.  Also, there >are probably going to be
variations depending on CPU features.

Based on the article he has checked this libraries from Microsoft and
GCC/LLVM/Clang/stdlib and their compilers. As this is written in C. It
should be easy to transfer it to whatever you like.
In the past, on a pretty badly structure programmed,  I have used two
compilers on a single project simply to catch different issues.  I don't see
this as a major issue and the advantage could be considerable.

I have not tested this with postgresql.

The article suggests the following benchmark

>These are only ESTIMATES taken from the original article, which did not
include my fastest implementations which were yet to come; so these
estimates are from older slower variations.
>large copy (>= 128 bytes)
>32-bit = 40% faster
>64-bit = 30% faster
>small copy (< 128-bytes)
>15%~40% faster
>These are very old numbers! The functions included here are faster!
Depending on hardware of course!

These should provide a great overall performance boost.

Hope this might help.

Best Regards



-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Alvaro Herrera
Sent: 06 July 2016 22:15
To: FarjadFarid(ChkNet) <farjad.farid@checknetworks.com>
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Fastest memmove in C

FarjadFarid(ChkNet) wrote:

> Excellent research and could be well worth checking out. As it could
> improve the performance of postgresql engine.

0) We certainly do a lot of memory copying.

1) this work is under the "Code Project Open License" which doesn't look
compatible with our Postgres license on first blush.  Maybe T Herselman
would agree to share under the Postgres licence, which would make things
easier.

2) from the description, the code is probably tailored to specific
compilers.  Even if it's faster now in some mainstream compilers, it won't
be in yesterday or tomorrow's ones.  Also, there are probably going to be
variations depending on CPU features.

3) How much faster does Postgres get when you replace memcpy/memmove with
these Apex versions?  If the percentage to be gained is small, then there's
probably no point in spending a lot of effort into providing
platform-specific implementations of these things anyway.

If you have enough interest in this topic, you could try using these Apex
versions in Postgres and measuring an improvement, to get a discussion
going.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general