Tiny speed comparison. Pyra vs Raspberry Pi3 vs core2duo vs i7

[levi]

Real time does decrease on the Pi3 up to -j4, but really it's probably not statistically significant improvement past -j2 on everything but the i7. Perhaps the Pi is throttling when you try to use all four cores at the same time to compile something?

 

[Linux-SWAT]

No, on Linux the -j test is correlated to the number of cpus whatever the arch so there's something wrong here, maybe some task eating CPU in the background.

 

[D32_bobjob]

Or the memory bandwith is the limiting factor. A synthetic benchmark that runs in cache only should show different data. Askarus test is a compile run which may also add the SD-card speed as a limiting factor.

 

[WizardStan]

Maybe at 4 the bottleneck becomes the disk access so you don't see any improvement over 2?

 

[Askarus]

Don't forget the most likely case.
I did it wrong because I was running the test on 3 Machines simultaneously.
I might have done the same test twice. Be it 2 or 4.
I need to do it again,

 

[Hellfleck]

I had a look around for an easy method to compare cpu + memory speed only

openssl speed sha512

@Askarus could you run this on your machines please ?

sha512 because it is 64bit and hash functions typically are not accelerated in hardware because they need complexity / runtime to make cryptography expensive to crack with brute force (thats why ASICs which accelerate these in hardware for cryptocurrency mining outperform anything else by a wide margin)

this will only test one core but here are my results on what was available to test atm. all machines were mostly idle during testing - the last number for 8192 bytes is probably easiest to compare with

Laptop (Win10)
Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 44,088.08k 175,853.14k 304,696.49k 449,638.74k 524,825.94k

GPD Pocket (Win10)
Intel(R) Atom(TM) x7-z8750 CPU @ 1.60GHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 15,455.39k 62,050.37k 92,394.55k 127,678.73k 143,106.05k

systems without desktop:

Server #1
Intel(R) Xeon(R) CPU E5-2603 v4 @ 1.70GHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 25,806.16k 103,611.54k 181,265.83k 272,235.86k 317,393.58k

Server #2
Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 47,084.60k 193,835.67k 332,567.30k 504,517.97k 579,228.83k

Server #3
Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 48,028.79k 191,447.08k 297,108.39k 429,713.21k 474,374.14k

Server #4
Intel(R) Xeon(R) CPU E3-1246 v3 @ 3.50GHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 46,476.95k 190,498.47k 295,599.88k 427,985.92k 474,077.30k

Server #5
Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 46,472.21k 186,929.10k 282,717.61k 398,995.80k 457,583.27k

Raspberry Pi 1*
ARMv6-compatible processor rev 7 (v6l) / BCM2835 @ 700 MHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 1030.10k 4079.68k 6142.39k 8409.25k 9428.25k

Raspberry Pi 1 (older)*
ARMv6-compatible processor rev 7 (v6l) / BCM2708 @ 700 MHz
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 1067.99k 3652.71k 5982.93k 7389.08k 7959.94k

-----

Raspberry Pi 3 (did not test myself)
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 3538.26k 14,210.94k 20,680.53k 28,309.85k 31,741.27k


*first generation Raspberry Pis came with 32bit CPUs which means they stink at doing 64bit calculations for sha512

 

[ptitSeb]

Test on a Gigahertz Pandora
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha512 4340.57k 17505.59k 26927.27k 38109.98k 43114.50k

*EDIT* in case you ask: it's a custom-build version of openSSL, the one in the codeblocks PND:

OpenSSL 1.0.2l  25 May 2017
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM

 

[Silent-Hunter]

What are the numbers in those results? Those can't be seconds.

 

[Askarus]

@Askarus could you run this on your machines please ?

Raspberry

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
sha512 3424.35k 13992.60k 20574.72k 28158.29k 31683.04k 31828.65k
[doublepost=1519314950,1519314236][/doublepost]Pyra

OpenSSL 1.1.0f 25 May 2017
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
sha512 6669.16k 27120.98k 39731.72k 55575.87k 62649.30k 63358.80k
[doublepost=1519315017][/doublepost]I did recheck the Raspberry j2 and j4.

Same results

 

[ptitSeb]

So, according to this openssl bench, the Pandora is faster than RPi3 !

