19 ms·

I think one day we’re going to wake up and discover that AWS mostly runs on Graviton (ARM) and not x86. And on that day intel’s troubles will go from future to

I think one day we’re going to wake up and discover that AWS mostly runs on Graviton (ARM) and not x86. And on that day intel’s troubles will go from future to present. My standing theory is that the m1 will accelerate it. Obviously all the wholly managed AWS services (Dynamo, Kinesis, S3, etc.) can change over silently, but the issue is EC2. I have a MBP, as do all of my engineers. Within a few years all of these machines will age out and be replaced with m1 powered machines. At that point the idea of developing on ARM and deploying on x86 will be unpleasant, especially since Graviton 2 is already cheaper per compute unit than x86 is for some work loads; imagine what Graviton 3 & 4 will offer.

mhh__ 6y ago
I can see this happening for things that run in entirely managed environments but I don't think AWS can make the switch fully until that exact hardware is on people's benches. Doing microbenchmarking is quite awkward on the cloud, whereas anyone with a Linux laptop from the last 20 years can access PMCs for their hardware
- ashtonkem 6y ago
  Professional laptops don’t last that long, and a lot of developers are given MBPs for their work. I personally expect that I’ll get a M1 laptop from my employer within the next 2 years. At that point the pressure to migrate from x86 to ARM will start to increase.
  - mhh__ 6y ago
    You miss my point - if I am seriously optimizing something I need to be on the same chip not the same ISA. Graviton2 is a Neoverse core from Arm and it's totally separate from M1. Besides, Apple don't let you play with PMCs easily and I'm assuming they won't be publishing any event tables any time soon so unless they get reverse engineered you'll have to do it through xcode.
    - ashtonkem 6y ago
      Yes, the m1 isn’t a graviton 2. But then again the mobile i7 in my current MBP isn’t the same as the Xeon processors my code runs on in production. This isn’t about serious optimization, but rather the ability for a developer to reasonably estimate how well their code will work in prod (e.g. “will it deadlock”). The closer your laptop gets to prod, the narrower the error bars get, but they’ll never go to zero. And keep in mind this is about reducing the incentive to switch to a chip that’s cheaper per compute unit in the cloud. If Graviton 2 was more expensive or just equal in price to x86, I doubt that M1 laptops alone would be enough to incentivize a switch.
      - mhh__ 6y ago
        That's true but the Xeon cores are much easier to compare and correlate because of the aforementioned access to well defined and supported performance counters rather than Apple's holier than thou approach to developers outside the castle.
    - lostapathy 6y ago
      This is typical Hacker News. Yes, some people "seriously optimize" but the vast majority of software written is not heavily optimized nor is it written at companies with good engineering culture. Most code is worked on until it'll pass QA then thrown over the wall. For that majority of people, an M1 is definitely close enough to a graviton.
      - mhh__ 6y ago
        > typical hacker news Let me have my fun!
    - foobarian 6y ago
      We have MBPs on our desks but our cloud are Centos Xeon machines. The problems I run into are not squeezing every last ms of performance, since it's vastly cheaper to just add more instances. The problems I care about is that some script I wrote suddenly doesn't work in production because of BSDisms, or Python incompatibilities, or old packages in brew, etc. Would be nice if Apple waved a magic wand and replaced its BSD subsystem with Centos* but I won't be holding my breath :) * yes I know Centos is done, substitute as needed.
- sitkack 6y ago
  Very little user code generates binaries that can _tell_ it is running on non-x86 hardware. Rust is Arm Memory Model safe, existing C/C++ code that targets the x86 memory model is slowly getting ported over, but unless you are writing multithreaded C++ code that cuts corners it isn't an issue. Running on the JVM, Ruby, Python, Go, Dlang, Swift, Julia or Rust and you won't notice a difference. It will be sooner than you think.
  - mhh__ 6y ago
    It's not the memory model I'm thinking of but the cache design, ROB size etc. Obviously this is fairly niche but the friction to making something fast is hugely easier locally.
    - sitkack 6y ago
      The vast majority of developers never profile their code. I think this is much less of an issue than anyone on HN would rank it. Only when the platform itself provides traces do they take it into consideration. And even then, I think most perf optimization is in a category of don't do the obviously slow thing, or the accidentally n^2 thing. I partially agree with you though, as the penetration of Arm goes deeper into the programmer ecosystem, any mental roadblocks about deploying to Arm will disappear. It is a mindset issue, not a technical one. In the 80s and 90s there were lots of alternative architectures and it wasn't a big deal, granted the software stacks were much much smaller and more metal. Now they are huge, but more abstract and farther away from machine issues.
      - mhh__ 6y ago
        This isn't really about you or me but the libraries that work behind the spaghetti people fling into the cloud.
        vinay_ys 6y ago
        Yes, and just like Intel & AMD spent a lot of effort/funding for building performance libraries and compilers, we should expect Amazon and Apple invest into similar efforts. Apple will definitely give all the necessary tools as part of Xcode for iOS/MacOS software optimisation. AWS is going to be more interesting – this is a great opportunity for them to provide distributed profiling/tracing tools (as a hosted service, obviously) for Linux that run across a fleet of Graviton instances and help you do fleet-wide profile guided optimizations. We should also see a lot of private companies building high-performance services on AWS to contribute to highly optimized open-source libraries being ported to graviton.
- api 6y ago
  I don't think it takes "exact" hardware. It takes ARM64, which M1 delivers. I already have a test M1 machine with Linux running in a Parallels (tech preview) VM and it works great.
- Someone 6y ago
  I would think the number of developers that have “that exact hardware” on their bench is extremely small (does AWS even tell you what cpu you get?) What fraction of products deployed to the cloud even has its developers seen doing _any_ microbenchmarking?
