Fix performance regression in reductions benchmark

[jeremiah-corrado]

Fix a performance regression caused by recent refactoring of ReductionMsg.

The refactor made total reductions (i.e., reducing an array to a single scalar value) return that scalar value via a 1-element array. This resulted in much cleaner code, but also added overhead for the total-reduction case. This PR separates total reductions into separate commands s.t. they can return a scalar directly.

Also fixes a bug in register_commands.py, where any unrecognized return type was being treated as a symbol-table entry.

[ajpotts]

It looks like the benchmark is failing b/c prod does not handle overflow. numpy seems to set the overflow result to 0.

I get this print statement from the failing case in ./benchmarks/reduce.py --correctness-only localhost 5555

op
prod

npa
[   1    2    3 ... 9997 9998 9999]

random
False

dtype
int64

SEED
None

npr
0

akr
-9223372036854775808

np.isclose(npr, akr)
False
Traceback (most recent call last):
  File "/home/amandapotts/git/arkouda/./benchmarks/reduce.py", line 176, in <module>
    check_correctness(dtype, args.randomize, args.seed)
  File "/home/amandapotts/git/arkouda/./benchmarks/reduce.py", line 123, in check_correctness
    assert np.isclose(npr, akr)
           ^^^^^^^^^^^^^^^^^^^^
AssertionError


``

[jeremiah-corrado]

Thanks for pointing that out! I'll see if I can fix it.

[jeremiah-corrado]

I'm seeing the following performance for the reduce benchmark (on the same system where the linked graph is generated):

numLocales = 16, N = 1,600,000,000
sum = 1279999999200000000
  sum Average time = 0.0070 sec
  sum Average rate = 1696.42 GiB/sec
prod = 0
  prod Average time = 0.0069 sec
  prod Average rate = 1722.76 GiB/sec
min = 1
  min Average time = 0.0068 sec
  min Average rate = 1748.09 GiB/sec
max = 1599999999
  max Average time = 0.0067 sec
  max Average rate = 1775.76 GiB/sec

This is around 10% lower than the results we've seen historically, which could be attributed to a difference in system configuration or something, but could also indicate that there are some other (more minor) performance fixes needed. I'd propose we merge this PR and see how the nightly performance testing graph responds before looking into this further.

[stress-tess]

looks good to me!

[ajpotts]

Thanks for doing this!