Backports for 1.8-rc1/beta3 #44710
Backports for 1.8-rc1/beta3 #44710
Conversation
On Aarch64, the `fpcr` register is 64bit wide, although the top 32bit are currently unused and reserved for future usage. Nevertheless, we should safe and restore the full 64 bit, not just 32 bit. This also silences a compiler warning about this. Reference: <https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Registers/FPCR--Floating-point-Control-Register> (cherry picked from commit 5bd0545)
* More flexibly test affinity setting When running on a machine with `cpusets` applied, we are unable to assign CPU affinity to CPUs 1 and 2; we may be locked to CPUs 9-16, for example. So we must inspect what our current cpumask is, and from that select CPUs that we can safely assign affinity to in our tests. * Import `uv_thread_getaffinity` from `print_process_affinity.jl` * Call `uv_thread_getaffinity` only if `AFFINITY_SUPPORTED` * Fix a syntax error Co-authored-by: Takafumi Arakaki <aka.tkf@gmail.com> (cherry picked from commit 32b1305)
(cherry picked from commit 99bdd00)
|
@nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
…44668) I found that a tricky thing can happen when constant inference derives `Const`-result while non-constant inference has derived (non-constant) `InterConditional` result beforehand. In such a case, currently we discard the result with constant inference (since `!(Const ⊑ InterConditional)`), but we can achieve more accuracy by not discarding that `Const`-information, e.g.: ```julia julia> iszero_simple(x) = x === 0 iszero_simple (generic function with 1 method) julia> @test Base.return_types() do iszero_simple(0) ? nothing : missing end |> only === Nothing Test Passed ```
* avoid using `@sync_add` on remotecalls It seems like @sync_add adds the Futures to a queue (Channel) for @sync, which in turn calls wait() for all the futures synchronously. Not only that is slightly detrimental for network operations (latencies add up), but in case of Distributed the call to wait() may actually cause some compilation on remote processes, which is also wait()ed for. In result, some operations took a great amount of "serial" processing time if executed on many workers at once. For me, this closes #44645. The major change can be illustrated as follows: First add some workers: ``` using Distributed addprocs(10) ``` and then trigger something that, for example, causes package imports on the workers: ``` using SomeTinyPackage ``` In my case (importing UnicodePlots on 10 workers), this improves the loading time over 10 workers from ~11s to ~5.5s. This is a far bigger issue when worker count gets high. The time of the processing on each worker is usually around 0.3s, so triggering this problem even on a relatively small cluster (64 workers) causes a really annoying delay, and running `@everywhere` for the first time on reasonable clusters (I tested with 1024 workers, see #44645) usually takes more than 5 minutes. Which sucks. Anyway, on 64 workers this reduces the "first import" time from ~30s to ~6s, and on 1024 workers this seems to reduce the time from over 5 minutes (I didn't bother to measure that precisely now, sorry) to ~11s. Related issues: - Probably fixes #39291. - #42156 is a kinda complementary -- it removes the most painful source of slowness (the 0.3s precompilation on the workers), but the fact that the wait()ing is serial remains a problem if the network latencies are high. May help with #38931 Co-authored-by: Valentin Churavy <vchuravy@users.noreply.github.com> (cherry picked from commit 62e0729)
Fix #44734. (cherry picked from commit 68e2969)
|
@nanosoldier |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
Backported PRs:
round(Integer, big(Inf))#44676*withAbstractQ#44615@sync_addon remotecalls #44671Matrixcntr work for structured matrices forzero(T) !isa T#44707ax(b)py!'s behavior on 1.7 #44736InterConditionalresult withConstcarefully #44668Contains multiple commits, manual intervention needed:
Non-merged PRs with backport label:
.opin lowering #44770abstract_invoke#44764Vararg-arguments insubtyperather than abort #44761===when encountering null pointer #44749stridesforReshapedArraywith strided parent. #44507