implement deep parallel in artiq.sim #22

New Issue

sb10q · 2021-09-24T12:43:16+08:00

sb10q commented

2021-09-24 12:43:16 +08:00

https://github.com/m-labs/artiq/issues/1555#issuecomment-922652441

ychenfo was assigned by sb10q

2021-09-24 12:43:16 +08:00

lriesebos commented

2021-09-27 10:29:50 +08:00

Are you sure artiq.sim is not already implemeting deep parallel? DAX.sim uses the same time model, which simulates deep parallel.

sb10q commented

2021-09-27 10:33:45 +08:00

Poster

It is implementing very deep parallel. The compromise we discussed was that parallel contexts would stop at function calls; doing this in artiq.sim requires Python bytecode patching.

Very deep parallel would be quite annoying to implement in the compiler, as a function would compile differently depending on whether it's in a parallel or sequential context.

It is implementing very deep parallel. The compromise we discussed was that parallel contexts would stop at function calls; doing this in artiq.sim requires Python bytecode patching. Very deep parallel would be quite annoying to implement in the compiler, as a function would compile differently depending on whether it's in a parallel or sequential context.

lriesebos commented

2021-09-27 10:40:25 +08:00

Implementing deep parallel in artiq.sim does not require Python bytecode patching, it can be done like this: https://gitlab.com/duke-artiq/dax/-/blob/master/dax/sim/coredevice/core.py#L86 . DAX.sim currently implements deep parallel (not shallow or very deep).

Regarding DAX.sim in general, I am open to have a discussion about upstreaming that code if there is interest. Though Duke obviously has to agree with that too.

Implementing deep parallel in artiq.sim does not require Python bytecode patching, it can be done like this: https://gitlab.com/duke-artiq/dax/-/blob/master/dax/sim/coredevice/core.py#L86 . DAX.sim currently implements deep parallel (not shallow or very deep). Regarding DAX.sim in general, I am open to have a discussion about upstreaming that code if there is interest. Though Duke obviously has to agree with that too.

sb10q commented

2021-09-27 12:24:02 +08:00

Poster

True, we can do it via the kernel decorator in a very straightforward manner. Though this can lead to confusing behavior if someone forgets a decorator on one of the functions.

sb10q commented

2021-09-27 12:27:32 +08:00

Poster

Maybe we can do it like you propose and then the simulator could check that any function that uses the RTIO operations is decorated (since lack of decorator would be an error at compilation anyway)?
This can be done using inspect in the simulated RTIO functions to go up a stack frame and get the caller function and then it can check for the presence of the decorator there.

Maybe we can do it like you propose and then the simulator could check that any function that uses the RTIO operations is decorated (since lack of decorator would be an error at compilation anyway)? This can be done using ``inspect`` in the simulated RTIO functions to go up a stack frame and get the caller function and then it can check for the presence of the decorator there.

lriesebos commented

2021-09-27 23:02:58 +08:00

I think such a check might help, but it is hard to cover all cases, e.g delay() outside a kernel and implicit sync rpc calls. It might also impact simulation speed. Hence, we created flake8-artiq to find at least part of these cases, but we accept that the simulator is more permissive than the actual compiler. Finally, we created an option that allows users to compile kernels before simulation, which should catch basically all of such errors, but at the cost of much slower simulation.

Oh and to link this to NAC3, this is one of the reason why I am a fan of explicitly decorating rpc functions with @rpc. Explicit marking will probably allow better checks for simulation.

I think such a check might help, but it is hard to cover all cases, e.g `delay()` outside a kernel and implicit sync rpc calls. It might also impact simulation speed. Hence, we created flake8-artiq to find at least part of these cases, but we accept that the simulator is more permissive than the actual compiler. Finally, we created an option that allows users to compile kernels before simulation, which should catch basically all of such errors, but at the cost of much slower simulation. Oh and to link this to NAC3, this is one of the reason why I am a fan of explicitly decorating rpc functions with `@rpc`. Explicit marking will probably allow better checks for simulation.

sb10q self-assigned this 2021-12-23 15:41:13 +08:00

ychenfo was unassigned by sb10q

2021-12-23 15:41:13 +08:00

sb10q commented

2022-04-12 16:05:05 +08:00

Poster

Done (without inspect checks).

Done (without ``inspect`` checks).

sb10q closed this issue

2022-04-12 16:05:05 +08:00

Sign in to join this conversation.