I got a Raspberry Pi 2 B (RPI2), and it’s a lot of fun. Gambit from Github runs out of the box with the compiler that’s shipped with Raspbian (the RPI version of Debian).
I was trying out some options to see how to best take advantage of the hardware. The numbers follow my sig.
Brad
I have a simple test:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc -march=armv7-a -mfpu=vfpv4 -mhard-float' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 494 ms real time 490 ms cpu time (490 user, 0 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 522 ms real time 530 ms cpu time (520 user, 10 system) 2 collections accounting for 4 ms real time (10 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
You can install gcc-4.8, but then it runs out of memory compiling _t-univ.c, so I reconfigured Gambit to not include _t-univ.*, and got the following results:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 430 ms real time 430 ms cpu time (420 user, 10 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 453 ms real time 450 ms cpu time (440 user, 10 system) 2 collections accounting for 3 ms real time (0 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
And on an experiment in spectral identification that mainly does F64 inner products, I get with the default build
(time (run-experiment-and-graph 5)) 785617 ms real time 785590 ms cpu time (785040 user, 550 system) 33 collections accounting for 442 ms real time (350 user, 80 system) 3216061748 bytes allocated 30338 minor faults no major faults
and with the gcc-4.8 build I get
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 739829 ms real time 739790 ms cpu time (739620 user, 170 system) 33 collections accounting for 292 ms real time (310 user, 0 system) 3216060588 bytes allocated 17663 minor faults no major faults
On my Intel Core i7 with
firefly:~> gsi -v v4.7.4 20150228031125 x86_64-unknown-linux-gnu "./configure '--enable-single-host' '--enable-shared' '--enable-multiple-versions’”
I get
firefly:~> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 19 ms real time 19 ms cpu time (19 user, 0 system) 2 collections accounting for 0 ms real time (0 user, 0 system) 9133952 bytes allocated 2154 minor faults no major faults (time (* a a)) 20 ms real time 20 ms cpu time (20 user, 0 system) 2 collections accounting for 0 ms real time (0 user, 0 system) 8817984 bytes allocated 1637 minor faults no major faults
and
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 50700 ms real time 50709 ms cpu time (50630 user, 79 system) 39 collections accounting for 66 ms real time (60 user, 8 system) 3754964264 bytes allocated 74006 minor faults no major faults
I thought I should be able to get things to run faster on the RPI2, but I don’t know what the gcc options should be. Maybe 32-bit versus 64-bit is the big difference.
cat /proc/cpuinfo says
processor : 3 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5
Hardware : BCM2709 Revision : a21041 Serial : 00000000c222f2d2
and
processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz stepping : 3 microcode : 0x7 cpu MHz : 3497.750 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm bogomips : 6784.67 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:
Afficher les réponses par date
More numbers:
On Mar 9, 2015, at 3:52 PM, Bradley Lucier lucier@math.purdue.edu wrote:
I got a Raspberry Pi 2 B (RPI2), and it’s a lot of fun. Gambit from Github runs out of the box with the compiler that’s shipped with Raspbian (the RPI version of Debian).
I was trying out some options to see how to best take advantage of the hardware. The numbers follow my sig.
Brad
I have a simple test:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc -march=armv7-a -mfpu=vfpv4 -mhard-float' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 494 ms real time 490 ms cpu time (490 user, 0 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 522 ms real time 530 ms cpu time (520 user, 10 system) 2 collections accounting for 4 ms real time (10 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
You can install gcc-4.8, but then it runs out of memory compiling _t-univ.c, so I reconfigured Gambit to not include _t-univ.*, and got the following results:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 430 ms real time 430 ms cpu time (420 user, 10 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 453 ms real time 450 ms cpu time (440 user, 10 system) 2 collections accounting for 3 ms real time (0 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
Changing -fno-strict-aliasing to -fstrict-aliasing by hand gives an even better result:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 395 ms real time 390 ms cpu time (370 user, 20 system) 7 collections accounting for 12 ms real time (0 user, 0 system) 9166544 bytes allocated 2000 minor faults no major faults (time (* a a)) 405 ms real time 400 ms cpu time (400 user, 0 system) 2 collections accounting for 5 ms real time (0 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
This may introduce impossible to debug errors, but I don’t think gcc’s aliasing analysis is yet smart enough to figure out how to do that.
And on an experiment in spectral identification that mainly does F64 inner products, I get with the default build
(time (run-experiment-and-graph 5)) 785617 ms real time 785590 ms cpu time (785040 user, 550 system) 33 collections accounting for 442 ms real time (350 user, 80 system) 3216061748 bytes allocated 30338 minor faults no major faults
and with the gcc-4.8 build I get
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 739829 ms real time 739790 ms cpu time (739620 user, 170 system) 33 collections accounting for 292 ms real time (310 user, 0 system) 3216060588 bytes allocated 17663 minor faults no major faults
using -fstrict-aliasing didn’t help the spectral identification code much:
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 733849 ms real time 733750 ms cpu time (733330 user, 420 system) 33 collections accounting for 219 ms real time (210 user, 0 system) 3216086556 bytes allocated 16938 minor faults no major faults
And on an experiment in spectral identification that mainly does F64
inner products, I get with the default build
(time (run-experiment-and-graph 5)) 785617 ms real time 785590 ms cpu time (785040 user, 550 system) 33 collections accounting for 442 ms real time (350 user, 80 system) 3216061748 bytes allocated 30338 minor faults no major faults
and with the gcc-4.8 build I get
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 739829 ms real time 739790 ms cpu time (739620 user, 170 system) 33 collections accounting for 292 ms real time (310 user, 0 system) 3216060588 bytes allocated 17663 minor faults no major faults
using -fstrict-aliasing didn’t help the spectral identification code much:
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 733849 ms real time 733750 ms cpu time (733330 user, 420 system) 33 collections accounting for 219 ms real time (210 user, 0 system) 3216086556 bytes allocated 16938 minor faults no major faults
Awesome project! Raspberry Pi is truly a wonderful machine. Thank you for posting your results. Since I don't have a reference performance, is this 20x difference expected or more than expected? Based on other tests with very different environments on mobile ARM, I would say that it should be on the 10x-50x ballpark.
On Mar 10, 2015, at 5:53 AM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Awesome project! Raspberry Pi is truly a wonderful machine. Thank you for posting your results. Since I don't have a reference performance, is this 20x difference expected or more than expected? Based on other tests with very different environments on mobile ARM, I would say that it should be on the 10x-50x ballpark.
The difference in bogomips is about 20x, so I think the 20x difference in execution time is expected.
Marc
On Mar 10, 2015, at 7:34 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
On Mar 10, 2015, at 5:53 AM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Awesome project! Raspberry Pi is truly a wonderful machine. Thank you for posting your results. Since I don't have a reference performance, is this 20x difference expected or more than expected? Based on other tests with very different environments on mobile ARM, I would say that it should be on the 10x-50x ballpark.
The difference in bogomips is about 20x, so I think the 20x difference in execution time is expected.
Marc
On my 5th generation iPod Touch, which also uses an Arm CPU, (expt 3 1000000) takes 429ms and then squaring that takes 440ms.
Which is almost exactly the same as on the Pi times when using gcc-4.8 with the good hardware specifications but keeping -fno-strict-aliasing.
Brad
Wow! I was planning to do the same experiment. To control the lights and energy in my home I use Gambit running on a Mac mini but I was planning to replace this with a RaspberryPi. I will! Thank you for sharing. Francois Magnan
On Mar 9, 2015, at 6:05 PM, Bradley Lucier lucier@math.purdue.edu wrote:
More numbers:
On Mar 9, 2015, at 3:52 PM, Bradley Lucier lucier@math.purdue.edu wrote:
I got a Raspberry Pi 2 B (RPI2), and it’s a lot of fun. Gambit from Github runs out of the box with the compiler that’s shipped with Raspbian (the RPI version of Debian).
I was trying out some options to see how to best take advantage of the hardware. The numbers follow my sig.
Brad
I have a simple test:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc -march=armv7-a -mfpu=vfpv4 -mhard-float' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 494 ms real time 490 ms cpu time (490 user, 0 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 522 ms real time 530 ms cpu time (520 user, 10 system) 2 collections accounting for 4 ms real time (10 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
You can install gcc-4.8, but then it runs out of memory compiling _t-univ.c, so I reconfigured Gambit to not include _t-univ.*, and got the following results:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 430 ms real time 430 ms cpu time (420 user, 10 system) 7 collections accounting for 8 ms real time (10 user, 0 system) 9166544 bytes allocated 2001 minor faults no major faults (time (* a a)) 453 ms real time 450 ms cpu time (440 user, 10 system) 2 collections accounting for 3 ms real time (0 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
Changing -fno-strict-aliasing to -fstrict-aliasing by hand gives an even better result:
cutie-pi:~/programs/gambit> gsi -v v4.7.4 20150228031125 armv7l-unknown-linux-gnueabihf "./configure 'CC=gcc-4.8 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' '--enable-single-host' '--enable-shared' '--enable-multiple-versions'" cutie-pi:~/programs/gambit> gsi -e '(define a (time (expt 3 1000000)))(define b (time (* a a)))' (time (expt 3 1000000)) 395 ms real time 390 ms cpu time (370 user, 20 system) 7 collections accounting for 12 ms real time (0 user, 0 system) 9166544 bytes allocated 2000 minor faults no major faults (time (* a a)) 405 ms real time 400 ms cpu time (400 user, 0 system) 2 collections accounting for 5 ms real time (0 user, 0 system) 8817880 bytes allocated 2067 minor faults no major faults
This may introduce impossible to debug errors, but I don’t think gcc’s aliasing analysis is yet smart enough to figure out how to do that.
And on an experiment in spectral identification that mainly does F64 inner products, I get with the default build
(time (run-experiment-and-graph 5)) 785617 ms real time 785590 ms cpu time (785040 user, 550 system) 33 collections accounting for 442 ms real time (350 user, 80 system) 3216061748 bytes allocated 30338 minor faults no major faults
and with the gcc-4.8 build I get
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 739829 ms real time 739790 ms cpu time (739620 user, 170 system) 33 collections accounting for 292 ms real time (310 user, 0 system) 3216060588 bytes allocated 17663 minor faults no major faults
using -fstrict-aliasing didn’t help the spectral identification code much:
(time (run-experiment-and-graph 5))
(time (run-experiment-and-graph 5)) 733849 ms real time 733750 ms cpu time (733330 user, 420 system) 33 collections accounting for 219 ms real time (210 user, 0 system) 3216086556 bytes allocated 16938 minor faults no major faults
Gambit-list mailing list Gambit-list@iro.umontreal.ca mailto:Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list