6 ms·

> Typically straightforward Numpy gets me from 40x slower than straightforward C to 5x slower. I find this hard to believe. What kind of numerical work are you

by steev 7y ago

> Typically straightforward Numpy gets me from 40x slower than straightforward C to 5x slower. I find this hard to believe. What kind of numerical work are you doing? Even something as simple as matrix-matrix multiplication should be hard to beat with C, unless your C code is using a cache efficient algorithm.

hoiuyoi9087 7y ago
Branch heavy code, for example trading order book updating. People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython)
- steev 7y ago
  That was my hunch. > People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython Agreed
- Sean1708 7y ago
  > (through Cython) My personal experience is that you can actually get another factor of 2 or 3 speed-up by ditching Cython and using actual C instead (I think it's because optimizers have a hard time cleaning up the C that Cython produces), even if you've turned off thing's like bounds checking.
  - hoiuyoi9087 7y ago
    I meant "through Cython" as in "passing through Cython", ie, Cython is just a thin wrapper layer over the real C/C++ code.
- cf 7y ago
  I think using numpy is always good first step after just trying to improve the algorithm. Numpy will be less effort than going to cython. After that cython is a good next step. I seriously don't know any situation where I would do the kind of micro-optimizations mentioned in the article.
kragen 7y ago
> I find this hard to believe I guess you haven't tried it, then. But your lack of knowledge is not a reasonable justification for attacking my integrity. > Even something as simple as matrix-matrix multiplication That's the best case for Numpy, not the worst. SGEMM is indeed just as fast when invoked from Numpy as when invoked from C, at least for large matrices.

by steev 7y ago

hoiuyoi9087 7y ago

Branch heavy code, for example trading order book updating. People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython)

steev 7y ago
That was my hunch. > People always say "use numpy", but that is only possible if your algorithm can be described in terms of vectorized operations. For many kinds of processing, the only alternative is C/C++ (through Cython Agreed
Sean1708 7y ago
> (through Cython) My personal experience is that you can actually get another factor of 2 or 3 speed-up by ditching Cython and using actual C instead (I think it's because optimizers have a hard time cleaning up the C that Cython produces), even if you've turned off thing's like bounds checking.
- hoiuyoi9087 7y ago
  I meant "through Cython" as in "passing through Cython", ie, Cython is just a thin wrapper layer over the real C/C++ code.
cf 7y ago
I think using numpy is always good first step after just trying to improve the algorithm. Numpy will be less effort than going to cython. After that cython is a good next step. I seriously don't know any situation where I would do the kind of micro-optimizations mentioned in the article.

kragen 7y ago

> I find this hard to believe I guess you haven't tried it, then. But your lack of knowledge is not a reasonable justification for attacking my integrity. > Even something as simple as matrix-matrix multiplication That's the best case for Numpy, not the worst. SGEMM is indeed just as fast when invoked from Numpy as when invoked from C, at least for large matrices.