Don't use @assert, and print some debugging info if C is not approximately equal to reference
#47
Conversation
…oximately equal to `reference`
| ) where {F} | ||
| maybe_sleep(sleep_time) | ||
| t0 = @elapsed f!(C, A, B) | ||
| isnothing(reference) || @assert C ≈ reference | ||
| if (reference !== nothing) && (!(C ≈ reference)) | ||
| msg = "C is not approximately equal to reference" |
There was a problem hiding this comment.
The reference is the first of the libraries passed to runbenchmark, so perhaps the order does matter -- we should trust that the reference is correct.
When we get this error, we know either the ref or lib is wrong.
There was a problem hiding this comment.
Not quite sure what you mean. Can you elaborate on this?
There was a problem hiding this comment.
Oh I see what you mean.
There was a problem hiding this comment.
Should we instead just always use LinearAlgebra.mul! to compute the reference C0?
There was a problem hiding this comment.
That could take potentially many extra seconds at larger sizes, and do we trust it more than BinaryBuilder OpenBLAS or MKL (or BLIS)?
The time issue would be major when it's integers, and mul! calls the generic matmul.
I guess it'd be nice to always know what the reference is, though.
There was a problem hiding this comment.
That's a good point. Hmmm.
There was a problem hiding this comment.
Let's keep the current behavior for now.
|
Feel free to merge when ready. |
Fixes #46
Also, if
C !≈ reference, we print some info (the name of the library, as well as the values ofM,K, andN) to help with debugging.