ejolson
Posts: 6645
Joined: Tue Mar 18, 2014 11:47 am

Re: A Pi Pie Chart

Fri Oct 30, 2020 7:09 pm

scruss wrote:
Wed Oct 28, 2020 2:21 am
gcc 4.7.2 didn't help, but an Armada 610 is not a fast processor at all.

Code: Select all

Prime Sieve          P=14630843 Workers=2 Sec=7.87456 Mops=118.652
Merge Sort           N=16777216 Workers=2 Sec=8.99944 Mops=44.742
Fourier Transform    N=4194304 Workers=1 Sec=15.5464 Mflops=29.6772
Lorenz 96            N=32768 K=16384 Workers=1 Sec=38.9505 Mflops=82.7006

The OLPC XO 1.75 has Raspberry Pi ratio=1.68703
Making pie charts...done.
From what I understand the production of the XO 1.75 started in 2012 around the same time as the first Raspberry Pi computers. It's interesting how similar was the processing power of the two machines, yet how different the design, marketing and resulting success. From a cost point of view a complete Pi setup may not have been much different, but the modular design with easily accessible GPIO filled a market niche for physical computing while the OLPC was essentially a toy laptop in a market already saturated with Chromebooks, Airbooks, Eeebooks and other types of netbooks.

At the same time, my experience is that physical computing projects require a constant source of funds to which many children may not access, whereas there is no financial limit on how much straight up programming a child can do in Scratch, Python and other languages. Even in this context, however, the modular design of the Pi is an advantage because old keyboards, mice and monitors can be recycled. Moreover, being able to swap out the SD card for one newly formatted and immediately start again is a very useful way to restore the system software after the last learning experience.

User avatar
scruss
Posts: 3852
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: A Pi Pie Chart

Fri Oct 30, 2020 9:20 pm

ejolson wrote:
Fri Oct 30, 2020 7:09 pm
… the OLPC was essentially a toy laptop
The OLPC as a concept was an utter disaster: an ego project for its founder, with shades of digital colonialism thrown in.

But the hardware is surprisingly solid. Sure, it's got a squishy keyboard meant for tiny fingers that's maddening to type on. The display is glorious: turn the backlight off and the greyscale transreflective screen is almost as crisp as e-paper, while still able to refresh quickly. I've never seen anything like it. The storage is replaceable. The battery will charge on anything > 11 V, and more importantly, can survive higher/inverted voltages being applied by accident.It's pretty much built like a tank, too.

It also uses the headphone jack and microphone socket in creative ways to read from simple sensors like thermistors, LDRs and switches. Hardly the flexibility of the GPIO connectors, but also won't fry your computer if you mess up. The system software has "activities" (Sugar's name for programs) built in to read sensors, log results and write up experiments in the user's journal.

Unlike Raspbian of the time, the XO 1.75 has (limited) hardware floating point support in Fedora/Sugar. The softfloat days on Raspberry Pi were no fun.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him

Heater
Posts: 17443
Joined: Tue Jul 17, 2012 3:02 pm

Re: A Pi Pie Chart

Fri Oct 30, 2020 10:53 pm

If only the OLPC had been available for purchase by everyone and anyone no matter who or where.

Then they might have got some money in to carry the thing forward.

Then they might have attracted a community or nerds, hackers and 'makers` to do all kind of interesting things with it, write endless blogs, tutorial and forum posts about it. Generally grow the idea.

But no. I remember being curious about that OLPC. As far as I could tell there was no way I could get my hands on one.

The Pi Foundation showed how it should be done.
Memory in C++ is a leaky abstraction .

User avatar
scruss
Posts: 3852
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: A Pi Pie Chart

Sat Nov 21, 2020 3:55 am

In yet another "Let's benchmark a pointless computer" outing for me, I present the Radxa Rock Pi X. It's an x86_64 SBC in a near-identical form factor to the Raspberry Pi. It's got an Intel Atom x5-Z8350 (Cherry Trail) CPU at 1.44GHz, 4 GB of LPDDR3 RAM , eMMC (your choice: mine has 64 GB), one USB3 port and all the expected bits and bobs.
pichart-RockPiX-OpenMP.png
Rock Pi X results
pichart-RockPiX-OpenMP.png (40.15 KiB) Viewed 411 times
These results from Ubuntu 20.10:

