[HN Gopher] Evaluating Graviton 2 for data-intensive application...
___________________________________________________________________
Evaluating Graviton 2 for data-intensive applications: Arm vs.
Intel comparison
Author : Aissen
Score : 37 points
Date : 2022-04-05 18:45 UTC (4 hours ago)
(HTM) web link (redpanda.com)
(TXT) w3m dump (redpanda.com)
| CyanLite2 wrote:
| cliff notes?
|
| Site seems to have been hugged to death
| pzarex wrote:
| Link works for me...
|
| TL;DR, Arm instances give better bang for the buck...
| bhouston wrote:
| Interesting to see that it has higher throughput per $. That is
| the most important fact.
| zokier wrote:
| Of course more perf/$ is the whole selling point of graviton so
| it would be pretty big failure somewhere if that were not the
| case
| BeeOnRope wrote:
| Yes, but I think one thing that is interesting here is that
| these Graviton 2 instance types also offer, for example,
| better IO throughput or storage/$ even though the CPU
| architecture doesn't obviously affect that (i.e., it's not
| like you get access to a new source of quality NAND chips to
| build SSDs when you switch your CPU).
|
| Another thing I found interesting was that the porting
| process was painless for this native application. There are
| lots of examples of quick wins on Graviton for interpreted or
| bytecode/JIT'd languages where the runtime exists on Arm and
| the software just works, but porting a complex native
| application would seem to pose more problems. In our case,
| however, it was quite straightforward (more than I would have
| expected).
| agallego wrote:
| perf is important, but predictability of the SSD perf is
| honestly just (if not more) valuable, specially when you have
| to build SLA's for your products.
| BeeOnRope wrote:
| Yeah, these instance types look strong and it seems that Amazon
| is also innovating in the local storage space as well as I
| don't find many of the usual gotchas with SSDs there (long GC
| pauses, etc).
|
| We may be moving to a future where cloud hardware stops being
| "just OK" and a low maintenance version of what you could build
| yourself, but actually offering unobtainable-by-mere-mortals
| hardware and firmware (we are already seeing this for e.g. with
| quantum computing options in the cloud and even arguably GPUs
| and ML accelerators).
| ceeplusplus wrote:
| It is still vastly cheaper to buy your own GPUs and ML
| accelerators than to rent from cloud providers for any
| reasonable level of utilization (i.e. not a hobby).
| BeeOnRope wrote:
| My point was that there are accelerators in the cloud which
| are not available to purchase by the general public and for
| a time the same applied also to GPUs in a practical sense
| (i.e., GPUs were being sold in principle but were out of
| stock for months on end).
|
| Depending on your individual time value of money, it can
| make sense to rent even a high rate so you can access this
| hardware _now_.
| ip26 wrote:
| I'm excited on behalf of the scientists I know for cloud
| HPC.
|
| I see a lot of " _develop program locally on tiny subset of
| data_ " followed by " _how the hell am I ever going to run
| the full model for the final run on all the data!?_ "
|
| A couple hours machine time leased on a behemoth is really
| the ticket, and not really that expensive.
| zozbot234 wrote:
| The cost of data egress from the cloud really limits its
| potential for most HPC applications, though. The "free"
| or reasonable-cost tiers are okay for small-scale toy
| use, but not much more than that.
| sharpy wrote:
| Recently worked on migrating a number of services (largely CPU
| bound) to Graviton 2. It was a bit of hit and mess. For some
| services, it worked great. Very negligible hit to performance,
| and since equivalent Graviton2 instances cost 20% less, it was a
| no brainer. Others needed a little bit of rewrite. There were
| also a couple that just didn't see good performance on ARM (very
| branchy code)
| BeeOnRope wrote:
| Interesting. Other than branchy-ness, was there anything else
| you think correlated to poorer performance on Graviton 2.
| ceeplusplus wrote:
| Branchy-ness usually also correlates with cache friendliness
| (e.g. branchy code is usually a server app calling lots of
| different functions, with lots of virtual function calls),
| and Graviton2 has an abnormally small L3 cache relative to
| its x86 competitors. If I had to hazard a guess I'd say
| heavily vectorized code will also perform worse especially
| compared to Intel instances where you have AVX-512.
| BeeOnRope wrote:
| I wrote this, happy for any feedback or to answer any question
| about the methodology or otherwise.
|
| One thing note is that the headline difference between these
| instances types is the CPU architecture, the value offered by
| these instance types is as much about how many IOPS and how much
| SSD space EC2 chooses to offer for each family, especially for
| this IO-bound benchmark.
|
| It is entirely plausible that EC2 will offer more hardware bang-
| for-buck on Graviton instances in an effort to encourage adoption
| so we can't necessarily draw a strong conclusion about the future
| of the Arm vs x86 battle on the server CPU front since Amazon is
| not an Arms-length entity here (pun intended).
| Uehreka wrote:
| One bit of feedback, it's a good idea to put "higher is better"
| or "lower is better" on graph axes.
| BeeOnRope wrote:
| Thanks, this is great feedback that I'll implement next time.
| You are right that it is not always obvious especially when
| talking about both throughput (higher is better) and latency
| (lower is better) in the same post.
___________________________________________________________________
(page generated 2022-04-05 23:01 UTC)