Hacker News Reader

Comment by bhouston | Hacker News Reader

Interesting to see that it has higher throughput per $. That is the most important fact.

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).

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).

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.

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.

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.

For academia, all 3 major cloud providers have a data egress waiver - meaning that as long as data egress is less than 15% of the total bill then it is free.

Combine this with the fact that S3/Glacier make much more sense than local HDDs for long-term archiving and egress turns out not to be a significant factor in my experience.

There's some truth to this, but for many sporadic jobs the cloud can be quite useful. My favorite applications are the streaming video services that have most of their traffic on Friday and Saturday night. You're right that the prices are too high for long, constant workloads, but not about this only being hobbies.

A lot of legitimate uses out there for occasional, important-when-it's-needed, on-demand compute that works out to very low utilization overall.

That's actually one reason why ARM has failed so hard in the server space. Nobody is going out of their way to get their code to run on unobtanium unless the cloud provider is an absolute giant and has a proven track record.

It's far more likely that someone will make the switch to ARM if their laptop or desktop is already ARM because then you aren't at the mercy of the server vendor deciding to only cooperate with a handful of cloud vendors or even dropping the project completely.

I agree, there's definitely some friction there and for random personal projects I for sure choose to host on the same architecture I develop on.

For large deployments, the calculation might be very different. Beyond that, plenty of people are developing on Arm Macs now.

> unless the cloud provider is an absolute giant and has a proven track record.

Right, well, this is Amazon AWS we are talking about?

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

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.

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).

Reply on news.ycombinator.com