ghettoimp 6y ago
If it can emulate x86, is there really a motivation for developers to switch to ARM? (I don't have an M1 and don't really know what it's like to compile stuff and deploy it to "the cloud.")
- ashtonkem 6y ago
  Emulation is no way to estimate performance.
  - acoard 6y ago
    Sure, but as a counter example Docker performance on Mac has historically been abysmal[0][1], but everyone on Mac I know still develops using it. We ignore the performance hit on dev machines, knowing it won't affect prod (Linux servers). I don't see why this pattern would fail to hold, but am open to new perspectives. [0] https://dev.to/ericnograles/why-is-docker-on-macos-so-much-worse-than-linux-flh https://dev.to/ericnograles/why-is-docker-on-macos-so-much-w... [1] https://www.reddit.com/r/docker/comments/bh8rpf/docker_performance_on_macos_vs_native_linux/ https://www.reddit.com/r/docker/comments/bh8rpf/docker_perfo...
    - remexre 6y ago
      The VM that uses takes advantage of hardware-accelerated virtualization, for running amd64 VMs on amd64 CPUs. You don't have hardware-accelerated virtualization for amd64 VMs on any ARM CPUs I know of...
    - fomine3 6y ago
      Abysmal Docker performance on non-Linux is mainly because of filesystem isn't native, not by CPU virtualization.
dogma1138 6y ago
At that point if it will be trouble for Intel it would be a death sentence for AMD... Intel has fabs, yes it’s what maybe holding them back atm but it also a big factor in what maintains their value. If x86 dies and neither Intel nor AMD pivot in time Intel can become a fab company they already offer these services, yes no where near the scale of say TSMC but they have a massive portfolio of fabs and their fabs are located in the west, they also have a massive IP portfolio related to everything form IC design to manufacturing.
- skohan 6y ago
  AMD also has a GPU division.
  - dogma1138 6y ago
    Intel makes more money selling their WiFi chipsets than AMD makes on selling GPUs heck even including consoles...
    - shrewduser 6y ago
      got a source for that? sounds hard to believe.
      - dogma1138 6y ago
        Computing and Graphics which includes the Radeon technology group revenue for AMDs last quarter was £1.67B industry estimates are that $1.2-1.3B were from CPU sales. Intel’s Internet of Things group alone revenue last quarter was $680M and they hit $1B IOTG revenue previously https://www.statista.com/statistics/1096381/intel-internet-of-things-group-revenue/ https://www.statista.com/statistics/1096381/intel-internet-o...
- nickik 6y ago
  AMD makes great designs, switching to ARM/RISC-V would make them lose value but not kill them.
tapirl 6y ago
Intel's fate predicted in 2014: https://pbs.twimg.com/media/ErrFtv0UwAA4JaW?format=png https://pbs.twimg.com/media/ErrFtv0UwAA4JaW?format=png
- afavour 6y ago
  On the flip side that post illustrates just how things can go wrong, too: Windows RT was a flop.
  - tapirl 6y ago
    It is more a stance to show Microsoft is ready to put Windows on arm CPUs if x86 loses the market.
  - deaddodo 6y ago
    Precisely for the reasons he gave though. It wasn't a unified experience. RT had lackluster support, no compatibility and a stripped down experience. They're trying to fix it with Windows on ARM now, but that's what people were asking for back then.
BenoitEssiambre 6y ago
Yeah and I assume we are going to see Graviton/Amazon linux based notebooks any day now.
- agloeregrets 6y ago
  Honestly, if Amazon spun this right and they came pre-setup for development and distribution and had all the right little specs (13 and 16 inch sizes, HiDPI matte displays, long battery life, solid keyboard, macbook-like trackpad) they could really hammer the backend dev market. Bonus points if they came with some sort of crazy assistance logic like each machine getting a pre-setup AWS Windows server for streaming windows X86 apps.
  - heartbreak 6y ago
    > could really hammer the backend dev market That's worth, what, a few thousand unit sales?
    - easton 6y ago
      If they could get it to $600-800 and have an option for Windows, decent trackpad/keyboard, you could sell them to students just as well. Shoot, if the DE for Amazon Linux was user friendly enough they wouldn’t even need windows, since half of schools are on GSuite these days.
    - TheOperator 6y ago
      The point wouldn't be to sell laptops.
      - agloeregrets 6y ago
        Exactly.
  - yesbabyyes 6y ago
    Like a Bloomberg machine for devops.
Const-me 6y ago
Building server software on Graviton ARM creates a vendor lock-in to Amazon, with very high costs of switching elsewhere. Despite using A64 ISA and ARM’s cores, they are Amazon’s proprietary chips no one else has access to. Migrating elsewhere gonna be very expensive. I wouldn’t be surprised if they sponsor their Graviton offering taking profits elsewhere. This might make it seem like a good deal for customers, but I don’t think it is, at least not in the long run. This doesn’t mean Graviton is useless. For services running Amazon’s code as opposed to customer’s code (like these PAAS things billed per transaction) the lock-in is already in place, custom processors aren’t gonna make it any worse.
- dragontamer 6y ago
  I'm not necessarily disagreeing with you, but... maybe elaborating in a contrary manner? Graviton ARM is certainly vendor lock-in to Amazon. But a Graviton ARM is just a bog-standard Neoverse N1 core. Which means the core is going to show similar characteristics as the Ampere Altra (also a bog-standard Neoverse N1 core). There's more to a chip than its core. But... from a performance-portability and ISA perspective... you'd expect performance-portability between Graviton ARM and Ampere Altra. Now Ampere Altra is like 2x80 core, while Graviton ARM is... a bunch of different configurations. So its still not perfect compatibility. But a single-threaded program probably couldn't tell the difference between the two platforms. I'd expect that migrating between Graviton and Ampere Altra is going to be easier than Intel Skylake -> AMD Zen.
  - Const-me 6y ago
    > you'd expect performance-portability between Graviton ARM and Ampere Altra I agree, that would what I would expect too. Still, are there many public clouds built of these Ampere Altra-s? Maybe we gonna have them widespread soon, but until then I wouldn’t want to build stuff that only runs on Amazon or my own servers with only a few on the market and not yet globally available on retail. Also, AFAIK on ARM the parts where CPUs integrate with the rest of the hardware are custom. The important thing for servers, disk and network I/O differs across ARM chips of the same ISA. Linux kernel abstracts it away i.e. stuff is likely to work, but I’m not so sure about performance portability.
jayd16 6y ago
I guess I don't understand why the M1 makes developing on Graviton easier. It doesn't make Android or Windows ARM dev any easier. I guess the idea is to run a Linux flavor that supports both the M1 and Graviton on the macs and hope any native work is compatible?
- wmf 6y ago
  It's not hope; ARM64 is compatible with ARM64 by definition. The same binaries can be used in development and production. Windows ARM development (in a VM) should be much faster on an M1 Mac than on an x86 computer since no emulation is needed.
  - jayd16 6y ago
    >It's not hope; ARM64 is compatible with ARM64 by definition Linux, mac or windows ARM64 binaries are not cross compatible by definition, thus my question. Is everyone excited to run a Graviton supported Linux distro on these M1s or is there something else? I would also be surprised if every M1 graphics feature was fully supported on these Amazon chips. If we're talking about cross compatibility then we can't use any binaries compiled for any M1 specific features either...So no. Its not compatible by definition.
- _alex_ 6y ago
  dev in a linux vm/container on your M1 macbook, then deploy to a graviton instance.
ksec 6y ago
I commented [1] on something similar a few days ago, >Cloud (Intel) isn’t really challenged yet.... AWS are estimated to be ~50% of HyperScalers. HyperScalers are estimated to be 50% of Server and Cloud Business. HyperScalers are expanding at a rate faster than other market. HyperScaler expanding trend are not projected to be slowing down anytime soon. AWS intends to have all of their own workload and SaaS product running on Graviton / ARM. ( While still providing x86 services to those who needs it ) Google and Microsoft are already gearing up their own ARM offering. Partly confirmed by Marvell's exit of ARM Server. >The problem is single core Arm performance outside of Apple chips isn’t there. Cloud computing charges per vCPU. On all current x86 instances, that is one hyper-thread. On AWS Graviton, vCPU = Actual CPU Core. There are plenty of workloads, and large customers like Twitter and Pinterest has tested and shown AWS Graviton 2 vCPU perform better than x86. All while being 30% cheaper. At the end of the day, it is workload / dollars that matters on Cloud computing. And right now in lots of applications Graviton 2 are winning, and in some cases by large margin. If AWS sell 50% of their services with ARM in 5 years time, that is 25% of Cloud Business Alone. Since it offer a huge competitive advantage Google and Microsoft has no other choice but to join the race. And then there will be enough of a market force for Qualcomm, or may be Marvell to Fab a commodity ARM Server part for the rest of the market. Which is why I was extremely worried about Intel. (Half of) The lucrative Server market is basically gone. ( And I haven't factored in AMD yet ) 5 years in Tech hardware is basically 1-2 cycles. And there is nothing on Intel's roadmap that shown they have the chance to compete apart from marketing and sales tactics. Which still goes a long way if I have to be honest, but not sustainable in long term. It is more of a delaying tactics. Along with a CEO that despite trying very hard, had no experience in market and product business. Luckily that is about to change. Evaluating ARM switch takes time, Software preparation takes time, and more importantly, getting wafer from TSMC takes time as demand from all market are exceeding expectations. But all of them are already in motion, and if these are the kind of response you get from Graviton 2, imagine Graviton 3. [1] https://news.ycombinator.com/item?id=25808856 https://news.ycombinator.com/item?id=25808856
- spideymans 6y ago
  >Which is why I was extremely worried about Intel. (Half of) The lucrative Server market is basically gone. Right. I suspect in time we'll look back to this time, and realize that it was already too late for Intel to right the ship, despite ARM having a tiny share of PC and server sales. Their PC business is in grave danger as well. Within a few years, we're going to see ARM-powered Windows PCs that are competitive with Intel's offerings in several metrics, but most critically, in power efficiency. These ARM PCs will have tiny market share (<5%) for the first few years, because the manufacturing capacity to supplant Intel simply does not exist. But despite their small marketshare, these ARM PCs will have a devastating impact on Intel's future. Assuming these ARM PCs can emulate x86 with sufficient performance (as Apple does with Rosetta), consumers and OEMs will realize that ARM PCs work just as well as x86 Intel PCs. At that point, the x86 "moat" will have been broken, and we'll see ARM PCs grow in market share in lockstep with the improvements in ARM manufacturing capacity (TSMC, etc...). Intel is in a downward spiral, and I've seen no indication that they know how to solve it. Their best "plan" appears to be to just hope that their manufacturing issues get sorted out quickly enough that they can right the ship. But given their track record, nobody would bet on that happening. Intel better pray that Windows x86 emulation is garbage. Intel does not have the luxury of time to sort out their issues. They need more competitive products to fend off ARM, today. Within a year or two, ARM will have a tiny but critical foothold in the PC and server market that will crack open the x86 moat, and invite ever increasing competition from ARM.
