Hacker News Reader

Comment by mcqueenjordan | Hacker News Reader

These graviton2 instances are no joke. As soon as they released, it probably became the new lowest hanging fruit for many people (from a cost efficiency standpoint). The increased L1 cache has an incredible effect on most workloads.

View on HN

Agreed. We have already migrated 90% of our workloads to graviton2. After running our performance tests, it's a no-brainer price/performance boost.

How big are the L1 and L2 caches? I couldn't find it in the article.

  [ec2-user@ip-10-0-42-228 ~]$ lscpu
  ...
  L1d cache:           64K
  L1i cache:           64K
  L2 cache:            1024K
  L3 cache:            32768K

Find a deep dive on the cache and memory micro-architecture here: https://www.anandtech.com/show/15578/cloud-clash-amazon-grav...

Of course, you can't compare those directly with epyc/xeon because of the architectural/instruction set differences.

EDIT: meaning that a larger sized cache wouldn't necessarily deliver better performance (though I think in this case the architectural differences do favor Graviton making better use of cache)

I couldn't find anything on the differences between the two different L1 caches. What's the purpose for a second L1 cache?

The ARM architecture is a modified Harvard architecture, so the CPU has separate instruction and data L1 caches. x86 CPUs don't have this separation.

  $ lscpu
  Architecture:                    x86_64
  Model name:                      AMD Ryzen 7 2700X Eight-Core Processor
  L1d cache:                       256 KiB
  L1i cache:                       512 KiB
  L2 cache:                        4 MiB
  L3 cache:                        16 MiB

I’m pretty sure x86 does have split L1i and L1d.

From Wikipedia (not the best source I know):

“L1 cache size unchanged at 32 KB (KiB) instruction and 32 KB (KiB) data cache per core.“

https://en.m.wikipedia.org/wiki/Skylake_(microarchitecture)

ARM is smaller due to simpler instruction decoders mostly, which leaves more room for a huge cache in the transistor budget.

I am hoping Apple does this with their desktop chips: basically take the fastest phone/tablet processor, give it better thermals, and pump up the cache. That would be an easy path to beating Intel on a laptop.

My understanding was that large cache was mostly a cost tradeoff, and that there's no technical reason why x86 processors couldn't do this too. I believe Apple's A-series chips already have a huge cache which is a big part of why they are so fast.

Cost/die size is part of the consideration especially for L3 but with L1 and L2 it is much more about latency than cost: bigger caches will have higher latency than smaller ones. That's the entire reason for the multi-level cache hierarchy to exist in the first place.

Graviton2 doesn't even have a particularly large total amount of cache, the only part of the cache system that's bigger than both AMD and Intel is the L1D. L1I is the same as AMD, L2 is same as Intel, L3 is smaller than both (talking about current-gen server chips). That L1D can indeed make a big difference in certain workloads though.

The L3 is actually pretty small for how many cores there are, ARM recommends 1-2MB/core for the N1 cores in the Graviton2 and it has 512KB/core. AMD has 4MB per core in Zen2 albeit with a slightly weird setup where the L3 is localized to 4 core clusters.

Disclosure: I work at AWS.

Graviton2 has 64KB L1 caches and 1MB L2 cache per vCPU, with a 32MB LLC.

Source: https://youtu.be/4jImmuMqnwc?t=1111

Ryzen CPU's seem to have a decent amount of cache's built in: Level 1 cache size 12 x 32 KB 8-way set associative instruction caches 12 x 32 KB 8-way set associative data caches Level 2 cache size 12 x 512 KB 8-way set associative unified caches Level 3 cache size 4 x 16 MB 16-way set associative shared caches

RDS is ridiculously overpriced, I just cut my bill from $1,000 to $50 per month by switching back to EC2 for my database server.

I'm interested in hearing what your setup was like that cost $1,000 that you could replicate on your own for just $50.

I am trying to backup gmail emails my employees send and receive and make them searchable. This will enable a new account manager on an account to easily search and find previous discussions with clients and come up to speed to help them quickly.

We were pulling in millions of emails from the past few years, so we had to do a larger size RDS and we were killed on the IO charges.

We are now just on a medium sized EC2 server.

Do you have suggestions for better ways of doing this?

I can't give you direct recommendations, but it does sound like you might have used Provisioned IOPS storage instead of General Purpose storage which is simply pay by the byte.

If you're willing to post a bit more details, I'm sure people could give you some more detailed options. You basically switched from a fully-managed database solution to a fully DIY solution, and I honestly think you might have just over provisioned the RDS instance. I'm willing to bet you can switch back to RDS and get all the benefits there while remaining within budget. You can get a 1-year reserved t3.medium RDS instance with 50 GB of storage for $40/month.

Here is the rest of the details from my developer on the project-

What was our specific server size and setup and costs with RDS? We were using db.t3.medium (1 CPU, 2 vCPU, 4GB RAM), we were using a DB cluster that has 2 instances db.t3.medium overall cost (~$118 monthly) And now with EC2? We are using c5d.xlarge (4 CPU, 20 ECU, 8GB RAM), we are using one instance c5d.xlarge overall cost (~$140 monthly) What was the big cost savings? Our main issue was in I/O (Read and write), we have very high I/O demand so we was paying for I/O and storage (~$600) and the second issue is CPU credit (~$90 monthly) so the total save is ($600+$90+$118)-$140= $668 per month.

Also EC2 performance is better than RDS because we get a very good cheaper than RDS server.

Note: RDS is configuration less and has support while if you want to use EC2 then you need a person to do configuration and support for DB on it.

Still not clear what your major cost was. Were you using RDS Aurora, which has an IO fee? ($0.20 per 1 million requests?)

Yes, our major cost is IO and yes we are using Aurora and you are correct IO fee is $0.20 per 1 million requests.

So I suggest trying vanilla Postgres RDS, which doesn't have IO fees, but is still managed.

Also, if you're doing such heavy IO, you might want to also look at I3en instances, which have fantastic IO using local storage.

Same please do tell

Or you know, just use a smaller RDS instance. The price difference is not 20x over an EC2 instance. It's been a while since I checked, but I remember the markup being less than 2x.

Yup, it's about 1.8x for the instance sizes I checked.

Yeah that’s only true if you aren’t using piops. It can be an order of magnitude in price difference vs i3 when you need lots of I/O.

PIOPS is the same price whether it's attached to an EC2 instance or an RDS instance.

Reply on news.ycombinator.com