2:50 p.m.
Hi,
some time ago I found an interesting disscusion on code optimisiation in
gcc with '-avx2 ' flag in case of copying blocks of matrixes. So, I
wrote a simple script and I got the following results:
? set verbose off
10,586272
9,690394
10,030351
10,335968
8,9853768
Difference 1: 0,895878
Difference 2: -0,305616
I have to say that I'm little surprised. Although I would expect
difference between the first and the second loop ('Difference 1:
0,895878'), I wouldn't expect any difference between timings of loops
three and four ('Difference 2: -0,305616'). And, after all, why the
difference between the last loop and the other loops are so big?
Marcin
<hansl>
set verbose off
clear
scalar ROW = 10000
scalar COL = 20
scalar BLOCK_size = 2000
scalar BLOCK_start = 115
scalar LOOP = 600
matrix A = mnormal(ROW, COL)
matrix B1 = zeros(ROW, COL)
matrix B2 = B1
matrix B3 = B1
matrix B4 = B1
matrix B5 = B1
set stopwatch
loop LOOP --quiet
loop i=1..BLOCK_size --quiet
loop j=1..COL --quiet
B1[BLOCK_start - 1 + i, j] = A[BLOCK_start - 1 + i, j]
endloop
endloop
endloop
est1 = $stopwatch
eval est1
set stopwatch
loop LOOP --quiet
loop i=0..BLOCK_size-1 --quiet
loop j=1..COL --quiet
B2[BLOCK_start + i, j] = A[BLOCK_start + i, j]
endloop
endloop
endloop
est2 = $stopwatch
eval est2
loop LOOP --quiet
loop i=1..BLOCK_size --quiet
loop j=1..COL --quiet
tmp1 = BLOCK_start - 1 + i
B3[tmp1, j] = A[tmp1, j]
endloop
endloop
endloop
est3 = $stopwatch
eval est3
set stopwatch
loop LOOP --quiet
loop i=0..BLOCK_size-1 --quiet
loop j=1..COL --quiet
tmp2 = BLOCK_start + i
B4[tmp2, j] = A[tmp2, j]
endloop
endloop
endloop
est4 = $stopwatch
eval est4
loop LOOP --quiet
loop i=BLOCK_start..BLOCK_start-1+BLOCK_size --quiet
loop j=1..COL --quiet
B5[i, j] = A[i, j]
endloop
endloop
endloop
eval $stopwatch
printf "Difference 1: %f\n", est1 - est2
printf "Difference 2: %f\n", est3 - est4
</hansl>
--
Marcin Błażejowski
8:01 p.m.
On Sat, 12 Oct 2019, Marcin Błażejowski wrote:
some time ago I found an interesting disscusion on code optimisiation
in
gcc with '-avx2 ' flag in case of copying blocks of matrixes. So, I
wrote a simple script and I got the following results [...]
I'm attaching a modified verson of your script which may clarify
things. The relative execution times of your variants are mostly a
function of how much excess indexation arithmetic you're doing. Do as
little arithmetic as possible in the inner loop in particular. Your
first variant does 160000 additions/subtractions where 2 will do just
fine.
That said, copying element-by-element by row -- as in all your
variants -- is very inefficient for two reasons.
First, gretl matrices are in column-major order: column elements are
adjacent in memory, row elements are separated by the number of rows
in the matrix. So go by columns whenever possible.
Second, one should uses ranges rather than single-element indices
whenever possible. If the data in the given range are contiguous in
memory, libgretl will use the C library's memcpy() to copy a chunk of
data in one call.
Here are my timings for the 6 variants in my version of your script
(on i7, Arch Linux):
loop 1: 5.3523 (add/sub = 160000)
loop 2: 4.6882 (add/sub = 80000)
loop 3: 4.9248 (add/sub = 80000)
loop 4: 4.5084 (add/sub = 40001)
loop 5: 3.3973 (add/sub = 2)
loop 6: 0.0109 (add/sub = 2; column chunks)
Note the huge speed-up when copying columns as chunks.
Allin
4:40 p.m.
On 12.10.2019 22:01, Allin Cottrell wrote:
On Sat, 12 Oct 2019, Marcin Błażejowski wrote:
I'm attaching a modified verson of your script which may clarify
things. The relative execution times of your variants are mostly a
function of how much excess indexation arithmetic you're doing. Do as
little arithmetic as possible in the inner loop in particular. Your
first variant does 160000 additions/subtractions where 2 will do just
fine.
Ok. And that is something I would expect.
That said, copying element-by-element by row -- as in all your
variants -- is very inefficient for two reasons.
First, gretl matrices are in column-major order: column elements are
adjacent in memory, row elements are separated by the number of rows
in the matrix. So go by columns whenever possible.
Ok, Does it mean that if I have
a matrix which I expand by adding new
"tuples" I should append these tuples as new columns instead of new rows?
Second, one should uses ranges rather than single-element indices
whenever possible. If the data in the given range are contiguous in
memory, libgretl will use the C library's memcpy() to copy a chunk of
data in one call.
I know. I just wanted to replicate an example I mentioned at the
beggining of my email, because people discovered that gcc was able to
'vectorize' only "a[i,j] = b[i,j]" copying (i.e. load the chunks of
matrixes into YMM/XMM registers and call specific AVX functions on it).
Here are my timings for the 6 variants in my version of your script
(on i7, Arch Linux):
loop 1: 5.3523 (add/sub = 160000)
loop 2: 4.6882 (add/sub = 80000)
loop 3: 4.9248 (add/sub = 80000)
loop 4: 4.5084 (add/sub = 40001)
loop 5: 3.3973 (add/sub = 2)
loop 6: 0.0109 (add/sub = 2; column chunks)
Note the huge speed-up when copying columns as chunks.
My results (Inspiron laptop with Debian, i7-8550U CPU @ 1.80GHz Skylake):
loop 1: 11,1638 (add/sub = 160000)
loop 2: 9,6939 (add/sub = 80000)
loop 3: 9,8530 (add/sub = 80000)
loop 4: 9,5306 (add/sub = 40001)
loop 4a: 8,7002 (add/sub = 2001)
loop 5: 8,5831 (add/sub = 2)
loop 6: 0,0163 (add/sub = 2; column chunks)
Marcin
--
Marcin Błażejowski
5:35 p.m.
On Sun, 13 Oct 2019, Marcin Błażejowski wrote:
On 12.10.2019 22:01, Allin Cottrell wrote:
> First, gretl matrices are in column-major order: column elements are
> adjacent in memory, row elements are separated by the number of rows
> in the matrix. So go by columns whenever possible.
Ok, Does it mean that if I have a matrix which I expand by adding new
"tuples" I should append these tuples as new columns instead of new rows?
If you have the choice then Yes, it should be cheaper to add columns
rather than rows.
> Second, one should uses ranges rather than single-element
indices
> whenever possible. If the data in the given range are contiguous in
> memory, libgretl will use the C library's memcpy() to copy a chunk of
> data in one call.
I know. I just wanted to replicate an example I mentioned at the
beggining of my email, because people discovered that gcc was able to
'vectorize' only "a[i,j] = b[i,j]" copying (i.e. load the chunks of
matrixes into YMM/XMM registers and call specific AVX functions on it).
OK, but hansl is not C ;-). I mean, gcc doesn't get to see your hansl
script, it only gets to look at the libgretl code -- and libgretl uses
the faster memcpy only for contiguous chunks of data in a matrix copy
operation.
Allin
9:23 p.m.
On Sat, 12 Oct 2019, Marcin Błażejowski wrote:
some time ago I found an interesting disscusion on code optimisiation
in
gcc with '-avx2 ' flag in case of copying blocks of matrixes.
Marcin, here's another observation, which chimes with what I think
may have been your original intent.
As I mentioned in my previous reply, one really wants to copy by
column when possible, and take advantage of libgretl's use of
memcpy() as opposed to copying element-by-element. But... the
question arises: is there such a thing as being "too greedy" in use
of memcpy? Might it help to divide the data to be copied into
smaller blocks? And the answer is Yes, if the matrix is big enough.
(I guess this has to do with the available cache.)
I'm appending an example script below. We have a big matrix (5000 x
500) and we'd like to copy its entire content. We try copying by
chunks of columns, starting at 1 column per chunk and going up to
the full 500 in a single chunk. At first the copy time declines, but
in this example the "too greedy" point arrives when copying 50
columns at a time. And if we try to copy all 500 columns in one go,
that's actually worse than going by individual columns.
Here are my timings:
1 columns per chunk: 2.4016s
2 columns per chunk: 1.1832s
5 columns per chunk: 0.3720s
10 columns per chunk: 0.1427s
25 columns per chunk: 0.0708s
50 columns per chunk: 0.1604s
100 columns per chunk: 0.5870s
125 columns per chunk: 0.8519s
500 columns per chunk: 2.8247s
And here's the script:
<hansl>
set verbose off
clear
scalar ROW = 5000
scalar COL = 500
scalar LOOP = 600
matrix A = mnormal(ROW, COL)
matrix B = zeros(ROW, COL)
matrix chunkcols = {1, 2, 5, 10, 25, 50, 100, 125, 500}
loop k=1..nelem(chunkcols) --quiet
cols = chunkcols[k]
n = COL / cols
set stopwatch
loop LOOP --quiet
loop for (j=1; j<=n; j+=cols) --quiet
B[,j:j+cols-1] = A[,j:j+cols-1]
endloop
endloop
printf "%3d columns per chunk: %.4fs\n", cols, $stopwatch
endloop
</hansl>
Quite interesting, and maybe we can make use of this in libgretl's
internals.
Allin
11:31 p.m.
On Sat, 12 Oct 2019, Allin Cottrell wrote:
Here are my timings:
[...]
and here are mine, on two different machines:
Laptop at home:
1 columns per chunk: 4.1346s
2 columns per chunk: 2.1247s
5 columns per chunk: 0.7616s
10 columns per chunk: 0.2831s
25 columns per chunk: 0.1298s
50 columns per chunk: 0.3060s
100 columns per chunk: 0.9900s
125 columns per chunk: 1.2825s
500 columns per chunk: 4.1578s
Desktop at work:
1 columns per chunk: 2.4007s
2 columns per chunk: 0.6390s
5 columns per chunk: 0.1440s
10 columns per chunk: 0.0739s
25 columns per chunk: 0.0363s
50 columns per chunk: 0.0724s
100 columns per chunk: 0.1957s
125 columns per chunk: 0.3581s
500 columns per chunk: 2.8391s
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
12:15 a.m.
On Sun, 13 Oct 2019, Riccardo (Jack) Lucchetti wrote:
On Sat, 12 Oct 2019, Allin Cottrell wrote:
> Here are my timings:
[...]
and here are mine, on two different machines:
Laptop at home:
1 columns per chunk: 4.1346s
2 columns per chunk: 2.1247s
5 columns per chunk: 0.7616s
10 columns per chunk: 0.2831s
25 columns per chunk: 0.1298s
50 columns per chunk: 0.3060s
100 columns per chunk: 0.9900s
125 columns per chunk: 1.2825s
500 columns per chunk: 4.1578s
Desktop at work:
1 columns per chunk: 2.4007s
2 columns per chunk: 0.6390s
5 columns per chunk: 0.1440s
10 columns per chunk: 0.0739s
25 columns per chunk: 0.0363s
50 columns per chunk: 0.0724s
100 columns per chunk: 0.1957s
125 columns per chunk: 0.3581s
500 columns per chunk: 2.8391s
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!
Allin
4:55 p.m.
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.
Marcin
--
Marcin Błażejowski
6:02 p.m.
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.
Allin
7:07 p.m.
Am 14.10.19 um 20:02 schrieb Allin Cottrell:
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.
By the way, these are results for an Intel(R) Core(TM) i5-6600 CPU
3.30GHz, L1=265kb, L2=1MB, L3=6MB
<output: ROW=5000, COL=500, LOOP=600>
1 columns per chunk: 1.5847s
2 columns per chunk: 0.7398s
5 columns per chunk: 0.2226s
10 columns per chunk: 0.0837s
20 columns per chunk: 0.0663s
21 columns per chunk: 0.0700s
22 columns per chunk: 0.0356s
23 columns per chunk: 0.0368s
24 columns per chunk: 0.0389s
25 columns per chunk: 0.0406s
35 columns per chunk: 0.0617s
45 columns per chunk: 0.0880s
50 columns per chunk: 0.1195s
100 columns per chunk: 0.3994s
125 columns per chunk: 0.3895s
500 columns per chunk: 1.7884s
</>
<output: ROW=10000, COL=500, LOOP=600>
1 columns per chunk: 3.2237s
2 columns per chunk: 1.6661s
5 columns per chunk: 0.6233s
10 columns per chunk: 0.2529s
20 columns per chunk: 0.1990s
21 columns per chunk: 0.2190s
22 columns per chunk: 0.0884s
23 columns per chunk: 0.0938s
24 columns per chunk: 0.1050s
25 columns per chunk: 0.1095s
35 columns per chunk: 0.2152s
45 columns per chunk: 0.3409s
50 columns per chunk: 0.3980s
100 columns per chunk: 0.6861s
125 columns per chunk: 0.8611s
500 columns per chunk: 11.8921s
</>
Artur
8:13 p.m.
On Mon, 14 Oct 2019, Artur Tarassow wrote:
Am 14.10.19 um 20:02 schrieb Allin Cottrell:
> 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.
By the way, these are results for an Intel(R) Core(TM) i5-6600 CPU 3.30GHz,
L1=265kb, L2=1MB, L3=6MB
<output: ROW=5000, COL=500, LOOP=600>
1 columns per chunk: 1.5847s
2 columns per chunk: 0.7398s
5 columns per chunk: 0.2226s
10 columns per chunk: 0.0837s
20 columns per chunk: 0.0663s
21 columns per chunk: 0.0700s
22 columns per chunk: 0.0356s
23 columns per chunk: 0.0368s
24 columns per chunk: 0.0389s
25 columns per chunk: 0.0406s
35 columns per chunk: 0.0617s
45 columns per chunk: 0.0880s
50 columns per chunk: 0.1195s
100 columns per chunk: 0.3994s
125 columns per chunk: 0.3895s
500 columns per chunk: 1.7884s
</>
<output: ROW=10000, COL=500, LOOP=600>
1 columns per chunk: 3.2237s
2 columns per chunk: 1.6661s
5 columns per chunk: 0.6233s
10 columns per chunk: 0.2529s
20 columns per chunk: 0.1990s
21 columns per chunk: 0.2190s
22 columns per chunk: 0.0884s
23 columns per chunk: 0.0938s
24 columns per chunk: 0.1050s
25 columns per chunk: 0.1095s
35 columns per chunk: 0.2152s
45 columns per chunk: 0.3409s
50 columns per chunk: 0.3980s
100 columns per chunk: 0.6861s
125 columns per chunk: 0.8611s
500 columns per chunk: 11.8921s
</>
So all the data seems to (pretty much) agree: the point at which
reduction in copy-time turns into increase, as we crank up the
number of columns to copy at once, is in the neighbourhood of the L2
cache size, which is typically 1 MB (2^20) these days.
We'll see what we can do with this information.
Allin
10:44 p.m.
On Mon, 14 Oct 2019, Allin Cottrell wrote:
So all the data seems to (pretty much) agree: the point at which
reduction in
copy-time turns into increase, as we crank up the number of columns to copy
at once, is in the neighbourhood of the L2 cache size, which is typically 1
MB (2^20) these days.
Oof, sorry people! I'm afraid that matrix-copy timings based on the
script I posted are mostly artifacts of an error in the script --
revealed when I finally checked for B == A after the copy. The limit
@n for the inner loop across columns was wrong, with the result that
not all columns were getting copied. Here are my current timings --
relatively flat in respect of the number/size of chunks:
matrix size = 2500000, (20000000 bytes)
1 columns per chunk: 2.4073s
2 columns per chunk: 2.3623s
5 columns per chunk: 2.4675s
10 columns per chunk: 2.4984s
25 columns per chunk: 2.5216s
50 columns per chunk: 2.5999s
100 columns per chunk: 3.2440s
125 columns per chunk: 3.5543s
500 columns per chunk: 2.8366s
And here's the corrected script:
<hansl>
set verbose off
clear
scalar ROW = 5000
scalar COL = 500
scalar LOOP = 600
matrix chunkcols = {1, 2, 5, 10, 25, 50, 100, 125, 500}
matrix A = mnormal(ROW, COL)
matrix B = zeros(ROW, COL)
printf "matrix size = %d, (%d bytes)\n", ROW*COL, ROW*COL*8
loop k=1..nelem(chunkcols) --quiet
cols = chunkcols[k]
# n = COL / cols # WRONG !!
n = COL - cols + 1
B .= 0
set stopwatch
loop LOOP --quiet
loop for (j=1; j<=n; j+=cols) --quiet
# printf "copy cols %d to %d (n=%d)\n", j, j+cols-1, n
B[,j:j+cols-1] = A[,j:j+cols-1]
endloop
endloop
printf "%3d columns per chunk: %.4fs\n", cols, $stopwatch
# printf "max(abs(A-B)) = %g\n", max(abs(A-B))
endloop
</hansl>
Some evidence remains that smaller chunks are better, but nothing
like as striking as before.
Allin
5:28 a.m.
On Mon, 14 Oct 2019, Allin Cottrell wrote:
Some evidence remains that smaller chunks are better, but nothing
like as
striking as before.
Confirmed here:
home laptop
matrix size = 2500000, (20000000 bytes)
1 columns per chunk: 4.1005s
2 columns per chunk: 3.9173s
5 columns per chunk: 4.3702s
10 columns per chunk: 4.3034s
25 columns per chunk: 3.7437s
50 columns per chunk: 3.7776s
100 columns per chunk: 5.0219s
125 columns per chunk: 5.2963s
500 columns per chunk: 4.2739s
work desktop
matrix size = 2500000, (20000000 bytes)
1 columns per chunk: 2.4840s
2 columns per chunk: 1.9271s
5 columns per chunk: 1.8937s
10 columns per chunk: 2.0993s
25 columns per chunk: 1.9555s
50 columns per chunk: 1.9354s
100 columns per chunk: 1.9425s
125 columns per chunk: 2.1190s
500 columns per chunk: 2.9539s
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
6:28 a.m.
On 15.10.2019 00:44, Allin Cottrell wrote:
On Mon, 14 Oct 2019, Allin Cottrell wrote:
> So all the data seems to (pretty much) agree: the point at which
> reduction in copy-time turns into increase, as we crank up the number
> of columns to copy at once, is in the neighbourhood of the L2 cache
> size, which is typically 1 MB (2^20) these days.
Oof, sorry people! I'm afraid that matrix-copy timings based on the
script I posted are mostly artifacts of an error in the script --
revealed when I finally checked for B == A after the copy. The limit
@n for the inner loop across columns was wrong, with the result that
not all columns were getting copied. Here are my current timings --
relatively flat in respect of the number/size of chunks:
My results:
Dell desktop with i5-4460 @3.2 GHz (L1 (data): 4x32 KB, L2: 4x256 KB,
L3: 6 MB):
1 columns per chunk: 2,7478s
2 columns per chunk: 2,6180s
5 columns per chunk: 2,7415s
10 columns per chunk: 3,3991s
25 columns per chunk: 3,3736s
50 columns per chunk: 6,5499s
100 columns per chunk: 6,6246s
125 columns per chunk: 6,6132s
500 columns per chunk: 6,9947s
Dell laptop with i7-8550U @1.80 GHz (L1 (data): 4x32 KB, L2: 4x256 KB,
L3: 8 MB):
1 columns per chunk: 2,5714s
2 columns per chunk: 2,3895s
5 columns per chunk: 2,4755s
10 columns per chunk: 2,4302s
25 columns per chunk: 2,4552s
50 columns per chunk: 2,3811s
100 columns per chunk: 2,7048s
125 columns per chunk: 3,2614s
500 columns per chunk: 3,1312s
Desktop with AMD Phenom II X6 1100T @3.3 GHz (L1 (data): 6x64 KB, L2:
6x512 KB, L3: 6 MB):
1 columns per chunk: 5,9561s
2 columns per chunk: 5,7848s
5 columns per chunk: 5,6697s
10 columns per chunk: 6,3291s
25 columns per chunk: 6,6432s
50 columns per chunk: 7,0944s
100 columns per chunk: 9,3844s
125 columns per chunk: 9,8562s
500 columns per chunk: 6,5650s
Marcin
--
Marcin Błażejowski
4:51 p.m.
On 12.10.2019 23:23, Allin Cottrell wrote:
Here are my timings:
and mine on:
1. Inspiron laptop with i7-8550U CPU @ 1.80GHz:
1 columns per chunk: 2,3008s
2 columns per chunk: 0,9288s
5 columns per chunk: 0,1957s
10 columns per chunk: 0,0793s
25 columns per chunk: 0,0398s
50 columns per chunk: 0,0897s
100 columns per chunk: 0,4300s
125 columns per chunk: 0,6502s
500 columns per chunk: 3,0006s
3. very old machine with AMD Phenom(tm) II X6 1100T:
1 columns per chunk: 5,3443s
2 columns per chunk: 2,6082s
5 columns per chunk: 1,1151s
10 columns per chunk: 0,4598s
25 columns per chunk: 0,2619s
50 columns per chunk: 0,5516s
100 columns per chunk: 1,7819s
125 columns per chunk: 2,2742s
500 columns per chunk: 5,9761s
Marcin
--
Marcin Błażejowski
1900
days inactive
1903
days old
14 comments
4 participants
participants (4)
-
Allin Cottrell -
Artur Tarassow -
Marcin Błażejowski -
Riccardo (Jack) Lucchetti