dfgdghdf 6y ago
Aren't most of us already programming against a virtual machine, such as Node, .NET or the JVM? I think the CPU architecture hardly matters today.
- dboreham 6y ago
  Having worked some on maintaining a stack on both Intel and ARM, it matters less than it did, but it's not a NOOP. e.g. Node packages with native modules are often not available prebuilt for ARM, and then the build fails due to ... <after 2 days debugging C++ compilation errors, you might know>.
- DreadY2K 6y ago
  Many people do code against some sort of VM, but there are still people writing code in C/C++/Rust/Go/&c that gets compiled to machine code and run directly. Also, even if you're running against a VM, your VM is running on an ISA, so performance differences between them are still relevant to your code's performance.
  - ncmncm 6y ago
    C, C++, Rust, & Go compile to an abstract machine, instead. It is quite hard these days to get it to do something different between x86, ARM, and Power, except relying on memory model features not guaranteed on the latter two; and on M1 the memory model apes x86's. Given a compatible memory model (which, NB, ARM has not had until M1) compiling for the target is trivial. The x86 memory model makes it increasingly hard to scale performance to more cores. That has not held up AMD much, mainly because people don't scale things out that don't perform well when they do, and use a GPU when that does better. In principle it has to break at some point, but that has been said for a long time. It is indefinitely hard to port code developed on x86 to a more relaxed memory model, so the overwhelming majority of such codes will never be ported.
    - wmf 6y ago
      Note that M1 only uses TSO for Rosetta; ARM code runs with the ARM weak memory model.
