Editorial x86 Lacks Innovation, Arm is Catching up. Enough to Replace the Giant?

[trparky]

Come on, let's be real, ARM simply took existing features and techniques meant to increase performance and adapted them to low power designs, their ideas didn't came up entirely out of thin air.

Yeah but you have to admit that it was a minor miracle that they were able to port that kind of functionality while maintaining low power usage. Meanwhile you have chips like the 8700K and 9900K that sucks power like there's no tomorrow.

If you really believe that, I have a bridge in Brooklyn I'd like to sell you, for cheap.

If this thing in New York keeps going you might be able to do that. I can imagine that real estate is going to go for cheap in a few months. But that's morbid talk there.

while x86 works and sometimes goes idle when unused but still terrible efficiency by any means.

Yeah, you got that right. I had to stop Folding@Home on my 8700K because it was easily sucking down 130 Watts out of the wall, at least according to my UPS. Now I only fold on my GTX1060 since it doesn't suck down nearly the same amount of power.

 

[ValenOne]

Intel is so strong that it sold its baseband solution to Apple.

For IoT, car and other appliance solutions, a quad-core generic ARM cores will do.
1. If you go x86, you will risk to have only 2 suppliers (Intel / AMD) while when you go ARM, you can just license and create your own solution.
2. x86 has neither performance nor power efficiency benefits over ARM in this segment.

There are many examples that Intel does not want to go "low-end":
1. Optane over NAND flash (sold to Micron)
2. x86 tablet solutions (ARM is dominant)
3. Rambus over DDR-RAM

For X86 CPUs besides AMD and Intel, there are VIA and CCP sponsored ZhaoXin X86 clone.

 

[ARF]

Actually, you got it all wrong.
Back in the 80s there were two main arguments in the CISC vs. RISC discussions;
- A smaller instruction set allows higher flexibility in implementation
- Having to support legacy instructions in hardware
Moving to using micro-operations solved both of these, and therefore eliminating the only real advantages of RISC over CISC. In all x86 CPUs since the early 90s, the CPU front-end decodes the x86 ISA into the microarchitecture's specific ISA, which gives the designer full control over which instructions are prioritized in the hardware implementation, and which can be "simulated" using a combination of other instructions. This way the instructions can be optimized for however many execution units and various resources are present in the CPU, and the whole pipeline doesn't need to support every legacy feature. Every modern x86 microarchtecture is sort of a hybrid of CISC and RISC, with RISC-like micro-operations. Even current ARM microarchitectures have gotten some CISC-like features including some SIMD and loads of ASIC features, but still differs from modern "CISC" designs by using a load-store architectures (like FordGT90Concept mentioned), which means that ARM will always require more instructions to do the same work.

x86 is still advancing, and if anything x86 is more held back by software than ARM is respectively. Very little software is compiled to use any ISA features beyond AMD64/SSE2, even as recently as Sunny Cove Intel added an instruction to speed up memory copying. AVX-512 is also shaping up to become very flexible compared to previous iterations, hopefully AMD will support it soon. Further down the line, Intel is researching into "threadlets", which have to potential for massive performance gains, but yet again are more in the "CISC" direction than "RISC".


While ARM have changed a lot over the years, it dates back to ~1985, so I wouldn't call it quite a "clean slate".

You forget the most important thing. Currently, Intel is having tremendous manufacturing nodes problems, so no matter what they got on paper, if in the physical world they only produce quad cores with max TDP 28-watt, then they are doomed. Their manufacturing arm might be soon for sell.

Empires rise and fall. Intel will be next.

 

[TheoneandonlyMrK]

You forget the most important thing. Currently, Intel is having tremendous manufacturing nodes problems, so no matter what they got on paper, if in the physical world they only produce quad cores with max TDP 28-watt, then they are doomed. Their manufacturing arm might be soon for sell.

Empires rise and fall. Intel will be next.

While you're empirical statement might technically be true it's a bit dramatic and short sighted, chip's may be Intel's bread and butter but they are far from their only revenue stream, and that's also ignorant of the Vast amount of IP Intel own.

I think the Op lacks some foresight too though, saying x86/64 lacks Innovation, AMD will with Intel ram that ideology back in his face within three years IMHO.

Arm will always have it's uses but the push to high end can't go fast enough and MIPS is stealing away their bottom end.

Interesting times.

 

[r9]

