Windows Server on ARM Is Finally Happening, And It Should Worry Intel (bloomberg.com)

Mary Jo Foley, writing for ZDNet: There have been rumors for the past several years that Windows Server would be coming to ARM. Today, March 8, that rumor became an acknowledged reality. Microsoft officials said that the company is committed to use ARM chips in machines running its cloud services. Microsoft will use the ARM chips in a cloud server design that its officials will detail at the the US Open Compute Project Summit today, March 8. Microsoft has been working with both Qualcomm and Cavium on the version of Windows Server for ARM, according to company officials. From a report on Bloomberg: Intel chips have remained one of the sole big-name products widely in use. Microsoft's work with ARM, in progress for several years, could pave the way for a real challenge to Intel, which controls more than 99 percent of the market for server chips. [...] Any challenge to Intel's dominance in server chips is a threat to its most profitable business and main revenue driver as demand for PC processors continues to shrink. The company's Data Center Group turned $17.2 billion of sales into $7.5 billion of operating profit in 2016, and Intel has been running ads that say, "98 percent of the cloud runs on Intel."

Comments

How ARM will handle the bloat?

[Anonymous Coward]

I am curious on how the lean ARM processors would cope up with the Windows bloat. Windows "server" boots the GUI first!

Re:How ARM will handle the bloat?

[MightyMartian]

Server Core can be run without said bloat. It's a pain to use, of course, because PowerShell is horribly verbose and it makes many CLI tasks long-winded and annoying as compared to *nix, but we have some HyperV servers that run that way, and we can actually do remote administration via the Server and HyperV tools so it's not that bad overall. Still lots of other ways it is bloated, and one can find some pretty minimalistic Linux installs that Windows Server could never come close to in small footprint.

Re:How ARM will handle the bloat?

[bondsbw]

A lot of that GUI bloat has been reduced dramatically since 10-15 years ago. Plus Server Core has been around since 2008 with command line only, and Server Nano was released for 2016 which is even leaner and has no remote desktop (it works more like Linux SSH-only management).

Re:How ARM will handle the bloat?

[bondsbw]

PowerShell is horribly verbose

PS offers shorthand syntax for most commands. I find it much less verbose in general, since it passes data structures which can be easily deconstructed instead of strings which need to be parsed.

Re:How ARM will handle the bloat?

[MightyMartian]

To each his own. Maybe it's because I've been using *nix for over a quarter of a century, and simply find the toolkit a lot easier to use and understand, and I've never particular bought into this notion that objects are better, considering anything requiring actually listing data inevitably has to be transformed into strings anyways. I find the object nature of Powershell to be just another irritant.

Re:How ARM will handle the bloat?

[Humbubba]

A.C. said:

I am curious on how the lean ARM processors would cope up with the Windows bloat. Windows "server" boots the GUI first!