skohan 6y ago
This is kind of what should happen right? I'm not an expert, but my understanding is that one of the takeaways from the M1 success has been the weaknesses of x86 and CISC in general. It seems as if there is a performance ceiling which exists for x86 due to things like memory ordering requirements, and complexity of legacy instructions, which just don't exist for other instruction sets. My impression is that we have been living under the cruft of x86 because of inertia, and what are mostly historical reasons, and it's mostly a good thing if we move away from it.
- sf_rob 6y ago
  Isn't most of M1's performance success due to being a SoC / increasing component locality/bandwidth? I think ARM vs x86 performance on its own isn't a disadvantage. Instead the disadvantages are a bigger competitive landscape (due to licensing and simplicity), growing performance parity, and SoCs arguable being contrary to x86 producers' business models.
  - UncleOxidant 6y ago
    ARM instructions are also much easier to decode than x86 instructions which allowed the M1 designers to have more instruction decoders and this, IIRC, is one of the important contributors to the M1's high performance.
  - erosenbe0 6y ago
    Umm, Intel laptop chips are SoC with onchip graphics, pci4, wifi, usb4, and thunderbolt4 controller, connectivity direct to many audio codec channels, plus some other functionality for dsp and encryption.
- kllrnohj 6y ago
  > weaknesses of x86 and CISC in general "RISC" and "CISC" distinctions are murky, but modern ARM is really a CISC design these days. ARM is not at all in a "an instruction only does one simple thing, period" mode of operation anymore. It's grown instructions like "FJCVTZS", "AESE", and "SHA256H" If anything CISC has overwhelmingly and clearly won the debate. RISC is dead & buried, at least in any high-performance product segment (TBD how RISC-V ends up fairing here). It's largely "just" the lack of variable length instructions that helps the M1 fly (M1 under Rosetta 2 runs with the same x86 memory model, after all, and is still quite fast).
rauhl 6y ago
> I have a MBP, as do all of my engineers. Within a few years all of these machines will age out and be replaced with m1 powered machines. At that point the idea of developing on ARM and deploying on x86 will be unpleasant Is it not at least somewhat possible that at least some of those Apple laptops will age out and be replaced with GNU/Linux laptops? Agreed that developing on ARM and deploying on x86 is unpleasant, but so too is developing on macOS and deploying on Linux. Apple’s GNU userland is pretty ancient, and while the BSD parts are at least updated, they are also very austere. Given that friction is already there, is it likelier that folks will try to alleviate it with macOS in the cloud or GNU/Linux locally? Mac OS X was a godsend in 2001: it put a great Unix underneath a fine UI atop good hardware. It dragged an awful lot of folks three-quarters of the way to a free system. But frankly I believe Apple have lost ground UI-wise over the intervening decades, while free alternatives have gained it (they are still not at parity, granted). Meanwhile, the negatives of using a proprietary OS are worse, not better.
- old-gregg 6y ago
  > Is it not at least somewhat possible that at least some of those Apple laptops will age out and be replaced with GNU/Linux laptops? And I personally hope that by then, GNU/Linux will have an M1-like processor available to happily run on. The possibilities demonstrated by this chip (performance+silence+battery) are so compelling that it's inevitable we'll see them in non-Apple designs. Also, as it usually happens with Apple hardware advancements, Linux experience will be gradually getting better on M1 Macbooks as well.
  - davish 6y ago
    I think we can look to mobile to see how feasible this might be: consistently over the past decade, iPhones have matched or exceeded Android performance with noticeably smaller capacity batteries. A-series chips and Qualcomm chips are both ARM. Apple's tight integration comes with a cost when it comes to flexibility, and, you can argue, developer experience, but it's clearly not just the silicon itself that leads to the performance we're seeing in the M1 Macs.
Steltek 6y ago
How much does arch matter if you're targeting AWS? Aren't the differences between local service instances vs instances running in the cloud a much bigger problem for development?
d33lio 6y ago
While I generally agree with this sentiment a lot of people don't realize how much enterprise supply chain / product chain vastly varies from the consumer equivalent. Huge customers that buy intel chips at datacenter scale are pandered to and treated like royalty by both intel and amd. Companies are courted in the earliest stages of cutting edge technical development and product development and given rates so low (granted for huge volume) that most consumers would not even believe. The fact that companies like Serve The Home exist proves this - for those who don't know, the realy business model of Serve The Home is to give enterprise clients the ability to play around with a whole data center of leading edge tech, Serve The Home is simply a marketing "edge api" of sorts for the operation. Sure it might look like intel isn't "competitive" but many of the intel V amd flame wars in the server space for un released tech have already had their bidding wars settled years ago for this very tech. One thing to also consider is why amazon hugely prioritizes using their "services" and not deploying on bare metal is likely because they can execute their "services" on cheapo arm hardware. Bare metal boxes and VM's give the impression that customer's software will perform in an x86 esque matter. For amazon, the cost of the underlying compute per core is irrelevant since they've already solved the issue of using blazing fast network links to mesh their hardware together - in this way, the ball is heavily in Arm's court for the future of Amazon data centers, although banking and gov clients will likely not move away from X86 any time soon.
hendry 6y ago
Can't take Graviton seriously until I can run my binaries via Lambda on it.