This is kind of pointless discussion.
The broader the purpose of ARM the fatter it will get. Arm laptops are terrible btw.

 

[danbert2000]

Though ARM is showing signs of life outside mobile, I don't think the architecture can overcome the sheer scope of x86 specific software and drivers for the Windows ecosystem. Perhaps the success of Raspberry Pi and other single-board computers have opened the door for first class Linux support, and of course Android and iOS are ARM-native, but to break into Windows requires having drivers for not only new hardware, but generic drivers for a decade-plus of legacy hardware. One of the great parts of the Windows experience is that you can take a Windows 10 thumb drive, plug it into just about any x86-based computer from 2000 or later, and it will be able to install drivers and software that makes the computer run anything coming out today, albeit slowly, and games probably excluded since GPUs deprecate much faster than any other part of the computer.

ARM would require a clean break for desktop computers in a way that Apple has some experience, but Microsoft likely will have to support ARM as a second class citizen for quite some time. Over time they will be able to add support for all the USB devices that need ARM specific drivers, but it's a long road and sure to break compatibility in enough areas that most businesses will continue to choose to keep with x86.

The mention of games is important, too, because consoles are moving to be more entrenched with x86, not less. PC gaming has benefited from the fact that ports now don't require rewriting the game engine to work on a different ISA. I suppose the Nintendo Switch and mobile are the only holdouts, where ARM is mandatory. I suppose the fact that most people use middleware like UE4 and Unity also helps to lay a path towards PCs eventually getting ARM binary support. But it is a sort of chicken and egg situation. Game makers aren't going to waste their time making sure that a game works on Windows on ARM when there aren't even drivers for graphics cards available. There's no hardware support for Windows on ARM outside of specific, mobile-oriented hardware stacks. So there's not even a customer waiting for game support until there is the chance to buy or build an ARM gaming machine. And AMD has little to no motivation to support their graphics cards on ARM. I guess Nvidia has enough of the stack working for their Shield products and for the Switch, but BSD/Linux drivers don't just port over to Windows on ARM. So the hardware isn't there because the driver support isn't there, the games aren't there because the hardware support isn't there, the driver support isn't there because the hardware and games aren't there. I don't see a credible way forward for Windows ARM game support outside of mobile games on the Windows store.

I appreciate the article, and I'm sure that ARM support will trickle into more controlled areas like ARM thin and lights and tablets, or servers with well defined stacks that are most of the way there to supporting ARM anyway, but for actual work and gaming PCs, someone would have to put out full support before there is even remotely a profit motive. I doubt that's going to happen now that game development is x86 first for PC and consoles. The only entry was during the PS3 and 360 days, when code had to be ported between ISAs just to get a port going at all. Now that things are so well aligned around x86, it would take an act of God to get support moving across hardware makers, drivers, software, and games. ARM will push x86 performance forward just because of servers and embedded. x86 is going nowhere for consumer laptops and desktops running Windows.

 

[efikkan]

Though ARM is showing signs of life outside mobile, I don't think the architecture can overcome the sheer scope of x86 specific software and drivers for the Windows ecosystem.

Compiling for ARM isn't hard, but making something run fast on ARM hardware is harder, as the various chips are very customized. The various chips from Apple, Samsung, MediaTek, etc. have very different accelerated features outside the base ISA. Using these accelerated features is essential to achieve good performance on phones, tablets, etc. But this means that software needs to be ported not only to ARM, but to numerous different ARM implementations, unless you just want to stick to the basic feature set, which is slow. This is the downside of custom features.

The mention of games is important, too, because consoles are moving to be more entrenched with x86, not less. PC gaming has benefited from the fact that ports now don't require rewriting the game engine to work on a different ISA.

The reality is that PlayStation and Xbox are benefiting from being similar to PCs as a whole, not primarily due to the ISA.
Practically no games are written with substantial amounts of x86 assembly or intrinsics these days (except perhaps a few uses AVX), so they should ultimately be portable. But having PCs very similar to the consoles is a huge advantage for other reasons, since development kits are not only expensive, but usually not ready years ahead of new consoles. Most games these days use off-the-shelf game engines, and most studios only write high-level code to interface with an engine.

 

[Tartaros]

Like some others said, it would depend on how the businesses and organizations are willing to move on, and I think the example here would be IBM's mainframes. Everyone wanted to get rid of those old massive monolithic systems that are so ugly and stuck in the past in the 90's. They later realized that upon decades of developement on them and security problems on microkernel systems, the cost was so high they ended up doubling down on mainframe.