I've heard that the Snapdragon 835 is a big enough muscle. It's got four high-power, low efficiency cores and four low power, low efficiency cores (ARM's big.LITTLE configuration.)

Re:How ARM will handle the bloat?

[Kryptonut]

I kind of feel that 2016 is a bit more bloated than 2012 R2 when you install it "with GUI"

A cluster of ARM server nano would be cool though

Re:How ARM will handle the bloat?

[Anonymous Coward]

No serious operation uses Windows on servers anyhow. 99% of all servers are Linux, BSD or some UNIX-like variant.

Re:How ARM will handle the bloat?

[TWX]

Depending on what needs configured, using the MMC on a GUI workstation associated with the Domain in question may let most of those configuration tasks happen without ever having to touch a command line.

It's oddly reminicent of the Novell model, which was where one put a minimal config on the server and then did the rest of the job with the supervisor account from a workstation. You couldn't even do most tasks directly on the server once it was set up, it was basically only really useful for operating the local tape backup. Everything else was done from whatever Novell-connected workstation you logged on to.

Back to Microsoft's current direction, it makese sense both for lightly equipped servers, presumably where there are lots of them working in parallel, and for VMs that are created and destroyed at will, for there to be very little actual on-box configuration to get them working. You don't want to have to manually manage dozens or hundreds of servers, you want to be able to do those tasks to the whole set as a group. Whether you use GUI or CLI, being able to do that from a single point makes a lot more sense.

Re:How ARM will handle the bloat?

[chispito]

Still lots of other ways it is bloated, and one can find some pretty minimalistic Linux installs that Windows Server could never come close to in small footprint.

Well, there is always Windows Server Nano. It's approximately 410 MB installed, I believe.

Re:How ARM will handle the bloat?

[MightyMartian]

For mundane tasks, Windows' remote admin is hard to beat, and providing there are no major roadblocks, most (probably 90%+) of the server tasks I've done over the last ten years or so were all done via the MMC remote admin components on my workstation. Some more complicated tasks can be done via remote admin, but can be a bit of a pain (like registry changes), and I end up just logging into the server instead.

Re:How ARM will handle the bloat?

[haruchai]

Still lots of other ways it is bloated, and one can find some pretty minimalistic Linux installs that Windows Server could never come close to in small footprint.

Well, there is always Windows Server Nano. It's approximately 410 MB installed, I believe.

They cut it down to *only* 400 Megabytes and called it NANO!?!?
I didn't realize M$ was such good comedians.

Re:How ARM will handle the bloat?

[LynnwoodRooster]

In the age of 2 GB RAM and 128 GB SSD phones, 400 MB is femto... Given current memory pricing, it's often cheaper to toss in a 1 GB flash chip than a 128 MB flash chip, especially if you want to interface with a more modern processor (faster speeds, etc.)

Re:How ARM will handle the bloat?

[Lumpy]

I found the .NET programmer!

Come on back when you can code a server in less than 10Meg that's with the OS and the application servers.

Re:How ARM will handle the bloat?

[Anonymous Coward]

Sorry, 400MB isn't "nano" by any metric.

Re:How ARM will handle the bloat?

[TWX]

I haven't tried to do registry stuff remotely in a very long time, but I remember being able to connect to remote registries in Windows 95... We used to mess with each other during computer class that way.

Re:How ARM will handle the bloat?

[Hadlock]

I use both on a daily basis, have used both side by side now for almost a decade, Powershell is at least as powerful as bash, at least as easy to write and maintain

Re:How ARM will handle the bloat?

[Anonymous Coward]

From a Linux point of view, I would Server Core STILL boots a GUI, which it then uses to display a command-line. So it's not really a counterexample to what the previous post said.

Re:How ARM will handle the bloat?

[thegarbz]

Windows "server" boots the GUI first!

Not all windows servers boot to a GUI. Some versions haven't done that for quite a while.

In fact it's quite the opposite now. Windows Server 2016 Tech Preview installs just like Ubuntu-Server. It doesn't provide you the option of even installing a GUI, you'll need to add that after first boot.

Re: How ARM will handle the bloat?

[Anonymous Coward]

Sadly, there are many, many .NET types and similar hanging out around here and polluting the atmosphere these days :-(

Re: How ARM will handle the bloat?

[Zero__Kelvin]

So they are all low efficiency cores then? My that DOES sound attractive!

Re:How ARM will handle the bloat?

[MightyMartian]

There are no lack of embedded devices which have constraints a lot smaller than that, whether it's due to price point or simply because achieving the smallest possible size with the lowest power consumption is essential. Now maybe it's unfair to suggest that Windows has much of a place in these kinds of devices, the fact is that you can make really really really small Linux distros whose footprints can be below 8-10mb (I think a minimalist OpenWRT install could fit in 2mb).

Re:How ARM will handle the bloat?

[MightyMartian]

I was under the impression that you could shut even that GUI off. We still run with the minimalist GUI so we can edit config files and the like.

Re:How ARM will handle the bloat?

[MightyMartian]

Further to that, it looks like a minimal uClinux install can fit in about 2mb:

The size of a practical bootable image, with Ethernet, TCP/IP and a reasonable set of user-space tools and applications confugured, would be in a 1.5 - 2 MBytes ballpark. With the "two-chips Linux design" concept in mind, a 1.5 MBytes image could possibly fit into internal Flash of today's Cortex-M microcontrollers. One example of a device that can hold an image of the size is the STM32F429 Cortex-M4 microcontroller.

http://www.emcraft.com/stm32f4...

Re:How ARM will handle the bloat?

[fuzzyfuzzyfungus]

I doubt that it's a major issue. Even cheap and dreadful ARM hardware runs Android without much trouble these days(partially because SoCs used to be a lot slower; and partially because Android used to suck even more, this wasn't always true; but unless the vendor has some truly atrocious skinning it is usually at least smooth these days); and that's not exactly lightweight. Contemporary Windows Phone is also an NT kernel with graphical stuff heavily borrowed from desktop Windows; and by all accounts it runs quite adequately on undistinguished ARM parts, when anyone actually buys it.

What will be interesting to see is if anyone from Team ARM manages to come up with a genuinely punchy option; or whether they'll be useful for scaring Intel away from 'because we can, that's why' pricing; and allowing specialty hardware vendors to quickly and cheaply add a well supported CPU core to their collection of custom accellerator components(like a lot of the Cavium NAS and networking parts, which are pretty unexciting as general purpose CPUs; but pack way more hardware acceleration for crypto, packet munging, and similar; along with markedly nicer integrated networking; than the cheap x86s that offer similar general purpose CPU support tend to); but not be all that interesting if you have scared Intel(and maybe AMD; for the first time in years, hooray) into not doubling the price just for leaving ECC support intact.

At least up till now; ARMs haven't been exactly slow by historical standards; but(especially if you need good single threaded performance) certainly haven't been exciting, and have mostly been of interest because Intel hates selling cheap CPUs; and really hates selling cheap CPUs with ECC and similar features; while there are enough hungry ARM vendors that they don't have the luxury of being picky.

Re:How ARM will handle the bloat?

[gravewax]

Windows Server DOES NOT boot the GUI first at all, in fact you don't even need to install a GUI and most cloud infrastructure would be running without the GUI.

Re:How ARM will handle the bloat?

[fuzzyfuzzyfungus]

.Net Micro is actually pretty teeny for what it is; but it bears about the same relationship to anything Windows that Micropython does to anything Linux: surprisingly good compatibility, for something that supports slightly upmarket microcontrollers, with a popular language used on the OS; but otherwise unrelated.

Re:How ARM will handle the bloat?

[Anonymous Coward]

Used both for a long time now. I would say I slightly favour PS now as it is simply faster to get things done in and is at least as powerful and in many ways more powerful. Though sometimes the verbose nature of the commands can be both a blessing and a curse.

Re: How ARM will handle the bloat?

[Anonymous Coward]

No you cannot. There is no terminal mode in Windows.

Re:How ARM will handle the bloat?

[ctilsie242]

This is the goal of both Windows and Linux, long term. The goal is to have virtual servers you configure once with a ruleset, then chuck and rebuild instead of trying to upgrade and maintain. Knowing the "pets versus cattle" aspect can score someone a job in an interview versus a hearty "thank you... next in line, please."

As time goes by, PowerShell is only going to get more emphasis, just because it is far easier to add cmdlets than to add usable GUI functionality.

Re:How ARM will handle the bloat?

[KiloByte]

Come on back when you can code a server in less than 10Meg that's with the OS and the application servers.

10 whole Megs? Try ConTiki web server on a Commodore 64.

Re:How ARM will handle the bloat?

[Anonymous Coward]

I thought bash was just for os stuff to support the large number of scripts out there but people on the whole use more modern shells to get things done, zsh comes to mind. After debian moved to dash there was little point staying with bash or relearning bash without the bashisms.

Re:How ARM will handle the bloat?

[serviscope_minor]

There are no lack of embedded devices which have constraints a lot smaller than that, whether it's due to price point or simply because achieving the smallest possible size with the lowest power consumption is essential.

A mix of all three. I'm currently using a CC2541 chip, which has a generous 2k of RAM and 128k flash. It's a bluetooth low energy chip, and depending on the application you can run for many months off a single coin cell. It's very, very power sensitive. And also tends to go into small, cheap devices.

Engineering is the art of compromise.

Re:How ARM will handle the bloat?

[david_thornley]

I stopped writing complicated bash (well, back in those days, ksh) scripts when I learned Perl.

Re:How ARM will handle the bloat?

[Anonymous Coward]

Come on back when you can code a server in less than 10Meg that's with the OS and the application servers.

Put up or shut up. Link to the repo where you have an OS and application servers in less than 10MB. If not then come back when you've done it. A lot of slashdotters talk a big game but then roll out the excuses when asked to back it up.

NB: Im not questioning the ability for it to be done, just your ability to do it.

Re: How ARM will handle the bloat?

[Humbubba]

Zero_Kelvin said

So they are all low efficiency cores then? My that DOES sound attractive!

My Bad. ARM's big.LITTLE configuration used in the Snapdragon 835 has 4 energy hungry, highly efficient cores and 4 energy stingy, low efficient cores.

(Thanks for catching my stupidity.)

Re:How ARM will handle the bloat?

[TWX]

I don't know if pets vs cows really applies perfectly here.

Near as I understand it, any system could fall into this including complex systems that handle the creation and destruction of individual nodes or virtual nodes, not just the end individual nodes themselves. The crux of the argument isn't about the scale of the system, it's about the willingness of the maintainer to replace a system instead of spending inordinate amounts of resources maintaining something for sentimental reasons. If sentimentality is getting in the way of a good business decision then the subject in question is a pet, regardless if it's a specific server, or a cluster of servers, or an entire set of network infrastructure, or even a slew of end-user devices. If the maintainer and the organization is willing to continually revisit the cost-effectiveness of the system and then willing to rip-out and replace the system when it is not cost-effective to maintain, that's when it's cattle/livestock/cows, whatever animal-husbandry euphemism you want to use.

Re:How ARM will handle the bloat?

[exomondo]

I kind of feel that 2016 is a bit more bloated than 2012 R2 when you install it "with GUI"

What's the resource usage difference?

Re:How ARM will handle the bloat?

[Anonymous Coward]

When did you stop writing Perl?

Re:How ARM will handle the bloat?

[Anonymous Coward]

As a scripting language PowerShell taps into .net applications much more easily than bash interacts with everyday *nix applications. And the wordiness is a good thing for the non-developers. If the limits start to get to you, maybe your project needs something more robust.

Re: How ARM will handle the bloat?

[Anonymous Coward]

Server nano has local logon capability. That's weird.

Re: How ARM will handle the bloat?

[Anonymous Coward]

Typo! *has no* local logon capability.

Re:How ARM will handle the bloat?

[Kryptonut]

It's kind of relative to the role really. But I know I get horrible redraw issues using default RDP settings because it tries to use things like image backgrounds (have to turn that off in the RDP connection settings before making a connection, never had to do that previous to 2016)

Does anyone know if services like "Sync Host" (used for syncing mail, contacts, calendars,etc.) and "Maps Downloader" are present on a core install? I'm guessing not....but I don't know why it's included in a GUI install either on a server? Only time it'd be possibly useful would be for RDS

Re:How ARM will handle the bloat?

[BoogieChile]

> In the age of 2 GB RAM and 128 GB SSD phones, 400 MB is femto

That'd be "femto": from the Greek femtos, lit, "nearly one quarter"

Re: How ARM will handle the bloat?

[Anonymous Coward]

False, Server Nano is completely headless and uses remote administration.

Re:How ARM will handle the bloat?

[Anonymous Coward]

PowerShell also has the worlds slowest autocomplete feature. Every time I fat-finger the tab key I am tempted to rip it completely off of my keyboard. And don't even get me started on the sh*tshow that is the way string parameters passed to legacy command line applications are irreparably munged.
 
 

Re:How ARM will handle the bloat?

[MightyMartian]

The one thing PS is not is fast. Christ almighty, it's so fucking slow to load, and then the first command you run, or hell sometimes even the first keypress can take several seconds, and even execution is pretty gawdawful. It may be powerful, and it is certainly the best automation toolset Windows is ever likely to have, but being based on .NET makes it as slow as molasses.

Re:How ARM will handle the bloat?

[Anonymous Coward]

execution is usually extremely fast and is down entirely to how well written the components you are using are written. We actually do a lot of processing in powershell now as it offers similar execution time to custom code for a lot of the stuff we do (most of it makes a lot of API or WEB API calls). It is definitely slower to start though.

Re:How ARM will handle the bloat?

[MightyMartian]

So, in other words, once it has grabbed up large amounts of memory to hold the libraries in, it's really fast. Well, okay, but that would apply to any environment with a cache. And that represents the significant philosophical divide between Microsoft and *nix. Powershell needs to load vast portions of the .NET libraries just to run, while *nix is built upon a minimalist model of only loading what you need. I'm not saying one is better than the other, but I prefer discrete tools with a shell as a sort glue, and I readily admit that comes from 25 years of working in *nix environments.

Re:How ARM will handle the bloat?

[Anonymous Coward]

Where do you get 10MB of anything these days? No one manufactures that small.

Re:How ARM will handle the bloat?

[dbIII]

For mundane tasks, Windows' remote admin is hard to beat

Perhaps, but I very much suspect that once you are working on more than a single host many different implementations of cluster management tools from fifteen years ago would leave it for dead.

Re:How ARM will handle the bloat?

[dbIII]

"Real" servers instead of virtual ones have been done that way in clusters for a long time. Rocks Cluster Distribution is 17 years old and I don't think it was the first.

Re: How ARM will handle the bloat?

[Anonymous Coward]

+1 from an AC.

Re:How ARM will handle the bloat?

[TheRaven64]

Not me (and I'm not the grandparent), but some of my colleagues would say that 10MB is bloatware for a server system.

Re:How ARM will handle the bloat?

[LynnwoodRooster]

Fully agree, in many cases the smallest PIC micro is overkill in terms of storage. But more and more having 1 GB of storage available is becoming less of a constraint for lots and lots of devices. For all of them? No, but I know of more than a few headphones/portable audio devices that contain 1 GB of OS drive and 256MB+ of RAM. IF Windows (and that's a big IF) brings features and functionality to your device that you need, the "limitation" of 400 MB is really not much of a limitation anymore...

Re:How ARM will handle the bloat?

[AaronW]

The processors being discussed are not the lean ARM processors you would find in a phone or tablet. These chips are designed for servers. The Cavium chips, for example, are designed to handle an insane amount of memory bandwidth with a lot of cores, far more cores than Intel offers.

The Cavium cores are lean in the sense that they do not support the older 32-bit ARM instructions or the baggage they bring, i.e. they only support AArch64, not ARMv7. The switch from 32-bit to 64-bit ARM is more radical than the change between X86 and X86-64. A lot of what made ARM 'ARM' is gone. AArch64 is basically a new modern RISC instruction set incorporating everything that has been learned in the last few decades while throwing out much of the cruft that holds back performance. While some things may have been a good idea at the time they later proved to be a hinderance. While many of the instructions may look similar (and even have the same mnemonic), the encoding is completely different. The register set is also completely different. Instead of 16 registers (where the PC was one of the registers) there are now 31 general purpose registers (R31 is always 0 (like MIPS R0) except when it is the stack pointer). See Wikipedia.

The problems with the 32-bit ARM instruction set that prevented out of order execution and issuing multiple instructions in parallel are pretty much gone. Conditional ALU instructions are gone (except branch instructions) and the PC is no longer a general purpose register. There are also now 31 general purpose registers with register r31 having special meaning. It is generally always zero, much like r0 on MIPS, though there are also special instructions so it can be used as a stack pointer. It also doubles the number of 128-bit NEON registers from 16 to 32.

There are other Cavium CPU chips that are targeted at high-speed network devices with a lot of built-in engines for things like networking (10 and 40Gbps networking is built-in), encryption, RAID, compression and a number of other interesting engines useful for big data.

The X86 platform has a lot of warts that make some things very expensive for backwards compatibility. I'm amazed that they get as much performance out of it as they do given how horrible the instruction set is.

These chips can handle Windows just fine.

Full disclosure: I work for Cavium though I'm primarily involved with their MIPS processors.

Re:How ARM will handle the bloat?

[Anonymous Coward]

http://distro.ibiblio.org/tiny...

Base is 11meg, but it can EASILY be reduced to 9meg by removing unneeded features.

Granted someone like you that has ZERO ability to code probably can't understand linux.

Performance per watt

[Anonymous Coward]

Last I heard, Intel still beats ARM easily on performance per watt and that is what's important in the data center, not absolute power usage. Did something change? The Cavium wasn't all that competitive in benchmarks and I'd surprised if Qualcomm managed anything better.

Re:Performance per watt

[Anonymous Coward]

Last I heard, Intel still beats ARM easily on performance per watt and that is what's important in the data center, not absolute power usage. Did something change?

No, nothing changed. This is just another round of misunderstanding from the anti-Intel zealotry. The most hilarious part of their recent (relatively) attachment to ARM processors in their war against Intel is that Intel has all the paperwork done to be not just an ARM fabricator, but optimizer. If ARM ever gets any performance advantage over x86, Intel-ARM CPUs will hit the market and (based on current trends) be roughly 8% more efficient than any competitor using the same layout. If Intel takes the time to optimize an ARM layout before fabbing, probably 12-20% more efficient while remaining fully compliant to the standard.

Re:Performance per watt

[Rockoon]

Did something change?

ARM on 10nm.

Mass production has begun, while Intel is still at least a year away from 10nm. Its why Intel announced last August that when it finally does get 10nm to work, it will be making ARM processors not just x86 in those fabs.

Intel is rightly fucked as a vertical company. A decade from now Intel, if it hasnt been decimated and sold off by then, will be just another rent-a-fab company.

Re:Performance per watt

[Anonymous Coward]

This is just another round of misunderstanding from the anti-Intel zealotry.

Aww, you're cute. You actually think Intel has a chance in the next ten years of processor design.

Re:Performance per watt

[EDA Wizard]

Intel's 14nm process is in most ways better than Samsung's 10nm (Qualcomm's fab for this chip). IMHO this isn't really going to be won on feature size of the process between the two.

The advantages Cavium and Qualcomm have are cheaper chips (also more integrated, SAS, PCI lanes) with higher core counts and more memory channels than Intel. In some applications the higher memory channels count and bandwith will be very valuable (HPC). Intel will be able to discount the heck out of their high core count Xeons to match on price and they can lower the clock to match on IPS for each core. They can't add a memory channel where it doesn't exist.

While I agree that the vertical integration of Intel's past may not be the best way for the future, they still have the best process engineers in the world. They still have the best process for the foreseeable future. They also have some of the best semiconductor engineers out there. So while there is a fight coming. Intel is hardly "fucked" or headed for decimation.

Re:Performance per watt

[Bugler412]

Intel has been an ARM licensee for over a decade, they can produce them whenever they desire to, and DID produce a lot of ARM chips in the pre smartphone PDA days.

Re:Performance per watt

[Rockoon]

Intel's 14nm process is in most ways better than Samsung's 10nm

Citation needed, and no I dont accept a citation that basically says "thats not real 10nm" because that 14nm intel isnt real 14nm. IIRC the smallest feature size on Intel 14nm is still 28nm, and thats after improvements while still at "14nm." Intel invented lying about feature size.

Also, Samsung isnt the only fab company beginning 10nm mass production well before Intel. TSMC and Toshiba will be mass produing before the end of the year (the end of the year is when Intel last said would be the absolute earliest that they could do it.)

TSMC, Samsung, and Global Foundries are also in a partnership with IBM on working out the kinks on 7nm. Intel is very fucked.

Re:Performance per watt

[cheesybagel]

Intel has enough money they could throw 2-3 teams on it if they wanted to. One of them would succeed.

Re:Performance per watt

[cheesybagel]

Yeah but XScale started out as StrongARM from DEC. Intel basically got the design team when they bought some of the remains of DEC. They basically applied some of the chip design ideas from the Alpha for an ARM core. Eventually Intel sold that business to Broadcom I think. They still have an ARM license but I'm not aware of them using it for anything right now.

Re:Performance per watt

[thegreatbob]

Had an XScale based PDA "back in the day" (Dell Axim X5, 300MHz?), and I'll attest that the performance/usability was quite good.

Re:Performance per watt

[thegreatbob]

Reply to myself to avoid spam, but I also had a Compaq iPaq 3630 (206MHz StrongARM), and it was more than capable of doing "useful" things such as NES emulation.

Re:Performance per watt

[Anonymous Coward]

Say you would like to cram a maximum number of cores into a hard power limit imposed by the facility, and not utilize virtualization but containers and such.

Re: Performance per watt

[Zero__Kelvin]

Why yes ... Just the other day I was accosted by a man who warned: "I better not find out you got a mind toward that there Intel or there'll be some need to call the Sheriff! Zealots I tell you! Like Savior Faire they are everywhere!!

Re:Performance per watt

[Anonymous Coward]

Anon here, this article seems to break it down:

http://wccftech.com/intel-losing-process-lead-analysis-7nm-2022/

Re:Performance per watt

[jwhyche]

If it is about low watts vs shear performance Intel should toss Atom processors in to the server market. Atom processors are x86 compatible so you don' t have to redo all your code to run it.

And when you want to move off the baby processor and on to a real server then its just a straight move up.

Why am I still posting at 0 when my karma is excellent?

Re: Performance per watt

[Anonymous Coward]

This is probably closer to the truth. Data Centers are the new industrial power hogs. They are popping up so fast and so densely clustered that power companies are having a hard time keeping up. We closed all the giant factories and multiplied residential subdivisions in the last thirty years. We don't have the infrastructure to get large amounts of power to all these places... that's partially why companies are running their own solar farms.

Servers need to go to deep sleep when they're lightly used. A giant Intel processor has to stay fully powered even if half its cloud VMs are not in use. That makes smaller, lighter, quicker servers better as density rises.

Re:Performance per watt

[Rockoon]

Anon here, this article seems to break it down:

Lets check that "break down"

"Intel’s processes use the same backbone as the advertised node (a 14nm process will use a 14nm backbone) ..."

See right here? Thats a lie. You are reading a lie and not questioning it. Intel is the semiconductor manufacturer that invented lying about node size. There is no feature in Intel chips that are 14nm be they their "14nm" chips or their new kaby lake "14nm+" chips, yet your article says Intel is the only one doing true 14nm. Its fucking comical how big a lie your article is spewing.

Intel invented lying about node size. Even your article shows no feature size smaller than 42nm when calling Intels latest lie "true 14nm"

..and the "+" in Intels new "14nm+" is Intel actually INCREASING a feature size so that they can increase voltages and thus clock higher. The last time Intel did that was Pentium 4 / Netburst. Better hope they dont do a "14nm++" generation.

Re:Performance per watt

[Anonymous Coward]

But this is about "cloud." There the whole business model relies on massive over provisioning. The only criteria from system owner point is that how many virtual servers can a server hardware start and what is its peak power consumption. Performance is irrelevant on cloud services, as they fabricate hardware details and sell them to people who don't know what they are buying.

Re:Performance per watt

[dbIII]

Intel has enough money they could throw 2-3 teams on it if they wanted to. One of them would succeed.

AMD's problem is they thought they could throw away 2-3 teams and did.

Re: Performance per watt

[Anonymous Coward]

I have lost count of the number of times I've seen people predict the demise of Intel. It is entirely unlikely in your lifetime and I say this as a huge fan of AMD and preferring AMD over Intel with my purchases.

Re:Performance per watt

[The Finn]

Here you go:

• http://ark.intel.com/products/codename/54859/Avoton
• http://ark.intel.com/products/codename/63508/Denverton

no threat

[Anonymous Coward]

Linux has had ARM support for a long time, there seems to be very little customer interest in data centers. Given how much linux stuff is open source and already working on ARM if there was a market we would see existing cloud players using it if it made sense, apparently it does not.
(as AC since I do not have a /. account)

Re:no threat

[MightyMartian]

It isn't a threat currently, but one can be sure that if ARM saw that it could make an in-road into the data center, it might just ponder making chips with greater overall horsepower for a "server line" of ARM CPUs. Just because ARM at the moment is more interested in low power chips doesn't mean they wouldn't ponder a move towards higher performance, and certainly if they could advertise both Windows and Linux as supported platforms, that makes for a pretty compelling argument.

The fact that Microsoft is going this direction clearly indicates to me that there must be some interested at the hardware end to produce server-grade chips.

Re:no threat

[DontBeAMoran]

Or maybe it's a chicken-egg problem and Microsoft decided to make the first step. Or maybe they're seeing more requests for Windows Server on ARM and they've made projections about future demand and it's going to happen soon according to their numbers.

Re:no threat

[MightyMartian]

Considering MS already ported the Windows kernel to ARM a while back, and certainly Windows NT, including the older CLI toolkit were all ported over to multiple architectures back in the day, it may not be all that hard. Obviously there's going to be some recompiling and porting over of a lot of server components, so I'm not saying that porting the entire Server ecosystem to ARM will be trivial, but it's not really a massive leap, just a lot of recompiling and testing. A lot of the admin tools have been moved over to .NET due to Powershell's increased use, so in some cases we're talking not much more than testing on the ARM versions of the CLR.

I wonder

[aglider]

How is to get the BSOD on arm CPUs... I am getting really curious: Intel is loosing it's crown!

Re:I wonder

[Anonymous Coward]

Maybe it should tighten it if it is so loose?

Re: I wonder

[Anonymous Coward]

Pro tip: goose, moose, loose.

What if you dont care about power consumption?

[Anonymous Coward]

Then arm is not better and intel has nothing to worry about in that market.

Re:What if you dont care about power consumption?

[DontBeAMoran]

If you manage a server farm, you have to worry about power consumption:
1. the more power you require, the more heat you generate
2. the more heat you generate, the more cooling you require
3. the more your hardware runs on higher temperatures, the lower its lifespan

Granted, #3 might not be relevant with rapidly changing technologies, but then again there's still companies out there using old servers running COBOL and FORTRAN so you never really know how long your servers will run. Could be a year, could be a decade, could be a quarter of a century.

Re:What if you dont care about power consumption?

[Bugler412]

you have to worry about performance per watt, not just raw watts. If you get lower transactions (or whatever) per watt with ARM then you've solved nothing and perhaps made things worse. Previous generation ARM chips couldn't match Intel on performance per watt, perhaps the current and future gen ARM chips can change that? I haven't seen that they have succeeded yet though.

Re:What if you dont care about power consumption?

[Lumpy]

If all this was true then AMD could not sell their server processors.
Yet they are highly popular.

And they, like all AMP processors run hot.

Re:What if you dont care about power consumption?

[rahvin112]

They won't. There seems to be some belief among younger folks that ARM is somehow special and that instruction set is more important than anything else. The reality is that is simply NOT true. Instruction set is essentially meaningless. Intel chips haven't used x86 internally since the first Pentium chips. The x86 is decoded and fed to the internal processor by a decoder that uses less than 123K transistors (not even 0.1% of the die). Because x86 is nothing more than an abstraction layer at this point this allows Intel to use whatever is the new hotness inside their CPU.

Even if you believe non of that consider this. There have been at least 6 companies that have tried to produce ARM servers that dropped the effort or abandoned the project after the test hardware was produced. The simple reality was that even with brand new top of the line designs they couldn't beat Intel in either raw performance or performance per watt. Every attempt has failed and that was using Linux where the software can be fully optimized for ARM and all software recompiled for it. Expect nothing like that on Windows and just like Windows RT it will be a colossal failure.

Intel will keep winning, they are literally 2 process nodes ahead than every other silicon manufacturer, their CPU's could be two generations old and still beat top of the line processors from other manufacturers just because of the process node advantage.

Re:What if you dont care about power consumption?

[Alioth]

It's not just the decoder, branch prediction is more complex (more scope for bugs), the pipeline has to be more complex due to the variable length instructions that can be one byte long up to 7 bytes long. It doesn't matter a lot in chips where you have few very powerful processors (traditional servers), but where you have many many low power processors it adds up.

Re:What if you dont care about power consumption?

[Lonewolf666]

Really?

About 1 1/2 years ago, AMD was on its way out in the server market because the Opterons were not competitive enough anymore: http://www.eweek.com/servers/amd-aims-to-reinvigorate-x86-server-business.html
Now they are going to give it another try with Zen, and I think it is a promising try. But then again, Zen is not more power hungry than comparable Xeons. Maybe less so.

Re:What if you dont care about power consumption?

[dbIII]

you have to worry about performance per watt

Not exactly. You have to worry about ENOUGH performance per watt. If you can get something to get the job done in a reasonable time frame without burning a lot of power that's great. That's what low power consumption systems are for.
If that's nowhere near enough performance you get whatever does the job instead no matter how many watts it burns. Trying to chase both generally just annoys everyone - pick one.

Re:What if you dont care about power consumption?

[Anonymous Coward]

So far no CPU can match the Commodore 64's 6510 on performance per Watt. Following your logic the MOS 6510 ought to be the processor of choice then. While performance per Watt is not unimportant, it is not the top decision factor for server hardware selection.

Re: What if you dont care about power consumption?

[Anonymous Coward]

If you were trying to be funny, you weren't and you're an idiot.

Re:What if you dont care about power consumption?

[AaronW]

You might be surprised with some of the new server oriented ARM chips.

Nope...

[David_Hart]

Intel is not worried. How is ARM any more of a threat today than AMD was?

Intel started building lower powered chips a long time ago to compete with ARM and have, in a number of areas, surpassed them. Time and again, Intel has been able to ramp up their R&D to stave off serious competition. I don't see ARM being any different.

Re:Nope...

[MightyMartian]

If Intel has been such a great success at low power chips, why is it exactly that ARM still dominates in the low power world?

Re:Nope...

[supremebob]

I think that the poster meant lower power server chips for devices like NAS boxes and routers, but not mobile parts. I could be wrong, though.

Re:Nope...

[Rockoon]

Intel is not worried.

Sure, thats why Intel just did massive layoffs and struck a deal with ARM to produce 10nm chips when Intel finally figures out 10nm.

Not worried at all.... oh... wait.... you havent been paying attention...

Re:Nope...

[Anonymous Coward]

When competing against AMD, Intel were competing against the same x86 architecture. With ARM, Intel are now competing against a far superior architecture. Intel x86 has always been a terrible architecture that has only flourished because IBM made the unfortunate decision to use it in their Personal Computer. The thing that has kept Intel ahead is that they've had a fortune to invest in improving their fabrication processes, but the architecture itself is junk. Even Intel know x86 is bad and tried to replace it with the IA-64 architecture, but completely botched the job and left us still stuck with x86.

Not only are Intel now competing against a different architecture, they're also competing against a lot more companies. ARM licence their designs to anyone, so Intel will be competing against anyone who cares to make an ARM server chip, whether that be Qualcomm, Nvidia, Samsung or anyone else. It's similar to the situation with Betamax where it was Sony vs everyone, except this time it's Intel vs everyone.

ARM offers performance advantages in metrics such as performance per watt or performance per dollar, as well as substantially reduced overall costs. Intel have been abusing the market for years, and when a competitor steps up offering lower prices and other technical advantages, Intel are likely in trouble.

Re:Nope...

[GreatDrok]

ARM doesn't make chips, it licenses designs to FABs who actually make them. Even Intel is making ARM chips again. Intel hasn't been able to get down to the very low power levels that an ARM CPU can run at without serious compromises on performance. ARM chips still have a lot of performance to give which is why we see them increasing rapidly each year like we did with the x86 back in the 90's and early 2000's. There's only so much that can be got out of a design and Intel has been flatlining for years since they debuted the i3/i5/i7 line and in that period ARM chips have got multiple times faster per core, and added more cores, not to mention tricks like having low and high power cores on the same die. All of this makes them attractive for servers, especially now that 64 bit ARM is out there. I've got a RP3 which is 64 bit and it zips along nicely with Linux and there's a whole bunch of useful things it can do in a machine which runs of a small USB power supply.

Re:Nope...

[barc0001]

Intel's low power foray into mobile SoC with the Atom platform has been about as successful as Windows Mobile was. So much so they're bailing:

http://www.eetimes.com/document.asp?doc_id=1329580

"As it proceeds with a massive restructuring plan announced earlier this month, Intel will exit the smartphone and tablet mobile SoC business by ending its struggling Atom chip product line. The discontinued products include those code-named SoFIA, Broxton and Cherry Trail."

Atom chipsets have been anemic compared to the ARM processors, and now ARM is going to move into the low end blade space for Windows/Linux servers where Intel was positioning Atoms for cloud clusters.

Re:Nope...

[tlhIngan]

Intel is not worried. How is ARM any more of a threat today than AMD was?

Intel started building lower powered chips a long time ago to compete with ARM and have, in a number of areas, surpassed them. Time and again, Intel has been able to ramp up their R&D to stave off serious competition. I don't see ARM being any different.

Exactly.

ARM will not replace Intel in the high-power CPU market. The one that's Intel's bread and butter with Xeons that cost $10,000+.

ARM will however replace the lower power CPU market - the ones where servers are either virtualized, or their tasks are light enough that CPU was never a problem. Think of things like web servers and other internet servers - the task is light duty and can be fulfilled by very low end machines. ARMs will excel here, and in many cases, you can fit easily 32+ ARM servers in a 1U form factor.

Maybe the biggest people who should worry are VM developers - if you have lightweight tasks that you could put into VMs, but now you can run them on a physical machine that takes little space, it becomes an option. Fitting 32 VMs on a 1U server is difficult, for example.

That's not to say there isn't an advantage to VMs, so they'll still be around (we won't have a mass "physicalization" of people moving VMs to physical machines again)

Re:Nope...

[MightyYar]

Honestly, it's probably because the margins are so low in mobile. Maybe they could compete with a $25 system-on-chip that implements an entire cell phone, but where is the profit?

Re:Nope...

[MightyMartian]

Exactly. Not every server is a high-end number crunching machine. The only server I'm running right now that I wouldn't really contemplate moving to ARM if it were available and was more economical than x86 would probably be our RDBMS servers, where cycles mean a helluva lot. But for our web, email, file and print servers, frankly when I look at them, they're spending a helluva lot of time idling, and the reason I don't virtualize all of them on one server is more about redundancy. As it is we have a three virtual server farm that runs all our servers except the database server and one of the Server 2012 DCs which we intentionally keep on separate hardware in case the NAS servers explode.

Re:Nope...

[Rockoon]

ARM will not replace Intel in the high-power CPU market.

Of course not, but there is a company that makes high-power cpu designs and will be buying time on 10nm fabs before Intel figures out 10nm.

So for low power, Intel cant compete at all, and in high power, Intel will be behind.

Re:Nope...

[cheesybagel]

Atom was working fine on cheap netbooks and HTPCs until Intel decided it had to compete on smartphones and tablets and then it failed. In addition they didn't invest as much on new designs as they should and they get outclassed by current top ARM processors as well.

Re:Nope...

[rahvin112]

Intel has not struggled in the phone business because the processors suck. It's because they handicap the processor and put limits on their use to try to avoid cannibalizing desktop and server sales.

It's those restrictions that have kept them out of the market, not performance or cost. Intels Atom line could have taken over the phone business if Intel had released all those restrictions, but they likely would have lost the desktop market to them as well which would have decimated their profits. They decided it was better to lose the far less profitable market than cannibalize their primary sales.

Re:Nope...

[thegarbz]

How is ARM any more of a threat today than AMD was?

It's not. You're just ignoring the fact that AMD has on several occasions been a threat to Intel.

Re:Nope...

[thegarbz]

why is it exactly that ARM still dominates in the low power world?

Scope. There's not a lot of markup selling a chip to a mobile phone or tablet manufacturer.

Server hardware on the other hand... well let me count the number of ARM chips commonly used in business back-end servers. Aaaand done, didn't even need to lift a finger.

Re:Nope...

[Alioth]

Because ARM is entrenched in that market.

Just like Intel is entrenched in servers/desktops (and therefore incredibly hard to displace, despite the fact you could make an ARM chip just as powerful), ARM is entrenched in low power even though Intel could make a low power chip. It's not worth the effort for those making low power devices to switch to Intel due to the massive investment in time and tools it would take for what would be very slight advantage (if any - after all, due to the insane x86 instruction set the decoder and pipeline for an x86 is bigger than a whole ARM execution core)

Re:Nope...

[swb]

When you have an existing x86 VM host farm, how exactly does ARM look appealing? I can't add ARM hosts to the same cluster because they can't run the same VMs as the existing x86 hosts.

What's the need for adding any more overhead in the form of a new CPU category, new hardware, etc, when the marginal hardware cost of adding an additional VM to most existing VM environments is essentially zero?

Maybe this makes sense in niche cases where you have zillions of low-power server images and you're building clusters at rack or aisle scale AND your specific application can run on ARM or x86 just as easily and it comes down to hardware cost only.

But for a lot of places, their existing x86 VM environments are just fine -- node level redundancy, flexible backup and restore, etc, and they need x86 anyway, at least now.

Switching back to the physical server model just because you can use tiny ARM CPUs doesn't make any sense. Maybe something like VMware for ARM, fine, but as long as they need any x86 they won't bother with ARM at all because it means a whole separate cluster.

Re:Nope...

[UnknownSoldier]

> Intel just did massive layoffs and
> struck a deal with ARM to produce 10nm chips when Intel finally figures out 10nm.

You wouldn't happen to have links handy by chance please? TIA.

I don't recall seeing both of these on /.'s front page ...

Re:Nope...

[mobby_6kl]

The latest phone Atom chips were perfectly competitive with midrange ARM stuff, but I don't think they saw any economic sense continuing this.

And ARM servers were supposed to be huge every year since iPhone made it big, I recon this will happen during the year of the Linux desktop.

Re:Nope...

[iggymanz]

ARM are low performance chips, that's why they have the room to improve. Intel server chips crush ARM in performance. Let's take a typical hyperconverged server my employer uses with 8 six core Xeon processors, how many of your USB powered ARM servers will it take to equal that? A row of racks?

Re:Nope...

[GreatDrok]

ARM are low performance today because they haven't had the investment x86 got. Back in the 80's when Acorn first released their Archimedes running on ARM it was 10x quicker than an equivalent Intel x86 machine. There's nothing specific to ARM that makes it low performance, just that they have been focussed on the low energy market but with a significant push the ARM architecture can easily make massive performance gains. These things look pretty neat: http://www.theregister.co.uk/2...

Re:Nope...

[Anonymous Coward]

Only in very low load envelopes do ARM chips offer better performance-per-watt - Basically they're better at being off for extended periods of time.

Intel chips are still much better performing a realistic loads and high loads. They also have much higher single thread performance celings - Orders of magnitude faster.

Where ARM will beat Intel, though, is market forces. Just like the mobile phone industry, the server and cloud industry is demanding extreme flexibility. Basically if you're ordering millions of machines you want to customize everything down to the function blocks that go in to your CPUs. Just like in the mobile phone industry. - Oh and the console industry. Know how AMD got both the Xbone and the ps4? They licensed their IP and made custom SoCs just like MS and Sony wanted. Exacly how Intel won't.

Intel's business model revolves around them creating a few chips and everyone else working around those designs. Intel failed in the mobile market and has basically sold atom to Rockchip because, as a business, they can't cope with ARM's buisness model.

Intel ate the big Unix vendors because they could not adapt. ARM will eat Intel similarly if Intel does not adapt.

Re:Nope...

[barc0001]

> And ARM servers were supposed to be huge every year since iPhone made it big,

Thing is without Microsoft along for the ride that wasn't really a possibility, at least to start. Now it is. Run it all on an ARM with x86 emulation so no porting. As long as the emulation performance hit isn't terrible the cost savings for cloud farms will be tempting.

Re:Nope...

[Lord Apathy]

Because until now Intel has never paid any attention to the low power market. Intel bread and butter is in the desktop and server markets. If, and that is a big if, ARM does make some in roads into the server market then I imagine Intel being the 800 pound gorilla might just have something to say about it.

Besides intel has a excellent low power chip. I have a intel atom processor in my data pad here. The battery life on it is about 10 hours, give or take. It has roughly the same battery life a the previous android pad that I had, which was arm based.

Don't get me wrong. I'm not a fan boy of anything, arm or intel. I just don't see this happening.

Re:Nope...

[MightyMartian]

Of course Intel paid attention to the low power market, which is where the Atom came from. And where is the Atom now????

Intel cuts Atom chips

Re:Nope...

[Lord Apathy]

Well, what do you know. I stand corrected.

Re:Nope...

[farble1670]

There's nothing specific to ARM that makes it low performance, just that they have been focussed on the low energy market but with a significant push the ARM architecture can easily make massive performance gains.

There's nothing specific to Intel that makes it high energy, just that they have been focussed [sic] on the high performance market but with a significant push the Intel architecture can easily make massive energy reductions.

Re:Nope...

[farble1670]

Intel's low power foray into mobile SoC with the Atom platform has been about as successful as Windows Mobile was. So much so they're bailing:

As opposed to ARM's foray into high performance desktop and server processors, which doesn't even exist. Oh but it could be done, it's just that the ARM licensees don't like money.

Like I always say though, the design / product that hasn't yet been implemented will always win against the one that has.

Re:Nope...

[Kryptonut]

ARM are low performance chips, that's why they have the room to improve. Intel server chips crush ARM in performance. Let's take a typical hyperconverged server my employer uses with 8 six core Xeon processors, how many of your USB powered ARM servers will it take to equal that? A row of racks?

The question is though....in some situations....is it better to have a monster multi xeon machine that sits there idling 98% of the time vs an ARM based server that may only be idle 10% of the time while consuming a hundreth of the power that the xeon system does?

Both the multi xeon machine, and the ARM machine have their purposes in the server area. It's about picking the best tool for the job. One size doesn't fit all.

Re:Nope...

[gravewax]

only for very short periods of time where Intel was caught mid cycle so AMD got 6-12 months to get some market. Not sure they really saw it as a significant threat though as Intel would have been well aware of what they had in the pipeline for the next 3-5 years.

Re:Nope...

[Bert64]

A VM can burst easily if load spikes, a physical server cannot unless you build the software to cluster and add more physical servers...
Having 32 VMs in a 1u server is no problem, i have a 1U server with 144gb ram that's a few years old now (hp dl160 g6) that runs many linux instances, some with as little as 128mb of ram.
These VMs may be small, but they will beat small arm servers on processor bound tasks assuming that only a small number of them are under load at any one time (which is the case)... The only thing to consider with a highly virtualized setup is changing the daily crontab times otherwise you get a big load spike at the default time.

Re:Nope...

[thegarbz]

Yep I'm sure a monopoly suddenly releasing capable server chips and desktop chips for half the cost was no threat at all. Intel are really good at one thing: resting on their laurels.

I would wager the opposite: AMD had for long periods been a serious competitor to Intel with shorter periods resulted by some stupid business decisions and the odd dud product.

Re:Nope...

[gravewax]

the fact intel didn't race to compete price wise and instead just released what they had been keeping back really says they didn't panic and had no reason too. I really want to see AMD push them but history shows everytime they get close Intel just spends a little more or pulls out of the closet the next chip they have been holding back while they milk the current one for all its worth. It isn't good enough for AMD to catch up to current stuff, they need to leapfrog.

Re:Nope...

[thegarbz]

the fact intel didn't race to compete price wise and instead just released what they had been keeping back really says they didn't panic and had no reason too.

Oh to live in that wonderful past. I remember it quite different. I remember Intel the laughing stock hamstrung by their general tic-tock cadence while everyone was buying cheaper and faster processors than the Pentium 4. I remember several occasions where Intel announced price drops to coincide with AMD releases, even when AMD performance wasn't up to par yet. Heck we only heard about one last week. I also remember all the marketing an whohar that went into the 64bit abortion of a processor they released while AMD ran rings around them.

Intel are resting on laurels, not some magical hardware, and it has caught them out several times in the past.

Re: Nope...

[Anonymous Coward]

You shut your whore mouth. This has turned into a religious war and you will pick a side and argue the merits of your choice without cease. We will have no rational comments or well reasoned posts, understand? Now get with the program and pick your side.

Re:Nope...

[GreatDrok]

It clearly can't or phones would be full of Intel x86 chips. The x86 underwent a large amount of development during the 90's where it doubled in speed pretty much every year until it peaked in the mid 2000's at which point they switched to multiple cores to keep ramping speed up. ARM took a different approach but the architecture has a lot more room to grow. Back in the 90's all the fastest chips were RISC like the ARM (eg Alpha AXP, SPARC, PA RISC) and x86 wasn't used at all on servers apart from small office servers but as it got faster and LINUX got better it displaced the RISC platforms. ARM will keep getting faster and x86 won't be the only game in town anymore. The last 15 years Intel has had it all its own way although they did get a bloody nose from AMD who produced a heck of a chip in Opteron also introducing us to 64 bit x86 while Intel tried to force the market onto Itanium and failed. Intel isn't the be all and end all of chip designers and it is good that they and Microsoft no longer control the market.

Re:Nope...

[farble1670]

It clearly can't or phones would be full of Intel x86 chips.

Okay. So ARM clearly can because we see server rooms and desktops full of ARM processors? Stellar reasoning. Like I said, at least Intel has a foray into their non-core-competence market. ARM hasn't even tried.

Back in the 90's all the fastest chips were RISC like the ARM (eg Alpha AXP, SPARC, PA RISC) and x86 wasn't used at all on servers

That's curious. So ARM was ahead of Intel in the 90s? ARM had a head start? So I guess ARM didn't just keep "getting faster and faster" did it?

Re:Nope...

[GreatDrok]

Investment in a platform makes all the difference. x86 was selling like hot cakes and Intel pushed hard (as well as being pushed by competitors like AMD, Cyrix etc) to keep getting faster. But physics finally kicked in and they couldn't keep making their chips faster but the costs over the huge volumes made their chips fast enough and cheap enough to compete against RISC chips which were much lower volume and more expensive as a result. Companies can only improve their products on the back of investment which comes from sales. ARM found a niche in low power portable products and so focussed on this because it was earning them money and they didn't need to compete with x86. Other chips died as a result of purchases. Alpha went to Compaq which had bought DEC and then it went to HP who bought Compaq, and they killed it because of the deal they had with Intel to develop Itanium. The Alpha devs went to AMD and producer the Opteron which killed Itanium in the market. The market determines where investment goes as well as the history. The x86 (once it got 64 bit support via AMD64 extensions, a direct result of the Alpha) it became suitable for big servers as it could now address more than 4GB of RAM. ARM continued in its niche but as smart phones came along, the need for more RAM and better performance started pushing the architecture towards the same sort of improvements that the x86 had gone through so it got 64 bit support, and multiple cores too and now the performance of ARM is such that a desktop or server could run on ARM, and ARM hasn't remotely hit the buffers that x86 is hitting.

I'm guessing you've not been around long enough to know this because you sound really inexperienced. I suggest you accept that you're wrong and give it up. ARM will keep getting faster and history got us to where we are. Do some reading, it is fascinating.

Finally ARM in improving

[ruir]

Got malware?

Re:Finally ARM in improving

[Anonymous Coward]

The CIA already figured that out a long time ago according to the new leaks...

Obvious Nonsense

[tsqr]

Everybody knows, "the Cloud runs on Intel."

Oh yeah?

[DontBeAMoran]

Linux servers on Raspberry Pi have been happening for years now, and it should worry Microsoft.

Re:Oh yeah?

[Anonymous Coward]

Raspberry Pi

Fuck the retarded cult!

Re:Oh yeah?

[Anonymous Coward]

Do you know another USD$5 computer?

What's the point?

[Anonymous Coward]

If it's like Microsoft's other Windows on ARM variants, it will only run worthless apps from the Windows Store. What's the point of dedicating a server to running apps?

Re:What's the point?

[Anonymous Coward]

It's a server, it doesn't have to run a gazillion apps, it just has to serve.

Can't wait!

[Anonymous Coward]

It will be fun to watch Windows on ARM "not quite" get the same love and attention as Windows on Intel. It will be even more fun to watch (BIG) customers come to hate Windows even more on ARM as they stumble over the edge cases of things that just don't work. Linux runs fine on ARM, especially on the server. This will be a complete reversal of "I'd run Linux if only I didn't need driver abc or application xyz".

Microsoft has spent too much time and energy into locking the world into it's OS... on Intel. I don't think Intel is very concerned. Any attempt to make Windows work on ARM will just lead to faster Linux adoption rates.

Re: Can't wait!

[Anonymous Coward]

Lol. Same story. Never happens. Linux has its place. Windows has its place.

Invalid conclusion

[mugurel]

Whether this should worry Intel does not depend on Intel's market share in the server world, but on Microsoft's. I suspect not all that much.

Windows Server RT

[Anonymous Coward]

Intel is quaking in their boots with laughter.

AMD busy fighing last war

[beckett]

luckily AMD recently pulled their ARM server Zen line turned back to X86. guess they wanted to shore up that 1%.

Re:AMD busy fighing last war

[cheesybagel]

Too much competition and too little profit in ARM to bother.

sorry i fucked up back there

[beckett]

sorry i was incorrect - the ARM parts were the Opteron product line, and the Zen chips are x86.

Alpha redux...

[Bugler412]

I started my career running NT on Alpha's, great runners, good performance and reliability. However, near zero support from the third party ISVs or add on hardware manufacturers (third party NIC and RAID cards for instance). Unless there is strong market uptake of servers using ARM, I foresee much the same path as NT on Alpha did.

Re:Alpha redux...

[cheesybagel]

Exactly. When you're using Linux or one of the BSDs, most of the apps you want to run are FLOSS, and it's just a question of recompiling them. With Windows, most of the applications you'll want to run are X86 binaries which will have to be translated (i.e. slow) to run on ARM and will be probably buggy. It's dead on arrival.

Perhaps Microsoft could use it internally on Azure but I don't see this having much impact.

Re:Alpha redux...

[Anonymous Coward]

I'm glad you liked our Alpha CPUs. :-) rip dec

Re:Alpha redux...

[scdeimos]

Thank goodness someone else remembers. I keep seeing these "Windows coming to ARM" stories and remember Windows NT... which used to run on IA-32, MIPS, DEC Alpha, PowerPC, Itanium, x86-64 and ARM. The same old shit is shiny new again.

Re:Alpha redux...

[Bert64]

I ran a bunch of Linux servers on Alphas... The vast majority of drivers for x86 also compiled and worked on alpha, as did the vast majority of userland software. There was virtually nothing you could do on an x86 linux box that you couldn't do on an alpha, only the alpha would be much faster.

The problem was cost, the hardware was too expensive and never came down in price. ARM doesn't have this problem, they are already widely available cheaply... If anything it's the opposite of Alpha, with x86 now being the expensive high performance option.

Will it run in a VM? will arm systems be locked to

[Joe_Dragon]

Will it run in a VM? will arm systems be locked to windows boot loaders? don't want to be stuck with hyper-v.

Do ARM chips have the pci-e for storage / 10-gig-e

[Joe_Dragon]

Do ARM chips have the pci-e for storage / 10-gig-e?

Worry Intel, really?

[GuB-42]

Let's assume the following :
- 25% of servers run Linux
- 50% of servers run Windows
- Linux is compatible with ARM
- 1% of server CPUs are ARM, the remaining 99% are Intel
- All ARM servers run Linux
- The situation with Windows Server will now be the same as with Linux regarding platforms.

With these generous assumptions in mind, Intel market share will drop from 99% to 97%, that's 2% less sales, big deal...
The reason servers don't run ARM is not because of incompatibilities. It is because they need more computing power than ARM chips can offer.

Re:Worry Intel, really?

[sl3xd]

Let's look at this slightly differently:

The age of the x86 family being a dominant platform is waning, as mobile computing continues to eat away its market share. It's not that the PC slice is "shrinking", so much as the rest of the market is growing much faster.

Intel isn't headed by fools, and they are aware that they're missing an opportunity. There's money Intel hasn't been successful in getting. Intel has been trying to enter the low-power, portable, and embedded markets, and has been unsuccessful thus far. They'd love to be the chip of choice for smartphones, for example.

So think of it this way: ARM is able to encroach into a market where Intel dominates, but the reverse is not true, in spite of many attempts.

Re:Worry Intel, really?

[EndlessNameless]

So think of it this way: ARM is able to encroach into a market where Intel dominates, but the reverse is not true, in spite of many attempts.

This isn't really the case though.

Intel made one or two pushes into small/mobile and failed. There have been a number of attempts to get ARM into the datacenter. AMD even did a start/stop with ARM.

Realistically, the incumbent in each market enjoys a number of advantages---working infrastructure like peripheral device standards, solid drivers and high-level interfaces, and strong validation/support from industry partners.

These practical advantages are worth far more than the theoretical advantage offered by a "superior" ISA.

If either ARM or Intel could out-engineer the other, they would have overcome those advantages, and the rest of the industry would develop the same level of support for the new platform. But that didn't happen for either party.

The real situation is that semiconductor manufacturing and processor design are two very complex disciplines, and both camps have trouble reaching outside of their respective niches. At the same time, both camps have enough talent to get there eventually---provided there is any room left for whoever ends up in 2nd place.

Re:Worry Intel, really?

[farble1670]

So think of it this way: ARM is able to encroach into a market where Intel dominates, but the reverse is not true, in spite of many attempts.

ARM is able huh? I guess the lack of any high performance ARM processors is due to the fact that ARM licensees don't like money?

The product that doesn't exist will always beat the one that was built. No nasty aspects of physics and market forces to get in the way of it's success.

Re:Worry Intel, really?

[GuB-42]

Behind mobile computing lies huge datacenters full of powerful servers. This is Intel's new market.
Intel isn't pushing that hard for the embedded market. They made a few half-assed attempts but that's about it. The reason they don't push harder, I think, is price. There is plenty of competition in the mobile market and margins are thin. Intel is a big US-based company with high running costs, there is no way it could win a price war.
It is much better suited for high performance computing where margins are higher but large investments are required.

Re:Worry Intel, really?

[Anonymous Coward]

How many times have we heard the breathless mantra:

"Look out! 64-bit ARM servers! OMG WOW, they are going to blow Intel out of the water!!"

And then nothing. Squat. Zilch. 64-bit ARM servers have been a damp squib each and every time.

"Well this time will be different!"

Really? How? What's the secret sauce that makes this time different? Until you make a case that this time truly is different, you're just shilling for an outcome you are HOPING for, not one likely to happen. Your need to humble Intel means nothing to me.

And remember, it's now you making the extraordinary claim. ARM servers have failed so many times, and in so many ways, that you had better bring more to the table than, "well, this company is different!" Even the backing of Microsoft is inadequate to convince me; remember, this isn't the 90's. Microsoft isn't the same company anymore and the computing market isn't the same now. Who really cares what powers those cloud servers? I don't and neither do 99.99999% of all the customers.

Re:Worry Intel, really?

[Bert64]

When ARM was first developed it *was* a high performance processor, beating x86 designs of the day quite easily...
In those days, x86 was the cheap low performance processor that was considered a joke, virtually everything else outperformed it and was a superior design.
But being faster and more expensive just results in lower sales, look at Alpha, MIPS, PPC, HPPA, SPARC, m68k, m88k etc... Intel had a cheap inferior product, but sold them by the millions and it was more profitable than selling a small handful of superior processors. ARM is now doing exactly the same, millions of their processors are sold every day in a huge range of different devices.
Most people likely own and use far more ARM processors on a daily basis than they do x86.

Re:Worry Intel, really?

[Anonymous Coward]

My god you live in a world of wishful thinking, don't you?

"...ARM is able to encroach into a market where Intel dominates, but the reverse is not true, in spite of many attempts..."

Neither party has been successful at entering and establishing themselves, in the other party's stronghold. ARM has been king of mobile. Intel has been king of servers, PC's, laptops and some tablets.

Where are you wrong? ARM has attempted many times to make a viable server chip. Many, many times! And failed, every single time. Yeah, don't bother lecturing me about the differing business models, I know all that. Net results matter and the net result has been retrenchment in the vendor's respective strongholds.

None of this means that additional attempts in the future are impossible, or even doomed to fail. What it does mean however, is that I am skeptical of these companies breaking out of their established areas of dominance. They will have to do something dramatically different, if they mean to mount an assault on the other. There is a record of success in their established markets and a record of failure to break out of those established markets.

So no, ARM does not get a pass from you, where their success in the server market is deemed 'inevitable, and certainly at the expense of Intel'. That is dumb to the point of being megadumb. I'm not sure if you are ignorant, stupid, hopelessly rooting for one side, tirelessly ragging on the other side, but I am sure that your analytical skills are lacking. Do better!

Re:Worry Intel, really?

[AaronW]

ARM never really understood the server until recently. The lack of decent 64-bit support was a major hindrance and all of the emphasis was on the mobile market. There are some decent server oriented chips now. The problem was that Qualcomm and the other vendors didn't understand the server market and what is involved. AArch64 is not the old ARM. Once you ditch the ARMv7 and older baggage you have a very nice modern RISC processor without the major hindrances holding back performance. ARMv7 doesn't lend itself very well to superscalar or out-of-order execution all that well and the lack of general-purpose registers is similar to that of X86. ARMv8.1 helped address the scalability issues involved with a lot of cores by adding atomic instructions.

The older ARM chips contained a lot of cruft like thumb, predicated ALU instructions and having the PC as one of the general purpose registers. This really limited their performance and scalability.

The ARM chips typically lacked things needed for a server like being able to support a large amount of memory with high memory and I/O bandwidth.

The Cavium ARM chip I'm looking at nicely addresses this with a lot more cores than anything Intel has. The Cavium cores also ditch the ARMv7 32-bit ARM instructions, simplifying things a fair amount.

Intel has a lot of cruft as well that hinders them for backwards compatibility. It adds a lot of complexity to the chips and hinders performance. The latest Intel processor still boots up in real mode and has a very complex instruction decoder. For example, with Intel an instruction can span a page boundary and begin on any byte boundary and be variable length. There's support for real mode, 32-bit mode and 64-bit mode. There's still support in there for 80286 segmentation and the old 8087 math coprocessor instructions in addition to MMX and all the SSE variants. There's a fair amount of microcode as well in order to handle everything.

The new server ARM chips do away with all of that cruft. On the Cavium chip, for example, all of the legacy 32-bit instruction decoding is gone as is Thumb. The instruction encoding for AArch64 is completely different than previous generations, in a sense making it a new modern RISC instruction set by taking advantage of everything that has been learned in the last few decades. AMD did Intel a big favor by cleaning things up quite a bit for x86_64, but it still leaves much of the legacy stuff in place which consumes chip real-estate and power.

Closed-source and multi-arch don't mix

[GameboyRMH]

Enjoy the CPU overhead of emulating x86 programs on an ARM CPU!

Re:Closed-source and multi-arch don't mix

[MightyMartian]

Why would they do that? Most of what constitutes Windows, even 20 years ago, was portable. If there's a port of the CLR, well that's .NET (and much of Powershell and its toolkit) taken care of, and I'm sure even CMD.EXE and the older NT toolkit having been built on a system intended to be portable between architectures, is still cross-compiliable. I can imagine that some things like many Server components will require some work to run natively on ARM, I cannot imagine MS going to the effort to produce an ARM operating system (which it has already done, BTW) and not port over all the server components and features for an ARM version of Server.

Re:Closed-source and multi-arch don't mix

[GameboyRMH]

Oh I'm sure they've re-compiled the OS and everything that comes with it (where necessary) for ARM, the trouble comes when you go to install any closed source 3rd-party software on it.

Might bring about some standardization finally

[caseih]

ARM has been an interesting platform of late, but a lot less useful than it could be. Proprietary bootloaders, custom hardware trees, all work against it. No ARM device that I know of can run a stock, off-the-shelf Linux distro with a fairly stock kernel. Not even the Pi. Maybe if MS starts pushing a Window ARM platform, it might provide impetus to manufacturers to standardize the boot loader and the platform so off-the-shelf OS's can run.

I have a drawer full of various ARM devices that were theoretically really neat and useful but in practice proved to be more trouble than they were worth. For example I have two sheevaplugs but the effort to try to update them from their default ancient ubuntu distro is via tftp and serial port u-boot prompt is just not worth the effort. I got more utility with a cheap Intel NUC, even though it was several times the cost of the plug.

Life is a bit better with the Pi since I can just burn a new SD card and boot on it. Still requires a custom distro and kernel. Repeat for every SBC like the Pine64.

Until things get more standardized, I'm skeptical that ARM will do any serious damage to the Intel hegemony, low power notwithstanding.

Re:Might bring about some standardization finally

[Anonymous Coward]

It is for this reason that RISC-V looks so attractive. Even with ARMv8, the spec is something like 8000 pages, and then there is the monstrosity of UEFI to deal with. The world desperately needs good open hardware with a standard platform, that is simple to both target and implement.

Re:Might bring about some standardization finally

[sl3xd]

No ARM device that I know of can run a stock, off-the-shelf Linux distro with a fairly stock kernel.

The Raspberry Pi is one of the more proprietary ones out there, and gets away with being non-standard because the Foundation maintains the fork well enough that few feel any desire to use a standard distribution and kernel (instead opting for NOOBS or Raspbian).

On the other hand, the C.H.I.P. and BeagleBone Black both use standard kernels, and use that fact as a selling point.

In fact, most non-Pi small board computers use standard kernels, because it's the easiest way to support their users.

Re:Might bring about some standardization finally

[sl3xd]

ARM was once a simple architecture that was defined in a small pamphlet.

Once people started to use it, its size began to grow. Soon backwards compatibility became a concern, and the specification grew further.

Every successful specification grows to a size the uninitiated consider absurd. Undefined behavior is the enemy, and a good specification needs to define behavior for corner cases that 99.9999% of readers will never think of, let alone see. Once in the spec, they tend to remain there, because somebody is invariably going to depend on that behavior.

Don't get me wrong - I like RISC-V. But don't confuse a current lack of baggage with superiority. The baggage will come.

Re:Might bring about some standardization finally

[caseih]

Very interesting. So I can just run stock ARM Debian on the BBB? And move the SD card to the C.H.I.P. and have it boot up? If so, that's good news.

Re:Might bring about some standardization finally

[Anonymous Coward]

I'm running a CubieTruck on stock Debian with the generic armmp (multi-plaftorm) kernel. u-boot is always device specific, but CubieTruck support is mainline. Since I don't care about wifi and graphics (it's headless and there is a serial port), I don't even need closed-source firmware. You just need a recent u-boot and kernel (from testing or backports), the ones in Jessie/8.0 have some problems if you want everything to work at full speed.

There is hope that arm64 (ARMv8) brings standardization (at least on server platforms), since it will have UEFI and ACPI

Re:Might bring about some standardization finally

[Anonymous Coward]

Not in a standard installation (everything on the SD card) : u-boot is almost the BIOS on ARM, it's always device specific. And the device-specific DTB to use is hard coded in the boot script.

A solution that may work is to install u-boot on a per-device medium (NAND ?) and boot a generic kernel on another medium

Re:Might bring about some standardization finally

[Anonymous Coward]

Chanticleer Hegemony

Re:Do ARM chips have the pci-e for storage / 10-gi

[Areyoukiddingme]

Do ARM chips have the pci-e for storage / 10-gig-e?

Yes.

Marvell:Armada XP supports four PCI-e 2.0 ports (two x4 ports can be configured to Quad x1 – up to 16 lanes)
Calxeda: Energycore SoC supports PCI Express Four (4) integrated Gen2 PCIe controllers

nVidia Tegra 2 also supports PCI-e. The ARM and PCI-e licenses are compatible. Electrically of course, the choice of supported buses is entirely up to the chip designer.

Re:Do ARM chips have the pci-e for storage / 10-gi

[fnj]

PCIe2, wow. Obsolete junk.

Re:Do ARM chips have the pci-e for storage / 10-gi

[Joe_Dragon]

and only 16 lanes.

Re:Links

[hackwrench]

https://www.bing.com/search?q=... The story is from April 2016.
https://www.bing.com/search?q=... Articles are from August 2016, but dont quite seem to be saying what the other poster was saying.

Re:Do ARM chips have the pci-e for storage / 10-gi

[Megol]

Obsolete? Perhaps you should look up a definition of the word. Junk it isn't, 8GBps* should be more than enough for any reasonable use case.

(* 0.5GBps per lane x 16 lanes)

AMD's Naples/Ryzen is coming soon.

[Anonymous Coward]

And it looks like it might actually compete with Intel. They were able to reduce power consumption, up IPC and core count on the desktop side, so their server processors should be good.

Low watt end of the graph - no decent Intel

[dbIII]

Sometimes maximum watts matters more than performance per watt and sometime Intel doesn't have anything decent to fit the niche. Nothing has changed really.

Japan's Softbank bought ARM last year ...

[devlp0]

Could be Intel's biggest mistake to let that happen!

Not sure about this

[Anonymous Coward]

I hate intel like many, but i dont want Microsoft to embrace ARM and then kill it.

AMD for the punch

[Anonymous Coward]

AMD mentioned plans a while back to combine ARM and x86_64 on the same chip. If they can make it so that server workloads can seamlessly switch between Windows server OS from one platform to the other within the same box I think they have a real winner here. Run light load on many power sipping ARM cores and switch to heavy duty jobs to the big x86 cores, or do both at the same time. That gives maximum flexibility without needing separate hardware.

Past Performance indicates....

[I75BJC]

Past experiences show that Microsoft hates to develop for 2 different platforms. They couldn't even support the differing Intel Pentium and Intel Itanium architectures let alone 2 different brands. (The AMD chips are trapped within the Intel architecture.) Whether M$ will drop ARM or Intel remains to be seen thought Intel has won all the previous battles.

Re:Past Performance indicates....

[AaronW]

The Itanium was quite different than the Pentium. Microsoft already supports two different architectures, X86 and X86-64. ARMv8 AArch64 is not that different than X86-64. While ARM can run either big or little-endian it typically runs little-endian, just like Intel. It also supports unaligned loads and stores like Intel. While hand-crafted assembly for certain things is different there really isn't used all that much any more. In most cases it's just a matter of recompiling. The fact that ARM standardized on UEFI makes things even easier.

The Itanium also suffered from the fact that it was very expensive and the instruction set was extremely complicated and the performance was often not very good except for specially profiled code that could take advantage of its capabilities.

Re:Do ARM chips have the pci-e for storage / 10-gi

[AaronW]

Yes.

Though why just 10-gig-e? The ARM chips I'm working with support multiple integrated 40-gig-e ports and multiple PCIe gen 3 buses.

I have the data sheet for the chip being discussed in the article in front of me. While I can't go into details, it is no slouch and has a massive amount of memory and I/O bandwidth. 10G? That's nothing. I regularly deal with 80G (dual 40G XLAUI) with this chip. The ARM chips are a newer generation than this so the cores are faster.

Some of the ARM chips I work with have built-in RAID engines for offloading all of the RAID calculations as well as engines for a number of other things. Here is a link that shows the I/O oriented chips.

Re:Do ARM chips have the pci-e for storage / 10-gi

[AaronW]

The Cavium chips handle multiple PCI-e 3.0 ports. Here's a brief on the I/O capabilities (though it doesn't go into much detail):
http://cavium.com/ThunderX2_AR...

Re:Do ARM chips have the pci-e for storage / 10-gi

[Areyoukiddingme]

The Cavium chips handle multiple PCI-e 3.0 ports.

Why does that page read like the TimeCube guy? It sounds significantly dubious, as if the chip doesn't actually exist. It sorta sounds like it could exist, but the company is mostly just tossing out a proposed spec, in hopes that someone will fund development of it. Too many superlatives, too many uses of the word "hundreds" in contexts that are exceedingly unlikely. Sounds bogus.

Re:Do ARM chips have the pci-e for storage / 10-gi

[AaronW]

The chip is the one referred to in the article, and yes, it does have hundreds of gigabits of bandwidth to it as it says, especially when there are many 25GBps serdes.