mhh__ 6y ago

I can see this happening for things that run in entirely managed environments but I don't think AWS can make the switch fully until that exact hardware is on people's benches. Doing microbenchmarking is quite awkward on the cloud, whereas anyone with a Linux laptop from the last 20 years can access PMCs for their hardware

ashtonkem 6y ago
Professional laptops don’t last that long, and a lot of developers are given MBPs for their work. I personally expect that I’ll get a M1 laptop from my employer within the next 2 years. At that point the pressure to migrate from x86 to ARM will start to increase.
- mhh__ 6y ago
  You miss my point - if I am seriously optimizing something I need to be on the same chip not the same ISA. Graviton2 is a Neoverse core from Arm and it's totally separate from M1. Besides, Apple don't let you play with PMCs easily and I'm assuming they won't be publishing any event tables any time soon so unless they get reverse engineered you'll have to do it through xcode.
  - ashtonkem 6y ago
    Yes, the m1 isn’t a graviton 2. But then again the mobile i7 in my current MBP isn’t the same as the Xeon processors my code runs on in production. This isn’t about serious optimization, but rather the ability for a developer to reasonably estimate how well their code will work in prod (e.g. “will it deadlock”). The closer your laptop gets to prod, the narrower the error bars get, but they’ll never go to zero. And keep in mind this is about reducing the incentive to switch to a chip that’s cheaper per compute unit in the cloud. If Graviton 2 was more expensive or just equal in price to x86, I doubt that M1 laptops alone would be enough to incentivize a switch.
    - mhh__ 6y ago
      That's true but the Xeon cores are much easier to compare and correlate because of the aforementioned access to well defined and supported performance counters rather than Apple's holier than thou approach to developers outside the castle.
  - lostapathy 6y ago
    This is typical Hacker News. Yes, some people "seriously optimize" but the vast majority of software written is not heavily optimized nor is it written at companies with good engineering culture. Most code is worked on until it'll pass QA then thrown over the wall. For that majority of people, an M1 is definitely close enough to a graviton.
    - mhh__ 6y ago
      > typical hacker news Let me have my fun!
  - foobarian 6y ago
    We have MBPs on our desks but our cloud are Centos Xeon machines. The problems I run into are not squeezing every last ms of performance, since it's vastly cheaper to just add more instances. The problems I care about is that some script I wrote suddenly doesn't work in production because of BSDisms, or Python incompatibilities, or old packages in brew, etc. Would be nice if Apple waved a magic wand and replaced its BSD subsystem with Centos* but I won't be holding my breath :) * yes I know Centos is done, substitute as needed.
sitkack 6y ago
Very little user code generates binaries that can _tell_ it is running on non-x86 hardware. Rust is Arm Memory Model safe, existing C/C++ code that targets the x86 memory model is slowly getting ported over, but unless you are writing multithreaded C++ code that cuts corners it isn't an issue. Running on the JVM, Ruby, Python, Go, Dlang, Swift, Julia or Rust and you won't notice a difference. It will be sooner than you think.
- mhh__ 6y ago
  It's not the memory model I'm thinking of but the cache design, ROB size etc. Obviously this is fairly niche but the friction to making something fast is hugely easier locally.
  - sitkack 6y ago
    The vast majority of developers never profile their code. I think this is much less of an issue than anyone on HN would rank it. Only when the platform itself provides traces do they take it into consideration. And even then, I think most perf optimization is in a category of don't do the obviously slow thing, or the accidentally n^2 thing. I partially agree with you though, as the penetration of Arm goes deeper into the programmer ecosystem, any mental roadblocks about deploying to Arm will disappear. It is a mindset issue, not a technical one. In the 80s and 90s there were lots of alternative architectures and it wasn't a big deal, granted the software stacks were much much smaller and more metal. Now they are huge, but more abstract and farther away from machine issues.
    - mhh__ 6y ago
      This isn't really about you or me but the libraries that work behind the spaghetti people fling into the cloud.
      - vinay_ys 6y ago
        Yes, and just like Intel & AMD spent a lot of effort/funding for building performance libraries and compilers, we should expect Amazon and Apple invest into similar efforts. Apple will definitely give all the necessary tools as part of Xcode for iOS/MacOS software optimisation. AWS is going to be more interesting – this is a great opportunity for them to provide distributed profiling/tracing tools (as a hosted service, obviously) for Linux that run across a fleet of Graviton instances and help you do fleet-wide profile guided optimizations. We should also see a lot of private companies building high-performance services on AWS to contribute to highly optimized open-source libraries being ported to graviton.
api 6y ago
I don't think it takes "exact" hardware. It takes ARM64, which M1 delivers. I already have a test M1 machine with Linux running in a Parallels (tech preview) VM and it works great.
Someone 6y ago
I would think the number of developers that have “that exact hardware” on their bench is extremely small (does AWS even tell you what cpu you get?) What fraction of products deployed to the cloud even has its developers seen doing _any_ microbenchmarking?

ghettoimp 6y ago