It would be a per case scenario, maybe x86 on consumer grade hardware would be replaced by ARM, but I doubt the industry would make that change.

 

[Vayra86]

Though ARM is showing signs of life outside mobile, I don't think the architecture can overcome the sheer scope of x86 specific software and drivers for the Windows ecosystem. Perhaps the success of Raspberry Pi and other single-board computers have opened the door for first class Linux support, and of course Android and iOS are ARM-native, but to break into Windows requires having drivers for not only new hardware, but generic drivers for a decade-plus of legacy hardware. One of the great parts of the Windows experience is that you can take a Windows 10 thumb drive, plug it into just about any x86-based computer from 2000 or later, and it will be able to install drivers and software that makes the computer run anything coming out today, albeit slowly, and games probably excluded since GPUs deprecate much faster than any other part of the computer.

ARM would require a clean break for desktop computers in a way that Apple has some experience, but Microsoft likely will have to support ARM as a second class citizen for quite some time. Over time they will be able to add support for all the USB devices that need ARM specific drivers, but it's a long road and sure to break compatibility in enough areas that most businesses will continue to choose to keep with x86.

The mention of games is important, too, because consoles are moving to be more entrenched with x86, not less. PC gaming has benefited from the fact that ports now don't require rewriting the game engine to work on a different ISA. I suppose the Nintendo Switch and mobile are the only holdouts, where ARM is mandatory. I suppose the fact that most people use middleware like UE4 and Unity also helps to lay a path towards PCs eventually getting ARM binary support. But it is a sort of chicken and egg situation. Game makers aren't going to waste their time making sure that a game works on Windows on ARM when there aren't even drivers for graphics cards available. There's no hardware support for Windows on ARM outside of specific, mobile-oriented hardware stacks. So there's not even a customer waiting for game support until there is the chance to buy or build an ARM gaming machine. And AMD has little to no motivation to support their graphics cards on ARM. I guess Nvidia has enough of the stack working for their Shield products and for the Switch, but BSD/Linux drivers don't just port over to Windows on ARM. So the hardware isn't there because the driver support isn't there, the games aren't there because the hardware support isn't there, the driver support isn't there because the hardware and games aren't there. I don't see a credible way forward for Windows ARM game support outside of mobile games on the Windows store.

I appreciate the article, and I'm sure that ARM support will trickle into more controlled areas like ARM thin and lights and tablets, or servers with well defined stacks that are most of the way there to supporting ARM anyway, but for actual work and gaming PCs, someone would have to put out full support before there is even remotely a profit motive. I doubt that's going to happen now that game development is x86 first for PC and consoles. The only entry was during the PS3 and 360 days, when code had to be ported between ISAs just to get a port going at all. Now that things are so well aligned around x86, it would take an act of God to get support moving across hardware makers, drivers, software, and games. ARM will push x86 performance forward just because of servers and embedded. x86 is going nowhere for consumer laptops and desktops running Windows.

This man gets it.

People always think way too easily of software. Take Windows and the criticism on it for instance. You can write books full of the bugs and minor and major screwups of MS, and of the infinite amount of issues users experience. And yet... it is still the dominant OS. Not just at home... but in enterprise too.

The code base and legacy Windows has is its strength, and I reckon it will remain so especially in a fast moving world such as this. Look at how we respond to changes. The Start Menu. The internet exploded... We don't want that. Its no coincidence that MS turned 180 degrees after the initial Windows 8 release and turned 10 into an improved 7. And if you squint a little bit, those releases we get now... aren't those really just glorified service packs? I think this company is learning quickly that people really are not ready for a paradigm shift at all when it comes to how they use technology. Those tablets and smartphone OS'es are just that. They are on top of other things that also just need to be done, or people just want to do. If you have serious productivity work of any kind, it won't happen on ARM.

And that is just consumer... now Enterprise. Look at what Windows has evolved into over there. A stable release, coupled with a top-end quality cloud service called Azure and all of the legacy and quality they built into Office and connected applications; all migrated and fully compliant with intranet / business environments. They are selling that subscription OS. But its called Azure now, and its booming. At the same time, MS's ARM efforts quickly turn to shit...

 

[TechLurker]

And AMD has little to no motivation to support their graphics cards on ARM.

