Slashdot Mirror
AMD Designing All-New CPU Cores For ARMv8, X86
crookedvulture (1866146) writes "AMD just revealed that it has two all-new CPU cores in the works. One will be compatible with the 64-bit ARMv8 instruction set, while the other is meant as an x86 replacement for the Bulldozer architecture and its descendants. Both cores have been designed from the ground up by a team led by Jim Keller, the lead architect behind AMD's K8 architecture. Keller worked at Apple on the A4 and A4 before returning to AMD in 2012. The first chips based on the new AMD cores are due in 2016."
Probably worked on the A4 and A4 and the A4, as well.
I'm a good cook. I'm a fantastic eater. - Steven Brust
They were never fast; but they were pretty much the only game in town if you wanted x86 within tight thermal constraints, for a time after they launched. VIA was similarly tepid and a bit hotter and Intel was pretending that a "Pentium 4 Mobile" was something other than a contradiction in terms.
Now, once Intel stopped pretending that Netburst was something other than a failure, and put some actual effort into lower power designs, it was Game Over; but they didn't do that overnight.
The last time I truly got excited about AMD was when the K6-2 came out.
What? During the P4 days AMD was ahead in almost every category in the benchmarks... did you miss that whole era? No denying the picture today is far less exciting, though.
Is AMD just around so Intel doesn't get bogged down by anti-monopoly or antitrust penalties?
Except that when you do this, you have the opportunity to effectively turn a hardware interpreter into a software compiler, reducing control logic (and its constant switching during code execution) and improving efficiency in the same way in which software compilers are better than software interpreters, even if the gap won't be nearly that wide. You can turn the same hardware interpreter into a hardware compiler, but then you have something like a trace cache and the logic has actually increased. Would the SW solution decrease performance per thread? Quite likely. Would it improve performance per watt, which is what will really matter in the future? Well, what if it will?
Ezekiel 23:20
Actually, K7 - when Dirk Meyer's team left DEC to join AMD - was when they first made any technical challenge to Intel's CPUs. Until then, they were a series of one mediocre challenge after the other - first the Am386s & 486s, then the NexGen acquisition, then the K6. Finally, when AMD did the Athlon w/ the ex-Alpha team from DEC and extended CISC to 64-bit, that's when things started getting interesting.
How about the AMD386? It ran at 40Mhz. 40!
Transmeta was at the end of the era where decoding performance mattered. Keeping the translated code around was actually useful. These days decoding is approximately free on any CPU with half-decent performance -- the amount of extra die space for a complex decoder is not worth worrying about.
You can save a bit of power with a simpler decode stage, but you are unlikely to beat ARM Thumb-2 on power by software-translating x86 the way Transmeta did. Besides, most of the interesting code for low power applications is ARM or MIPS already, so what is the point?
Finally! A year of moderation! Ready for 2019?
I'm still waiting for an upgrade to my AMD FX-6300. I bought it on the promise that there would be an upgrade. I've liked AMD for a long time, but getting burned on the first processor I buy from them is no way to keep customers.
So you've been here longer than I have (UID), liked AMD for a long time yet never bought one in the golden years from 1999 (launch of Athlon) - 2006 (Intel launching Core) or relative competitiveness up to 2010 (with Phenom II x6 still giving Intel a fair fight) but waited until October 2012 when they were clearly well into a decline? Pardon me but your story smells worse than shrimps left out in the sun for a week.
Live today, because you never know what tomorrow brings
I was such an AMD fanboy ever since I built my first (new) computer with a K6-II. I have to admit I miss the days of the Athlon being called "The CPU that keeps Intel awake at night." After Bulldozer bombed so thoroughly I just gave up and haven't followed AMD's products since. I definitely wouldn't mind a comeback, if they can pull it off.
I had an AMD486 80Mhz. It was cheaper than an i486 66Mhz and performed great. The Pentium had just come out at the time but was super expensive. I was able to find late model 486 board with PCI slots though and with the awesome value of the AMD chip was able to have a nice "budget" system for the time. It was even able to run Quake playably(a game which "required" the Pentium and it's baller FPU).
You cannot meaningfully do reordering and so on in software on a modern CPU. You do not know in advance which operands will be available from memory at which time. You have to redo that work every time you get to the code (unless it is in a tight loop, but modern x86's are REALLY good at tight loops) because circumstances will likely have changed -- and you cannot reorder in software every time, that is just too costly.
If you want to see an architecture which looks like it has a chance of breaking the limits on single-threaded performance, look at the Mill. In theory you could software-translate x86 to Mill code and gain performance, but it would be really tricky and no Mill implementations exist yet.
Finally! A year of moderation! Ready for 2019?
But that was a part of the very concept of VLIW, which both Crusoe & Efficeon were. But those processors were somewhat more RISC than VLIW, except that their integer units were 128-bit and 256-bit, as opposed to 32-bit or 64-bit. Essentially, the idea here was that the bottom core would be constant, and any time there was an instruction set upgrade in a CPU from Intel or AMD, the Transmeta CPU would implement those new instructions in terms of their own native instructions, which would presumably either outperform them, or provide a better performance per watt.
In Itanium, Intel found that they didn't save much in real estate by tossing all the decoding to the compiler: in the Itanium3, some things like register renaming, which are a part of the compiler in VLIW, have found their way back into the hardware. I think that's what the GP meant by stating that decoding comes cheap.
When did they start labeling the CPUs with their operating temperature?
Ezekiel 23:20
Well, in the *desktops*, core marked an end to AMD dominance in most practical terms, but architecturally they still were not very good for scalability. Basically, they turned back the clock to pentium iii on modern processes and that was enough to recover the desktop space.
Nehalem is the point at which Intel basically overtook AMD again and AMD has not come back since that point. So Intel's had the ball for 3 of their 'tocks'. AMD prior to K7 was pretty weak for a lot longer than that and I don't think anyone familiar with AMD in K6 and older would guess they would be something more than a budget alternative. So AMD could conceivably come out of this with something awesome despite recent misfortune.
XML is like violence. If it doesn't solve the problem, use more.
Sounds useful, but for smaller cores. Having said that, the more you simplify the design the better for certain smarter methods. For example, it's my understanding that Chuck Moore optimizes his Forth cores to expand the envelope of operating conditions to such extent that AMD and Intel can't afford simply because their cores are too large to be understood. Too many state transitions to study, too many gates etc., whereas CM can afford to simply run a full physical model including individual transistor temperatures on a regular basis (and his stack machine is simple, so there's not as many states and state transitions to check for non-exceeding of operating limits exhaustively). That's one part why nothing seriously programmable I'm aware of can do more bit-ops per joule (as in bit-equivalent operations, as opposed to some fixed-width integers - since those chips have non-traditional widths, unless you really like PDP-1). At this level, it might be even worthwhile to try to generate instruction sets automatically hand in hand with HW synthesis and simulation and with automated compiler generation, if such thing is possible. I have this nagging idea that we're still guessing what ISAs designs are actually efficient, given that it's so damned hard to cycle a single ISA through the whole design and feedback process. This whole S/360, x86, SPARC, IA64 etc. situation feels like peeking into a few points in the total CPU design space and thinking that we're smarter and know where to look based on those few data points. Except we may be completely wrong on that.
Ezekiel 23:20
You should have tried OS/2 with the 486DX. The SX laptop would have been slow with anything but DOS; no local bus and a glacial hard disk is killer. I had OS/2 on a 486DX-40 with 8 MB RAM and it was great.
Gamingmuseum.com: Give your 3D accelerator a rest.
Do I really need to know that, or can I just switch to a different thread of execution until then?
Sun tried it, market penetration near zero. You can get 12 threads per socket on a desktop Intel CPU, good luck keeping 12 threads busy on mainstream workloads.
Single threaded performance is everything for a CPU; it is cheap to add sockets and cores for parallel workloads. For real parallel work you use the GPU anyway.
Finally! A year of moderation! Ready for 2019?
Consoles are using AMD because the parts are cheap, not because the performance/watt is fantastic. AMD hasn't been able to produce a CPU with amazing performance, decent thermals, and high power efficiency for years now. Why do you think gaming PCs and nearly all laptops use Intel? Because Intel offers all three with ease.
The Amarri pray for god, the Caldari pray for profit. the Gallente pray for peace, but the Minmatar pray their ships hol
> And do we really need to care about single-threaded performance that much these days?
Not every task is parallelizable.
Second, are you going to pay for an engineer to make their code multi-threaded that shows X% run-time performance?
On the bright side, you would no longer need a heater for that room in winter. Just run Folding@Home.
I still think Intel's business agreements in the mid 2000s that put AMD in its current position were immoral if not illegal, so I buy AMD anyway. But I don't buy because the product is better, I buy because the competition were assholes even though they're currently assholes with better products.
Not to mention that on most 'desktop' or 'server' machines, the OS is constantly juggling hundreds or thousands of processes, so while an individual program may be single threaded, the operating system can be spread across all available processes. The hard thing is knowing, for an individual process and core, when it is worth switching context - shunting it off to wait for I/O and shoveling a different process onto that core - or just idling that core for a while. IIRC (from _long_ ago), I/O typically costs 1000 or so CPU cycles, so it's an important judgement.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
But unixisc, that's a solved problem. We don't write software in Assembly Languages anymore.
See, we can simply compile the program on the chip we want to use it on.
The problem is that humans are stupid. Languages at the Human interface level should never compile down into machine code. All languages should compile down into bytecode. You should NEVER distribute programs as binaries (that would be dumb). Then the hardware abstraction layer (your OS) can compile the bytecode INTO OPTIMIZED machine code for the hardware.
Why is this so hard for you apes to understand? If you distribute your compiled programs as bytecode then languages can compile into a common bytecode, and OSs can compile bytecode for any chipset. The OS can cache the native code at program install to prevent VM overhead per use. That way it doesn't matter what language or hardware you want to install a program on. You can have a trillion languages and HW platforms without any interoperability issues. That was what Turing was Trying to teach you: How to use a universal virtual machine. Why do you refuse to use technology?! It's like you refuse to do anything the easy way unless you personally thought of it yourselves.
Why don't you ever take a fucking step back, look at the big picture and THINK? I hate this planet. I really do.
On a performance per $ metric, AMD are arguably still competitive, at the expense of selling cheaply and barely breaking even financially. They are currently not competitive in performance per watt and absolute performance (both on the desktop, mobile looks a bit better).
AMD really fucked up with the Bulldozer, and while there have been modest improvements to that with Vishera and Steamroller, they were insufficient to close the gap to Intel.
C - the footgun of programming languages