bensimmo wrote: ↑Mon Sep 28, 2020 6:58 am
Don't forget the Pi4 uses a 2016 ARM, so only five years newer than your Sandy Bridge Xeon (assuming original, Xeon has stupid version numbering),
so not 8 years.
Also given the Pi processor will have been for a media player, set top box at the time, I doubt server encryption security was high on the list
.
Fast forward to 2020, security at a higher importance as connections start to demand it.
it's not a CPU age issue ARMv8 CPUs of the same generation with cryptoextensions will perform a way better. Just for a quick one with data collected under 'kinda similar' conditions (I like to get the data from one spot, otherwise you've no idea what you really compare, so all this data comes from
https://github.com/ThomasKaiser/sbc-ben ... Results.md). Further the BCM2711 is not a 4 years old SoC design (the arm cores design was released 2015 if I got that right, but the overall SoC first showed up 2019 with the RPi, likely that broadcom released kinda similar stuff earlier under a different SoC name earlier - I've no idea about the broadcom SoC lineup as far as I know raspberries always (at least for the more recent iterations) had slightly customized SoCs or at least they got their own number.
Code: Select all
Board Clockspeed Kernel Distro 7-zip AES-128 (16 byte) AES-256 (16 KB)
Raspberry Pi 4 B 1500 MHz 5.4 Raspbian Buster arm64 5080 38070 30170
Raspberry Pi 4 B 1500 MHz 4.19 Raspbian Buster 5500 62350 64860
Rock64 1300 MHz 4.18 Bionic arm64 3530 116100 605250
Rock64 1300 MHz 4.18 Stretch arm64 3560 89070 603800
RockPro64 1800/1400 MHz 4.18 Stretch arm64 6300 237700 1021500
Tinkerboard 1730 MHz 4.14 Stretch armhf 5350 63150 66600
x5-Z8300 1420 MHz 4.9 Stretch amd64 3900 101580 178010
comparing the rpi to a 8y old server CPU might not be that fair due to server CPUs focused on crypto a way earlier. But here are some other SoCs which might be closer to the RPi usecase.
- Rock64 is a rk3328 with a quadcore a53 SoC (according to your definition that's a ~8y old arm CPU, the built in SoC is from somewhere 2016 or so). With a weaker CPU and slower clockspeed it still outperforms the RPi by a large margin
- RockPro64 is a rk3399 with 2x a72 4x a53 core setup (also from 2016, in a lot of use-cases it performs 'kinda similar' to the 4x a72 rpi setup, except for crypto where it's just a beast compared to the Pi4)
- Z8300 is a dirtcheap atom from 2015 which also targets consumer market (I think the cheapest device with that SoC I bought was a 7'' tablet for something like 40$), it has intels AES-NI and without surprise it manages to beat the RPi in crypto as well.
-and for the last one the tinkerboard with a rk3288 (4x a17 from 2014, 32bit obviously without cryptoextensions cause it's a armV7) which performs kinda similar to the RPi in terms of AES
if we now look at 7zip score, it's not that the Pi4 underperforms here (it manages to beat some of the competitors and is even close to the rk3399). But this is not a "arm vs amd64" or "the chipdesign is old" problem. It's simply "has cryptoextensions or not issue", SoCs having it integrated will outperform the RPi in that even if they are overall slower (e.g. rk3328). Whenever this affects your use-case is then up to you to test. As long as encryption (and the increased CPU usage due to it) is not the bottleneck of your application it doesn't really matter. If it is the bottleneck you either have to accept it or go for another board/SoC.
This was/is a broadcom/RPT decision, broadcom for being one of the few chipmakers not opting for crypto extensions in their 'tv box/consumer grade stuff' SoC - rk3328 is a 'tv box' SoC too but has it (the only others I'm aware of are older amlogic SoCs but they added it to their newer SoCs) and RPT for opting for such an SoC. I might be wrong here but I would assume that you may have some impact on chipdesign given the tight connection between RPT and broadcom especially when you can assume that you can sell a couple million SoCs with every raspberry pi release. This topic came also up with the Pi3 as being the 'first' ARMv8 RPi (or was the Pi2 update with 64bit SoC earlier? I don't remember), but it seems that this was not of high priority for RPT. I think this was not that much of an issue during VC4 times where for a lot of use-cases the whole system was anyway bottlenecked by the single USB2 connection but now with a proper GbE as well as decent USB3 things might look different.
bensimmo wrote: ↑Mon Sep 28, 2020 6:58 am
Maybe something like the BCM58732 would fit the bill, sounds expensive from the specs compared to the Pi setup.
just by a quick look, this SoC addresses a complete different audience compared to BCM2711, likely for headless only stuff. Maybe newer broadcom 'consumer SoC' will have them as well or already have it.. Their website summarizing their SoC lineup is just to painful (for me) to check that.