Well, they kind of do? They did come to an agreement with Samsung to start porting over elements of RDNA to bring GPU power to the mobile-world. AMD will have to optimize some features for the ARM-world. On the other hand, having the mobile world start tweaking towards a dedicated RDNA-based system (thanks to Samsung's relative popularity and dominance) helps AMD break into the ARM and mobile ecosystem via their GPU division (and competing with NVIDIA's half-hearted attempts).

On a more direct front, AMD also still has their K12 ARM design in reserve, though they haven't had a need to bring it out after the runaway success of Ryzen. If any company was to be in a prime position to evolve with either side (ARM or x86-64), AMD would be it, as they'd also be able to take the console manufacturers with them, considering AMD's well-established Semi-Custom business.

------

At any rate, it'll be impossible for ARM (and it's "more open" cousin RISC-V) to really overtake x86-64 for the same reasons it's more popular than x86-64; the sheer variability between ARM designs. We already see issues in the mobile world where games and apps have issues running consistently across different ARM devices of the same generation, to say nothing of running consistently across older devices ("Your Device is No Longer Supported. Please Upgrade your Device to Continue Using This App").

x86-64 rarely experiences extreme changes between generations partially due to the lack of competitors, but does include support for older instructions, and is also more stable and consistent as a result. While not exactly optimal, it is possible to run even older OS like Win98 and ancient, single-purpose, x86 programs on a modern x86-64 CPU and it'd still run with minor tweaking.

Apple is pretty much the only one that's remotely capable of forcing the software ecosystem to change; but even that is limited to their walled garden. That and dictatorships with a strong technological arm, like China or Russia, who already are trying to reduce reliance on x86 in favor of ARM/RISC-V designs.

What we're more likely to see is heavy emulation. It's currently easier for x86-64 systems to emulate ARM-based software, but not the other way around. Microsoft is leading the way with their Windows on ARM initiative, and I expect others to follow suit. But I don't expect ARM to ever really overtake x86. Both can coexist with their niches; one able to be flexible and hyper-focused, one that remains steady and consistent.

 

[R-T-B]

They never quite made it

ARM has mad it to high performance. Read the article.

ARM will never be as universal as x86 (not anytime soon anyway) one reason being the giant pile of old but extremely necessary software lying around. Control systems for many things, medical stuff, industrial stuff, and so on and so forth.

For extremely old software, there is emulation as an option. For more modern games, it's a little more tricky.

The headline of the article is x86 Lacks Innovation and you are arguing that x86 is a second coming of Jesus Christ.

It's neither. People are obsessed with what language the processor speaks when it means very little. The micro-architecture makes a much bigger difference.

X86 is just a dialect.

 

[bug]

Actually, you got it all wrong.
Back in the 80s there were two main arguments in the CISC vs. RISC discussions;
- A smaller instruction set allows higher flexibility in implementation
- Having to support legacy instructions in hardware
Moving to using micro-operations solved both of these, and therefore eliminating the only real advantages of RISC over CISC. In all x86 CPUs since the early 90s, the CPU front-end decodes the x86 ISA into the microarchitecture's specific ISA, which gives the designer full control over which instructions are prioritized in the hardware implementation, and which can be "simulated" using a combination of other instructions. This way the instructions can be optimized for however many execution units and various resources are present in the CPU, and the whole pipeline doesn't need to support every legacy feature. Every modern x86 microarchtecture is sort of a hybrid of CISC and RISC, with RISC-like micro-operations. Even current ARM microarchitectures have gotten some CISC-like features including some SIMD and loads of ASIC features, but still differs from modern "CISC" designs by using a load-store architectures (like FordGT90Concept mentioned), which means that ARM will always require more instructions to do the same work.

x86 is still advancing, and if anything x86 is more held back by software than ARM is respectively. Very little software is compiled to use any ISA features beyond AMD64/SSE2, even as recently as Sunny Cove Intel added an instruction to speed up memory copying. AVX-512 is also shaping up to become very flexible compared to previous iterations, hopefully AMD will support it soon. Further down the line, Intel is researching into "threadlets", which have to potential for massive performance gains, but yet again are more in the "CISC" direction than "RISC".

