[Gretl-devel] Re: Speed of matrix "block" operations

On Sun, 13 Oct 2019, Marcin Błażejowski wrote: > On 13.10.2019 02:15, Allin Cottrell wrote: >> Thanks, Jack. So, given the options I posited, our machines agree on a >> best chunk size of (25 * 5000 * 8) bytes (=~ 1 MB) for use with >> memcpy. (5000 being the number of rows in the matrix to be copied, and >> 8 the number of bytes to represent a double-precision floating point >> value.) >> >> Now, to optimize libgretl's copying of contiguous data, we just have >> to figure out how that relates to the size of L1 or L2 cache, or >> whatever is truly the relevant hardware parameter here! > > But Allin, isn't it something that could/should(?) be done by AVX > extensions? But I have to admit that I no idea how to use such low-level > optimisation for scripting language. The AVX extensions are facilities that a compiler may or may not end up using as part of its optimization efforts. In the matrix-copying context the relevant question would be how the compiler and C-library jointly interpret and implement calls to memcpy (e.g. does memcpy translate to some AVX-optimized variant?). From the timings we're looking at (thanks for sending yours, Marcin) it's clear that whatever optimizations are employed by gcc and the relevant C-libraries, they are not automatically dividing a big call to memcpy into smaller chunks whenever that would speed up the total copy. Hence the idea that we may want to try some dividing up at the libgretl level. I suspect that things are slowing when we try to copy more data than fits into L2 cache in one go.