With the launch of Phase 1, we also release flopscope v0.8.0rc1, which supports `flops.symmetrize` in the `flopscope-client`. So all Phase 1 submissions should be able to use `symmetrize` on the evaluation servers.
and regarding,
> the grader doesn’t have stock numpy and some other deps that are included in the starterkit env.
yes that is correct, and it is a challenge design decision we make, for security reasons. The starter-kit locally runs flopscope natively, while, on the evaluation servers, it exposes the same API, via a think `flopscope-client` which executes the actual operations through a RPC like call, even if the submitted code does not needf to change. The support for external dependencies like `numpy` is a challenge design choice at the moment, and we might revisit that decision if we come across strong usecases where using numpy or other libraries (which will still count towards the heavily penalized residual time) are necessary. So we are open to feedback.
Sharada Mohanty
Karma: 4
This misattribution issue of remote-dispatch + array-unpacking has been resolved in the new flopscope release we did for Phase 1. The residual wall times you see on the evaluation servers should be much closer to what you would expect when running flopscope locally. Let us know on the forums, if thats not the case.
Regarding:
> (Also if the arrays are being copied back and forth that seems a bit excessive and causing the grader to be way slower than necessary! I’d try to have the remote endpoint have durable custody of arrays within a session, and only transfer data on creation and when-demanded.)
Agree, and we will be rolling out some fixes soon to address this.