But that's just the thing, having to break down into microops needs silicone, it's a trade-off. Apparently a very costly one when trying to scale down.
And then you have to consider, another point in favor of RISC was simpler compilers. But as the hardware grew stronger, smarter compilers aren't the problem they used to be (though as all things programming, simpler is still better). And then RISC itself isn't what it used to be. I don't know ARM architecture very well, but I'm willing to bet its instruction set isn't as reduced as it was 10-15 years ago.
So I guess what I'm trying to say is there are arguments going both ways.

While you're empirical statement might technically be true it's a bit dramatic and short sighted, chip's may be Intel's bread and butter but they are far from their only revenue stream, and that's also ignorant of the Vast amount of IP Intel own.

You know him so well

 

[TheoneandonlyMrK]

But that's just the thing, having to break down into microops needs silicone, it's a trade-off. Apparently a very costly one when trying to scale down.
And then you have to consider, another point in favor of RISC was simpler compilers. But as the hardware grew stronger, smarter compilers aren't the problem they used to be (though as all things programming, simpler is still better). And then RISC itself isn't what it used to be. I don't know ARM architecture very well, but I'm willing to bet its instruction set isn't as reduced as it was 10-15 years ago.
So I guess what I'm trying to say is there are arguments going both ways.


You know him so well

Look up Intel's subdivisions , then say they're in trouble that's all I'm saying.
I also was amused that the Op went on to do a piece on tech that makes this whole thread a true comedy.
So CXL and genZ tie up and X86 has issues, with the accelerator tech it will bring it hasn't, you know.

 

[bug]

Look up Intel's subdivisions , then say they're in trouble that's all I'm saying.

