Optimize signum function (3-25x faster)

[simonvandel]

Which issue does this PR close?

Didn't create an issue beforehand.

Rationale for this change

Same idea as #12881. Using the unary functions allow faster processing (most likely auto-vectorized code) by avoiding branching on nulls.

What changes are included in this PR?

• Add bench
• Apply unary

Are these changes tested?

Yes, with existing tests.

Are there any user-facing changes?

Yes, faster signum:

signum f32 array: 1024  time:   [419.68 ns 420.68 ns 421.84 ns]
                        change: [-93.679% -93.655% -93.628%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 7 outliers among 100 measurements (7.00%)
  3 (3.00%) high mild
  4 (4.00%) high severe

signum f64 array: 1024  time:   [1.1809 µs 1.1822 µs 1.1835 µs]
                        change: [-81.672% -81.630% -81.593%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  4 (4.00%) high mild
  1 (1.00%) high severe

signum f32 array: 4096  time:   [1.1124 µs 1.1137 µs 1.1153 µs]
                        change: [-96.060% -96.049% -96.039%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  6 (6.00%) high mild
  2 (2.00%) high severe

signum f64 array: 4096  time:   [5.4527 µs 5.4624 µs 5.4725 µs]
                        change: [-80.223% -80.176% -80.125%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  4 (4.00%) high mild

signum f32 array: 8192  time:   [2.2937 µs 2.2959 µs 2.2983 µs]
                        change: [-96.218% -96.199% -96.181%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

signum f64 array: 8192  time:   [15.455 µs 15.534 µs 15.630 µs]
                        change: [-75.051% -74.722% -74.440%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  4 (4.00%) high mild
  1 (1.00%) high severe

[jonahgao]

LGTM👍

[findepi]

Are we going to remove all usages of make_function_scalar_inputs_return_type?

[simonvandel]

Are we going to remove all usages of make_function_scalar_inputs_return_type?

If the replacement always has same or better performance, I don't see why not

[findepi]

Makes sense to me!
If this is an already established knowledge that replacing make_function_scalar_inputs_return_type with unary is an improvement, I don't see a need to benchmark this every time separately. IMO we could just do this change everywhere where the code pattern is same.

[simonvandel]

I don't mind adding the benchmarks, since they

• are easy to add
• will benefit the next contributor wanting to try some optimizations
• motivate me by quantifying performance of the changes I make

[alamb]

🚀 looking very nice 👌

[alamb]

Are we going to remove all usages of make_function_scalar_inputs_return_type?

Perhaps it could be a nice ticket to file / project ti organize

[findepi]

Are we going to remove all usages of make_function_scalar_inputs_return_type?

Perhaps it could be a nice ticket to file / project ti organize

filed #12923