Code: Select all

pichart -- Raspberry Pi Performance OPENMP version 35

Prime Sieve          P=14630843 Workers=4 Sec=1.04637 Mops=892.923
Merge Sort           N=16777216 Workers=8 Sec=1.24162 Mops=324.295
Fourier Transform    N=4194304 Workers=8 Sec=2.11141 Mflops=218.514
Lorenz 96            N=32768 K=16384 Workers=4 Sec=1.43093 Mflops=2251.15

The Rock Pi X has Raspberry Pi ratio=17.2505
Making pie charts...done.

real    3m49.201s
user    7m12.244s
sys     0m1.919s
So, overall, it's slightly disappointing. Certainly proves that low-end Intel CPUs are handily outclassed by the Raspberry Pi 4.

The neat things about the Rock Pi X:
  • It's an Intel CPU on a board with a real BIOS. Yes, you could run Windows on it, or anything that runs x86
  • It has a real BIOS that can boot from lots of media
  • It has storage built in
  • It's passively cooled. The bottom of the case is a big metal heatsink
  • It's nicely made and the packaging is attractive.
The not-so-neat things:
  • It's not super fast
  • It's more expensive that a Raspberry Pi 4B
  • The optional BIOS battery is really not optional for reliable operation
  • AllNet seem a little random with shipping. A friend bought a few of these at the same time, and they were shipped with a couple of different heights of cases
  • It doesn't seem finished, or is like the early days of the Raspberry Pi. You have to manually download a wifi driver, copy the files to somewhere in /lib, then fix the wifi power so it doesn't fall off your network.
  • A suitable power adapter is really expensive. The Rock Pi X only accepts power from USB C PD sources, and a decent power supply for that is $20 or more. Radxa's own PSU is terrible: the pins are wobbly and don't reach the wall socket
In conclusion, I should have bought a Raspberry Pi 400.
Last edited by scruss on Mon Jan 11, 2021 3:46 pm, edited 1 time in total.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him

ejolson
Posts: 6645
Joined: Tue Mar 18, 2014 11:47 am

Re: A Pi Pie Chart

Sat Nov 21, 2020 5:55 pm

scruss wrote:
Sat Nov 21, 2020 3:55 am
In yet another "Let's benchmark a pointless computer" outing for me, I present the Radxa Rock Pi X. It's an x86_64 SBC in a near-identical form factor to the Raspberry Pi. It's got an Intel Atom x5-Z8350 (Cherry Trail) CPU at 1.44GHz, 4 GB of LPDDR3 RAM , eMMC (your choice: mine has 64 GB), one USB3 port and all the expected bits and bobs.
It seems astonishingly slow. What are you using for a heatsink? What happens if you hold it upside down with a fan blowing on the CPU? How about a stronger fan?

User avatar
scruss
Posts: 3852
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: A Pi Pie Chart

Sat Nov 21, 2020 10:27 pm

Hey, it's a 4+ year old low-end chip meant for cheap Windows tablets. It's barely even getting warm. The heatsink is this: a big chunk of metal with a milled section under the CPU and a thermal pad. It's the base of the standard Rock Pi X case.

The LPDDR3 won't be doing it any favours, but I'm not really expecting much faster.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him

ejolson
Posts: 6645
Joined: Tue Mar 18, 2014 11:47 am

Re: A Pi Pie Chart

Sun Feb 07, 2021 5:15 am

Some interesting runs of the Pi Pie Chart program for the M1 ARM-based Apple computer have been posted in the thread

viewtopic.php?p=1814072#p1814072

To quote from that thread, single-core results using the clang-based Apple compiler are
Heater wrote:

Code: Select all

$ ./pichart-serial ; # Compiled using the Apple Compiler
pichart -- Raspberry Pi Performance Serial version 35

