CompatHelper: bump compat for "Polyester" to "0.4"

[github-actions[bot]]

This pull request changes the compat entry for the Polyester package from 0.3.5 to 0.3.5, 0.4.

This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request.

[codecov[bot]]

Codecov Report

Merging #111 (2a8bc5f) into master (8907884) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #111   +/-   ##
=======================================
  Coverage   86.62%   86.62%           
=======================================
  Files          11       11           
  Lines         755      755           
=======================================
  Hits          654      654           
  Misses        101      101           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 8907884...2a8bc5f. Read the comment docs.

[ranocha]

If I may ask here: What was/were the breaking change(s) in Polyester.jl from v0.3.x to v0.4?

[chriselrod]

If I may ask here: What was/were the breaking change(s) in Polyester.jl from v0.3.x to v0.4?

Two breaking changes: 1) The first change is making a feature from previous versions now silently not do anything. I don't know of anyone using the feature, so that's probably okay, and code will still work. The feature was the option to reserve some number of threads per launched thread, e.g. @batch reserve=4 for .... Then if it launched 4 threads, it would set aside 3 additional threads for each of these, so that any Polyester-based threading (Polyester, Octavian, LoopVectorization) would be able to run on those 4 threads. This potentially let someone specify a sort of breadth-first parallelization scheme. This option is now silently ignored. 2) Internal changes, where instead of using an unsigned integer to represent threads you can allocate on, it now uses a tuple of such integers. This breaks every library relying on the internals (LoopVectorization, Octavian). I updated LoopVectorization, but I haven't updated Octavian.

The positive of 0.4 is that I added untested support for CPUs with >128 threads (related to "2" above: UInt128 is the biggest unsigned integer in base). I haven't actually tested it, so it's probably buggy. I probably could test it via redefining a few methods to make my 8 thread laptop look like a 256 thread machine to Polyester, but I haven't gotten around to it.

[ranocha]

Thanks a lot!