mixed sparse-dense matrix multiplication benchmarks #128
Conversation
|
This seems to be right to me. The sizes of my matrices are about two magnitudes bigger and even more sparser. I cannot judge, what impact it is going to have on the benchmark though. Thanks a lot for this initiative. |
|
The continuous integration results suggest that these benchmarks took order of a minute, so massaging these benchmarks a bit larger may be alright (@ararslan?). Also, the benchmarks for adjoint matmul variants will exercise essentially the same kernels as the benchmarks for corresponding transpose matmul variants. (Consider, for example, (That said, I imagine that these benchmarks should be fairly representative of corresponding larger problems as long as they spill out of L2 cache. Increasing Thoughts? Particular suggestions? Thanks and best! :) |
¯\_(ツ)_/¯ Sure, seems reasonable |
|
I added some scale variation to the matrices in accord with the notes above. Assuming the revised benchmarks run in a reasonable amount of time, this pull request should be in shape. Best! |
|
Thanks Alex and Tomas! :) |
* Improve/fix show methods Previously the logic for switching compact or verbose form of various benchmark result objects are in `show(io::IO, group::BenchmarkGroup)`. A more natural place would be `show(io::IO, t::Trial)` etc. as it let code outside BenchmarkTools to switch the compactness using the standard `IOContext` interface. For example, with this patch `Trial`s in `Vector` are shown in the compact form automatically. This patch also adds: * Colored output for the words `improvement` and `regression`. * `:typeinfo` IO context support * Remove :verbose IOContext
3 participants
This pull request adds benchmarks for mixed sparse-dense matrix multiplication (in anticipation of improved kernels for these operations).
@pevnak, could you confirm that these benchmarks cover all cases relevant to your application?
These benchmarks might be a bit heavy. If so, is there some flag behind which we can hide some of these benchmarks? If not, perhaps changing the
1inm, k, n = 1 .* (om, ok, on)to3would more realistically exercise cache. (Edit: These benchmarks should become much lighter once improved kernels go live.)Thanks and best!