If it can emulate x86, is there really a motivation for developers to switch to ARM? (I don't have an M1 and don't really know what it's like to compile stuff and deploy it to "the cloud.")

ashtonkem 6y ago
Emulation is no way to estimate performance.
- acoard 6y ago
  Sure, but as a counter example Docker performance on Mac has historically been abysmal[0][1], but everyone on Mac I know still develops using it. We ignore the performance hit on dev machines, knowing it won't affect prod (Linux servers). I don't see why this pattern would fail to hold, but am open to new perspectives. [0] https://dev.to/ericnograles/why-is-docker-on-macos-so-much-worse-than-linux-flh https://dev.to/ericnograles/why-is-docker-on-macos-so-much-w... [1] https://www.reddit.com/r/docker/comments/bh8rpf/docker_performance_on_macos_vs_native_linux/ https://www.reddit.com/r/docker/comments/bh8rpf/docker_perfo...
  - remexre 6y ago
    The VM that uses takes advantage of hardware-accelerated virtualization, for running amd64 VMs on amd64 CPUs. You don't have hardware-accelerated virtualization for amd64 VMs on any ARM CPUs I know of...
  - fomine3 6y ago
    Abysmal Docker performance on non-Linux is mainly because of filesystem isn't native, not by CPU virtualization.

dogma1138 6y ago

At that point if it will be trouble for Intel it would be a death sentence for AMD... Intel has fabs, yes it’s what maybe holding them back atm but it also a big factor in what maintains their value. If x86 dies and neither Intel nor AMD pivot in time Intel can become a fab company they already offer these services, yes no where near the scale of say TSMC but they have a massive portfolio of fabs and their fabs are located in the west, they also have a massive IP portfolio related to everything form IC design to manufacturing.

skohan 6y ago
AMD also has a GPU division.
- dogma1138 6y ago
  Intel makes more money selling their WiFi chipsets than AMD makes on selling GPUs heck even including consoles...
  - shrewduser 6y ago
    got a source for that? sounds hard to believe.
    - dogma1138 6y ago
      Computing and Graphics which includes the Radeon technology group revenue for AMDs last quarter was £1.67B industry estimates are that $1.2-1.3B were from CPU sales. Intel’s Internet of Things group alone revenue last quarter was $680M and they hit $1B IOTG revenue previously https://www.statista.com/statistics/1096381/intel-internet-of-things-group-revenue/ https://www.statista.com/statistics/1096381/intel-internet-o...
nickik 6y ago
AMD makes great designs, switching to ARM/RISC-V would make them lose value but not kill them.

tapirl 6y ago

Intel's fate predicted in 2014: https://pbs.twimg.com/media/ErrFtv0UwAA4JaW?format=png https://pbs.twimg.com/media/ErrFtv0UwAA4JaW?format=png

afavour 6y ago
On the flip side that post illustrates just how things can go wrong, too: Windows RT was a flop.
- tapirl 6y ago
  It is more a stance to show Microsoft is ready to put Windows on arm CPUs if x86 loses the market.
- deaddodo 6y ago
  Precisely for the reasons he gave though. It wasn't a unified experience. RT had lackluster support, no compatibility and a stripped down experience. They're trying to fix it with Windows on ARM now, but that's what people were asking for back then.

BenoitEssiambre 6y ago

Yeah and I assume we are going to see Graviton/Amazon linux based notebooks any day now.

agloeregrets 6y ago
Honestly, if Amazon spun this right and they came pre-setup for development and distribution and had all the right little specs (13 and 16 inch sizes, HiDPI matte displays, long battery life, solid keyboard, macbook-like trackpad) they could really hammer the backend dev market. Bonus points if they came with some sort of crazy assistance logic like each machine getting a pre-setup AWS Windows server for streaming windows X86 apps.
- heartbreak 6y ago
  > could really hammer the backend dev market That's worth, what, a few thousand unit sales?
  - easton 6y ago
    If they could get it to $600-800 and have an option for Windows, decent trackpad/keyboard, you could sell them to students just as well. Shoot, if the DE for Amazon Linux was user friendly enough they wouldn’t even need windows, since half of schools are on GSuite these days.
  - TheOperator 6y ago
    The point wouldn't be to sell laptops.
    - agloeregrets 6y ago
      Exactly.
- yesbabyyes 6y ago
  Like a Bloomberg machine for devops.

Const-me 6y ago

Building server software on Graviton ARM creates a vendor lock-in to Amazon, with very high costs of switching elsewhere. Despite using A64 ISA and ARM’s cores, they are Amazon’s proprietary chips no one else has access to. Migrating elsewhere gonna be very expensive. I wouldn’t be surprised if they sponsor their Graviton offering taking profits elsewhere. This might make it seem like a good deal for customers, but I don’t think it is, at least not in the long run. This doesn’t mean Graviton is useless. For services running Amazon’s code as opposed to customer’s code (like these PAAS things billed per transaction) the lock-in is already in place, custom processors aren’t gonna make it any worse.

dragontamer 6y ago
I'm not necessarily disagreeing with you, but... maybe elaborating in a contrary manner? Graviton ARM is certainly vendor lock-in to Amazon. But a Graviton ARM is just a bog-standard Neoverse N1 core. Which means the core is going to show similar characteristics as the Ampere Altra (also a bog-standard Neoverse N1 core). There's more to a chip than its core. But... from a performance-portability and ISA perspective... you'd expect performance-portability between Graviton ARM and Ampere Altra. Now Ampere Altra is like 2x80 core, while Graviton ARM is... a bunch of different configurations. So its still not perfect compatibility. But a single-threaded program probably couldn't tell the difference between the two platforms. I'd expect that migrating between Graviton and Ampere Altra is going to be easier than Intel Skylake -> AMD Zen.
- Const-me 6y ago
  > you'd expect performance-portability between Graviton ARM and Ampere Altra I agree, that would what I would expect too. Still, are there many public clouds built of these Ampere Altra-s? Maybe we gonna have them widespread soon, but until then I wouldn’t want to build stuff that only runs on Amazon or my own servers with only a few on the market and not yet globally available on retail. Also, AFAIK on ARM the parts where CPUs integrate with the rest of the hardware are custom. The important thing for servers, disk and network I/O differs across ARM chips of the same ISA. Linux kernel abstracts it away i.e. stuff is likely to work, but I’m not so sure about performance portability.

jayd16 6y ago

I guess I don't understand why the M1 makes developing on Graviton easier. It doesn't make Android or Windows ARM dev any easier. I guess the idea is to run a Linux flavor that supports both the M1 and Graviton on the macs and hope any native work is compatible?

wmf 6y ago
It's not hope; ARM64 is compatible with ARM64 by definition. The same binaries can be used in development and production. Windows ARM development (in a VM) should be much faster on an M1 Mac than on an x86 computer since no emulation is needed.
- jayd16 6y ago
  >It's not hope; ARM64 is compatible with ARM64 by definition Linux, mac or windows ARM64 binaries are not cross compatible by definition, thus my question. Is everyone excited to run a Graviton supported Linux distro on these M1s or is there something else? I would also be surprised if every M1 graphics feature was fully supported on these Amazon chips. If we're talking about cross compatibility then we can't use any binaries compiled for any M1 specific features either...So no. Its not compatible by definition.
_alex_ 6y ago
dev in a linux vm/container on your M1 macbook, then deploy to a graviton instance.

ksec 6y ago

I commented [1] on something similar a few days ago, >Cloud (Intel) isn’t really challenged yet.... AWS are estimated to be ~50% of HyperScalers. HyperScalers are estimated to be 50% of Server and Cloud Business. HyperScalers are expanding at a rate faster than other market. HyperScaler expanding trend are not projected to be slowing down anytime soon. AWS intends to have all of their own workload and SaaS product running on Graviton / ARM. ( While still providing x86 services to those who needs it ) Google and Microsoft are already gearing up their own ARM offering. Partly confirmed by Marvell's exit of ARM Server. >The problem is single core Arm performance outside of Apple chips isn’t there. Cloud computing charges per vCPU. On all current x86 instances, that is one hyper-thread. On AWS Graviton, vCPU = Actual CPU Core. There are plenty of workloads, and large customers like Twitter and Pinterest has tested and shown AWS Graviton 2 vCPU perform better than x86. All while being 30% cheaper. At the end of the day, it is workload / dollars that matters on Cloud computing. And right now in lots of applications Graviton 2 are winning, and in some cases by large margin. If AWS sell 50% of their services with ARM in 5 years time, that is 25% of Cloud Business Alone. Since it offer a huge competitive advantage Google and Microsoft has no other choice but to join the race. And then there will be enough of a market force for Qualcomm, or may be Marvell to Fab a commodity ARM Server part for the rest of the market. Which is why I was extremely worried about Intel. (Half of) The lucrative Server market is basically gone. ( And I haven't factored in AMD yet ) 5 years in Tech hardware is basically 1-2 cycles. And there is nothing on Intel's roadmap that shown they have the chance to compete apart from marketing and sales tactics. Which still goes a long way if I have to be honest, but not sustainable in long term. It is more of a delaying tactics. Along with a CEO that despite trying very hard, had no experience in market and product business. Luckily that is about to change. Evaluating ARM switch takes time, Software preparation takes time, and more importantly, getting wafer from TSMC takes time as demand from all market are exceeding expectations. But all of them are already in motion, and if these are the kind of response you get from Graviton 2, imagine Graviton 3. [1] https://news.ycombinator.com/item?id=25808856 https://news.ycombinator.com/item?id=25808856

