8 ms·
Were these benchmarks before or after 2020.03.26? There was a bug that caused max operations to take twice as long. From the KDB+ 4.0 release notes: 2020.03.2
by binomiq 6y ago
Were these benchmarks before or after 2020.03.26? There was a bug that caused max operations to take twice as long.
From the KDB+ 4.0 release notes:
2020.03.26
FIX
fixed performance regression for max. e.g.
q)x:100000000?100;system"ts:10 max x"
- bluestreak 6y agothese are against the latest 4.0 KDB+, after 26 March. KDB before that could not aggregate in parallel implicitly.
- binomiq 6y agoIn your benchmarks, KDB's max on longs takes twice as long as sum on longs. I am not able to replicate this with the most recent version of KDB (2020.03.30). $QHOME/l64/q -s 4 KDB+ 4.0 2020.03.30 Copyright (C) 1993-2020 Kx Systems l64/ 4()core 516718MB <snip> q)zz:1000000000?1000j q)0.01*system"t do[100;max zz]" 257.52 q)0.01*system"t do[100;sum zz]" 251.95 There's a marginal difference here rather than double. For the version of KDB with the regression bug: q)0.01*system"t do[100;max zz]" 512.21 q)0.01*system"t do[100;sum zz]" 254.24 Which starts to look more like your numbers.
- bluestreak 6y agosorry, i think we tested with this one: KDB+ 4.0 2020.03.17 Copyright (C) 1993-2020 Kx Systems l64/ 12(16)core 63960MB EXPIRE 2021.03.26
- dintech 6y agoEven without that 2x, all benchmarks are still in the same ballpark which is impressive in its own right. It will be interesting to see where this goes.