Zha0q1 edited a comment on issue #18926: URL: https://github.com/apache/incubator-mxnet/issues/18926#issuecomment-676842186
Update: The difference in numerical value is caused by the fact that DLAMI (what i referred to earlier as vanilla openblas) uses a special (possibly optimized) openblas lib. I did more tests and found that: DLAMI openblas (LP64, int32): no loss of precision on my example 2.14748e+09 openblas dev (ILP64, int64): loss of precision 1.93274e+09 openblas dev (LP64, int32): loss of precision 1.93274e+09 In that sense the results are consistent between the 32 and 64 openblas if we build from the same source with the same configs (except for int size). Now the problem seems to be that whoever uses DLAMI will potentially get different numerical results from the ones who build openblas dev from source. The DLAMI openblas version is: ``` ubuntu@ip-172-31-11-14:~$ ll /usr/local/lib/ |grep blas lrwxrwxrwx 1 root root 30 Aug 7 01:38 libopenblas.a -> libopenblas_haswellp-r0.2.20.a lrwxrwxrwx 1 root root 31 Aug 7 01:38 libopenblas.so -> libopenblas_haswellp-r0.2.20.so* lrwxrwxrwx 1 root root 31 Aug 7 01:38 libopenblas.so.0 -> libopenblas_haswellp-r0.2.20.so* -rw-r--r-- 1 root root 28498048 Aug 7 01:12 libopenblas_haswellp-r0.2.20.a -rwxr-xr-x 1 root root 14344848 Aug 7 01:13 libopenblas_haswellp-r0.2.20.so* ``` My openblas dev build is: ``` -rw-r--r-- 1 root root 65650108 Aug 15 21:38 libopenblasp-r0.3.10.dev.a -rwxr-xr-x 1 root root 39439000 Aug 15 21:38 libopenblasp-r0.3.10.dev.so* ``` Whether the root cause comes from different version or different config needs further investigation update: openblas team said the kernel for gemm was changed earlier this year and that might cause the different rounding due to FMA operations ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