It's one of ARF's memes (he doesn't have many). It's dumb, I'm not going there.

 

[notb]

Yeah but you have to admit that it was a minor miracle that they were able to port that kind of functionality while maintaining low power usage. Meanwhile you have chips like the 8700K and 9900K that sucks power like there's no tomorrow.

-K CPUs are DESIGNED to suck a lot and push as much performance as possible from the architecture. It takes away some efficiency, obviously. But less than you would think. Maybe even less than it gains from being made out of best quality dies.

There's still a big misunderstanding of what "efficiency" is.
Sure, if you run a PC for few hours and do multiple things: go through TPU forum, watch a movie, play a game, leave it idle while cooking etc, 9900K will use more power than e.g. 9900T or something similarly frugal. And way more than an ULV SoC for laptops or something ARM-based.

However, if you power up a PC, run a 100% load and switch it off, 9900K will use pretty much the same amount of energy any other CPU form it's generation would. It'll just complete the task a lot faster.
Check the last graph here:

Intel Core i9-9900K Review

Today, Intel released their new flagship processor for the LGA 1151 platform. The Core i9-9900K finally comes with eight core and 16 threads, reaching parity with AMD's Ryzen offerings. Maximum Boost Clock has been increased as well, now to a staggering 5 GHz.

www.techpowerup.com

So efficiency is measured differently for e.g. networking devices which run non-stop and for workstations which don't (not all of them anyway).

ARM CPUs aren't magically more efficient. They're just slow.
If you really want to compare, do it against a -U SoC.

Compiling for ARM isn't hard, but making something run fast on ARM hardware is harder, as the various chips are very customized.

It's not about compliting for ARM being hard or not. It's about the cost of recompliting everything we need. And more importantly: of supporting and optimizing for both architectures.

If we now ask companies to make the same software for both x86 and ARM, they'll just ask more for it. And software is already way more expensive than hardware (at least in the enterprise segment).
It'll just make computing more complex. Complexity always costs. There's just no gain in this in long term.

There's still a lot that can be done to improve x86 efficiency and flexibility. The heterogeneous architecture idea (e.g. Intel Lakefield) is the most obvious - and for some reason: very underestimated on this forum...
If ARM didn't have big.LITTLE, we probably wouldn't be having this discussion. ARM SoCs would suck just like they did 10 years ago.

 

[ARF]

There is surely a reason why the top 3 fastest supercomputers are based on RISC processors - top 1 and 2 are on Power9, and top 3 is the Chinese SW26010.
And why all of our smartphones and perhaps tablets (here I cannot confirm) are ARM based.

The only x86 segment is the desktop mainstream which actually doesn't see its best times with Intel not moving from its 5-year-old CPU, and VIA only competing with Intel's 7th gen i5 and i3.

 

[TheoneandonlyMrK]

There is surely a reason why the top 3 fastest supercomputers are based on RISC processors - top 1 and 2 are on Power9, and top 3 is the Chinese SW26010.
And why all of our smartphones and perhaps tablets (here I cannot confirm) are ARM based.

The only x86 segment is the desktop mainstream which actually doesn't see its best times with Intel not moving from its 5-year-old CPU, and VIA only competing with Intel's 7th gen i5 and i3.

Seams like a narrow viewpoint issue to me , desktop mainstream is far from the only segment sold in to by X86 tech.
I worked at companies that sold intel chips in lab equipment all year long, they sure as shit won't swap to arm , despite wanting iPad control.

 

[notb]

There is surely a reason why the top 3 fastest supercomputers are based on RISC processors - top 1 and 2 are on Power9, and top 3 is the Chinese SW26010.

They're in top3 because they are enormous. It has nothing to do with architecture.
Plus, the top two are GPGPU-based.
These are clusters. You have some processing potential in mind and you provide as many cores as you need to fullfil it.

But I commend how you're looking into new ways to support your crazy ideas.

And why all of our smartphones and perhaps tablets (here I cannot confirm) are ARM based.

Because ARM was designed to power these devices.
BTW: your blender is also RISC-based. Make yourself a green tea smoothie - it'll help with all that stress.

The only x86 segment is the desktop mainstream which actually doesn't see its best times with Intel not moving from its 5-year-old CPU, and VIA only competing with Intel's 7th gen i5 and i3.

And puff! Just like that servers and laptops stopped existing.

 

[lexluthermiester]

Arm laptops are terrible btw.

No they're not. They're a great idea.

 

[mtcn77]

There is surely a reason why the top 3 fastest supercomputers are based on RISC processors - top 1 and 2 are on Power9, and top 3 is the Chinese SW26010.
And why all of our smartphones and perhaps tablets (here I cannot confirm) are ARM based.

However, the personal computer is not HPC, nor a mainframe. They are worlds apart.
Likewise, CISC architecture is developed on the basis of Load to Store memory access architecture - which RISC does not have - to maximise register bandwidth, cause RISC does not have alignment issues that come with L2S accessing. Had ARM had L2S now, its native access performance would stop being a feature of the code base.
Intel while there is a misconception that suggest hasn't developed its core architecture apart from simple IPC improvements, have actually made big swings in load to store accesses, essentially freeing any code alignment dependence. Write anything and it profers top notch cache buffering. Thus, it has made the opposite access pattern its core feature, exemption of any alignment penalty.
Intel and AMD has made such attempts to highlight a similar goal that which is, again, groundbreaking and distinct from supercomputer goals. You don't build a supercomputer for branch handling the most accesses by the base computer processor unit, you do it exclusive to computing. However, in client environment, throughput is second to accesses. Both cpu brands have their gpu compute lineups for throughput, the cpu is only relegated to its frontend decoder in future workload projections. In that read ahead decoding, you need L2S and that makes Intel a good cpu despite some form or another of depreceated dsp vector computers might score paper tiger thoroughput numbers, it is a joke Intel/AMD is too scalar to understand.

 

[lexluthermiester]

However, the personal computer is not HTPC

What? I make Home Theater PC's on a regular basis. PC literally stands for Personal Computer. I think you have your terms mixed up..

 

[mtcn77]

What? I make Home Theater PC's on a regular basis. PC literally stands for Personal Computer. I think you have your terms mixed up..

HPC, I guess I met the nomenclature this time.

 

[trparky]

-K CPUs are DESIGNED to suck a lot and push as much performance as possible from the architecture. It takes away some efficiency, obviously. But less than you would think. Maybe even less than it gains from being made out of best quality dies.

Yet AMD is showing that they can do more work with more efficiency. Goes to show you that Intel badly needs a new architecture, the current one is showing that it's not up to the task.

 

[mtcn77]

Yet AMD is showing that they can do more work with more efficiency. Goes to show you that Intel badly needs a new architecture, the current one is showing that it's not up to the task.

Same goes for qualcomm. They park bang in the middle of the task efficiency zone. At least for spec2006. That is just crazy level of tuning, btw. It is a full house unless kirin 990.

This is picture perfect performance right out of the box.

 

[londiste]

Yet AMD is showing that they can do more work with more efficiency. Goes to show you that Intel badly needs a new architecture, the current one is showing that it's not up to the task.

Intel needs a new manufacturing process. They have architecture(s).