The results (if you want to run your own tests) and keys are from hardinfo - or in my case the GUI version “System profiler and Benchmark”.
CPU Blowfish: lower number is better
CPU Cryptohash: higher
CPU Fibonacci: lower
CPU N-Queens: lower
CPU Zlib: higher
FPU FFT: lower
FPU: Raytracing: lower
Also, at the end of @dylanlesterpvcs data (and the GUI) there are reference results to compare also (although a bit older CPUs but still).
If anyone has a PinePhone, can you please run the hardinfo -r command on it?
I asked on the PinePhone forum, but the results in Ubuntu Touch don’t make sense, so I would like to see the results from other distros.
The guy on the PinePhone forum re-ran hardinfo in Mobian Nightly using a recent version of hardinfo, and now the results seem reasonable. Here are the results:
| Benchmark | Thinkpad T450s (4x 2.7GHz Core i5-5200U) | Librem 5 (4x 1.5GHz Cortex-A53) | PinePhone (4x 1.152GHz Cortex-A53) | i5 vs L5 % difference | L5 vs PP % difference |
|---|---|---|---|---|---|
| CPU Blowfish | 4.94 | 8.81 | 12.58 | 78% | 43% |
| CPU CryptoHash | 432.63 | 105.57 | 104.85 | 310% | 1% |
| CPU Fibonacci | 0.82 | 3.36 | 3.36 | 310% | 0% |
| CPU N-Queens | 7.01 | 5.31 | 10.27 | -24% | 93% |
| CPU Zlib | 0.47 | 0.18 | 0.12 | 161% | 50% |
| FPU FFT | 2.10 | 9.86 | 17.81 | 370% | 81% |
| FPU Raytracing | 2.10 | 5.08 | 9.80 | 142% | 93% |
Based on the 30% difference in clock speed between the Librem 5 and PinePhone, and the much faster RAM in the Librem 5 (LPDDR4-3200 vs LPDDR3-1264), I expected a 40%-50% difference in performance, which is what we see in Blowfish and Zlib, but everything else surprised me.
For CryptoHash and Fibonacci, the Librem 5 and PinePhone were the same. For some reason, the i.MX 8M Quad is really good at N-Queens–even better than a fifth-gen Core i5.
It isn’t clear to me whether the floating point benchmarks are being run in the CPU or the GPU. I expect that the Vivante GC7000Lite in the Librem 5 will have twice the graphics performance of the Mali-400 MP2 in the PinePhone. @dos’s gaming tests (1 2 3) showed a big difference in the GPU performance. I wish that we had some more GPU benchmarks to compare the two phones.
I placed my order back in Nov. Any idea when I’ll receive my librem 5?
I’m in the EU.
I think it would be about time for another betting pool on that… [edit: What do we use in stead of Brexit? 
]
@Kyle_Rankin indicated that “mid-to-late” November would be the start for shipping them. In general there were some previous assumptions made about possible challenges by @amosbatto, which may or may not be relevant. (Btw. those would be better threads for this question at the moment)
For an individual (pre)order, @antpanlinux made a nice approximation on how fast they can be assembled, so it could be made into a formula which includes your number in queue and how many people are assembling the phones. Plus the shipping and such delays.
November does not unfortunately mean you are near the front of the queue, if this thread is to be believed.
@amosbatto I’ve ran some benchmarks (hardinfo and glmark2) on my Librem 5 Dogwood and PinePhone Breaveheart: https://dosowisko.net/bench/
I have mostly removed the section about network (nothing interesting there, just some info about my LAN :P) and disabled terrain test in glmark2, since it makes the whole process hang on the PinePhone:
Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0
[terrain] <default>: Unsupported
It works on the Librem 5:
[terrain] <default>: FPS: 12 FrameTime: 83.333 ms
but to make the scores easier to compare I’ve also disabled it in the test run there.
I’m running pretty much the exact same userspace on both devices (based on Debian Buster), with PinePhone’s bootloader and kernel coming from Mobian.
If Purism manufactures the Librem 5 in one large production batch, then we should all get Evergreen at close to the same time. Electronics assemblers in China don’t take that long to produce 5k-10k of phones. Maybe they are putting in the M.2 cards in San Francisco, but that shouldn’t take that long.
Most likely you are in the evergreen batch which will probably begin shipping q4 of 2020-q2 of 2021 due to covid false plandemic.
@dos, Your hardinfo benchmarks are generally better than what @dylanlesterpvcs reported for Dogwood and what evilbunny reported for the PinePhone running Mobian Nightly:
| Benchmark | Librem 5 (4x 1.5GHz Cortex-A53, @dylanlesterpvcs) | Librem 5 (4x 1.5GHz Cortex-A53, @dos) | PinePhone (4x 1.15GHz Cortex-A53, Mobian Nightly) | PinePhone (4x 1.15GHz Cortex-A53, @dos) |
|---|---|---|---|---|
| ↓ CPU Blowfish | 8.81 | 8.44 | 12.58 | 11.27 |
| ↑ CPU CryptoHash | 105.57 | 160.14 | 104.85 | 118.55 |
| ↓ CPU Fibonacci | 3.36 | 3.35 | 3.36 | 4.36 |
| ↓ CPU N-Queens | 5.31 | 5.26 | 10.27 | 7.45 |
| ↑ CPU Zlib | 0.18 | 0.21 | 0.12 | 0.11 |
| ↓ FPU FFT | 9.86 | 9.44 | 17.81 | 14.15 |
| ↓ FPU Raytracing | 5.08 | 4.81 | 9.80 | 7.12 |
| ↑ GLMark2 | 203 | 84 |
↑ Benchmark where higher is better.
↓ Benchmark where lower is better.
I ran hardinfo on my Thinkpad T450s and Raspberry Pi 4B to get a comparison, but I can’t figure out how to run glmark2 without the terrain scene. I tried this command, but it gave very different results for all the tests:
glmark2 -b build -b texture -b shading -b bump -b effect2d -b pulsar -b desktop -b buffer -b ideas -b jellyfish -b shadow -b refract -b conditionals -b function -b loop
Can you share the glmark2 command you used?
On the Raspberry Pi 4B, glmark2 compiles, but I ran into a bug while running the [texture] texture-filter=linear scene.
So here is the comparison, combining your numbers and mine:
| Benchmark | Thinkpad T450s (4x 2.7GHz Core i5-5200U) | Raspberry Pi 4B (4x 1.5GHz Cortex-A72) | Librem 5 (4x 1.5GHz Cortex-A53) | PinePhone (4x 1.15GHz Cortex-A53) | L5 vs RPi4B | PP vs RP4B | L5 vs PP |
|---|---|---|---|---|---|---|---|
| ↓ CPU Blowfish | 4.94 | 6.87 | 8.44 | 11.27 | -23% | -64% | 34% |
| ↑ CPU CryptoHash | 432.63 | 346.8 | 160.14 | 118.55 | -117% | -193% | 35% |
| ↓ CPU Fibonacci | 0.82 | 2.25 | 3.35 | 4.36 | -49% | -94% | 30% |
| ↓ CPU N-Queens | 7.01 | 11.57 | 5.26 | 7.45 | 55% | 36% | 42% |
| ↑ CPU Zlib | 0.47 | 0.25 | 0.21 | 0.11 | -19% | -127% | 91% |
| ↓ FPU FFT | 2.10 | 5.29 | 9.44 | 14.15 | -78% | -167% | 50% |
| ↓ FPU Raytracing | 2.10 | 2.87 | 4.81 | 7.12 | -68% | -148% | 48% |
| ↑ GLMark2* | 850 | 203 | 84 | 142% |
↑ Benchmark where higher is better.
↓ Benchmark where lower is better.
*GLMark2 is without the “terrain” test for the Librem 5 and PinePhone, but includes it for the T450s.
The N-Queens benchmark is strange, because the i.MX 8M Quad did better at it than both the i5 and the RPi4B. Otherwise, everything else is close to what I expected with the Librem 5’s CPU having 30% to 50% better performance than the PinePhone’s CPU and the Vivante GC7000Lite getting more than double the performance of the Mali-400 MP2. The strong Zlib compression scores by the Librem 5 is probably a reflection of its faster memory access with its LPDDR4-3200 RAM, compared to the PinePhone’s pokey LPDDR3-1248 RAM.
These results should make everyone happy. The backers of the Librem 5 can feel good that they are getting significantly better performance than the PinePhone, and TheLinuxGamer should be happy that he’ll get decent graphics performance on the Librem 5. On the other hand, the critics of the Librem 5 can point out that the Librem 5’s performance is significantly less than the Raspberry Pi 4B, which only costs $35. The backers of the PinePhone who bought it for economic reasons can look at the results and conclude the difference in the price between the two phones doesn’t justify the difference in performance.
Everyone can see what they want in the numbers, so we should all rejoice and sing “Kumbaya”.
Not really a command 
diff --git a/src/default-benchmarks.h b/src/default-benchmarks.h
index 4065937..9188d44 100644
--- a/src/default-benchmarks.h
+++ b/src/default-benchmarks.h
@@ -63,7 +63,7 @@ private:
benchmarks.push_back("buffer:update-fraction=0.5:update-dispersion=0.9:columns=200:update-method=map:interleave=true");
benchmarks.push_back("ideas:speed=duration");
benchmarks.push_back("jellyfish");
- benchmarks.push_back("terrain");
+ //benchmarks.push_back("terrain");
benchmarks.push_back("shadow");
benchmarks.push_back("refract");
benchmarks.push_back("conditionals:vertex-steps=0:fragment-steps=0");
Maybe it’s more influenced by the cache size?
Could you add a column with H for when a higher number is better and L for when a lower number is better?
Technically that’s the cost of the 2GB model, which is not an apples-to-apples comparison.
Looking at the hash numbers, the Cortex-A72 is surprisingly good or is the hashing being done in the GPU?
Otherwise, the Cortex-A72 is wider and deeper than the Cortex-A53 and perhaps most importantly the former has out-of-order execution, while the latter does not.
The downside of that though is that the Cortex-A72 is vulnerable to Spectre whereas the Cortex-A53 is not. 
(Some stuff on the internet confuses out-of-order execution with speculative execution. They are not the same thing. So I don’t really know the true situation. Don’t run some random’s code on your Pi / phone and it probably won’t matter.)
Also,
FWIW I’ve switched both phones into performance governors before starting the tests to not have cpufreq and devfreq influence the tests, which may have helped a bit.
Is hardinfo -r supposed to start a benchmark? On my PostmarketOS Pinephone it just lists a bunch of information and has a few failed assertions from GTK.
By default, the command hardinfo -r should run all the benchmarks in the table above, except for glmark2. You should file a bug report, if you got hardinfo from the repos of your distro. You can also try compiling it yourself.
PostmarketOS doesn’t supply hardinfo in their repository, I had to build it from source. I’m considering switching to PureOS or another mobile-friendly distro to get a more mainline selection of packages, as PMOS’s seems to be fairly limited.
I have posted the benchmark results in the community wiki:
Thanks for adding the up and down arrows.
PS Re
FFT converts a signal to frequencies and vice-versa. It is used in audio digital signal processing and image signal processing
Things like JPEG and MPEG use the Discrete Cosine Transform, rather than the Fourier Transform. It is beyond my knowledge to say how representative an FFT benchmark would be for these applications.
I won’t be able to get that data for you, I got 1A and 1B done then had an issue I tried to resolve by reflashing the phone. Needless to say it was lost. Before you ask no unloading it was not an option due to the issue, and it is ongoing right now. I’m not sure why it is happening. I’m trying to resolve it. I’ll get back to you when I can.
That’s all right - you do what you can and must. If you (or anyone else) can do it later, that would be useful too as a base level to compare everything else later. In the mean time, if you can and want to help verify and add specifics, caliper level (".1") measurements of the phone size, shape and weight and of the battery would be nice (placement of contacts for example determine what kind of external charger can be used).
And btw., now that you’ve had it for a while, any new impressions and insights?
Everything of what I’ve done with it has been very polished. I have to say they are making progress in leaps and bounds. Currently my only pet peeve is that the headphone jack is using the wrong sound output so it’s mono atm. Something easy to fix, but I’d pick them focusing on what matters more any day of the week.
A don’t have any way to use calipers for the moment, If my classes were not all online I’d go use some at my collage.