On Thu, Jul 7, 2016 at 6:12 AM, FarjadFarid(ChkNet) <farjad.farid@xxxxxxxxxxxxxxxxx> wrote: > > > 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 Well, testing is the key here. Microbechmarks demonstrating the value are not enough; proven statistically relevant benchmarks generated from postgres are the data points needed to make an assessment. My recommendation would be to dynamically link in these routines to postgres and start running a battery of memory heavy tests (start with pgbench -S on a small database). Ideally you could tease out some measurable benefit; license discussions and formal integration strategies are secondary to that IMO. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
