Micron Kicks Off Mass Production of 12 Gb DRAM Chips

No, the power efficiency of (micro)architectures is highly dependent on how well the workload fits design assumptions. CPU cores spend their time in one of several states with different power profiles. You can increase the power efficiency of one state by reducing the power efficiency of another, so assumptions about what a CPU core will spend most of its time doing matter quite a bit in terms of optimizing throughput per watt. If a CPU core spends most of its time idle, it makes sense to optimize power consumption of idle time even if it makes actual computing or waiting for memory more expensive.

Intel microarchitectures tend to be heavily optimized around a workload that assumes a CPU core is doing heavy scalar computation all the time. If your workload and code actually looks like that -- and many kinds of server workloads do -- you can't beat them for performance per watt. But this comes at the cost of things like power consumption when idle. Most personal computing, on the other hand, spends most of its time idle and may benefit significantly from architectures that optimize more for power consumption at low utilization levels. There are many ways to attack these problems at the architectural level.

This becomes complicated to optimize in intermittent compute-intensive environments, since over-optimizing for the idle time effectively increases the amount of time you spend in a less efficient compute-intensive state (see also: Apple's big/little core hybrid ARM architecture). There was a lot of empirical work done on this in the supercomputing world, which is sensitive to power costs and had built ARM clusters. The consensus seemed to be in that environment, for example, that throughput per watt under max load was the driver of power costs, which favored Intel.

Modeling this is difficult because it is a complex interaction between specific pieces of code and specific architecture implementations. Even just comparing Intel and AMD, they have different tradeoffs for real code because the architectures are optimized differently. For example, while some codes run very efficiently on AMD's Epyc, I have a couple old codes that have terrible performance on Epyc that can be traced to design decisions made by AMD. You can't design a CPU that is the best at everything or even most things.

There's not much that intrinsically makes an aarch chip lower-power or more energy-efficient than an x86 or x64 one – energy use will be more about the design goals of the microarchitecture than anything else.

There's a paper from a few years ago the looked into this in some detail – ftp://doc.nit.ac.ir/cee/computer/alinejhad.saeedeh/old/95-96-1/MS/Advanced%20Architecture/project/paper/6-ISA%20Wars%20Understanding%20the%20Relevance%20of%20ISA%20being%20RISC%20or%20CISC.pdf – there's no immediate reason to think the conclusions should have changed.

In addition to what others have said there’s one area to consider: the “uncore” performance: memory controllers, PCIE busses, core crosslinks, cache coherency etc.

Both Intel and AMD have demonstrated they can scale these effectively. The A12X isn’t even playing in the same league when it comes to uncore functionality. I’m sure if you created a version of the A12X with the same cache, memory, PCIE, core count, and interconnections the power picture looks a lot different.

This is part of the reason why “datacenter arm” CPUs never get much of a foothold: as soon as you start ramping up your uncore transistor count, your power advantage erodes significantly, to the point where Intel and AMD begin to yield better performance-per-watt in typical server workloads due to a tightly optimized microarch and an “uncore” to feed it.

Even if one arch is intrinsically lower power than the other, I am not sure that x86 would be the one to come off worse.

For example, could one not argue that an x86 binary / code size is on average smaller and more dense than the ARM equivalent, therefore on x86 cache misses will be less common, less ram needs to be used etc etc. Perhaps a denser binary is better for power consumption?

Although this effect would be very marginal even if it is present at all.

In the end it all comes down to the energy cost of doing a computation. With good architectures and compilers, the code is causing as few unnecessary bit flips as possible to get to the results and, unless you have a significant difference in how much energy it takes do that, all CPUs will end up close.

But CPUs are just part of the equation - you can make significant gains in other parts of the computer and memory is a good target. When we got to the point PSUs live as independent things plugged into the same rack as your servers, it means we are really concerned about not feeding one amp more than we need to.

We have about 40 years of software development on x86. I'm not even sure we could reuse any of that when moving to a new architecture.

Significant portion of that electricity spend is to power cooling systems tho

Yes, it might; though, unlike memory, a processor is more than just a frequency/feature size and a TDP. A processor also has specialty instructions which workloads may have been optimized for.

I would expect that right now, Google is 1. seeing to the re-engineering of certain math libraries they use internally for Google Search et al, and 2. like AWS, intending to create separate cloud-VM instance classes for Intel vs. AMD processors, where each workload type can “pay its own bills.” If AMD continues to dominate in server TDP, then I would expect this to lead to the AMD instance classes getting cheaper while the Intel classes remain the same; and so most customers switching to AMD instances, save for the customers who themselves have workloads optimized for Xeon-specific SIMD instructions.

Care to link to processor efficiency benchmarks underlining your statement?

Google produces their own sticks anyway.

At one point they were taking chips that had failed manufacturers QA, sticking them on DIMMs themselves in a way so that the ECC would cover those errors, and just running jobs on many machines to make up for the reduced ability of ECC to make guarantees.

And the make their own motherboards too, so just soldering down LPDDR isn't out of the question.

LPDDR doesn't come in modular form. It's always soldered onto the same PCB as the processor. The number of packages used is determined by the data bus width of the processor. If Google has access to a processor with a DRAM controller that supports LPDDR4 and ECC, they can design a suitable motherboard.

Do you not think the IO voltage reduction alone gets you that? Or are you saying its just not worth it?

> It’s not unreasonable though. For every x watts of server you need y watts of cooling.

Probably less than you think. To be precise, for every x watts of power Google needs about y = 0.12*x watts of cooling (and other overhead) on average. That's based on the PUE number at <https://www.google.com/about/datacenters/efficiency/internal....

> Years ago Google complained that they couldn’t fill up their data centers because they had hit the limits of electrical code. Servers plus A/C took them into no man’s land as far as electrical code was concerned. That also means wasted real estate.

I don't remember that, but I'm guessing it was from the days Google's servers were in datacenters built by other companies. They probably outfitted so many circuits at x volts / y amps each, and there's only so much you can do with that.

(To be precise, Google still runs some servers in non-Google datacenters, as part of running a CDN. But this isn't the bulk of Google's processing power.)

That seems unlikely. An aluminum smelter uses far more energy than a data center ever will.

Well, since you started, it's not 1.5Gb, but 1.5GB :)

Were there any 3-core processors which were not de-rated 4-core processors?

> Phones want 6 GB

Why? Why not 8? Whatever, I doubt I've ever seen a phone with more than 2 GB RAM. I wish my phone was as powerful as my PC (which is very old, has 4 GB RAM and can't handle more because of the chipset limitations) so I could just attach peripherals I want, boot a desktop Linux (directly or in a VM) and use it instead of the PC.

A datasheet for a related non-power-of-2-sized product from Micron gives a hint as to what they're doing:

https://prod.micron.com/~/media/documents/products/data-shee...

Page 28:

"For non-binary memory densities, only a half of the row address space is valid. When the MSB address bit is HIGH, then the MSB-1 address bit must be LOW."

They basically cut off the upper 1/4 of the address decoder.

Also, and speaking as a jaded developer, it’s strategically a bad idea to give your team a 2x bump in available memory especially if it’s maxing out the memory on your servers. If that’s 16GB per slot then 12GB DRAM sticks let you slowly increase memory a bit longer.

Once you hit the ceiling a whole bunch of disciplines have to change overnight. Better to give them a 25-50% bump and start the story about horizontal scalability before you’re entirely out of other options.

Or Apple switch them to the A series processors! Although I really cannot see that happening on the pro lineup anytime soon (Although I think its highly likely on the air and non-pro MacBooks)

So I wonder if Micron will support 16Gbit LPDDR4X chips by the time Intel launches its 10nm chips.

Apollo lake and Gemini lake support regular LPDDR4. I bet, you can make it use LPDDRX timings.