Discussion: AMD's last hope for survival lies in the Zen CPU architecture

Page 5 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.


AMD motherboards have some issues, particularly the lower end models having very weak, uncooled VRMs that can't even handle an 8 core FX chip at stock speeds without throttling, yet those 8 core chips are still on the CPU support list for those cheap boards. AMD does need to reign in some of the corner cutting the motherboard manufacturers do on the low end, especially if their chips are going to continue consuming lots of power.
 
AMD will never catch a break in the CPU market. Even if they double the performance of a competing Intel it won't matter. Lets face it, the Athlon64 was vastly superior to the Pentium IV, but the chip maker could not make any serious gains.
The same applies in the GPU market. From the Radeon HD 4800 until the 7900 it dominated the GPU market. It didn't stop most people from buying nVidia.
 


I haven't looked at at all AMD boards, probably not even most, but I usually don't see this. Most of the time, the cheap boards I see specifically say they don't support CPUs over 95W, so almost every 8 core model isn't supported.
 


I doubt they'd be in too much trouble. Servers are going to get more important as tablets and smart phones rise and Intel has a strong presence in that.
 


All you need to do is look at any of the 700 series chipset boards that say they support the 125 Watt CPUs and even some of the cheaper 970 chipset boards and you will run into them. They will say they support 125 Watt 8 core FX chips, and they will boot up, but put them under load, and the CPUs start constantly bouncing back and forth between idle and maximum clockspeed because the VRMs start overheating. It's why there's always lots of threads with people complaining about poor performance on their 8 core FX CPU. The 8 core FX CPUs tend to need more than a 4+1 phase VRM to work properly, and none of the cheaper boards have anything more than that.
 

If x86 ends up becoming a second choice for personal computing, there is a high probability developers who have grown on ARM/Android or ARM/whatever will be more than happy to select ARM/whatever when they need to pick servers.
 


The ONLY reason X86 is still a thing is because Windows doesn't support any other architectures. That's why I'm still sad WinRT bombed as badly as it did.

X86 was always intended to be a stopgap architecture; it's VERY inefficient, and if Intel actually junked it and designed a better arch without needing to waste die space to support X86's quirks (segment registers, X86 Real/Protected/Extended modes, etc), you'd probably gain a good 25% CPU performance for free. X86 is a 30 year stopgap at this point, due in large point to the lack of software support for any other alternative.
 

I would not be so sure about that: if you look at all other architectures that are still under active development, none of them match up against Intel's on single-threaded IPC. All the remaining high-performance computing and server chips have given up on raw single-thread performance and have gone SMT.

With Intel implementing legacy instructions and quirks in microcode, there isn't much of the x86 legacy left in the performance-critical path.
 


PPC and POWER are both faster clock for clock. ARM is catching up fast too. As far as design goes, X86 is VERY inefficient because Intel has refused to clean up the architecture at the expense of compatibility.
 
The problem to get rid of the fat inside X86 (and X86-64 ext) is the legacy code running in big companies. There is no company in the whole world that will like to hear Intel say "ok guys, next CPU will make you re-compile and re-adapt your code!". That would cost companies running legacy code millions. They will be willing to not buy a new system and make do until the balance of cost turns around. That in itself could cost Intel millions.

It's the same problem Khronos faces with OpenGL. The API has a ton of fat and big players relying on that legacy part are not giving it up.

It's a HORRIBLE balancing act when you have a successful product. ARM, IBM or any other ISA creator would face the same problem if they are widely adopted and not in time-critical systems (these are usually state of the art or rarely changed).

Cheers!
 

Modern POWER-series CPUs have axed most out-of-order execution capabilities in favor of SMT with four threads per core. They aren't going to perform anywhere near as fast as Intel or even AMD CPUs in desktop applications.

ARM is "catching up fast" only because they are implementing many of the performance enhancement tricks x86 and other mature architectures not limited by handheld power budgets have had for over a decade, much like how Intel had to axe tons of stuff to create their first sub-5W mobile CPUs and then added most of it back in to get performance back up once they figured how to do so while still reducing power.

