add initial stress test #2364
add initial stress test #2364
Conversation
Zzzabiyaka
force-pushed
the
add_stress_test
branch
from
97d5afd
to
67be429
Compare
Zzzabiyaka
force-pushed
the
add_stress_test
branch
4 times, most recently
from
850f2f3
to
7f926ad
Compare
Zzzabiyaka
force-pushed
the
add_stress_test
branch
from
7f926ad
to
42f7054
Compare
| int | ||
| main(int argc, char **argv) | ||
| { | ||
| for (; factorised_number < NUM_ITER; ++factorised_number) { |
There was a problem hiding this comment.
Just a note - if you try to maximize the number of threads running all the times, this code does not do that. Imagine situation where you have 3 threads (1, 2, 3) and for some reason 1 is really slow, but 2 and 3 are fast. Once 1, 2, and 3 are spawned, and then 2 and 3 complete, they'll have to wait for thread 1 to complete before 2 and 3 is spawned again. If you want to achieve maximum concurrency at most possible times, you should probably just maintain a list of thread ids and keep track on the number of active threads.
There was a problem hiding this comment.
I'm not sure we can benefit much from testing how many threads exactly run together. Looks like we're more interested in creation/destruction as a part of proposal, aren't we?
There was a problem hiding this comment.
yes, and by implementing it the way it's currently done in this PR, we're delaying spawning new threads
Zzzabiyaka
force-pushed
the
add_stress_test
branch
5 times, most recently
from
7f20e6b
to
0a50623
Compare
| */ | ||
|
|
||
| #ifndef __wasi__ | ||
| #error This example only compiles to WASM/WASI target |
There was a problem hiding this comment.
are we using any specific WASM/WASI instruction here?
There was a problem hiding this comment.
looks like we're not but I'm not sure we should allow anyone running this test without WASI define, should we?
I mean, I checked this code only with WASI sdk, where this flag is defined. Without it, you won't be able to run build.sh etc
There was a problem hiding this comment.
sure, all I'm saying that one can most likely compile the code with a regular C compiler on linux.
There was a problem hiding this comment.
yeah, probably they can.
Zzzabiyaka
force-pushed
the
add_stress_test
branch
7 times, most recently
from
8f60126
to
ef548af
Compare
Zzzabiyaka
force-pushed
the
add_stress_test
branch
from
ef548af
to
73752ae
Compare
| check_if_prime(void *value) | ||
| { | ||
| unsigned int *num = (unsigned int *)(value); | ||
| usleep(10000); |
There was a problem hiding this comment.
we can probably make the sleep even smaller. I think for stress tests it'd be good to not only validate if the runtime can have multiple threads running at the same time for an extended period of time, but also whether multiple thread create/stop operations ran in a short amount of time work well. This can be implemented here, but perhaps we need another stress test for that.
There was a problem hiding this comment.
Yeah I also feel like another test is good for it
Zzzabiyaka
force-pushed
the
add_stress_test
branch
from
73752ae
to
22f5164
Compare
|
This PR is currently blocked on #2389 UPD: 2389 is merged, this PR is rebased and green |
Zzzabiyaka
force-pushed
the
add_stress_test
branch
3 times, most recently
from
6377117
to
b4b1261
Compare
Zzzabiyaka
force-pushed
the
add_stress_test
branch
from
b4b1261
to
6d96bfc
Compare
We need to make a test that runs longer than the tests we had before to check some problems that might happen after running for some time (e.g. memory corruption or something else).
Follows up #2364 where we discussed that we might want to have a test which has really short thread function and creates many threads.
We need to make a test that runs longer than the tests we had before to check some problems that might happen after running for some time (e.g. memory corruption or something else).
Follows up bytecodealliance#2364 where we discussed that we might want to have a test which has really short thread function and creates many threads.
We need to make a test that runs longer than the tests we had before to check some problems that might happen after running for some time (e.g. memory corruption or something else)