5 ms·

Could probably squeeze a bit more out of the C++ version by targeting the specific architecture of the CPU to make use of SSE. Also, what floating point type i

by berkut 15y ago

Could probably squeeze a bit more out of the C++ version by targeting the specific architecture of the CPU to make use of SSE. Also, what floating point type is KL using? float or double? - and is double necessary? - converting the C++ code to use floats would probably provide a fair speedup on the divides and due to squeezing more data into cache lines...

gcp 15y ago
Could probably squeeze a bit more out of the C++ version by targeting the specific architecture of the CPU to make use of SSE. Not only that, from browsing the code, the critical loop is likely matrix multiplication. If that's the case, any kind of engine who is smart about SSE, cache lines, etc is going to be able to outperform simple C/C++ code. Of course there's excellent matrix maths libraries for C/C++ that could be used instead.
- to3m 15y ago
  More than half of the running time seems to be taken up by the generation of normally-distributed random numbers. Sort of makes sense, I suppose, since that bit has a loop and a `sqrt' and a `log' in it. The repeated calls to `exp' seem to take up some time too. As for the matrix multiplication, that only happens on startup, so it's surely irrelevant. The bit that runs a lot just does matrix*vector. It is rather hard to make that cache-incoherent, as it just walks forwards through all inputs and outputs. In any event I would think that the program's entire working set will fit in L1. I was merely fiddling with this out of interest, so I didn't spend ages SSE2ifying it. The VC++ x64 compiler doesn't do inline assembly language anyway. But if you halve the number of multiply-adds `multMatVec' does, under the assumption that this would make it twice as fast, and that twice as fast would be what an SSE2 implementation would be like, it makes no noticeable difference. (I was fiddling with the single-threaded version, using Visual Studio 2010, compiling for x64.)
berkut 15y ago
Actually seems like it doesn't...: Using: -O3 -march=corei7 -msse -msse2 -msse3 -msse4 -fipa-matrix-reorg -fwhole-program made negligible (if any) difference running var-mt: Original: 30.464 30.211 30.646 with g++ options: 30.381 30.487 30.277 However, using ICC 12.0.4 (-o3 -xssse3) 25.418 25.613 25.392 On the same machine (SB 2.2Ghz).

by berkut 15y ago

gcp 15y ago

Could probably squeeze a bit more out of the C++ version by targeting the specific architecture of the CPU to make use of SSE. Not only that, from browsing the code, the critical loop is likely matrix multiplication. If that's the case, any kind of engine who is smart about SSE, cache lines, etc is going to be able to outperform simple C/C++ code. Of course there's excellent matrix maths libraries for C/C++ that could be used instead.

to3m 15y ago
More than half of the running time seems to be taken up by the generation of normally-distributed random numbers. Sort of makes sense, I suppose, since that bit has a loop and a `sqrt' and a `log' in it. The repeated calls to `exp' seem to take up some time too. As for the matrix multiplication, that only happens on startup, so it's surely irrelevant. The bit that runs a lot just does matrix*vector. It is rather hard to make that cache-incoherent, as it just walks forwards through all inputs and outputs. In any event I would think that the program's entire working set will fit in L1. I was merely fiddling with this out of interest, so I didn't spend ages SSE2ifying it. The VC++ x64 compiler doesn't do inline assembly language anyway. But if you halve the number of multiply-adds `multMatVec' does, under the assumption that this would make it twice as fast, and that twice as fast would be what an SSE2 implementation would be like, it makes no noticeable difference. (I was fiddling with the single-threaded version, using Visual Studio 2010, compiling for x64.)

berkut 15y ago

Actually seems like it doesn't...: Using: -O3 -march=corei7 -msse -msse2 -msse3 -msse4 -fipa-matrix-reorg -fwhole-program made negligible (if any) difference running var-mt: Original: 30.464 30.211 30.646 with g++ options: 30.381 30.487 30.277 However, using ICC 12.0.4 (-o3 -xssse3) 25.418 25.613 25.392 On the same machine (SB 2.2Ghz).