performance is not a key feature of arturo, isn't it?

[retsyo]

I met a stupid speed bench topic: in 0-N, how many numbers can be devided by 7? The code should use native LOOP statement only supplied by the language. On my PC, 41.09 seconds is used by Cpython 3.10.9.amd64. However, arturo takes 150 seconds!

I did not make more comparision with various tasks. In the stupid loop task, arturo behaves bad. So my question, may be biased, are

1. generally, whether arturo runs slowly or not?
2. any way to speed up arturo? of cause, I don't mean "you can just calculate int(N/7)+1 which is faster"

Thanks

python code

import time

def f(N):
    st = time.time()

    count = 0;
    for i in range(N):
        if (i % 7 == 0):
            count +=1;

    et = time.time()
    print(f'use {(et-st):.2f} secs, between 0-{N}, find {count}')


for i in range(1, 11):
    N = 10_0000_0000 * i
    f(N)

and arturo code

f: function [N][
    st:  now
    st: to :integer st

    i: 0
    count: 0
    loop 0 .. N 'i [
        if (i % 7) = 0 [
            count: count + 1
        ]
    ]

    et: now
    et: to :integer et

    print [ "use", (et - st), "seconds, in 0 -", N, ", find", count]
]

i: 0
loop 0 .. 9 'i [
    N: 1000000000 * (i + 1)
    f N
]

[RickBarretto]

That's a good question, @retsyo. Arturo isn't on its stable version yet, we did not reach v1.0 and the language still lacks a lot of fundamental features.
Performance is not the killer feature of Arturo. Sometimes it can be faster and sometimes it can be slower. We need to add more benchmarks and unit-tests to know more about the hot points of the language, trying to change what can be crucial here, and it takes times.

But, oh well! You know... A small team with a lot of work to be done. IMO, performance should not be the focus for now, we have more things to take care, like robustness and fundamental features, as modules and fix the UI lib and a lot of another broken things.

"Premature optimization is the root of all evil." - Knuth, D.

[RickBarretto]

And also, to properly know what is slowing down our code here, we must to test it with a profiler.

[drkameleon]

I've just found the time to properly investigate your message and I have to admit it has lead to some interesting conclusions.

TL;DR: apparently, I have to re-work some details regarding the Iterators module, as well as their implementation and performance.

Now, not that you're going to see any major performance breakthrough, but a few ideas:

• instead of having a variable and incrementing one by one, you can do that in-place. so, instead of count: count + 1, it would be 'count + 1 (that's faster)
• also, there is a faster way of performing the check-for-zero test. So, instead of (i % 7) = 0, you could do zero? i % 7
• regarding measuring the time a block of code takes, you can use Arturo's own benchmark function: https://arturo-lang.io/documentation/library/reflection/benchmark/
• also, for this type of things, a more suitable function (instead of loop and using that to increment a counter, and so on), would be to use enumerate; in your case, that could be count: enumerate 0..N 'x -> zero? x % 7 (just a one-liner 😉 )
• last but not least, functions that are meant to be called multiple times, if you don't care about variable "leaks" and want to go for performance, I'd suggest you mark them with .inline (it'll resemble more the process of actually inlining the whole function body)

As I said above, doing all this, you won't see any impressive performance gain (you will, but not as expected). So... food for thought for me to see how we can improve it even more. (admittedly, it appears that Nim's v2.0 hasn't helped either - since I have noticed some performance drop merely because of the transition, but there are also internal things in Arturo's codebase that could be better - I guess)

So... back to work!

Thanks for pointing it out! I'll definitely use this as a basis for testing and improving things! 🚀