[CI] run pytest in parallel

[szha]

Description

run pytest in parallel

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

• Changes are complete (i.e. I finished coding on this PR)
• To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

• run small tests in parallel
• mark tests that require more resources
• run large tests in serial
• use built-in tmpdir fixtures for temporary files

[mxnet-bot]

Hey @szha , Thanks for submitting the PR
All tests are already queued to run once. If tests fail, you can trigger one or more tests again with the following commands:

• To trigger all jobs: @mxnet-bot run ci [all]
• To trigger specific jobs: @mxnet-bot run ci [job1, job2]

---

CI supported jobs: [website, clang, centos-gpu, unix-cpu, windows-cpu, unix-gpu, sanity, windows-gpu, centos-cpu, edge, miscellaneous]

---

Note:
Only following 3 categories can trigger CI :PR Author, MXNet Committer, Jenkins Admin.
All CI tests must pass before the PR can be merged.

[leezu]

Thanks.

I find that the runtime of some tests is increased, maybe due to thrashing, overhead of the threadedengine or other problems. Though this can be improved in separate PR.

For example

505.28s call tests/python/unittest/test_optimizer.py::test_sparse_adam4
and
460.96s call tests/python/unittest/test_optimizer.py::test_sparse_adam
on last two unix-cpu runs in this PR in (Python3 MKL-CPU) but on master
150.76s call tests/python/unittest/test_optimizer.py::test_sparse_adam

[szha]

will look into it in a follow-up PR.

[szha]

@PatricZhao I noticed that the MKL/MKLDNN tests are taking a lot longer than non-MKL builds in the parallel test setting. I will try to run a couple more times to verify so this is just FYI. Example:
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-18146/51/pipeline/366

[szha]

Update: the MKLDNN builds are actually executing a different set of tests which could explain the time difference. However, the MKL build is indeed executing the same unittest as regular python 3 CPU build and it's consistently taking a lot longer.

[marcoabreu]

Could that be due to cold booz? Doesn't mkl generate kernels the first time you invoke them? Sheng Zha <notifications@github.com> schrieb am Di., 5. Mai 2020, 21:13:

…

Update: the MKLDNN builds are actually executing a different set of tests which could explain the time difference. However, the MKL build is indeed executing the same unittest as regular python 3 CPU build and it's consistently taking a lot longer. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#18146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEOED27YF6LHD3T3K2GP7N3RQBQNBANCNFSM4MOZZ7VQ> .

[szha]

@marcoabreu indeed that could be a likely cause. I reported my findings in #18244 and we can continue the discussion there.