spideymans 6y ago
>Which is why I was extremely worried about Intel. (Half of) The lucrative Server market is basically gone. Right. I suspect in time we'll look back to this time, and realize that it was already too late for Intel to right the ship, despite ARM having a tiny share of PC and server sales. Their PC business is in grave danger as well. Within a few years, we're going to see ARM-powered Windows PCs that are competitive with Intel's offerings in several metrics, but most critically, in power efficiency. These ARM PCs will have tiny market share (<5%) for the first few years, because the manufacturing capacity to supplant Intel simply does not exist. But despite their small marketshare, these ARM PCs will have a devastating impact on Intel's future. Assuming these ARM PCs can emulate x86 with sufficient performance (as Apple does with Rosetta), consumers and OEMs will realize that ARM PCs work just as well as x86 Intel PCs. At that point, the x86 "moat" will have been broken, and we'll see ARM PCs grow in market share in lockstep with the improvements in ARM manufacturing capacity (TSMC, etc...). Intel is in a downward spiral, and I've seen no indication that they know how to solve it. Their best "plan" appears to be to just hope that their manufacturing issues get sorted out quickly enough that they can right the ship. But given their track record, nobody would bet on that happening. Intel better pray that Windows x86 emulation is garbage. Intel does not have the luxury of time to sort out their issues. They need more competitive products to fend off ARM, today. Within a year or two, ARM will have a tiny but critical foothold in the PC and server market that will crack open the x86 moat, and invite ever increasing competition from ARM.

dfgdghdf 6y ago

Aren't most of us already programming against a virtual machine, such as Node, .NET or the JVM? I think the CPU architecture hardly matters today.

dboreham 6y ago
Having worked some on maintaining a stack on both Intel and ARM, it matters less than it did, but it's not a NOOP. e.g. Node packages with native modules are often not available prebuilt for ARM, and then the build fails due to ... <after 2 days debugging C++ compilation errors, you might know>.
DreadY2K 6y ago
Many people do code against some sort of VM, but there are still people writing code in C/C++/Rust/Go/&c that gets compiled to machine code and run directly. Also, even if you're running against a VM, your VM is running on an ISA, so performance differences between them are still relevant to your code's performance.
- ncmncm 6y ago
  C, C++, Rust, & Go compile to an abstract machine, instead. It is quite hard these days to get it to do something different between x86, ARM, and Power, except relying on memory model features not guaranteed on the latter two; and on M1 the memory model apes x86's. Given a compatible memory model (which, NB, ARM has not had until M1) compiling for the target is trivial. The x86 memory model makes it increasingly hard to scale performance to more cores. That has not held up AMD much, mainly because people don't scale things out that don't perform well when they do, and use a GPU when that does better. In principle it has to break at some point, but that has been said for a long time. It is indefinitely hard to port code developed on x86 to a more relaxed memory model, so the overwhelming majority of such codes will never be ported.
  - wmf 6y ago
    Note that M1 only uses TSO for Rosetta; ARM code runs with the ARM weak memory model.

