External Issue: Tasks assigned in standalone forall loop when number of tasks is more than probSize (in the code attached) is highly biased, since only one task gets assigned with full problem set and the rest of the tasks do not get anything assigned to

16795, “rchinmay”, “Tasks assigned in standalone forall loop when number of tasks is more than probSize (in the code attached) is highly biased, since only one task gets assigned with full problem set and the rest of the tasks do not get anything assigned to them.”, “2020-11-30T09:10:38Z”

Summary of Problem

In the Parallel iterators primers, the example of count iterator using standalone approach are explained. I was trying some variants of the code given in that section. I fixed numTasks=4 which was equal to here.maxTaskPar value, and then tried different values of probSize. It works very well for probSize>=numTasks. For example when numTasks=4 and probSize=15, then the output on my device looks like:
In count() standalone, creating 4 tasks
task 3 owns 10…15
task 0 owns 1…3
task 1 owns 4…6
task 2 owns 7…9
But when numTasks>probSize, then only one task gets assigned with full probSize and the rest of the tasks do not get anything assigned. I do not feel this is the right way. I know that some of the tasks created can go empty, but others tasks should own problem size of 1. For example, when numTasks=4 and probSIze=3, the output on my device looks like:
In count() standalone, creating 4 tasks
task 3 owns 1…3
task 0 owns 1…0
task 2 owns 1…0
Also, when numTasks=10 and probSize=5, by compiling using the command $chpl Chapel_Program.chpl -snumTasks=10 -sprobSize=5, then the output looks like:
In count() standalone, creating 10 tasks
task 1 owns 1…0
task 0 owns 1…0
task 9 owns 1…5
task 2 owns 1…0
task 4 owns 1…0
task 6 owns 1…0
task 3 owns 1…0
task 7 owns 1…0
task 8 owns 1…0
I feel the best way is to give (numTasks-probSize) tasks as empty and the rest each owning 1 problem of the probSize. But if my opinions and suggestions are wrong, then please inform me.

Steps to Reproduce:

I used chpl version 1.22.0, and have not shifted to chpl version 1.23 yet. If this does not produce such behaviour in the newer versions, then it is not a problem.
** Source Code **
Chapel_Program.txt

** Compilation Command **
chpl Chapel_Program.chpl

** Execution Command **
./Chapel_Program

###Configuration Information:
Output of chpl --version: chpl version 1.22.0
Copyright 2020 Hewlett Packard Enterprise Development LP
Copyright 2004-2019 Cray Inc.
(See LICENSE file for more details)

Output of $CHPL_HOME/util/printchplenv --anonymize:
CHPL_TARGET_PLATFORM: linux64
CHPL_TARGET_COMPILER: gnu
CHPL_TARGET_ARCH: x86_64
CHPL_TARGET_CPU: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none *
CHPL_TASKS: fifo *
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: cstdlib *
CHPL_ATOMICS: cstdlib
CHPL_GMP: none *
CHPL_HWLOC: none
CHPL_REGEXP: none *
CHPL_LLVM: none *
CHPL_AUX_FILESYS: none

Back-end compiler and version, e.g. gcc --version:
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright © 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.