Single-threaded performance is ultimately limited by instruction-level parallelism (software design) and there is only so much that hardware can do about it before the power and complexity costs get out of control. In a few years, when ARM reaches a similar maturity to x86, it will hit very similar performance speed bumps. Just like all other architectures ever invented. This is why all HPC and server chips are going SMT to mitigate the ILP bottleneck. Even Intel does it with Xeon Phi.
 


Absolutely. I have done tech support for a major car manufacturer, a lot of that in their RnD, and you wouldn't believe the lengths they will go to keep old software running. Stuff like measurement instrumentation that is at least partially self-developed, for which there is no support, but it has to run anyway because they haven't found a good replacement on the market. So you try to make do with virtual machines or getting special permission from central IT to purposely keep a machine out-of-date and off the network (a fucking nightmare to convince them. Not that I blame them, I don't really want to do it either.) to keep this hardware running.
 


I'm not disagreeing with this at all (And I work with HP Calculator based software that no one really knows how it works anymore). Just pointing out, if Intel wanted to release a specific CPU arch that did away with the backward compatibility for extra performance, they could.
 

Intel tried that with Itanium: IA64 was supposed to be the next step after x86 but most industry support for IA64 vanished shortly after AMD launched the x86-64 Athlon64 and forced Intel to release 64bits Prescott CPUs.
 


I was going to mention IA64, but there's more to that than MS and AMD's X86-64 push. The problem was HP as well, from what I recall. It was a "joint venture", so the fault is shared there among a lot of factors. I don't really feel like going there either XD

In regards to the buyout rumors and GPU BU house shake. I don't think any tech company in the world is better off buying AMD as it is now. All of the "pros" the big ones would have, go down the drain in lawyer fees trying to convince Intel to let them keep X86 and keep producing CPUs. Intel will just let AMD die, but won't try to kill it either. Moving a finger either way would cost them money and they don't need to do a thing to achieve that if things continue like this 😛

And the GPU Division shake, I take them as good news. GCN, being the jack of all trades, AMD has made it to be is a "good enough" approach. They can do better now and really get back in the game, since the other units "involvement in decisions" should be hampered from the division now. So, management wise, it should be something good for future AMD GPUs. Too bad we won't see any tangible results (if any) until 2018 or so. And this doesn't exclude the possibility (to my sadness) that they could spin off the whole BU.

Cheers!

PS: BU = Business Unit.
 
Businesses would not adopt a 64-bit only architecture like the IA64 because they have devoted 100's of millions or even into the billions of dollars over the of years for enterprise level software / proprietary software that would be incompatible with the new 64-bit only CPU.

Consumers will want backwards compatibly as well. I am pretty sure gamers would rebel against the idea of a CPU (and OS) that would be incompatible with their game library.

Microsoft would need to develop an OS for the 64-bit CPU along side Windows for x86-64 CPUs. That involves additional expenses that MS would not undertake if no one accepts the new 64-bit architecture.

 
AMD and its shared-core processors (Bulldozer architecture) was innovative for the time, and it was right on track in my opinion. But they were too radical and the software couldn't even use 4 cores at that time. Zen would greatly "improve" performance not only by improving IPC, but also due to the fact that more and more software can use multi-core setups.

Don't forget that when Bulldozer came out, its critic wasn't for its poor performance in CPU computing, it was mainly in games. Rendering done on the Piledriver was faster than on the Intel i7.

Furthermore, as OpenCL and other GPU based (parallel) computing develops, Multi-core usage will increase and more and more cores in a CPU would greatly help the GPU in processing information.
 

Microsoft did produce Windows XP, Server 2003 and Server 2008 for IA64. They also produced Windows Mobile versions for MIPS and ARM. Microsoft is no stranger to porting Windows to different architectures.

If AMD had not sprung x86-64 just when it looked like IA64 was about to make a market breakthrough, x86 might have ended ~10 years ago.
 
Like jaguarskx said, people aren't happy when 'new and improved' renders older software useless. If it's businesses, they work day in and day out with something they're familiar with and so long as it does what they need there's no reason to reinvent the wheel. Not at the cost of expense and training and upgrades. Businesses work on a profit margin and when you up their cost of business you cut into that profit margin = unhappy companies.

Take for instance an auto company, whether a dealer or repair shop. They don't need all the new bells and whistles, the actual hardware demands are pretty low. Most of what they deal with is data, either technical data/charts or customer info and barely need more than a dos based system. If you go requiring a hardware upgrade or software migration to something that costs them a significant amount and they ask 'why do I need this, how will it improve what I currently have?' the answer needs to be something more than 'well technology is evolving - essentially you need to pay xyz to do the exact same tasks you're already doing'. They don't care how bits of code are processed or some fancy new architecture is 'technically' superior to what exists. If it doesn't make their day to day operations faster or more efficient and yet costs them money (potentially a LOT of money) it's a losing scenario. Not everyone works with the latest 3d animation or cad software or has a need for bleeding edge.

In terms of games, I've already encountered the issue personally. One of my favorite games is a bit older, the original far cry. Worked great on xp, on win7 64bit not so much. There are patches that help some but initially it wouldn't even install (compatibility mode didn't help) and still has glitches from time to time. It's not a steam based game, you simply install locally and play it. Despite paying for it, 'progress' has nearly decided that it's useless and now I have to address the headaches of getting it to run. That's just a small example and for leisure, not critical software to the operation of a for profit business who doesn't want to be faced with the same. Advancement purely for the sake of advancement means little to a business's bottom line.
 

We have to admit that people don't like change in general. Why would you change the entire structure of how the CPU and the OS kernel works while you could just improve the x86?

By changing to IA64 you would need to make a specialized OS, then re-compile ALL the programs and libraries (dll) to make it work. People would just freaking start emulating x86 on the IA64 anyway, so it would be useless...
 


IBM will not buy AMD.

In the last 10 years, they shed off their, x86 server business to Lenovo, Printer business to Rioch and Lexmark, and chip manufacturing facilities to GlobalFoundries. IBM has turned into a service oriented business, and is getting away from consumer level hardware. However, they're still keeping their Power systems, Unix, zOS, and Mainframes, for enterprise level buisness.

Sorry to burst that bubble. But I think Microsoft or Apple might pick up AMD instead.
 


Yeah, I did not upgrade to Win 10 because I am in the middle of playing Fallout 3 which at this time is not compatible with Win 10. Besides, I still like using Win 7. I probably will not upgrade any of my machines (desktop, 2 laptops) until SP1 is released. The exception is my HTPC which is still running on Win XP.
 


IA64 included an X86 emulation layer that suffered about a 10% performance hit. That was what killed it in the consumer space, which is a shame, since IA64 would run circles around X86-64.
 

As I said earlier, the work for porting OSes to IA64 has already been done before - there are three versions of Windows available for it with a full blown suite of Microsoft server-side tools, so there is no point in harping about the recompile work - most of it had already been done before IA64 vanished. Changing the underlying architecture does not necessarily affect high-level APIs and most software would only require a trivial re-compile, so not much effort there. On the low-level/driver side, merely going from x86 to x86-64 already requires an almost complete rewrite due to the new driver model, so no effort saved there either by picking x86-64 over IA64.

If x86 had remained stuck on 32bits as was Intel's original plan to force things along, most newer software would have been compiled for IA64 and x86 emulation would only have mattered for legacy software. People depending on legacy software could still use x86-based PCs instead of upgrading to IA64 or use IA64's compatibility mode, no real problem there - those would be most of the same applications that are still running on XP or older OSes today with no plan to upgrade to newer OSes or machines.
 
Status
Not open for further replies.