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@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Alvaro Herrera Sent: 06 July 2016 22:15 To: FarjadFarid(ChkNet) <farjad.farid@xxxxxxxxxxxxxxxxx> Cc: pgsql-general@xxxxxxxxxxxxxx Subject: Re: 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
