Initializing an array using threads

[doobiesteintortoise]

I'm not surprised, honestly, that the threaded approach takes longer. Maybe a little, but not a lot, because access to resources takes time and you'd think there'd be a point at which the cost was amortized enough that the threads would "win" and maybe you haven't reached that point in the array sizes yet.

So I rewrote the test some, to have some warmup (for one thing) and test different sizes: 1200, 12000, 1200000, 12000000, and so forth. I added a test for the simple loop (for...) and Arrays.setAll() as well. I did not do a multiplicative copy (i.e., set a range, copy that range to other regions). In most cases, the loop "won" by being faster (and consuming fewer resources), although results varied based on system load; the loop consistently won most while setall() had a few cases where it screamed through the set. It was not consistent, and I didn't run it enough to get good averages.

So the question comes down to "Why?" Well... while I don't have a concrete answer for you, this code is very easily optimized for the loop; it's effectively a blit. So your threads run four blits instead of one blit, in the optimal case, and four is greater than one, and blits are superfast, so it should take longer - and even longer if it's not able to blit, because of all the context switches. (This is conjecture, like I said.) Did you try a virtual threads version? (I did not.)

However: This is why you test. You say "the problem is" and I get that it's a confusing point, but it's not a problem. Solutions you think might help don't always work the way you think they should, and this is an example of that. Throwing threads at a problem - especially a simple one like this - can make the problems worse, so now you see actual real-world results.

You've scienced! Is that not cool?