Any idea when these will be available on the genomics pipeline API (now "Cloud Life Sciences" API)?
New AMD EPYC-based Compute Engine family, now in beta
111–120 of 146 posts
Re: New AMD EPYC-based Compute Engine family, now in beta
#112Earlier quoted context omitted.
I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient. It's long been the "google wa…
Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.
It is a philosophical one when you design around scaling out at a high rate. You incur significant additional complexity in many cases along with increased overhead.
It's fallacious to think that relying on "n" things is strictly safer than "3" things where n is large. That's not quite true due to the significant complexity increases when dealing with large "n" and accompanying overhead.
For web applications (which I suspect the majority of HN readers work on) then sure, but plenty of realtime or safety critical applications are perfectly ok with three-way redundancy.
Re: New AMD EPYC-based Compute Engine family, now in beta
#113Earlier quoted context omitted.
Disclosure: I work on Google Cloud (and really care about this). The challenge here is balancing diverse customer workloads against the processor vendors. Historically, at Google, we just bought a single server variant (basically) because almost all code is expected to care primarily about scale-out environments. That made the GCE decision simple: offer the same hardware we build for Google, at great prices. The prob…
This makes a lot of sense, but it doesn't explain why the pricing isn't consistent. Why is an N1 the same price as an N2, except for sustained-use? Why is an E2 cheaper than an N1/N2D, except for sustained-use? E2 is just such an amazing idea that feels like it's going to be under-utilized because it isn't cheaper for the sustained-use case. There doesn't seem to be any reason why E2 would be more expensive (to Googl…
Pricing confusion is a cornerstone of big single shop vendors, the more confusing you make pricing, the more chances a customer is going to spend more than they otherwise might.
Also opens avenues for highly paid consultants to dip their beak and promote your products.
Re: New AMD EPYC-based Compute Engine family, now in beta
#114Its really great to see more AMD options for cloud instances. Now I'm just waiting for more ARM architecture options. Not having to cross compile code (a1/m6g AWS instance types) has been very useful in my day to day job.
Re: New AMD EPYC-based Compute Engine family, now in beta
#115Earlier quoted context omitted.
Is that with spectre/meltdown/etc protection on?
AWS patched their hosts back in 2018 which caused a huge shitstorm in terms of performance lost across various workloads..so yes. https://blog.appoptics.com/visualizing-meltdown-aws/
Afaik amd patches aren’t as penalizing as Intel ones. I have no idea if ^^^ refers to bare metal, bare metal w/ patches or cloud env (unlikely) hence the question.
Re: New AMD EPYC-based Compute Engine family, now in beta
#116Earlier quoted context omitted.
Is that with spectre/meltdown/etc protection on?
Don't know, but for pure numeric code these mitigations are not (AFAIK) that expensive. The main cost is incurred for any code that is syscall-heavy like I/O.
Pure numeric benches aren’t very useful irl tho. My hunch is with security patches single core will be very comparable
Re: New AMD EPYC-based Compute Engine family, now in beta
#117Earlier quoted context omitted.
AWS patched their hosts back in 2018 which caused a huge shitstorm in terms of performance lost across various workloads..so yes. https://blog.appoptics.com/visualizing-meltdown-aws/
Afaik amd patches aren’t as penalizing as Intel ones. I have no idea if ^^^ refers to bare metal, bare metal w/ patches or cloud env (unlikely) hence the question.
The link above is specific to AWS -- hence, "Visualizing Meltdown on AWS" as their title.
Re: New AMD EPYC-based Compute Engine family, now in beta
#118Earlier quoted context omitted.
Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.
Plenty of services can deal with X hours of downtime when a single machine fails for values of X that are longer than it takes to restore to a new machine from backups.
I'd like to add to this and say that a server being down for 6 hours, that if over the life of its uptime (months? years?) saves uncountable number of hours on computations and complexity, is so worth it.
Heck, even a machine like that being down for a week is usually still worth it.
Re: New AMD EPYC-based Compute Engine family, now in beta
#119Earlier quoted context omitted.
I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient. It's long been the "google wa…
Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.
I've heard lots of anecdotes from big sites doing fine with a small number of machines.
eg stackoverflow only has 1 active DB server, and 1 backup.
Re: New AMD EPYC-based Compute Engine family, now in beta
#120Earlier quoted context omitted.
I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient. It's long been the "google wa…
Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.
Totally. We could replace our GPU stack with who knows how many CPUs to hit the same 20ms SLAs, and we'll just pretend data transfer overhead doesn't exist ;-)
More seriously, we're adding multi-node stuff for isolation and multi-GPU for performance. Both are quite different... and useful!