Fix #33948 by decreasing number of tests per group

[echesakov]

Decrease MaxGroupSize to 100

Fixes: #33948

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[echesakov]

Let's see if 100 is small enough to allow runtime-coreclr gcstress-extra to pass without timing out

[echesakov]

No timeouts in gcstress-extra jobs.

@dotnet/jit-contrib @tannergooding PTAL

[tannergooding]

Is it potentially interesting that the group count is timing out on ARM while x86 has significantly more and doesn't?

[echesakov]

Is it potentially interesting that the group count is timing out on ARM while x86 has significantly more and doesn't?

You mean, that test groups under HardwareIntrinsics.X86 have the greater number of tests per group and still not timing out?

[tannergooding]

You mean, that test groups under HardwareIntrinsics.X86 have the greater number of tests per group and still not timing out?

Yes, they currently aren't split at all (outside where the default file names conflicted for 128-bit vs 256-bit variants)

AVX has 150, AVX2 has 250, SSE2 has 257

[echesakov]

@tannergooding There could be a dozen of potential reasons why this happens... For example, different performance characteristics of hardware we are using to run the tests, or the average load of these machines. It definitely wouldn't hurt to know - but I am not sure if such analysis should be done at the moment.

Ideally, I would like to have the partitioning of the tests done as in #40177 But as I described in that PR we would have to pay some price for such approach. I hope to re-visit this again in 6.0

[echesakov]

Can anyone sign off on the changes?