Slashdot Mirror

← Back to Stories (view on slashdot.org)

Amazon Web Services Introduces its Own Custom-Designed ARM Server Processor, Promises 45 Percent Lower Costs For Some Workloads (geekwire.com)

Posted by msmash on from the shape-of-things-to-come dept.

After years of waiting for someone to design an ARM server processor that could work at scale on the cloud, Amazon Web Services just went ahead and designed its own. From a report: Vice president of infrastructure Peter DeSantis introduced the AWS Graviton Processor Monday night, adding a third chip option for cloud customers alongside instances that use processors from Intel and AMD. The company did not provide a lot of details about the processor itself, but DeSantis said that it was designed for scale-out workloads that benefit from a lot of servers chipping away at a problem. The new instances will be known as EC2 A1, and they can run applications written for Amazon Linux, Red Hat Enterprise Linux, and Ubuntu. They are generally available in four regions: US East (Northern Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland). Intel dominates the market for server processors, both in the cloud and in the on-premises server market. AMD has tried to challenge that lead over the years with little success, although its new Epyc processors have been well-received by server buyers and cloud companies like AWS. John Gruber of DaringFireball, where we first spotted this story, adds: Makes you wonder what the hell is going on at Intel and AMD -- first they missed out on mobile, now they're missing out on the cloud's move to power-efficient ARM chips.

