2020 Cloud Report: AWS vs. GCP vs. Azure • Hacker News Board

Re: 2020 Cloud Report: AWS vs. GCP vs. Azure

#121

Post by user5994461 » Tue, Dec 17, 2019, 7:26 PM UTC

sudosysgen wrote: post #65

user5994461 wrote: post #42

Earlier quoted context omitted.

AWS also stopped to drop instance price periodically. Sadly Moore law has stopped some time ago affecting everyone.

As we're starting to see, it was mostly Intel not keeping up, actually. Moore's law is mostly holding up till today, and probably for a couple more years before we really have to switch paradigms.

The definition of doubling performance every few years stopped holding up a while ago. The formal definition of doubling the amount of transistors somewhat holds up, see the huge increase in core counts in recent years, but that doesn't benefit most applications much. Incidentally cloud providers are billing by core count so adding more cores doesn't help the bill.

Re: 2020 Cloud Report: AWS vs. GCP vs. Azure

#122

Post by imtringued » Wed, Dec 18, 2019, 1:05 PM UTC

Kiro wrote: post #111

derefr wrote: post #64

Earlier quoted context omitted.

Elastic rates are really what you should be comparing when using cloud IaaS services, though. That's where the price works out in favor of using cloud IaaS hosts in the first place, after all. If you have a stable set of instances and a known lifetime for them, then, before trying to calculate whether AWS or GCP is cheaper, step back and plug those same numbers into a regular non-cloud DC managed-hardware-leasing pri…

> If you have a stable set of instances and a known lifetime for them I do but I don't even know how to assemble my own computer, much less deal with bare metal for servers. I want to stay as far away from hardware as possible.

What's so difficult about clicking buttons on a web form?

Re: 2020 Cloud Report: AWS vs. GCP vs. Azure

#123

Post by imtringued » Thu, Dec 19, 2019, 10:29 AM UTC

user5994461 wrote: post #121

sudosysgen wrote: post #65

Earlier quoted context omitted.

As we're starting to see, it was mostly Intel not keeping up, actually. Moore's law is mostly holding up till today, and probably for a couple more years before we really have to switch paradigms.

The definition of doubling performance every few years stopped holding up a while ago. The formal definition of doubling the amount of transistors somewhat holds up, see the huge increase in core counts in recent years, but that doesn't benefit most applications much. Incidentally cloud providers are billing by core count so adding more cores doesn't help the bill.

Most applications that run on a server create a process or thread per request/session and scale reasonably well.

Re: 2020 Cloud Report: AWS vs. GCP vs. Azure

#124

Post by sudosysgen » Thu, Dec 19, 2019, 10:59 PM UTC

user5994461 wrote: post #121

sudosysgen wrote: post #65

Earlier quoted context omitted.

As we're starting to see, it was mostly Intel not keeping up, actually. Moore's law is mostly holding up till today, and probably for a couple more years before we really have to switch paradigms.

The definition of doubling performance every few years stopped holding up a while ago. The formal definition of doubling the amount of transistors somewhat holds up, see the huge increase in core counts in recent years, but that doesn't benefit most applications much. Incidentally cloud providers are billing by core count so adding more cores doesn't help the bill.

Nope. It's just that GPUs carried the mantle. If you have a massively parallel number crunching application you should bite the bullet and port it to GPU, and you'll see a truly massive FLOP/$ increase. And unlike processors GPU performance is still rising 35-45% per generation, although that will slow if NVidia gets too far ahead.

Also, if your goal is to get optimal cost/FLOP and you are computing pretty much constantly then you shouldn't be using the cloud, to be honest. If you are IO limited or if you have burst use then maybe, but for cost/FLOP the kings are still consumer GPUs and Threadrippers, by very far and large.