[HN Gopher] Turing RK1 is 2x faster, 1.8x pricier than Pi 5
___________________________________________________________________
Turing RK1 is 2x faster, 1.8x pricier than Pi 5
Author : ingve
Score : 36 points
Date : 2024-04-26 16:22 UTC (6 hours ago)
(HTM) web link (www.jeffgeerling.com)
(TXT) w3m dump (www.jeffgeerling.com)
| refulgentis wrote:
| Imagine a Beowulf cluster of these...
| jmakov wrote:
| Why? For that price you get a used laptop with higher perf.
| kube-system wrote:
| Depends on how long you want to run it and your utility costs,
| performance/watt is good on newer chips like these.
| JudasGoat wrote:
| I wish it were easier to quantify the energy cost of building
| these newer more efficient devices, as opposed to repurposing
| existing hardware. When you add e-waste to the equation, it
| gets cloudier.
| dragontamer wrote:
| Intel Xeon D-2700* or 1700 SoC are the preferred "low power
| servers" in practice. Yes, they idle at 25W, but I bet you that
| the Xeon D-2500 will have more performance than 10x Rasp. Pi 5.
|
| More importantly: there will be server-class features like out-
| of-band management/IPMI, 10Gbase-T ports, etc. etc.
| geerlingguy wrote:
| Note that this board runs RK1's (which use the RK3588 SoC),
| not Raspberry Pis.
|
| It burns 18.5W with CPU cores maxed out, producing 224 Gflops
| of compute (see:
| https://github.com/geerlingguy/top500-benchmark/issues/27).
| Efficiency-wise, it's a little more power efficient than at
| least last-gen AMD/Intel chips, and a little less than Ampere
| CPUs and Apple's M1. I haven't had a chance to compare to
| M2/M3 for power efficiency yet.
|
| The Turing Pi 2 has a BMC that allows out-of-band management,
| and the firmware is fairly stable at this point, and the
| community helped build a nice CLI for it so IMO it's even
| nicer (from automation/remote sysadmin aspect) than IPMI for
| some things. There's no remote VNC/display, but these aren't
| meant to have displays (even though node 1 has HDMI routed to
| a connector on the back).
|
| The most crippling thing for my use cases is the single 1
| Gbps connection externally, and the internal 1 Gbps Ethernet
| switching. It'd be nice if it did at least 2.5 Gbps.
| dragontamer wrote:
| Xeons / AMD EPYCs are measured in (low single-digit)
| TFlops, not GFlops.
|
| AVX512 gets places, especially with Fused Multiply-
| accumulate (FMA) instructions and multiple pipelines.
|
| That the thing though: TFlops is still "weak" because GPU
| market crushes Linpack so hard its just not comparable. But
| I'd assume that your typical Xeon D will run circles around
| these other cores watt-for-watt.
|
| Its the GPUs that Xeon D is competing with and struggling
| with. But if we're talking about a bunch of CPU-style
| compute (non-Linpack workloads), or even the occassional
| matrix-multiply, its hard to beat Xeon or EPYC in cost and
| power-efficiency.
|
| And you certainly ain't gonna beat a Xeon or EPYC with tiny
| ARM chips right now.
| justinclift wrote:
| > And you certainly ain't gonna beat a Xeon or EPYC with
| tiny ARM chips right now.
|
| Do you include Apple's M family in that list of tiny ARM
| chips?
| dragontamer wrote:
| That's an edge case. But I'm mostly talking about RK1 or
| Rasp. Pi 5.
|
| I'm well aware of "large" ARM chips like Fujitsu A64FX
| ARM that did well (when it came out) in terms of Linpack
| performance, thanks to hugely efficient designs like HBM
| and 512-bit SVE.
|
| I'm not very well aware of what Apple M1 offers to the
| table, I know some people are experimenting with it but
| its a far larger chip than RK1 or Rasp. Pi. But its
| probably smaller than A64FX.
|
| I know that Apple M1 has only 128-bit vectors though, so
| that's a big penalty vs AVX512 or even the older Fujitsu
| A64FX. I'd expect them to be bad at Linpack / Matrix
| multiplication as this is where SIMD shines exceptionally
| well... and AVX512 on Xeon is a very good SIMD
| implementation.
|
| I recognize Apple M1 has multiple 128-bit pipelines that
| operate in parallel per core, so its better than it
| looks, but there's a huge power-efficiency advantage to
| 512-bit sized vector units in the Linpack-style matrix-
| multiplication code.
| tubs wrote:
| M chips has some matrix multipliers in hardware as well.
| chokolad wrote:
| > Note that this board runs RK1's (which use the RK3588
| SoC), not Raspberry Pis.
|
| Turing Pi 2 was designed to run Paspberry Pi CM4 via
| adapter as well as Jetson Nano (?). RK1 is somewhat recent
| development that was shipped way after Turing Pi2 release.
| shrubble wrote:
| For 'serious' use I would always recommend ECC RAM.
| kube-system wrote:
| If you're not running in two independent regions of tier 4 data
| centers, are you even really serious? /s
|
| There are 'serious' applications of technology that can
| tolerate memory faults.
| kevindamm wrote:
| only two? you know you should have N+2 deployment for real
| redundancy
| scheme271 wrote:
| Only if N+2 is an odd number, otherwise you may end up with
| a split brain scenario
| margalabargala wrote:
| > There are 'serious' applications of technology that can
| tolerate memory faults.
|
| We can define "serious" use to mean "use where memory faults
| would be more expensive than buying ECC RAM" :)
| kkielhofner wrote:
| > It may be an irrational hobby
|
| Refreshing to hear someone just come out and say it. I don't get
| it but hey, I'm into all kinds of weird stuff that doesn't make
| sense either.
|
| Just don't try to attempt some argument the capability,
| performance, or even power usage makes any practical sense. It
| doesn't.
| baq wrote:
| It certainly makes for a fun homelab to set up a bare metal
| cluster of say k8s in a desk drawer, where Pis usually end up
| anyway.
| foobarian wrote:
| I think there need to be some tiny Lego or similar figurines
| operating those tiny blades on those tiny racks :-D
| neilv wrote:
| I love the idea of Lego minifigs posed inside a chassis for
| these compute module cluster boards, like they're IT workers in
| a datacenter.
|
| Every time you pull a server and pop the lid, they're in there
| working.
|
| (Maybe not for production, lest a minifig get sucked into a
| fan, taking down a mission-critical cat picture sharing app.)
| ianburrell wrote:
| It looks like RK1 is only compatible with the Turing Pi 2 4-slot
| board. I was hoping that it was CM4 compatible. Module faster
| than Pi5 before CM5 has come out would be useful.
| scheme271 wrote:
| I think the power draw is going to be too high to be CM4
| compatible.
| ianburrell wrote:
| It looks like the RTK1 has the exact power draw, 7W, of CM4.
|
| It seems that the carrier board is same as Nvidia Jetson.
| ianburrell wrote:
| I wish that the half-width 10" rack was more popular in the US. I
| got the impression that they are more popular in Europea.
|
| It should be a good size for home networking gear and small
| servers. Also, it should be possible to mount 10" device in 19"
| rack. I don't think it is possible to mount two together.
| hinkley wrote:
| Back in the day some people tried to go the other way. Half
| depth servers that were light enough to fit into musician's
| audio racks, which also tend to be rather small affairs of 6-12
| units tall. Noise however is often the problem with these
| things. Substantially because the 1-2u height leads to comical
| fans.
|
| I suppose that servers would tend to be taller in the half-
| width racks?
| hinkley wrote:
| The original one of these was 6 slots wasn't it? How did we end
| up with 4 in the last two generations? Bandwidth concerns?
| redundantly wrote:
| You're probably thinking of the DeskPi board.
|
| https://deskpi.com/products/deskpi-super6c-raspberry-pi-cm4-...
|
| It's a different product.
| hinkley wrote:
| No but that one is interesting.
|
| I believe Jeff is how I heard about Turing in the first place
| (or at least the first time I saw their stuff working.)
|
| Sure enough he still has the old videos up and I was wrong;
| it had 7 slots not 6, which means the new one loses almost
| half its slots, and explains some of my remembered
| disappointment.
|
| https://www.jeffgeerling.com/blog/2020/raspberry-pi-
| cluster-...
___________________________________________________________________
(page generated 2024-04-26 23:01 UTC)