65 comments

  1. snicker snort by drinkypoo · · Score: 3

    Makes you wonder what the hell is going on at Intel and AMD -- first they missed out on mobile, now they're missing out on the cloud's move to power-efficient ARM chips.

    Now hold on thar, pardner. The industry has been building ARM-based servers for ages. They have so far failed to take off because power consumption isn't the most important factor for servers. Let's wait to see how much of teh cloud goes ARM before we declare this the year of ARM on the server.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    1. Re:snicker snort by thegarbz · · Score: 2

      On top of this the comment acts like you just flip a switch and produce a power efficient processor. Moving to ARM would involve a product that they aren't overly familiar with, in a platform (non-plug and play) that both companies generally don't have much experience with, and god forbid they may actually need to pay license fees without any guaranteed ROI.

      TFHeadline says it nicely: "Some workloads"

    2. Re:snicker snort by supremebob · · Score: 2

      I don't think that we're really sure yet that customers really WANT power-efficient ARM chips. I think that many of them are more worried about x86 compatibility right now.

      Hell... there are a lot of people out there who are afraid to move off of Intel processors because they can't be sure that their vendors validated their older software on the AMD Epyc stuff yet.

    3. Re:snicker snort by jellomizer · · Score: 3, Insightful

      The primary thing is price/processing power.
      Power Consumption is part of the price. its over all performance is also a big deal, also the size the data center fills up, and ability to have staff to be able to code for the data center.

      Intel and AMD server design was to boost processing power to make the radio low. However now we are moving to more parallel software designs, where we find the big power chips are not fully utilized. While we can take more cheaper slower low power chips and get more processing power for the total cost.

      The Intel and AMD chips are Semi-trucks of processors while what is needed are delivery vans.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    4. Re:snicker snort by Hadlock · · Score: 3, Interesting

      99% of my workload in AWS is on open source code, mostly python, with some commercial java products, and a couple of private proprietary java apps. The 1% that is not is our VPN software that IT runs. All of this runs in Kubernetes. Inside that number is also our entire Jenkins/Selenium CI/CD process for QA. Our Kubernetes spend is $4000-8000/month, 100% of our kubernetes spend could run on ARM tomorrow just by adding an ARM build target for the container.
       
      If we could shrink our AWS K8S spend from $8000 to $4000 per month, that is almost $50,000 in annual savings. My boss would buy me a round trip ticket to Europe if we accomplished that kind of monthly savings.
       
      ARM might not be useful for someone in the Windows world, but there is very much zero reason why our company would be tied to intel arch, and we weren't even trying to be architecture agnostic. I suspect that if Amazon can offer ARM at a competitive cost to intel with the same reliability, people will make the jump. I can see putting all our low priority processes on ARM in the next quarter to save money.

      --
      moox. for a new generation.
    5. Re:snicker snort by Anonymous Coward · · Score: 0

      It's a cycle. Every few years, marketing bees shout the virtues of running processes across many slower CPUs vs running your application on one (or a few) fast CPUs. On paper the math looks great. But in reality, running a process on one CPU at full speed is not the same as running a process on two CPUs at half speed.

      For a while we had the crappiest line of laptops coming off the line claiming more (slower cores) were just as good as a single (fast) core. They were slow and people noticed. It stayed that way until the big two started pumping out CPUs on clock steroids again.

      If ARM cant process instructions like a Semi-truck in the server room, it will always be an almost contender.

    6. Re:snicker snort by guruevi · · Score: 1

      A lot of the "cloud" load is poorly written, open and compatible across broad ranges. The drawback of writing in languages like Python/MATLAB is the immense language overhead compared to well-written, optimized C and assembler. That's why ARM in these kinds of load is suddenly 'good' because most of the time the processor is not spent calculating but sitting idly around reading in instructions or waiting for other nodes.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    7. Re:snicker snort by Anonymous Coward · · Score: 0

      Wait, so the cheapest ARM instance in the EC2 space is $19/mo? Yikes. (Assuming you aren't using spot instances/reserved instances.) That's pricey when some of the other AWS instances go down to $5/mo for the same thing.

    8. Re:snicker snort by LostMyBeaver · · Score: 1

      I'll bite..

      2018 soon 2019... people learn to program from places like CodeAcademy. They take 12 week classes and are professional programmers. Etc...

      Most of the code out there in the world is being produced by people writing node or python scripts. A lot of it is just deploying packages on Linux and running a server. In many cases, it's just a blog deployed by clicking a few links. If you're coding for the cloud, then you would never deploy your own database... well unless you're a moron, you'd use nothing but cloud storage (or in Amazon terms) Elastic everything.

      Probably close to 50% of all code going into the cloud today is pretty much entirely CPU agnostic and if you can do it on x86, you could do it on ARM or anything else and be entirely clueless about it. Linux is Linux, Python is Python.

      So... yeh.. within reason... for most projects (done by programmers, not IT guys.. they always fuck things up) there's really no difference between the platforms.

      I'll toss you a bone though. Coders are not programmers. Coders are generally slapping stuff together non-stop without any real idea how anything works. Programmers should never have a problem switching CPUs. I've been coding on many architectures for decades and to be honest, other than ARM being among the worst with regards to performance.. ALWAYS... I haven't seen a difference between them. So one is, big endian, the other is small. One is 32-bit the other is 64. One works without word alignment, the other demands it. But a CPU is a CPU.

      I will admit that I've had suspicions for a long time that ARM is simply not compatible with a user workflow. It's an amazing design when you really limit the task swapping. But as soon as multithreading is involved, it chokes. This is why it works so well on phones and Nintendo and such. It's great when you have one single foreground application. But it's a crappy system when you're running multiple equal class citizens like server processes and such.

      Yes, there is an ARM license. But they focus on volume. I think it's something like $1 a core or something like that. It might be $1 per die. But unless you're doing 100 cores, it's pretty cheap.

    9. Re:snicker snort by LostMyBeaver · · Score: 1

      My fear before switching to Docker, ARM and .NET Core was that if I switched to a non-Intel architecture, I might not be able to go back. Meaning, let's say I did something stupid like writing my code to work in the public cloud. Then, I coded and optimized against Amazon's ARM architecture... then Amazon decided to change the terms of service or jack up their prices, etc... then I would be stuck paying and doing whatever they demanded.

      Of course, now with Docker and .NET Core, I simply code towards Docker and ignore the underlying platform.

    10. Re:snicker snort by LostMyBeaver · · Score: 1

      I'm choking here... you're spending up to $96,000 a year on K8S in the cloud? I don't know what you do and to be fair, if there's a solid reason why hosting in the cloud makes more sense than just running it back home... ignore me. But running K8S on premise (or Swarm which I like better) is cheap. I've spent a few thousand bucks on the infrastructure and it's all disposable. Raspberry Pi + Linux + GlusterFS (shared volumes) + Docker + K8S +.NET Core .... it's pretty good. The only problem I have at this time is that while I have Crate.IO in test for SQL... who the hell uses SQL anymore. I'm focused more on NoSQL and would love a functional Couchbase solution, but I'm running that on a few x86 servers which were left over after we realized that VMware was the blackhole of IT spending.

      As for backup, we're backing up GlusterFS volumes to S3, we're backing up Couchbase natively.

      I'm pretty sure that you could self host on LattePanda Alpha for substantially less than you're paying for Amazon.

      The shortcoming in my design of course if you're an online service. Then the money you'd save by self hosting would be entirely consumed by bandwidth and networking costs.

      As for cutting AWS costs... you know that if you move to Lambda, you probably would cut back by as much as 98%? Docker was an insane improvement over VMs... saved companies millions. But if you trim to Lambdas, you can get the same savings again.

    11. Re:snicker snort by thegarbz · · Score: 1

      What has any of that got to do with back end servers supporting cloud infrastructure? The question is not "can it run on ARM?" You have correctly identified that yes a lot of code being churned out today is CPU agnostic. The question is: "Does it make sense to run it on ARM?" That question at the moment is overwhelmingly no for the vast majority of workloads we throw at processors unless the workload in question requires the processor to sit idle and save power for a considerable amount of time.

      If you suitably schedule your client workloads to keep your processors busy then performance is king. There's several test results on the net from companies which have put some ARM cores through their paces which show this. e.g. if you hit an nginx server with an x86 CPU once the ARM core performs about 20% worse while consuming 50% of the power. Sounds good right? Open an SSL session to that same server (nginx consumes significantly more CPU cycles for this obviously) and the ARM core performs about 80% worse while consuming 70% of the power, i.e. it hits its TPD limit and sits there for longer computing.

      If your CPU isn't doing much, ARM may make sense financially. Keep your CPUs busy and the performance / $ equation changes quite a bit. God help you if you need to run an AVX accelerated load on an ARM.

    12. Re:snicker snort by Anonymous Coward · · Score: 0

      who the hell "still" uses SQL? LOLOLOLOLLLLL

      I attended an official couchbase training in jan 2018 (they charged my sucker of a company $30k for it) and the entire time the guy basically just talked about how "niql" or "nickel" or whatever crap it is basically can't do simple basic querying. it was pathetic. everyone in the audience was basically joking with each other in our IMs about him being there to convince us not to use it. 11 months later and the PoC team that was supposed to have revolutionized the company with microservices is still barely sputtering along despite having 5 dedicated FTE programmers. Geez

      yeahhhhhh - good luck over there buddy. i'm sure it has it's uses but your statements show some sad blindspots on your part

  2. Amazon is killing it by Anonymous Coward · · Score: 0

    After managing servers for decades, the jump to AWS had its problems, but holy shit is it effective and cuts down my daily workload considerably.

    1. Re:Amazon is killing it by Anonymous Coward · · Score: 2, Interesting

      After managing servers for decades, the jump to AWS had its problems, but holy shit is it effective and cuts down my daily workload considerably.

      If only their documentation was coherent and usable without mental gymnastics due to poorly written and outdated electronic documents (read HTML pages).

    2. Re:Amazon is killing it by Anonymous Coward · · Score: 1

      Sadly yes, I had to use third party tutorials to get ramped up.

  3. busted link? by necro81 · · Score: 5, Insightful
    I click on the link for the story, and it directs me to:

    https://hardware.slashdot.org/story/18/11/28/1438250/&%23226;&%238364;oehttps://www.geekwire.com/2018/amazon-web-services-introduces-custom-designed-arm-server-processor-promises-45-percent-lower-costs-workloads/&%23226;&%238364;

    Here is a corrected link without the garbage: https://www.geekwire.com/2018/amazon-web-services-introduces-custom-designed-arm-server-processor-promises-45-percent-lower-costs-workloads/

  4. Commodity vs lock-in by GeLeTo · · Score: 3, Informative

    Intel and AMD have a lot to lose if the cloud moves to ARM chips. This will allow many rivals to enter the market - bringing their market share and profit margins down.

    1. Re: Commodity vs lock-in by Anonymous Coward · · Score: 1

      Don't believe the fake news. It's really about HMP vs SMP or what arm (I thought they changed it to lowercase) calls big.LITTLE for no apparent reason. Intel could easily combine an Atom SoC with say, an i7 U-series and just use the same scheduler tricks.

    2. Re:Commodity vs lock-in by Tsolias · · Score: 2

      cloud is fancy talk for servers and servers tend to need a lot of juice.
      There have been numerous attempts to make the transition to arm-based solutions but many big companies, but haven't got too far: amd, qualcomm, cavium, dell, hp, softiron, etc.
      I don't know why everyone reacts as if it's the first time we see this?
      Outside of a very specific spectrum, arm servers cannot offer much.

    3. Re:Commodity vs lock-in by ctilsie242 · · Score: 2

      Intel/AMD gives the best computing ability out there, well, perhaps next to SPARC and POWER, but those CPUs are not really relevant here.

      If you want CPU power, it will be Intel/AMD. If you want best CPU power per watt, ARM by far. Both have their niches. The car example would be saying a Prius is better than a class 8 Kenworth because of its fuel consumption, but the Prius is going to be hard-pressed to move 80,000 pounds of cargo.

      It would be nice if SPARC or POWER were relevant to this. I wonder if they would offer not just top tier compute power, but a better MIPS/watt radio than Intel/AMD CPUs.

    4. Re:Commodity vs lock-in by vovin · · Score: 1

      SPARC (the Sun/Oracle version) hasn't been clock-for-clock competitive for 20 years. I don't have experience with the Fujitsu line.
      POWER still has an edge on floating point over the Intel/AMD ... however the cost to deploy makes it pretty hard for non IBM shops to justify.

    5. Re:Commodity vs lock-in by GameboyRMH · · Score: 1

      This, ARM beats x86 easily in performance per watt, and that's a serious advantage. Single-core performance doesn't really matter for any kind of distributed computing task.

      To use a car analogy, with a sufficiently large road, you're better off with a pack of Priuses hauling your container :-P

      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
    6. Re:Commodity vs lock-in by Anonymous Coward · · Score: 0

      Well, there are Power9 boards (Talos from RaptorCS) which are not that expensive, especially when an 18core/72 threads processor is around $1k5, with loads of memory and I/O (48 PCIe Gen4 lanes) bandwidth.

    7. Re:Commodity vs lock-in by LostMyBeaver · · Score: 1

      I agree mostly but will make an amendment.

      This will be devastating to all chip vendors.

      Amazon isn't buying a premade chip. They bought an ARM licensee who made an Amazon branded chip. This is an Amazon ARM processor.

      Microsoft I've heard is doing the same.

      Google I'm sure could do the same. They of course own several companies who have experience licensing ARM cores.

      If each of these companies establish their own chip development teams and simply license cores, that's the end of pretty much the entire server chip market... period.

      I work for a massive corporation who among other things owns a cloud provider. I have two racks for my mad science in their data centers. I still haven't seen a current generation Xeon chip. I haven't seen new servers purchased. Even as an enterprise, I haven't seen these newer systems. The reason is simple... there are only three cloud companies out there. And if all three make their own chips, I know we're not picking up the slack at Intel.

  5. Niche by JBMcB · · Score: 3, Interesting

    I don't think, short to mid term, it will be an issue for them. ARM is more efficient at very specific workloads, depending on the configuration. They might be used as static web servers and proxies with hardware decrypt. For heavy application and database loads, AMD and Intel - usually - still blow the doors off of ARM.

    --
    My Other Computer Is A Data General Nova III.
    1. Re:Niche by Anonymous Coward · · Score: 0

      I don't think, short to mid term, it will be an issue for them. ARM is more efficient at very specific workloads, depending on the configuration. They might be used as static web servers and proxies with hardware decrypt. For heavy application and database loads, AMD and Intel - usually - still blow the doors off of ARM.

      Possibly. There are an ever increasing number of static content websites which represents a strong recurring revenue stream for hosting services

    2. Re:Niche by ledow · · Score: 3, Insightful

      I dunno... looks pretty competitive to me, for a first try:

      https://blog.cloudflare.com/ar...

      You can be sure that in the year hence, and with Amazon rolling their own, that they are now at least on a par with some more traditional setups.

      They literally only have to be a dollar cheaper (whether in power usage or purchase cost) to start taking over.

      Most people *aren't* maxing out their servers 24/7/365.25. As such, ARM could be a serious threat. Especially if they can come in anywhere near cheap or they offer other advantages (e.g. presumably, if Amazon are making their own chips, they know EXACTLY what's running on their hardware and can optimise to their exact needs, like Google does with its own motherboards etc. in-house - both security and performance get a boost from that).

    3. Re:Niche by JBMcB · · Score: 3, Insightful

      https://blog.cloudflare.com/ar...

      And that matches up from what I've read about ARM performance. It's competitive on relatively simple loads for data compression, encryption, and shoveling data out the door. Once you start doing regex / database / complex transnational loads, performance suffers.

      Seems like a perfect solution for Cloudflare, who, basically, shovels data out the door. Not so much for a hadoop / SQL based application stack.

      At some point ARM will implement transaction acceleration, and database and application platforms will be tuned for the ARM architecture, but until then I think it will be more of a niche player in the server market.

      --
      My Other Computer Is A Data General Nova III.
    4. Re:Niche by Anonymous Coward · · Score: 0

      and for all of those uses you suggest arm for, a similarly-efficient intel chip (for lack of an actual term for them these days.. lets just call them 'atom-based' or 'atom-derived' processors) will do the same... and, more significantly, keep your shit all on the same fucking platform.

    5. Re:Niche by lgw · · Score: 1

      By "DB Load" do you mean "being a DB" or "using a DB"? The later makes no sense. Waiting idle for your query to return results is hardly CPU intensive.

      For being a SQL DB, yeah, that obviously doesn't make sense yet. When it does, you can be sure Amazon will offer an ARM server type for Aurora, since they can do all the porting and perf tuning themselves. For being a NoSQL DB, that's always going to be I/O bound. For doing map/reduce, that sure sounds like "a relatively simple load and shoveling data out the door."

      That being said, I've been doing backend work for many years, and it's a rare exception when I have anything to do with a SQL DB, and then only on legacy systems. For anything in AWS, I just use DynamoDB and design around its limitations. Who wants to have DBAs these days? Or servers, for that matter (though you're usually stuck with some)?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    6. Re:Niche by JBMcB · · Score: 1

      By "DB Load" do you mean "being a DB" or "using a DB"? The later makes no sense. Waiting idle for your query to return results is hardly CPU intensive.

      Excellent point. My perspective is a bit skewed I suppose. I work with large enterprise applications that always use SQL or other structured (and more importantly transactional) database servers on the back end, along with application servers that involve gobs of logic using either Java or .NET. None of this stuff is going to run well on ARM anytime soon.

      --
      My Other Computer Is A Data General Nova III.
    7. Re:Niche by lgw · · Score: 1

      As I understand it, ARM is ahead now on raw compute/$. Intel is ahead where it has hardware acceleration that ARM doesn't, or where you have to scale vertically. Java seems faster/$ on ARM processors with Jazelle (which may not apply to the new AWS instance). No clue about .NET Core perf on ARM, though I can't imagine it's great. OTOH, as MS keeps working on Azure ARM instances, I bet it gets a lot better.

      So, if you don't need to scale vertically, you care about comput/$ not compute/core, and I can see ARM winning out in the long run. Intel has been stagnant for some time now.

      --
      Socialism: a lie told by totalitarians and believed by fools.
  6. ARM don't make chips by monkeyxpress · · Score: 4, Interesting

    Comparing this with AMD and Intel offerings is silly, because you cannot buy a chip from ARM. They simply design the cores (and many manufacturers don't even use their reference implementations - only the ISA). There is nothing really magical about ARM except that if you are wanting to build your own processor you might as well use them because licenses are pretty cheap, there is a large range of support tools available for them, and they incorporate many of the latest features in their designs with little historical cruft attached. It also helps to have a licensor who will happily work with you on your design to reach what ever objectives you're after rather than unleash the lawyers on you.

    In other words, they are an excellent place to start, the alternatives aren't that great, and there is little point rolling your own ISA unless you've discovered something pretty incredible.

    1. Re:ARM don't make chips by Anonymous Coward · · Score: 0

      AMD designs processors and has Global Foundries manufacture them.

    2. Re:ARM don't make chips by vovin · · Score: 1

      And AMD sells AMD chips produced from manufactures that were contracted to manufacture those chips.

      ARM sells 0 chips.
      There are 0 'motherboards' ready to be populated by various vendors that make CPUs and Micro-controllers based on ARM reference designs.

      Selling an ARM processor is a lot closer to rolling a (Linux or BSD) software distribution:
        - Are you going for performance or power efficiency
        - What 'drivers' are you going to support (3rd party IP like USB, Ethernet controllers, Video processors and crypto offload processoring)
        - What is your target boot address .. reference design etc.

      The ARM customer will most typically work within the above to build the board and break out whatever peripherals are useful for their application.

      There must be at least a dozen well know ARM CPUs out there ... Qualcomm, Apple, Samsung, Freescale, Allwinner, TI, Broadcom, ...

    3. Re:ARM don't make chips by GameboyRMH · · Score: 1

      If you're designing your own processor you might be better off making a RISC-V CPU with no license fees attached.

      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
    4. Re:ARM don't make chips by Anonymous Coward · · Score: 0

      MediaTek and Rockchip basically use ARM Holding's designs without modifications. Might as well be a re-seller for ARM.

  7. EC2 dominates cloud computing by Anonymous Coward · · Score: 1

    No, they didn't run the software. However now they run AWS EC2, and EC2 is the dominant cloud platform. So now they run the dominant cloud platform.

    I used an ARM cluster because they're cheap. Insanely cheaper than Intel boxes.

    It depends how Amazon price these as whether their AWS business switches to ARM, you can bet part of the game here is to get Intel and AMD to deep discount their processors to more competitive levels.

    That Manchester University super computer is probably only $2 per ARM core in hardware costs. They really are that cheap.

    1. Re:EC2 dominates cloud computing by LostMyBeaver · · Score: 1

      I use ARM almost exclusively for my servers. The exception is my Couchbase servers and I'm considering replacing them since they don't really do Docker well either. If Couchbase manages to do ARM + Docker... as in it's possible to deploy an entire redundant Couchbase Enterprise cluster using (preferably) Swarm or possibly Kubernetes, then I'm back with them.

      I use small, cheap Raspberry Pi servers running Linux, Docker and .NET Core. All my code is map/reduce so scalabiiity is not an issue. I can run tens of thousands of nodes without a problem. At an average cost (including board, case, power supply, SD card, NB-IOT, LCD, wires and fan) of about $95 a unit, this is just silly inexpensive. Because I use Swarm with Docker Community Edition, Linux and .NET Core, management is super simple, ridiculously cheap and just plain smarter than using much of anything else.

      That said, since ARM is still a second class citizen in the sense that there's still no native ARM development computers out there worth using, I get easily frustrated by having to constantly work on stupidly underpowered Raspberry Pi devices.

      As for ARM servers... they never made sense for any application I've ever heard of. The industry is so full of shit these days. I means serious... most of the tasks running on the 50+ Xeon Core systems are terribly wasteful. Consider that I'm running basically a massive scale (I mean massive) data collection and mining system for system management. I'm streaming syslog, snmp, netflow, etc... from over 100,000 devices into a semi-centralized database and mining the data constantly. My average footprint per system is about 32 megs of RAM (I'm running in debug at this time), 75 megs of flash (I haven't optimized the docker images yet) and about 4% CPU usage... on a Raspberry Pi 3B+.

      I use gigabit Ethernet ... I'm not sure why... but 100Mb isn't really available anymore. I never waste money on things like redundant networking since I have absolutely no possibility of a single point of failure due to the nature of the map/reduce architecture. I don't waste time fixing broken systems, I simply throw them away (donate them to schools) and when capacity drops below a certain level, I add 10 or 20 more units.

      I can't for the life of me imagine why anyone would build anything else... unless you're just a cloud vendor and focused on density. But for daily operations at a company, all you need is a 9 Raspberry Pis, 3 routers with built in switches (Banana Pi R2 if you're brave, Cisco 4220 otherwise), and that should be enough to provide a fully redundant massive server cluster. It won't run Windows server... but that stuff is in the cloud these days. Local infrastructure is for business systems... because why the hell would you put that in the cloud when it costs a few hundred bucks to host it yourself?

      So again... massive ARM processors... I guess if you're Amazon, it makes sense. But for what typically amounts to little more than a transaction processing system (business systems) they are just completely overkill.

  8. What the hell is going on? by Viol8 · · Score: 1

    The x86 instruction set simply doesn't lend itself to pared down power efficient architectures.

    1. Re:What the hell is going on? by drinkypoo · · Score: 2

      The x86 instruction set simply doesn't lend itself to pared down power efficient architectures.

      The x86 decoder is a minuscule portion of a modern processor, all of which are internally RISC anyway.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:What the hell is going on? by ctilsie242 · · Score: 1

      There are so many transistors on chips now, that the layer it takes to handle the "shell" around x86 and amd64 instructions to make them RISC is a tiny piece of the die.

      It would be nice if we could go with a better CPU architecture like Itanium or something with a ton of registers, with 128 registers, but it seems ARM is doing a good job with 13 registers, and amd64 does OK with 16 registers.

      I can see when there isn't any real way to shrink dies, that we go back to looking at the basic CPU design and improving that, but for right now, what we have is "good enough" for business, and any major changes to CPU architecture likely won't happen for a number of years.

    3. Re:What the hell is going on? by OrangeTide · · Score: 1

      Too many registers can be a burden when context switching. And in older ABIs it was a significant overhead for procedure calls. Register windows like in SPARC help quite a bit, but seemed to have died with that architecture.

      Newer compilers with better algorithms for register allocation has improved utilization of the dozen or so registers on modern CPUs, to the point that I don't think having 128 registers would make as significant difference as using the same area to implement SMT/HyperThreading.

      As a software developer (rather than a computer engineer), I want a CPU that has zero general purpose registers. And amazingly good cache performance. i'd rather keep my data as stack-relative temporaries. Just waiting for amazing good cache to be invented.

      --
      “Common sense is not so common.” — Voltaire
    4. Re:What the hell is going on? by Anonymous Coward · · Score: 0

      64-bit ARM ISA makes considerable changes compared to the previous 32-bit ISA. For example, it has 32 registers.
      It also eliminates some features of the earlier ISA, like most predication.

    5. Re:What the hell is going on? by Bryan+Ischo · · Score: 1

      "Amazingly good cache" is called "registers".

    6. Re:What the hell is going on? by Anonymous Coward · · Score: 0

      Yawn. I see the ARM knob-heads are out again.

      Clue: ARM has half a dozen instruction sets - so much for RISC - and it doesn't even come close to the processing power of x86 designs.

      Now, I'm not slagging off ARM. ARM powered the mobile revolution, but enterprise servers are an eco-system. Not just a processor. ARM isn't playing in that space... maybe it will begin to, but it hasn't until now. When ARM designs scale up in speed... then you start to see the power usage creeping up to x86 levels.

      Things may be about to change radically anyway. Intel has stayed ahead of the pack with its silicon nodes. It's losing that. So advantage of ARM selling designs that can be turned into a SOC may really begin to tell is servers. On the other hand, RISC-V is now chasing ARM's tale... but it's got the same eco-system problem that ARM did for enterprise servers.

    7. Re:What the hell is going on? by Anonymous Coward · · Score: 0

      Intel and AMD CPUs internally have more registers than architecture specifies. They do register renaming and reallocation to make use of these registers. The internal architectures of the chips have very little to do with ISA outside of layer that converts the original instructions to internal representation.

    8. Re:What the hell is going on? by Anonymous Coward · · Score: 0

      I know... dude... with 128 HUGE registers.... you can... wait for it... use them as Amazingly good cache!

      Give me 256-bit fp please :)____ (scientific computing here)

    9. Re:What the hell is going on? by serviscope_minor · · Score: 1

      It would be nice if we could go with a better CPU architecture like Itanium or something with a ton of registers, with 128 registers, but it seems ARM is doing a good job with 13 registers, and amd64 does OK with 16 registers.

      The ISA might not, but any of the superscalar, out of order chips (i.e. the fast ones from Intel, AMD, Arm and others) have hundreds of registers internally. You can't access them explicitly but they are there and the CPU does the register allocation for you.

      --
      SJW n. One who posts facts.
    10. Re:What the hell is going on? by OrangeTide · · Score: 1

      A directly addressable "cache" of a small number of words (128) that is not shareable between cores is not good in my book.

      Back in the old days of software we fretted over what was called Primary storage (memory) and Secondary storage (tape, disk). The more you could move into primary storage, the nicer it was to access from a programming language. We like regular old addressable "primary storage" memory, not lots of special access memories.

      Architectures that can provide uniform access to all system resources are generally considered more elegant, even if the hardware is probably a pain in the ass to design and optimize.

      --
      “Common sense is not so common.” — Voltaire
    11. Re:What the hell is going on? by OrangeTide · · Score: 1

      128 64-bit register = 32 256-bit values. Comfortable enough that you could hold two 4x4 matrices of them for a comfortable scalar & matrix -> matrix operation. Now if your architecture has primitives for 256-bit floats is another problem entirely. I think you'll be out of luck when it comes to 256-bit floats outside of supercomputer, ASIC, and FPGA designs. Because your desktop PC is Turing complete, you can totally perform the calculations at home, but they won't necessarily be all that optimal. Patience is a virtue, or at least saves you from buying costly hardware.

      For a pure software implementation I'd be more apt to lean towards a higher precision variant of the DEC64 library and format. I think decimal formats are easier to wedge into scientific problems than binary formats, given the ease at specifying the desired rounding rules versus the binary formats.

      --
      “Common sense is not so common.” — Voltaire
    12. Re:What the hell is going on? by Anonymous Coward · · Score: 0

      But always on, and sucking power. It's not that small, with 2 instruction caches, one is native encoding, one in a less baroque and more efficient encoding (on Intel at least).
      On AMD the instruction decoder assumes that an instruction may start on any byte boundary, there are 16 decoders in parallel, and the results of the decoders that do not end up corresponding to an instruction boundary are thrown away. This takes power and some delay (large fanout of the buffer between the fetcher and the decoders).

    13. Re:What the hell is going on? by Anonymous Coward · · Score: 0

      AMD played with more registers for AMD64, but they went with 16 because there was virtually zero performance gains for more than 16 unless hand writing ASM for extreme corner cases, and it came with performance penalties for the kinds of work loads x86 generally deals with.

    14. Re:What the hell is going on? by Anonymous Coward · · Score: 0

      Almost always on. Modern CPUs usually have microcode caches that allow the decoder to be disabled during loops, assuming the loops fit within the limited cache size.

  9. ARM is an ISA, not a platform by Anonymous Coward · · Score: 1, Interesting

    The fact that you can't download a generic Android and install it on your ARM smartphone tells you what is still missing from the ARM world after all these years: a standard that allows an OS to enumerate all components of the system and their configuration parameters. There is no generic kernel for ARM systems. You need one configured for just the type of ARM system you want to use.

  10. Amazon has done wonders, especially NoOps by Anonymous Coward · · Score: 0

    Amazon has done wonders. With serverless items like Lambda, all companies need is a development staff. All the OS guys, DBAs, rackers/stackers can be cut, and development can do what it does best... make stuff. No IT department needed. Any "plumbing" chores can be handled by someplace like Infosys, Deloitte, or some other world class consulting company.

    1. Re:Amazon has done wonders, especially NoOps by LostMyBeaver · · Score: 1

      I'm almost 100% with you.

      A DBA is actually part of the development staff.

      When working in Lambdas, an effective DBA on the team can be focused on optimizing queries which will shorten the time you're running lambdas for. If nothing else, they can help identify queries which should be made async and recommend how. So... while I'm entirely on board with canning the IT department, please keep the DBAs, they are really really useful... especially in a lambda world.

  11. can't wait for the trickle down cost savings! by Kwirl · · Score: 1

    i'm sure that these savings will be passed along by vendors who use the services

  12. Is it really that great? by Stonent1 · · Score: 1

    "In the SciMark testing, the AWS system-on-chip was twice as fast as a Raspberry Pi 3 Model B+ on Linux 4.14."

    So twice as fast as a 35 dollar computer that can run off of a cell phone charger. Ok yeah I know, more ram, better storage, better networking. But we're being sold on the CPU itself rather than the system.

    1. Re:Is it really that great? by Areyoukiddingme · · Score: 1

      In the SciMark testing, the AWS system-on-chip was twice as fast as a Raspberry Pi 3 Model B+ on Linux 4.14.

      So twice as fast as a 35 dollar computer that can run off of a cell phone charger. Ok yeah I know, more ram, better storage, better networking. But we're being sold on the CPU itself rather than the system.

      Yes, that's a completely useless comparison. Datacenters of cloud providers are not full of Raspberry Pis.

  13. Somehow ARM instances cost more? by bobzrkr · · Score: 1

    I'm a little confused. Title mentions 45% lower cost, but for the same vCPU and memory, ARM instances cost more than x86 instances?

    ARM:
    a1.large 2 vCPU 4GiB RAM $0.0510/hour
    x86
    t3.medium 2vcpu 4Gib RAM $0.0416/hour

    Why am I going to pay more the same memory and CPU, but run on hardware that less software supports?

    https://aws.amazon.com/ec2/pricing/on-demand/

    1. Re: Somehow ARM instances cost more? by buchanmilne · · Score: 1

      "I'm a little confused. Title mentions 45% lower cost, but for the same vCPU and memory, ARM instances cost more than x86 instances?

      ARM:
      a1.large 2 vCPU 4GiB RAM $0.0510/hour
      x86
      t3.medium 2vcpu 4Gib RAM $0.0416/hour "

      T-series instances are CPU-over-subscribed/burstable and use a cpu-credits system, where once you have used your credits, you will be throttled, or you muat choose to be billed more for credits (T2/T3-unlimited at $0.05 per vCPU-Hour for Linux, from lower down on the page you linked). So, you shouldn't directly compare instance-hour prices for T-series to other series, or you should include the T-unlimited pricing

      Maybe AWS will introduce cpu-oversubscription for ARM, and then you can compare that.

      For now, it's probably best/easiest to compare to C-series

      ARM:
      a1.large 2 vCPU 4GiB RAM $0.0510/hour

      x86:
      c5.large 2vCPU 4GiB RAM $0.085 per Hour

      That is 40% cheaper for a1.large.

      Disclaimer: I work for AWS/EC2 but am posting in my personal capacity.

    2. Re: Somehow ARM instances cost more? by Anonymous Coward · · Score: 0

      Wouldn't m5 make more sense than c5 to compare? Or even m4 or older? Though honestly I don't know if the price is much different.