Prime Sieve          P=14630843 Workers=1 Sec=1.18669 Mops=787.339
Merge Sort           N=16777216 Workers=2 Sec=1.52591 Mops=263.878
Fourier Transform    N=4194304 Workers=1 Sec=0.328173 Mflops=1405.89
Lorenz 96            N=32768 K=16384 Workers=2 Sec=0.199056 Mflops=16182.5

My Computer has Raspberry Pi ratio=41.4031
Making pie charts...done.
while the results for an 8-core parallel run obtained using gcc 10.2 are
Heater wrote:

Code: Select all

$ pichart-35 ./pichart-openmp -t "MacBook Pro M1" ; # Using gcc 10.2
pichart -- Raspberry Pi Performance OPENMP version 35

Prime Sieve          P=14630843 Workers=16 Sec=0.192798 Mops=4846.16
Merge Sort           N=16777216 Workers=16 Sec=0.266217 Mops=1512.5
Fourier Transform    N=4194304 Workers=16 Sec=0.0869724 Mflops=5304.83
Lorenz 96            N=32768 K=16384 Workers=16 Sec=0.0896742 Mflops=35921.4

The MacBook Pro M1 has Raspberry Pi ratio=171.661
Making pie charts...done.
To put this in perspective, I decided to rent an 8-core ARM based Graviton2 node on the Amazon EC2 cloud for US$ 0.2688 per hour. Fortunately, it took significantly less than an hour to make my Pi charts.

I launched the Amazon brand of Linux, which claimed to be optimized for the Graviton2 but otherwise similar to Red Hat Linux. The results I obtained were

Code: Select all

$ taskset -c 0 ./pichart-serial -t "Graviton2"
pichart -- Raspberry Pi Performance Serial version 36

Prime Sieve          P=14630843 Workers=2 Sec=1.26893 Mops=736.314
Merge Sort           N=16777216 Workers=2 Sec=2.01622 Mops=199.707
Fourier Transform    N=4194304 Workers=2 Sec=0.618462 Mflops=746.001
Lorenz 96            N=32768 K=16384 Workers=2 Sec=0.479058 Mflops=6724.08

The Graviton2 has Raspberry Pi ratio=26.0225
Making pie charts...done.
$ gcc --version
gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-12)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and

Code: Select all

$ ./pichart-openmp -t "Graviton2 (8 core)"
pichart -- Raspberry Pi Performance OPENMP version 36

Prime Sieve          P=14630843 Workers=8 Sec=0.161511 Mops=5784.91
Merge Sort           N=16777216 Workers=16 Sec=0.259438 Mops=1552.02
Fourier Transform    N=4194304 Workers=16 Sec=0.0828757 Mflops=5567.05
Lorenz 96            N=32768 K=16384 Workers=8 Sec=0.0865634 Mflops=37212.3

The Graviton2 (8 core) has Raspberry Pi ratio=184.404
Making pie charts...done.
Interestingly, the single-core speed of the Graviton2 was 38 percent slower than the M1 while the 8-core parallel benchmark was about 7 percent faster. Since the M1 results used different compilers for the serial and parallel tests, this reversal of performance advantage between serial and parallel could be due to differences in the compilers. On the other hand, since the Graviton2 is designed as a server, better parallel scaling could also be due to a higher bandwidth memory bus among other things.

To get a feel for how compilers make a difference, I used my Raspberry Pi to compile the Pi Pie Chart program in 32-bit mode with the -static flag using gcc version 10.1 and copied it over to the EC2 cloud. This resulted in

Code: Select all

$ ./pichart-serial ; # Statically compiled 32-bit binary on the Graviton2
pichart -- Raspberry Pi Performance Serial version 35

Prime Sieve          P=14630843 Workers=1 Sec=1.25911 Mops=742.057
Merge Sort           N=16777216 Workers=2 Sec=1.25237 Mops=321.512
Fourier Transform    N=4194304 Workers=2 Sec=0.536878 Mflops=859.363
Lorenz 96            N=32768 K=16384 Workers=1 Sec=0.83934 Mflops=3837.81

My Computer has Raspberry Pi ratio=26.4464
Making pie charts...done.
and

Code: Select all

