Skip to content

cblas_ddot different results #2953

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
miro-janosik opened this issue Oct 28, 2020 · 2 comments
Closed

cblas_ddot different results #2953

miro-janosik opened this issue Oct 28, 2020 · 2 comments

Comments

@miro-janosik
Copy link

Good afternoon

my problem shares the error with #1168 - I also get error "Cholesky decomposition failed. Maybe matrix is not positive definite" when loading matrix with Kaldi.

My problem is that I have code compiled for Windows 10 (where it works), for CentOS 7 (where it works too), and after compiling it for Ubuntu 20 machine there it fails with this error, while loading the same matrix data. From what I see the operation call cblas_Xdot() returns different result for the same data .

What would be a best way to track down the problem please? I am trying to use the same version on all platforms (it is xianyi-OpenBLAS-eebc189-0-3-5 ) and I tried to build it with just a 'make' or 'make USE_THREAD=1 DYNAMIC_ARCH=1'.

When I run the tests I can see that cblas_ddot passed ... though, also when loading the matrices in Kaldi it works in first 30 matrices and fails on 31st.

I have a sample text output from the Cholesky decomposition - one run on windows, another on the linux, where it is clearly visible (in a diff tool like Meld or WinDiff) where results start to differ and Cholesky fails. It can be seen at http://bin.mypage.sk/FILES/localCholesky.zip

cheers and thanks for hints, Miro

@martin-frbg
Copy link
Collaborator

Is there a reason why you need to use version 0.3.5 from almost 2 years ago ? In particular, 0.3.6 had a fix for sloppy declarations of register use in the dot microkernel (and several others) on x86_64 (where the consequences of the sloppyness would depend on the optimisations performed by the compiler - the newer the more aggressive) and there have been a few fixes for race conditions in the multithreading.

@miro-janosik
Copy link
Author

Hi, reason was that we jumped off from the version that was available in some of linux distributions at the time, and wanted to have the same versions on all other platforms too as it worked well.

Also Kaldi suggested using 0.3.5 until end of 2019 ( https://github.com/kaldi-asr/kaldi/pull/3642/files ), now it suggests 0.3.7.

I have now tried to use latest OpenBLAS 0.3.12 and problem is gone, this is a good enough solution for now for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants