RPi 4 / STM32 / ESP32 / Teensy 4 / RISC-V GAZPACHO

[maginnovision]

Can you do sample and hold with peak detect?

[GeorgeOfTheJungle]

The best we could have done 41 years ago:

Code: [Select]

* = $1000
1000 CLRAN0 = C058
1000 SETAN0 = C059

1000        CLC             18
1001 LOOP   
1001        LDA SETAN0      AD 59 C0    //4 cycles
1004        LDA CLRAN0      AD 58 C0    //4 cycles
1007        BCC LOOP        90 F8       //3 cycles -> 11

1009 .END
done.
On an $666 Apple II @1MHz => 1/11e-6 = 90.9 kHz = 0.09 MHz. Today 2640x times better at 1/32th the price. 

[SiliconWizard]

The best we could have done 41 years ago:

Code: [Select]

* = $1000
1000 CLRAN0 = C058
1000 SETAN0 = C059

1000        CLC             18
1001 LOOP   
1001        LDA CLRAN0      AD 58 C0    //4 cycles
1004        LDA SETAN0      AD 59 C0    //4 cycles
1007        BCC LOOP        90 F8       //3 cycles -> 11

1009 .END
done.
On an $666 Apple II @1MHz => 1/11e-6 = 90.9 kHz. Today 2640x times better at 1/32th the price. 

Ahah, yes. I think we often don't even realize how "lucky" we are these days. Too bad that a lot of the extra performance is just wasted because we're lazy and it's become cheap.

[GeorgeOfTheJungle]

Ahah, yes. I think we often don't even realize how "lucky" we are these days. Too bad that a lot of the extra performance is just wasted because we're lazy and it's become cheap.

I've seen attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate... but I had never seen a pin bit banged @250 MHz !!

[SiliconWizard]

Blade Runner?

[Nominal Animal]

There's an interrupt that kicks in every 1ms.

That is the systick_isr interrupt that delay(), millis(), and micros() need.  If you don't use those three functions, and use the cycle counter instead, then you can disable the interrupt via SYST_CSR=0;. To re-enable, use SYST_CSR=SYST_CSR_TICKINT|SYST_CSR_ENABLE;.

[GeorgeOfTheJungle]

It would fit on an Apple ][ or C64 or Atari XL. But no one has C compilers for them. C compilers for Z80 suck but at least they exist. Anyone have a working Speccy or Amstrad CPC or something?

It'll probably take a week to run.

My Apple II is still operative :-) , not that I'm exactly willing to program that in 6502 assembly LOL. If the bit banging experiment result serves as indication (which it doesn't), it should take 43516*(150e6/90,9e3)/1e3/60/60= "only" 20 hours.

Millennials, take note: there are things that were much worse when we were young 

[GeorgeOfTheJungle]

There's an interrupt that kicks in every 1ms.

That is the systick_isr interrupt that delay(), millis(), and micros() need.  If you don't use those three functions, and use the cycle counter instead, then you can disable the interrupt via SYST_CSR=0;. To re-enable, use SYST_CSR=SYST_CSR_TICKINT|SYST_CSR_ENABLE;.

It only lasts 100 ns, but, good to know! Thanks.

[brucehoult]

It would fit on an Apple ][ or C64 or Atari XL. But no one has C compilers for them. C compilers for Z80 suck but at least they exist. Anyone have a working Speccy or Amstrad CPC or something?

It'll probably take a week to run.

My Apple II is still operative :-) , not that I'm exactly willing to program that in 6502 assembly LOL. If the bit banging experiment result serves as indication (which it doesn't), it should take 43516*(150e6/90,9e3)/1e3/60/60= "only" 20 hours.

I'd code it up for you to try.

But not today :-)

[techman-001]

Ahah, yes. I think we often don't even realize how "lucky" we are these days. Too bad that a lot of the extra performance is just wasted because we're lazy and it's become cheap.

I've seen attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate... but I had never seen a pin bit banged @250 MHz !!

Morons, they could make awesome artificial people, but used self oxidizing metals in their attack ships ... and what's with these "c-beams" don't people know that only "forth-beams" are approved for use in outer space ?

[brucehoult]

So, I tried my primes test on an ATmega2560. It was a bit hacky. It has 8192 bytes of SRAM. My code uses 8004 bytes of global variables if I change the "int"s to "long"s (which I have to because the numbers being used get as high as 62,710,561 but "int" means 16 bit on avr-gcc). That's tight. Too tight. The first compile says I need 8254 bytes for global variables. Knowing that AVR copies initialized constants from flash to RAM on start up I removed the printing of all the string literals. OMG. Now it's *exactly* 8192 bytes.