(I guess that's the difference between a custom build with specific flags and a generic build)

 

[Linux-SWAT]

So the SSL bench is probably not multithread, and as the RPi3 is 1,2 GHz, the A8 is better on this test than the A53.
Exophase has posted some comparisons:
https://pyra-handheld.com/boards/threads/snapdragon-soc-410e-and-600e.78238/page-2#post-1394493

The j4 is quite strange.
Here's a storage speed test:
dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync

--EDIT:
The load average (in top) may also be interesting to watch while compiling.

 

[Hellfleck]

What are the numbers in those results? Those can't be seconds.

those are in bytes (kilo bytes actually) processed per second - higher is better

and yes openssl speed runs single core only (else the xeons would have smoked my laptop easily)

another thing to consider would be when CPUs will go into speed throttling e.g. Intel CPUs tend to cheat by using dynamic overclocking for short time speed bursts while mobile CPUs will throttle down when they get hot so this might be an slightly unfair comparison

given these numbers I would say the Pyra will do very well for normal use and great on emulation

 

[Grench]

So the SSL bench is probably not multithread, and as the RPi3 is 1,2 GHz, the A8 is better on this test than the A53.
Exophase has posted some comparisons:
https://pyra-handheld.com/boards/threads/snapdragon-soc-410e-and-600e.78238/page-2#post-1394493

The j4 is quite strange.
Here's a storage speed test:
dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync

--EDIT:
The load average (in top) may also be interesting to watch while compiling.

Most of our applications are single threaded or single thread dominated. So, this methodology for processor comparison would still be valid despite being imperfect.

As to the storage speed test...
We need a Pyra specific GUI application that a user can simply launch, click -test all-, benchmark any mounted media and scan the media for identifiers (type, which slot/port, etc...), present the data to the user, allow the user to insert notes to each entry, then with user's explicit permission to do so, allow them to upload their annotated results to a common database.

It should benchmark and report on any available media in the eMMC, microSDXC, left SDXC, right SDXC, USB 3.0 OTG, left USB 2.0, right USB 2.0 and the eSATA port.

Why do we need that? In the early days of the Pandora, the Pandora's SD card slots were faster than the available media. A lot of what people used to get started were older cards. New cards were/are expensive and the inevitable questions came up of, which brand/card/model is best? Then a month later, what about now? This led to a series of forum posts, various attempts to collect them, confusion from overclocked/not, which port the card was in, conflicting results, etc. Having a common methodology and results collection point would be so much better.

Essentially, the media benchmarking program would be like a community scoreboard - that is something that has been discussed for various games too. Both are software writing to a database.

 

[kaprikawn]

It might be a good idea to stick a frontend on the Phoronix Test Suite with a few alterations to achieve that ^^

 

[oskda]

The competitors:
RasPi: Raspberry Pi 3
Pyra: Pyra clocked at 1GHz
core2Duo: Intel(R) Core(TM)2 Duo CPU @ 3.06GHz
i7: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GH

I think storage speed (including interface speed) is crucial in this test (compiling moves a lot of data). Of course there are other factors like main memory size and speed, caches size and speed, but storage is very different on those machines.

For example RPI3 uses a slow SD interface with somethink like ~20 MB/s. And USB isn't very good: On RPI3 there is only one USB port on SOC and to that port are connected a 4-port hub, 100 Mbps Ethernet card... all sharing one only USB 2.0.

Pyra has various storages inside, so it will vary depending the one you choose.

And of course Intel Core 2 Duo or i7 have much faster memory interfaces and storage interfaces. Even you can attach a very fast SSD to them.

PD: GPD Win 2 has a M.2 standard SSD, so it gets excellent storage speed (but I don't like a small fan in my pocket ).
[doublepost=1520079069,1520077647][/doublepost]

The GPD Win and Win2 are a lot faster than the Pyra, of course.

Then again, you can easily hear the fan of the GPD Win 2 10m away... My Parents asked my what that noise is when I was at home.

So it's either fast or silent.

Sent from my XT1650-03 using Tapatalk

I am very glad you finally decided not to use a fan inside Pyra, as sometime you were considering it (a very very small fan by the way).

On other side, it would be interesting to know if GPD Win 2 could be in "silent" mode, without fan being activated and related performance.

Since I have come back to "SILENCE COMPUTING", thanks to a Core-M in my convertible ultrabook-tablet (without fan), it is hard to me to back to heavier notebooks or desktops with its audible fans. This Core-M has worse performance, but it has a fast SSD, and silence, no fan, is a precious gift. I expect same silence from pocket size Pyra.

 

[Hồng Thất Công]

The GPD Win and Win2 are a lot faster than the Pyra, of course.

Then again, you can easily hear the fan of the GPD Win 2 10m away... My Parents asked my what that noise is when I was at home.

So it's either fast or silent.

Sent from my XT1650-03 using Tapatalk

When do you ship GPD Win 2?

 

[EvilDragon]

As soon as I receive them from GPD.

Sent from my XT1650-03 using Tapatalk

 

[klapse]

I had a look around for an easy method to compare cpu + memory speed only

sha512 because it is 64bit and hash functions typically are not accelerated in hardware because they need complexity / runtime to make cryptography expensive to crack with brute force (thats why ASICs which accelerate these in hardware for cryptocurrency mining outperform anything else by a wide margin)

How much of an 'unfair' performance hit do these create for the pi3 results (or are they using a 64-bit OS?)

 

[Hellfleck]

How much of an 'unfair' performance hit do these create for the pi3 results (or are they using a 64-bit OS?)

after looking into this, it seems that it is actually difficult to say ... perhaps a factor of 2x-3x ? (emulating 64bit operations on 32bit systems takes roughly 10x but not all operations are 64bit)

I initially thought that only the Raspberry Pi (one) was running a 32bit OS (as its a 32bit processor) but it seems even the RPi2 and RPi3 are still running the 32bit OS (even though they are 64bit processors) so the RPi Foundation only has to maintain one OS version (which makes a lot of sense)

 

[emphyrio]

I think storage speed (including interface speed) is crucial in this test (compiling moves a lot of data). Of course there are other factors like main memory size and speed, caches size and speed, but storage is very different on those machines.

For example RPI3 uses a slow SD interface with somethink like ~20 MB/s. And USB isn't very good: On RPI3 there is only one USB port on SOC and to that port are connected a 4-port hub, 100 Mbps Ethernet card... all sharing one only USB 2.0.

...

So, overclocking the sdcard reader speed (see: http://www.pidramble.com/wiki/benchmarks/microsd-cards ) should improve raspberrypi's performance (when using the right sdcard) in this test?