max_concurrency: scheduled at run-time or compile-time?

Hey @xwuupb

Changing the concurrency of the loop changes the hardware that gets produced. So this is a compile time change.

Reducing the concurrency of a loop reduces the resource usage for that loop (because it needs to be able to handle fewer concurrent iterations).

Now it is called "max_concurrecy" and not "concurrency" for a reason.

Your loop may now not have a new iteration ready to execute at each cycle.

This may be due to different reasons such as a blocking pipe read or any upstream component that stalls your loop.

So there is also a run-time aspect to how loop iterations are scheduled.

The reason why you can't find the exact answer you are looking for is because it would not make sense to artificially limit the concurrency of a loop at runtime.

If you have the hardware that allows you to interleave as many iterations as possible, there is no reason to limit it at run time.

So the entire point of this attribute is to tell the compiler that it can limit the maximum concurrency because you know that the consumer of that the result being computed in this loop does not require the result to be computed so fast.

Therefore, you can make hardware savings by limiting the max concurrency (compile time).

The page linked above by @hareesh says "The max_concurrency attribute enables you to control the on-chip memory resources required to pipeline your loop." which implicitly tells you this is done at compile time.