Code: [Select]

Global variables use 8192 bytes (100%) of dynamic memory, leaving 0 bytes for local variables. Maximum is 8192 bytes.
Low memory available, stability problems may occur.

Ugh. That means as soon as I run main() the stack will be overwriting some global variables. I don't know if it will be my own arrays and "nSieve" or some library's globals. Best case, maybe it's the end of a buffer used by Serial.

I try replacing "if (nSieve < SZ){" with 10 instead of SZ and run it. No drama! The correct answer is printed. I try 100 instead of 10. Still get the correct answer and no crash. OK . let's try the full thing overnight!

After 12249318 ms (3.4 hours) the correct number of primes, 3713160, is printed.

My apologies to whoever's globals my stack clobbered. But it worked. It wouldn't have worked if it was one of my arrays that got clobbered.

[brucehoult]

Zynq-7010 (Cortex A9) @ 650MHz:

Code: [Select]

$ gcc primes.c -o primes -O3
$ time ./primes
Starting run
3713160 primes found in 39728 ms
-396 bytes of code in countPrimes()

real    0m39.745s
user    0m39.723s
sys     0m0.011s
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
650000

i7-4700MQ @ 2.40GHz:

Code: [Select]

$ clang-7 primes.c -o primes -Ofast
$ time ./primes
Starting run
3713160 primes found in 4707 ms
256 bytes of code in countPrimes()

real 0m4.708s
user 0m4.708s
sys 0m0.000s
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
2400000
$ grep MHz /proc/cpuinfo
cpu MHz : 2394.522
cpu MHz : 2395.176
cpu MHz : 2394.455
cpu MHz : 2394.955
cpu MHz : 2394.427
cpu MHz : 2394.608
cpu MHz : 2394.432
cpu MHz : 2394.821


Hi, thanks for the data! The Zynq is especially interesting.

However, to keep things fair between different machines I'm only including results that use the same optimization level on everything, and that is -O1.

If you redo the test with -O1 then I'll include your results in my list.

Thanks!

[maginnovision]

So, I tried my primes test on an ATmega2560. It was a bit hacky. It has 8192 bytes of SRAM. My code uses 8004 bytes of global variables if I change the "int"s to "long"s (which I have to because the numbers being used get as high as 62,710,561 but "int" means 16 bit on avr-gcc). That's tight. Too tight. The first compile says I need 8254 bytes for global variables. Knowing that AVR copies initialized constants from flash to RAM on start up I removed the printing of all the string literals. OMG. Now it's *exactly* 8192 bytes.

Code: [Select]

Global variables use 8192 bytes (100%) of dynamic memory, leaving 0 bytes for local variables. Maximum is 8192 bytes.
Low memory available, stability problems may occur.

Ugh. That means as soon as I run main() the stack will be overwriting some global variables. I don't know if it will be my own arrays and "nSieve" or some library's globals. Best case, maybe it's the end of a buffer used by Serial.

I try replacing "if (nSieve < SZ){" with 10 instead of SZ and run it. No drama! The correct answer is printed. I try 100 instead of 10. Still get the correct answer and no crash. OK . let's try the full thing overnight!

After 12249318 ms (3.4 hours) the correct number of primes, 3713160, is printed.

My apologies to whoever's globals my stack clobbered. But it worked. It wouldn't have worked if it was one of my arrays that got clobbered.

Was this with printf? I just compiled and started running it on my board(20MHz) and it only ended up as 8082 bytes. I only use an LCD but I'm running the code now at -O1 and exactly as you originally wrote it.

Code: [Select]

Sketch uses 2832 bytes (1%) of program storage space. Maximum is 262144 bytes.
Global variables use 8082 bytes (12%) of dynamic memory, leaving 57453 bytes for local variables. Maximum is 65535 bytes.

[brucehoult]

That's using Serial.println(long) in an Arduino sketch. An attached LCD is probably ideal for minimal code. Or printing to the UART with minimal abstraction overhead in between, but I'm not set up for that at the moment..

[maginnovision]

Ah, alternatively I'm not set up for anything else. I don't have any 2560 boards with UARTs or USB connections. I'll post results when done, see if cycles(roughly) match up with yours.

[OwO]

i7-4700MQ @ 2.40GHz:

Scripted it this time. Also killed most background processes.

Code: [Select]

