Closed 27pchrisl closed 1 year ago
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅
I have read the CLA Document and I hereby sign the CLA
Awesome @27pchrisl thanks for looking into this for us! Your help is greatly appreciated.
Did you run the benchmarks with these changes yet by any chance? I'm curious to know if we take a performance hit. If there is a performance hit, do you think we could try to find the point at which these arrays become "unpacked" and "re-pack" them as a way to mitigate the performance loss?
There doesn't appear to be much (if any) of a performance impact.
Baseline ...
|---|---|---|---|---|---|---|---| | MatrixMatrixMultiplyBench | multiply | | 1 | 5 | 112.114mb | 0.015s | ±9.78% | | MatrixVectorMultiplyBench | multiply | | 1 | 5 | 75.193mb | 0.011s | ±9.72% | | MatrixScalarMultiplyBench | multiply | | 1 | 5 | 75.119mb | 0.011s | ±1.85% | | VectorVectorMultiplyBench | multiply | | 1 | 5 | 3.737mb | 0.385ms | ±2.14% |
After your changes ...
|---|---|---|---|---|---|---|---| | MatrixMatrixMultiplyBench | multiply | | 1 | 5 | 112.114mb | 0.015s | ±12.67% | | MatrixVectorMultiplyBench | multiply | | 1 | 5 | 75.193mb | 0.012s | ±9.72% | | MatrixScalarMultiplyBench | multiply | | 1 | 5 | 75.119mb | 0.011s | ±0.19% | | VectorVectorMultiplyBench | multiply | | 1 | 5 | 3.737mb | 0.393ms | ±58.90% |
This PR changes how arrays are accessed in all the operations. It appears that for some reason the hashtables are becoming non-packed, but I am not sure why. Changing directly accessing
arData
to usingzend_hash_index_find
fixes this issue. Under the hoodzend_hash_index_find
evaluates whether the array is properly packed, and delegates to directly accessing arData. So I think this change should be as performant as it was before, if your arrays are properly packed.All the tests run successfully with these changes.
There are still deprecation warnings about
self
andstatic
calls, but it looks like Zephir has not yet developed a fix for this. https://github.com/zephir-lang/zephir/issues/2405There are also warnings like "Implicit conversion from float 3.3 to int loses precision", which appear to be coming from calls into Zend mod_function. I was not sure of the mathematically correct way to resolve this one. Minor changes like
int
tofloat
warnings are also fixed, and a return type ofVector
is fixed to match the non-extension code.(Potentially) fixes #33 and #38