glm.min and glm.max benchmark slower than python 3.11 min and max operating over glm.array[glm.c_float]

[cspotcode]

My benchmark was pretty informal, I used this hyperfine invocation:

> hyperfine --runs 5 --parameter-list impl pyglm,python 'python .\test-{impl}-min-max.py'

The two python scripts were this file, but with one of the two benchmarks uncommented in each:

import glm
from glm import min as glm_min

a = glm.array([glm.vec2(x, x + 1) for x in range(0, 10000, 2)])
a_x, a_y = a.split_components()

for i in range(99999):
    # PyGLM
    # glm_min(a_x)
    # glm_min(a_y)

    # Python
    min(a_x)
    min(a_y)

I got this output:

Benchmark 1: python .\test-pyglm-min-max.py
  Time (mean ± σ):     16.518 s ±  0.171 s    [User: 9.596 s, System: 0.023 s]
  Range (min … max):   16.370 s … 16.798 s    5 runs

Benchmark 2: python .\test-python-min-max.py
  Time (mean ± σ):     12.781 s ±  0.093 s    [User: 7.483 s, System: 0.023 s]
  Range (min … max):   12.705 s … 12.936 s    5 runs

Summary
  'python .\test-python-min-max.py' ran
    1.29 ± 0.02 times faster than 'python .\test-pyglm-min-max.py'

My first attempt used very small arrays. But I increased the array size a lot, and python min and max are still faster. I looked at #147, thinking maybe that slowed down min and max? But I'm not sure.

[Zuzu-Typ]

The reason why min and max are slow in this context is because both operations currently only support list, tuple and other iterable types. Therefore, glm.array is simply interpreted as an iterable. Because there is a slight overhead in the glm.min function compared to the builtin min function (or max-function respectively), the builtin function is faster.

To change this, a dedicated routine for arrays would be required.
I think it's a very good idea to have one.

[cspotcode]

If I wanted to add a dedicated routine, where would I start?

…

On Sun, Feb 26, 2023, 4:03 AM Zuzu-Typ ***@***.***> wrote: The reason why min and max are slow in this context is because both operations currently only support list, tuple and other iterable types. Therefore, glm.array is simply interpreted as an iterable. Because there is a slight overhead in the glm.min function compared to the builtin min function (or max-function respectively), the builtin function is faster. To change this, a dedicated routine for arrays would be required. I think it's a very good idea to have one. — Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35ODPQQLJH4DIJ6O27X3WZML73ANCNFSM6AAAAAAVHLLFPY> . You are receiving this because you authored the thread.Message ID: ***@***.***>