gcc -O1: 3713160 primes found in 5253 ms; 258 bytes of code in countPrimes()
gcc -O2: 3713160 primes found in 4806 ms; -400 bytes of code in countPrimes()
gcc -O3: 3713160 primes found in 4767 ms; -400 bytes of code in countPrimes()
gcc -Ofast: 3713160 primes found in 4832 ms; -432 bytes of code in countPrimes()
clang-7 -O1: 3713160 primes found in 4452 ms; 240 bytes of code in countPrimes()
clang-7 -O2: 3713160 primes found in 4434 ms; 256 bytes of code in countPrimes()
clang-7 -O3: 3713160 primes found in 4442 ms; 256 bytes of code in countPrimes()
clang-7 -Ofast: 3713160 primes found in 4429 ms; 256 bytes of code in countPrimes()

Zynq-7010 @ 650MHz:

Code: [Select]

gcc -O1: 3713160 primes found in 48206 ms; 248 bytes of code in countPrimes()
gcc -O2: 3713160 primes found in 39535 ms; -420 bytes of code in countPrimes()
gcc -O3: 3713160 primes found in 39536 ms; -420 bytes of code in countPrimes()
gcc -Ofast: 3713160 primes found in 39855 ms; -428 bytes of code in countPrimes()
clang-7 -O1: 3713160 primes found in 49687 ms; 232 bytes of code in countPrimes()
clang-7 -O2: 3713160 primes found in 45148 ms; 216 bytes of code in countPrimes()
clang-7 -O3: 3713160 primes found in 45152 ms; 216 bytes of code in countPrimes()
clang-7 -Ofast: 3713160 primes found in 45368 ms; 216 bytes of code in countPrimes()

Looks like gcc at O1 misses quite a few optimizations, but unfortunately clang on ARM seems broken because it can't match gcc even at -Ofast. gcc version is 8.3.0 on both systems.

Script:

Code: [Select]

#!/bin/bash

# warmup

echo "warmup..."
for i in {1..3}; do
gcc primes.c -o primes -O1 && ./primes 2>/dev/null
done

for CC in gcc clang-7; do
for OPTLEVEL in O1 O2 O3 Ofast; do
echo -n "$CC -$OPTLEVEL: "
$CC primes.c -o primes -"$OPTLEVEL" && ./primes 2>/dev/null
done;
done;

I would suggest maybe using a similar script like the above and then pick the fastest result for every platform, because the optimization levels probably don't translate well across platforms (there are CPU specific optimizations). You can see here that the gap between O1 and O2 is much wider on the Zynq than the i7. Maybe also even -march=native.

[maginnovision]

So, I tried my primes test on an ATmega2560. It was a bit hacky. It has 8192 bytes of SRAM. My code uses 8004 bytes of global variables if I change the "int"s to "long"s (which I have to because the numbers being used get as high as 62,710,561 but "int" means 16 bit on avr-gcc). That's tight. Too tight. The first compile says I need 8254 bytes for global variables. Knowing that AVR copies initialized constants from flash to RAM on start up I removed the printing of all the string literals. OMG. Now it's *exactly* 8192 bytes.

Code: [Select]

Global variables use 8192 bytes (100%) of dynamic memory, leaving 0 bytes for local variables. Maximum is 8192 bytes.
Low memory available, stability problems may occur.

Ugh. That means as soon as I run main() the stack will be overwriting some global variables. I don't know if it will be my own arrays and "nSieve" or some library's globals. Best case, maybe it's the end of a buffer used by Serial.

I try replacing "if (nSieve < SZ){" with 10 instead of SZ and run it. No drama! The correct answer is printed. I try 100 instead of 10. Still get the correct answer and no crash. OK . let's try the full thing overnight!

After 12249318 ms (3.4 hours) the correct number of primes, 3713160, is printed.

My apologies to whoever's globals my stack clobbered. But it worked. It wouldn't have worked if it was one of my arrays that got clobbered.

Here is my result with a 20MHz 2560 using exact code from your .txt. Only change was int to int32_t for
the arrays, nSieve, nPrimes, trial, and sqr. 3.73597588 hours, so adjusting SZ to some other number is definitely a shortcut.

[brucehoult]

I would suggest maybe using a similar script like the above and then pick the fastest result for every platform, because the optimization levels probably don't translate well across platforms (there are CPU specific optimizations). You can see here that the gap between O1 and O2 is much wider on the Zynq than the i7. Maybe also even -march=native.

I don't have access to most of those machines now, so changing the methodology would not make sense.

