chriselrod/PaddedMatrices.jl

New release with the glorious new multithreading?

DilumAluthge opened this issue · 6 comments

DilumAluthge commented
New release with the glorious new multithreading?
chriselrod commented

I'm trying channel-based multithreading.
If it's comparably fast or faster, I'll use that.
If not, I'll try to fix ci (I think I fixed the .yml files locally, are spaces vs tabs a problem?) and issue a release assuming tests pass.

  • 👍1
DilumAluthge commented

(I think I fixed the .yml files locally, are spaces vs tabs a problem?)

Yeah it's gotta be spaces I think. You can try:

  1. Run through any online YAML parser, e.g. https://yaml-online-parser.appspot.com/
  2. Open the YAML files in the GitHub web editor, and usually the linter will let you know if there are problems.
  • 👍1
DilumAluthge commented

YAML is so sensitive to tiny whitespace changes.

chriselrod commented

I fixed the yamls, and I'll address the test failures shortly.

But a couple questions:

  1. Do you think I should add an @warn on init if Julia has less than NUM_CORES-1 threads?
  2. Do you think I should make jmul(!) thread by default? Note that nested jmul(!)s will not be threaded, so it'd only use threads when they weren't being used anyway. Meaning it shouldn't be invasive, and it also means that existing code like the Tullio benchmark using jmul! won't need to be updated.
DilumAluthge commented
  1. Do you think I should add an @warn on init if Julia has less than NUM_CORES-1 threads?

Yes, that makes sense to me.

2. Do you think I should make jmul(!) thread by default? Note that nested jmul(!)s will not be threaded, so it'd only use threads when they weren't being used anyway. Meaning it shouldn't be invasive, and it also means that existing code like the Tullio benchmark using jmul! won't need to be updated.

I don't feel strongly either way. I'd probably lean towards the status quo of having separate functions for threading vs non-threading.

chriselrod commented

I've been experimenting with parameters. I want the benchmarks to look a little better before making the release.

I don't feel strongly either way. I'd probably lean towards the status quo of having separate functions for threading vs non-threading.

I added jmul_single_threaded! to have the same behavior as the old jmul!.

  • 👍1