skohan 6y ago

This is kind of what should happen right? I'm not an expert, but my understanding is that one of the takeaways from the M1 success has been the weaknesses of x86 and CISC in general. It seems as if there is a performance ceiling which exists for x86 due to things like memory ordering requirements, and complexity of legacy instructions, which just don't exist for other instruction sets. My impression is that we have been living under the cruft of x86 because of inertia, and what are mostly historical reasons, and it's mostly a good thing if we move away from it.

sf_rob 6y ago
Isn't most of M1's performance success due to being a SoC / increasing component locality/bandwidth? I think ARM vs x86 performance on its own isn't a disadvantage. Instead the disadvantages are a bigger competitive landscape (due to licensing and simplicity), growing performance parity, and SoCs arguable being contrary to x86 producers' business models.
- UncleOxidant 6y ago
  ARM instructions are also much easier to decode than x86 instructions which allowed the M1 designers to have more instruction decoders and this, IIRC, is one of the important contributors to the M1's high performance.
- erosenbe0 6y ago
  Umm, Intel laptop chips are SoC with onchip graphics, pci4, wifi, usb4, and thunderbolt4 controller, connectivity direct to many audio codec channels, plus some other functionality for dsp and encryption.
kllrnohj 6y ago
> weaknesses of x86 and CISC in general "RISC" and "CISC" distinctions are murky, but modern ARM is really a CISC design these days. ARM is not at all in a "an instruction only does one simple thing, period" mode of operation anymore. It's grown instructions like "FJCVTZS", "AESE", and "SHA256H" If anything CISC has overwhelmingly and clearly won the debate. RISC is dead & buried, at least in any high-performance product segment (TBD how RISC-V ends up fairing here). It's largely "just" the lack of variable length instructions that helps the M1 fly (M1 under Rosetta 2 runs with the same x86 memory model, after all, and is still quite fast).

rauhl 6y ago

> I have a MBP, as do all of my engineers. Within a few years all of these machines will age out and be replaced with m1 powered machines. At that point the idea of developing on ARM and deploying on x86 will be unpleasant Is it not at least somewhat possible that at least some of those Apple laptops will age out and be replaced with GNU/Linux laptops? Agreed that developing on ARM and deploying on x86 is unpleasant, but so too is developing on macOS and deploying on Linux. Apple’s GNU userland is pretty ancient, and while the BSD parts are at least updated, they are also very austere. Given that friction is already there, is it likelier that folks will try to alleviate it with macOS in the cloud or GNU/Linux locally? Mac OS X was a godsend in 2001: it put a great Unix underneath a fine UI atop good hardware. It dragged an awful lot of folks three-quarters of the way to a free system. But frankly I believe Apple have lost ground UI-wise over the intervening decades, while free alternatives have gained it (they are still not at parity, granted). Meanwhile, the negatives of using a proprietary OS are worse, not better.

old-gregg 6y ago
> Is it not at least somewhat possible that at least some of those Apple laptops will age out and be replaced with GNU/Linux laptops? And I personally hope that by then, GNU/Linux will have an M1-like processor available to happily run on. The possibilities demonstrated by this chip (performance+silence+battery) are so compelling that it's inevitable we'll see them in non-Apple designs. Also, as it usually happens with Apple hardware advancements, Linux experience will be gradually getting better on M1 Macbooks as well.
- davish 6y ago
  I think we can look to mobile to see how feasible this might be: consistently over the past decade, iPhones have matched or exceeded Android performance with noticeably smaller capacity batteries. A-series chips and Qualcomm chips are both ARM. Apple's tight integration comes with a cost when it comes to flexibility, and, you can argue, developer experience, but it's clearly not just the silicon itself that leads to the performance we're seeing in the M1 Macs.

Steltek 6y ago

How much does arch matter if you're targeting AWS? Aren't the differences between local service instances vs instances running in the cloud a much bigger problem for development?

d33lio 6y ago

While I generally agree with this sentiment a lot of people don't realize how much enterprise supply chain / product chain vastly varies from the consumer equivalent. Huge customers that buy intel chips at datacenter scale are pandered to and treated like royalty by both intel and amd. Companies are courted in the earliest stages of cutting edge technical development and product development and given rates so low (granted for huge volume) that most consumers would not even believe. The fact that companies like Serve The Home exist proves this - for those who don't know, the realy business model of Serve The Home is to give enterprise clients the ability to play around with a whole data center of leading edge tech, Serve The Home is simply a marketing "edge api" of sorts for the operation. Sure it might look like intel isn't "competitive" but many of the intel V amd flame wars in the server space for un released tech have already had their bidding wars settled years ago for this very tech. One thing to also consider is why amazon hugely prioritizes using their "services" and not deploying on bare metal is likely because they can execute their "services" on cheapo arm hardware. Bare metal boxes and VM's give the impression that customer's software will perform in an x86 esque matter. For amazon, the cost of the underlying compute per core is irrelevant since they've already solved the issue of using blazing fast network links to mesh their hardware together - in this way, the ball is heavily in Arm's court for the future of Amazon data centers, although banking and gov clients will likely not move away from X86 any time soon.

hendry 6y ago

Can't take Graviton seriously until I can run my binaries via Lambda on it.