With this script is my arduino Nano faster. Why ?

[Dj-EKI]

I have now written a lot of scripts in Python and notice that my pico is getting slower and slower. Then I tried simple scripts. What the Arduino Nano can do in microseconds, the Pico does in 250,000 microseconds!??? Whats going on here? the cpu freq is running at 125000000.

This is Python with 250000 microseconds:

import time

t = 0
e = 0
rgb = [0,0,0]
Time2 = 0
hex1 = 0xF0
hex = 0x0
test = 0
t = 0

def convert():
    rgb[0] = (int((hex1 >> 8) & 0xFF))
    rgb[1] = (int((hex1 >> 3) & 0xFF))
    rgb[2] = (int((hex1 << 3) & 0xFF))
        
def ConvertToRGB(hextext):
    rgb = []
    rgb.append(int((hextext >> 8) & 0xFF))
    rgb.append(int((hextext >> 3) & 0xFF))
    rgb.append(int((hextext << 3) & 0xFF))
    return rgb

if __name__=='__main__':
    
    while(True):
        
        Time2 = time.ticks_cpu()
        for i in range(2500):
            i=i
            convert()
            #ConvertToRGB(0xF0)
            test = t
        
        print(time.ticks_diff(time.ticks_cpu(),Time2))
        print(rgb)

This is Arduino Nano:

void convert(){
    rgb[0] = (((hex1 >> 8) & 0xFF));
    rgb[1] = (((hex1 >> 3) & 0xFF));
    rgb[2] = (((hex1 << 3) & 0xFF));
}


void loop() {
  Time1 = millis();
  for (int i=0; i<2500; i++){
    convert();
  }
  Serial.println(millis()-Time1);
  Serial.println(rgb[1]);
  Serial.println(millis());

[robert-hh]

You did not show the result for Arduino. And you did not show all of the Arduino code. Compilers can do a lot of optimization, when variables are statically declared, which interpreters like Python cannot do. If the result is really in the µs range (<< 1 ms), then the compiler may have eliminated the loop. You may also try making in the Arduino code hex1 an argument of convert().
Skipping the int() in convert() and making hex1 an argument of the function convert brings it down to ~84 ms. And no change in execution time over looping.

[Dj-EKI]

Then I see no reason to continue working with Pico if Pico is so slow. I just found the Pico Board in Arduino and will try it.
I assume you mean 84 microseconds on Arduino Nano. On the Pico it's 250 milliseconds. That's a big difference.
Maybe I'm thinking wrong with Python. Because when I work with functions, everything is slower than when I write the code directly in the script.

[robert-hh]

The time with the Python script on the Pico is 74 ms after more optimization. What was the time you got on the Arduino Nano (which one)? You did not tell. You just said microseconds.
Running code from REPL like e.g. Thonny does or after importing it makes a big difference.
Besides that, it is to be expected that interpreted code is slower than compiled code. The advantage comes when complex operations are run. Below is the slimmed down code I used, similar to the assumed Arduino code. You could try to change the Arduino code by making hex1 the argument of the convert() function and vary the value in each loop iteration. That makes it more reasonable.

import time

def convert(rgb, hex1):
    rgb[0] = (hex1 >> 8) & 0xFF
    rgb[1] = (hex1 >> 3) & 0xFF
    rgb[2] = (hex1 << 3) & 0xFF

def run():
    while(True):
        rgb = [0,0,0]
        Time2 = time.ticks_cpu()
        for i in range(2500):
            convert(rgb, i & 0xff)

        print(time.ticks_diff(time.ticks_cpu(),Time2))
        print(rgb)

[Dj-EKI]

ok, your code is much better than what i could make. Do you think there is a faster way?
I just tried Arduino IDE with Pico and used the same code that is on Arduino Nano. Serial.println(millis()-Time1); shows me 0. That means it's under a millisecond. So it's faster. Unfortunately, I have already written a lot in python. I think I'll try Arduino.

[robert-hh]

I made your Arduino code to something reasonable and have put it on a Arduino Nano. It shows 24ms execution time. The issue with your test: both hex1 and rgb are static. So the optimizer in the compiler decides that it does not have to call convert 2500 times and eliminates the for (...) loop. Making hex1 an argument of the convert() function prevents this "optimization".

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
}

unsigned char rgb[3];

void convert(unsigned char hex1){
    rgb[0] = (((hex1 >> 8) & 0xFF));
    rgb[1] = (((hex1 >> 3) & 0xFF));
    rgb[2] = (((hex1 << 3) & 0xFF));
}

void loop() {
  int Time1;
  Time1 = millis();
  for (int i=0; i<2500; i++){
    convert(i & 0xff);
  }
  Serial.println(millis()-Time1);
  Serial.println(rgb[1]);
  delay(1000);
}

[Dj-EKI]

The 24 is from the rgb as a result. You should also have a zero.

[robert-hh]

There is a chapter in the documentation about Optimization: https://docs.micropython.org/en/latest/reference/speed_python.html
And there was a talk by Damien about optimizing Python code: https://2018.pycon-au.org/talks/45358-writing-fast-and-efficient-micropython/

[Dj-EKI]

Thanks, the video confirmed my research. I won't start here in assembler :) But I've gotten a little smarter about how I could possibly improve my script in Python.

[robert-hh]

You were right. The code was still zero optimized by the compiler. Another way to make it reasonable, telling the compiler not to assume that rgb and hex1 will keep their values between calls. Note that with Python even the type of variables can change.

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
}

volatile unsigned char rgb[3];
volatile unsigned char hex1;

void convert(){
    rgb[0] = (((hex1 >> 8) & 0xFF));
    rgb[1] = (((hex1 >> 3) & 0xFF));
    rgb[2] = (((hex1 << 3) & 0xFF));
}


void loop() {
  unsigned long Time1;
  Time1 = millis();
  for (int i=0; i<2500; i++){
    convert();
  }
  Serial.println(millis()-Time1);
  // Serial.println(rgb[1]);
  delay(1000);
}

[Dj-EKI]

ok i see it Arduino is just too clever ^^
And very fast.
I'm trying to rewrite my Python script and will then decide whether to switch to Arduino.

[robert-hh]

ok i see it Arduino is just too clever ^^

That's what modern compilers do. Arduino just uses the AVR compiler. To be sure, I looked at the generated assembly code, which shows, that without the volatile no code is generated for the convert function and the loop. Still, in that example the C code looks about 100 times more efficient that the Python code. That's more than I expected. My usual rule of thumb would be a factor of 10.