I've added your results. I've put the 4700MQ at its advertised 3.4 GHz turbo speed which places it a bit better than 3rd generation 3770 in clock cycles. 2.4 GHz would not make any sense.

[brucehoult]

After 12249318 ms (3.4 hours) the correct number of primes, 3713160, is printed.

Here is my result with a 20MHz 2560 using exact code from your .txt. Only change was int to int32_t for
the arrays, nSieve, nPrimes, trial, and sqr. 3.73597588 hours, so adjusting SZ to some other number is definitely a shortcut.

Wow interesting yours took 9.8% longer despite having 25% faster clock. Did you say that's on a 2560 with more RAM than standard, but slower?

You can't adjust SZ to some other value and get results that are in any way comparable. The execution time is I think something close to cubic in SZ. This test needs 8000 bytes plus a bit, or out of luck.

We have almost a 5000:1 speed range in the results! Should be near 6000:1 with a current generation x86 that turbos to 5.0 GHz.

[maginnovision]

After 12249318 ms (3.4 hours) the correct number of primes, 3713160, is printed.

Here is my result with a 20MHz 2560 using exact code from your .txt. Only change was int to int32_t for
the arrays, nSieve, nPrimes, trial, and sqr. 3.73597588 hours, so adjusting SZ to some other number is definitely a shortcut.

Wow interesting yours took 9.8% longer despite having 25% faster clock. Did you say that's on a 2560 with more RAM than standard, but slower?

You can't adjust SZ to some other value and get results that are in any way comparable. The execution time is I think something close to cubic in SZ. This test needs 8000 bytes plus a bit, or out of luck.

We have almost a 5000:1 speed range in the results! Should be near 6000:1 with a current generation x86 that turbos to 5.0 GHz.

Since the extended ram isn't used it'll be running full speed. Total RAM usage was reported as 8082 bytes.

[brucehoult]

Since the extended ram isn't used it'll be running full speed. Total RAM usage was reported as 8082 bytes.

Ahhh .. I see now the Arduino environment is running avr-gcc with -Os. No menu to change that and I can't be bothered to dig in the config files to change it right now. That's probably enough to do it.

I'll just take your result as the authoritative one then :-)

[maginnovision]

Since the extended ram isn't used it'll be running full speed. Total RAM usage was reported as 8082 bytes.

Ahhh .. I see now the Arduino environment is running avr-gcc with -Os. No menu to change that and I can't be bothered to dig in the config files to change it right now. That's probably enough to do it.

I'll just take your result as the authoritative one then :-)

I did change it to -O1. I'm re-running now without extended ram enabled just to make sure.

Also on my I7-7700K with stock clocks(4.2GHz):

Code: [Select]

Starting run
3713160 primes found in 2453ms
242 bytes of code in countPrimes()
EDIT: Updated after using WSL to recompile and run.

[GeorgeOfTheJungle]

Ahhh .. I see now the Arduino environment is running avr-gcc with -Os. No menu to change that and I can't be bothered to dig in the config files to change it right now. That's probably enough to do it.

Find and replace -Os in the file platform.txt

[brucehoult]

Since the extended ram isn't used it'll be running full speed. Total RAM usage was reported as 8082 bytes.

Ahhh .. I see now the Arduino environment is running avr-gcc with -Os. No menu to change that and I can't be bothered to dig in the config files to change it right now. That's probably enough to do it.

I'll just take your result as the authoritative one then :-)

I did change it to -O1. I'm re-running now without extended ram enabled just to make sure.

Yes, I know (or anyway assumed) you did. It's me that accidentally used -Os and whatever does that is buried deep in some script I don't want to find right now.

If you're re-running it, one thing you could change is it's ok for nSieve to be 16 bits. And i as well, but I think you left that one as "int"? It will help a little bit.

Poor little AVR. Though it'll thrash the heck out of 6502 or Z80 or VAX 780 or even probably 68000 or 286. 68020 and 386 would probably be a close-run thing against AVR :-)

[OwO]

The i7-4700MQ result was actually ran at 2.4GHz. Here is the result at 3.4GHz:

Code: [Select]

$ gcc primes.c -o primes -O1
$ time ./primes
Starting run
3713160 primes found in 3841 ms; 258 bytes of code in countPrimes()

real 0m3.848s
user 0m3.843s
sys 0m0.001s
$ time ./primes
Starting run
3713160 primes found in 3836 ms; 258 bytes of code in countPrimes()

real 0m3.843s
user 0m3.827s
sys 0m0.011s

That would put it at around 13 billion cycles.
But the full suite of tests is more difficult to run because it runs into thermal throttling issues.