Interpreting `JET` warnings on a simple `Polyester` multithreaded loop

Polyester seems to be one of the bigger sources of TTFX in some of my libraries. It is similarly the main source of warnings when using JET. Below is a very simple multi-threaded loop that causes a large number of JET warnings (both in 1.7.0 and in nightly). I do not have much understanding of ThreadingUtilities and of StaticArrays, where the warnings originate. Would someone be able to guide me where to look for improvements or how I can change my function, in order to silence the JET warnings and make sure there is no risk of runtime dispatch?

julia> using JET, Polyester

julia> function a(m::Matrix, i::Int)
           @batch for r in axes(m,1)
               m[r,:] .+= i
a (generic function with 1 method)

julia> m = rand(Int,5,5)

julia> @report_opt a(m,1)
═════ 92 possible errors found ═════

With these versions

  [c3a54625] JET v0.5.16
  [f517fe37] Polyester v0.6.13
  [aedffcd0] Static v0.7.5
  [90137ffa] StaticArrays v1.5.0
  [8290d209] ThreadingUtilities v0.5.0
1 Like

Are you using the array slices as indices? Or do you mean to use axes(m,1) instead of eachrow(m)?

1 Like

Is this with Static v0.7?

Thanks for the correction, got confused as I was cutting down the size of the example. It is corrected in the original post now.

It is indeed Static v0.7, but I used the wrong MWE, so that might have been a bit mislead. Please excuse the confusion. The warnings are from StaticArrays (and ThreadingUtilities), not from Static. All versions are added to the original post.

1 Like

These are basically all for printing.
I’m apparently on different versions (as I get 60, not 72, possible errors found).
But everything I see comes from these two lines:

This code is for diagnostics, that is, it displays and dumps a failed task so you can see the stacktrace when your threaded code runs an error.

If your program’s performance is bottlenecked by how quickly it can print error messages, I’d suggest trying to stop it from throwing so many errors. Maybe fix the bugs that keep showing up in all those stacktraces?
Or PR base Julia to speed up display(::Task) and dump(::Task), I guess.

Of course, you probably didn’t hit these lines in your code.
You just got a report from JET.

Is there some way I can hide this code from JET, so we don’t have so many false positives/its output is more useful?

I don’t think dump(::Task) is all that useful, so I can probably remove that line.

1 Like

I’ve gotten reports about Polyester being bad for latency before. If you have some examples, I may be able to look at it sometime.

1 Like

Indeed, I am not hitting these lines, they are just showing up in JET’s abstract interpretation. To great extent, I am just cargo-culting my approach to lowering TTFX: I have noticed that the fewer Aqua and JET warnings I have, the faster the package imports (while I did not have as much luck with SnoopCompile), so I am spending some time trying to figure out the source of every JET warning. Admittedly, this is not the best “first principles” approach, but it is educational enough, and I needed to start somewhere.

Thanks for your explanation! It does not seem there is anything more to see here. If I figure out how to tell the compiler and/or JET to not worry about these lines, I will send you a pull request.