search

RagnarGrootKoerkamp / BAPCtools

Tools for developing ICPC-style programming contest problems.
GNU General Public License v3.0
49 stars 22 forks source link

`sanity_check` is slow #398

Closed RagnarGrootKoerkamp closed 2 hours ago

RagnarGrootKoerkamp commented 5 hours ago

~We're not measuring time/memory usage here, so we should parallellize to speed up bt zip.~

Old but wrong title: bt constraints doesn't do parallel while it should.

mzuenni commented 4 hours ago

what exactly is not parallel here? ^^'

RagnarGrootKoerkamp commented 4 hours ago

The loop here: https://github.com/RagnarGrootKoerkamp/BAPCtools/blob/master/bin/problem.py#L846-L871

It looks parallel for sure, but my CPU is only using 1 core. Maybe the merging of constraints is somehow blocking the parallellization (via the GIL?). I doubt the merging itself is a bottleneck.

Maybe first collecting all per-testcase constraints data and then merging at the end fixes it?

mzuenni commented 4 hours ago

It still seems to be parallel? (and as far as I can tell from htop all cpus have more load during constraints collection). However, we parallelize by testcases not by validators i.e. if you have many validators and few tests there is less parallelism...

also making the _merge_constraints a nop (by simple returning) doesn't speed up anything

RagnarGrootKoerkamp commented 4 hours ago

Turns out it's the sanity_check that's slow in this case. Not sure if it's easy to make that faster. We could shell it out to a separate process but that's probably overkill.

Knowing this, I can just pass the flag to skip it next time.

mzuenni commented 4 hours ago

hmm we could write this in c++ instead?

RagnarGrootKoerkamp commented 4 hours ago

If we do so, we could probably do something similar to the default_output_validator, and implicitly add it along all other validators.

mzuenni commented 4 hours ago

on the other hand at least for the problem i tested on this doesn't seem to be the bottle neck.. validation is just slow