$ ./pichart-openmp ; # Statically compiled 32-bit binary on the Graviton2
pichart -- Raspberry Pi Performance OPENMP version 35

Prime Sieve          P=14630843 Workers=8 Sec=0.160751 Mops=5812.27
Merge Sort           N=16777216 Workers=16 Sec=0.166754 Mops=2414.65
Fourier Transform    N=4194304 Workers=16 Sec=0.0757316 Mflops=6092.22
Lorenz 96            N=32768 K=16384 Workers=8 Sec=0.128949 Mflops=24980.7

My Computer has Raspberry Pi ratio=190.892
Making pie charts...done.
I would emphasize that the above two results were obtained using a 32-bit executable that was compiled and optimized for the Pi 4B with -mcpu=native and -mtune=native. The 32-bit executable ran faster in all categories except the Lorenz 96 dynamical simulation. My guess is that particular test vectorizes well on the 64-bit Neoverse architecture upon which the Graviton2 is based using instructions that aren't available on a Raspberry Pi.

Another point of comparison for the M1 would be an 8-core AMD processor such as the first-generation Ryzen desktop that's been sitting all alone in my office for a year while I shelter at home. That was, in fact, one of the first non-Pi computers which made it into the Pi charts.

viewtopic.php?p=1396281#p1396281

Fortunately, I can still log into that machine remotely. The updated results are

Code: Select all

$ taskset -c 2 ./pichart-serial ; # Ryzen 7 Pro 1700 (single core)
pichart -- Raspberry Pi Performance Serial version 36

Prime Sieve          P=14630843 Workers=1 Sec=0.854191 Mops=1093.82
Merge Sort           N=16777216 Workers=1 Sec=1.82074 Mops=221.148
Fourier Transform    N=4194304 Workers=2 Sec=0.670359 Mflops=688.248
Lorenz 96            N=32768 K=16384 Workers=1 Sec=0.220898 Mflops=14582.4

My Computer has Raspberry Pi ratio=35.0504
Making pie charts...done.
and

Code: Select all

$ ./pichart-openmp ; # Ryzen 7 Pro 1700 (8 cores)
pichart -- Raspberry Pi Performance OPENMP version 36

Prime Sieve          P=14630843 Workers=16 Sec=0.119876 Mops=7794.13
Merge Sort           N=16777216 Workers=32 Sec=0.171299 Mops=2350.59
Fourier Transform    N=4194304 Workers=16 Sec=0.153614 Mflops=3003.46
Lorenz 96            N=32768 K=16384 Workers=32 Sec=0.0595906 Mflops=54055.9

My Computer has Raspberry Pi ratio=207.369
Making pie charts...done.
As before, single-core performance of the M1 is faster while the parallel results in a relative sense are slower. I'm starting to think gcc just doesn't generate good executables for the M1.

Would the parallel Pi Pie Chart results look different for the M1 if a version of clang that supports OpenMP were used instead of gcc? Does gcc have some compiler options that would improve things?

User avatar
bensimmo
Posts: 5153
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: A Pi Pie Chart

Sun Feb 07, 2021 10:10 am

But what about the Pico?
It's all about the pico at the moment.

ejolson
Posts: 6645
Joined: Tue Mar 18, 2014 11:47 am

Re: A Pi Pie Chart

Sun Feb 07, 2021 5:22 pm

bensimmo wrote:
Sun Feb 07, 2021 10:10 am
But what about the Pico?
It's all about the pico at the moment.
That's a good question. Except for the Lorenz dynamical simulation, the other computations require about 200 MB of RAM each. I made a scaled version that runs on a 486 with 32 MB RAM in

viewtopic.php?p=1552972#p1552972

The Pico has only 0.264 MB, so the code will require additional changes, especially the test on sorting numbers.

The original computations were written as a set of tests to verify operation of my port of the Cilk parallel programming language to the Raspberry Pi. With only two cores, the recursive parallel algorithms used in the merge sort and Fourier transform tests should be simple enough to code by hand. The parallel loops in the prime sieve and Lorenz 96 dynamical simulation would be even easier.

Do you have a Pico to help with testing?

Return to “General discussion”