AMD Designing All-New CPU Cores For ARMv8, X86

← Back to Stories (view on slashdot.org)

AMD Designing All-New CPU Cores For ARMv8, X86

Posted by samzenpus on Monday May 5, 2014 @07:24AM from the brand-new dept.

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."

181 comments

Min score:

Reason:

Sort:

Keller worked at Apple on the A4 and A4 by nitehawk214 · 2014-05-05 07:27 · Score: 5, Funny

Probably worked on the A4 and A4 and the A4, as well.

--
I'm a good cook. I'm a fantastic eater. - Steven Brust
1. Re:Keller worked at Apple on the A4 and A4 by unixisc · 2014-05-05 07:32 · Score: 1
  
  You forgot to mention the A4
2. Re:Keller worked at Apple on the A4 and A4 by Megane · 2014-05-05 07:32 · Score: 1
  
  But did he work on the A4?
  
  --
  #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
3. Re:Keller worked at Apple on the A4 and A4 by jonyen · 2014-05-05 07:33 · Score: 1
  
  Unless it's owned by Apple, probably not.
4. Re:Keller worked at Apple on the A4 and A4 by Desler · 2014-05-05 07:33 · Score: 2
  
  Are you sure? I heard he worked on the A4 not the A4.
5. Re:Keller worked at Apple on the A4 and A4 by ttyX · 2014-05-05 07:42 · Score: 1
  
  So the way I understand it, up until now all processors he has worked on were named A4 and for the first time he's working on a CPU which ins't named A4?
6. Re:Keller worked at Apple on the A4 and A4 by tbuddy · 2014-05-05 07:48 · Score: 1
  
  Pretty sure Apple needs to log a sueball at these guys.
7. Re:Keller worked at Apple on the A4 and A4 by flyingfsck · 2014-05-05 07:55 · Score: 5, Funny
  
  No, no, that is obviously a typo. T'was the A4, Letter and Legal.
  
  --
  Excuse me, but please get off my Pennisetum Clandestinum, eh!
8. Re:Keller worked at Apple on the A4 and A4 by K.+S.+Kyosuke · 2014-05-05 07:56 · Score: 1
  
  Keller worked at Apple on the A4 and A4
  Either they meant that it was a dual-core CPU, or that Apple was churning them out like M&M's.
  
  --
  Ezekiel 23:20
9. Re:Keller worked at Apple on the A4 and A4 by GodfatherofSoul · 2014-05-05 07:56 · Score: 4, Informative
  
  You mean the A4 on the A4 on the A4?
  
  --
  I swear to God...I swear to God! That is NOT how you treat your human!
10. Re:Keller worked at Apple on the A4 and A4 by Anonymous Coward · 2014-05-05 07:56 · Score: 0
  
  Genius! Apple could sue itself for infringing on its own trademark, both win & lose (without admitting any wrongdoing of course) and keep itself in the headlines for weeks.
11. Re:Keller worked at Apple on the A4 and A4 by bill_mcgonigle · 2014-05-05 08:07 · Score: 1
  
  Either they meant that it was a dual-core CPU
  Somebody has been spending too much time staring at /proc/cpuinfo !
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
12. Re:Keller worked at Apple on the A4 and A4 by bill_mcgonigle · 2014-05-05 08:11 · Score: 1
  
  I heard he worked on the A4 not the A4.
  Classic Apple disinfo machine. :)
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
13. Re:Keller worked at Apple on the A4 and A4 by jfdavis668 · 2014-05-05 08:18 · Score: 1
  
  and, of course "Imagine a Beowulf Cluster of these!"
14. Re:Keller worked at Apple on the A4 and A4 by nigelo · 2014-05-05 08:37 · Score: 1
  
  Ah! The M4? It's close to the A4: http://en.wikipedia.org/wiki/M...
  
  --
  *Still* negative function...
15. Re:Keller worked at Apple on the A4 and A4 by Anonymous Coward · 2014-05-05 12:02 · Score: 0
  
  don't be a dick. It was a dual-core chip.
16. Re:Keller worked at Apple on the A4 and A4 by Anonymous Coward · 2014-05-05 13:40 · Score: 0
  
  As was clearly documented on A4.
17. Re:Keller worked at Apple on the A4 and A4 by nitehawk214 · 2014-05-05 15:21 · Score: 4, Funny
  
  Ahh, you figured it out, the multiple A4s were referencing different things.
  So pick two of those.
  
  --
  I'm a good cook. I'm a fantastic eater. - Steven Brust
18. Re:Keller worked at Apple on the A4 and A4 by Anonymous Coward · 2014-05-05 18:18 · Score: 0
  
  No - probably this A4: http://acorn.chriswhy.co.uk/Computers/A4.html
  Well - at least then he knows somthing about RISC design hm?
19. Re:Keller worked at Apple on the A4 and A4 by Anonymous Coward · 2014-05-05 19:14 · Score: 0
  
  What do you mean?
20. Re:Keller worked at Apple on the A4 and A4 by Anonymous Coward · 2014-05-06 02:18 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
21. Re:Keller worked at Apple on the A4 and A4 by Anonymous Coward · 2014-05-06 03:18 · Score: 0
  
  here's to hoping for a finally competitive again x86 core, instead of the garbage cores that they's been coughing up since k8...
  ARM: yeah whatever, they'll need even more help than AMD on x86 to get a competitive ARM core... even after ARM got th GINORMOUS cortex boost from the guys in Austin...
Couldn't one core... by unixisc · 2014-05-05 07:34 · Score: 1

... be common, and use something like code morphing - which Transmeta used - to come up w/ a solution that would work w/ both x64 and ARM 64? Thereby avoiding inventory mix issues during production?
1. Re:Couldn't one core... by Anonymous Coward · 2014-05-05 07:38 · Score: 1
  
  Put simply, no.
  These things are so heavily optimised, you can't have that kind of thing getting in the way of making detailed performance tweaks.
2. Re:Couldn't one core... by LWATCDR · 2014-05-05 07:46 · Score: 1
  
  The Transmeta chip was not a smash hit so probably not.
  The really cool thing is that you will see ARM and X86 will share parts. GPU cores are a no brainer. Throwing in things like cache and memory controllers could be a big deal.
  ARM sharing a socket with x86 will be really cool IMHO.
  
  --
  See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
3. Re: Couldn't one core... by loufoque · 2014-05-05 07:53 · Score: 0
  
  Yes, because such complex heterogeneous hardware is so easy to program for.
4. Re:Couldn't one core... by K.+S.+Kyosuke · 2014-05-05 08:00 · Score: 2
  
  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
5. Re: Couldn't one core... by K.+S.+Kyosuke · 2014-05-05 08:16 · Score: 1
  
  How old is x86 now? It took a long time (ten years?) to get just a basic 32-bit protected mode operating system out to people at large after the hardware (80386) was out. I hope you're not expecting AMD to roll out a full-blown ecosystem of HW, drivers, compilers, and thousands of applications within a year just because you're impatient. I'm afraid the free lunch is over, but still, HSA is hardly a complexity monster. To me, it didn't seem nearly as threatening as a single look at the total size of x86+AMD64+extra instruction sets+documentation for OS developers+HW errata specs together. I suspect the only reason why you see it as "complex" is because you're closing your eyes when faced with the reality that we're already facing much more complex legacy HW. x86 has only the advantage that the tools are already here, but a heterogeneous system properly designed from scratch can't really be that much more complex than the "homoheterogenous" x86AMD64SSE1234AVX123 architecture that we have right now.
  
  --
  Ezekiel 23:20
6. Re: Couldn't one core... by aliquis · 2014-05-05 08:22 · Score: 1
  
  What? No support for MMX?
7. Re: Couldn't one core... by K.+S.+Kyosuke · 2014-05-05 08:37 · Score: 1
  
  I thought MMX was obsoleted, at least on AMD64 ABIs? Aren't you supposed to be using SSE because the ABI is throwing huge logs under your legs if you don't?
  
  --
  Ezekiel 23:20
8. Re: Couldn't one core... by unixisc · 2014-05-05 08:41 · Score: 1
  
  Wasn't SSE a superset of MMX?
9. Re: Couldn't one core... by loufoque · 2014-05-05 09:02 · Score: 1
  
  I don't see how SSE is anything like it. Either you have a SSE or AVX unit or you don't. If you do, you use it exclusively. With a hybrid x86+ARM+GPU chip, you need to give work to at least all 3 of them, and it's nearly impossible to predict which unit will be the best for each task or even to schedule the damn thing dynamically.
10. Re: Couldn't one core... by aliquis · 2014-05-05 09:41 · Score: 1
  
  I'm not sure. I figured that maybe it was / that there at least was better instructions around now and no need for it.
  Might still had worked for enlengthening (? Enlonging? Dictionary don't like either) the list.
11. Re:Couldn't one core... by farble1670 · 2014-05-05 09:43 · Score: 1
  
  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.
  ^^^^
  that
  doesn't support this,
  
  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?
12. Re: Couldn't one core... by K.+S.+Kyosuke · 2014-05-05 10:07 · Score: 1
  
  Functionality-wise, yes. Instruction-encoding-wise, I'm not sure but I don't think so. Nor does it use the same registers (SSE ones are physically separate from x87/MMX ones).
  
  --
  Ezekiel 23:20
13. Re: Couldn't one core... by Anonymous Coward · 2014-05-05 11:15 · Score: 0
  
  MMX was SIMD INT, and SSE was SIMD FLOAT.
  There were other differences as well, but that's it in a nutshell.
14. Re: Couldn't one core... by K.+S.+Kyosuke · 2014-05-05 12:07 · Score: 1
  
  SSE1 also included packed integer operations.
  
  --
  Ezekiel 23:20
15. Re: Couldn't one core... by savuporo · 2014-05-05 12:15 · Score: 1
  
  There are hardly any ARM CPUs or MCUs around that will ever get inserted in a socket. They are all mostly SMD chips.
  
  --
  http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
16. Re: Couldn't one core... by yuhong · 2014-05-05 15:17 · Score: 1
  
  It took a long time (ten years?) to get just a basic 32-bit protected mode operating system out to people at large after the hardware (80386) was out.
  Ah, this is exactly one of the reasons why the MS OS/2 2.0 fiasco is one of my favorite topics!
17. Re:Couldn't one core... by VortexCortex · 2014-05-05 15:52 · Score: 2
  
  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.
18. Re: Couldn't one core... by LWATCDR · 2014-05-06 00:38 · Score: 1
  
  AMD is targeting this at the server market. It is supposed to be socket compatible with the new X86 they working on. It is not strictly targeting the mobile market.
  
  --
  See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
19. Re: Couldn't one core... by RatherBeAnonymous · 2014-05-06 02:09 · Score: 1
  
  As I recall, the shared registers were a real problem with MMX. It meant that there was a big latency cost as the chip switched between superscalar and traditional operating modes. It made for penalty that frequently negated the MMX performance benefit.
20. Re:Couldn't one core... by Anonymous Coward · 2014-05-06 02:19 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
21. Re: Couldn't one core... by Anonymous Coward · 2014-05-06 02:24 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
22. Re: Couldn't one core... by K.+S.+Kyosuke · 2014-05-06 07:24 · Score: 1
  
  Either you have a SSE or AVX unit or you don't. If you do, you use it exclusively.
  
  That doesn't seem that much different from how a GPU-run kernel is used.
  
  With a hybrid x86+ARM+GPU chip, you need to give work to at least all 3 of them, and it's nearly impossible to predict which unit will be the best for each task or even to schedule the damn thing dynamically.
  You think they're going to make a x86+ARM chip? I thought they're going to make a x86+ARM+GCN architecture, with the option of configuring a x86+GCN SoC or an ARM+GCN SoC either at tape-out time or at packaging time (there are chips today that simply disable some units when they're being packaged, rather then not putting them onto silicon in the first place, due to costs arising from keeping two or more silicon lines). Anyway, when it comes to deciding what should be running where, we already have a precedent for this: Intel's and GCC's auto-vectorizers analyze the code and try to decide, using heuristic techniques, whether an attempt at vectorization into SSE or AVX is worth the effort. HSA makes the GPU cores so close to the CPU cores in terms of memory access latencies and execution latencies that very much the same process seems feasible for HSA hardware (as opposed to doing the same for CUDA or OpenCL code, which is more like pushing a card stack to the mainframe people to have it run overnight :-)). And I've seen quite a few AVX/SSE functions that were purely performance primitives without much in terms of scalar code (which GCN can run as well).
  
  --
  Ezekiel 23:20
23. Re: Couldn't one core... by Anonymous Coward · 2014-05-06 08:06 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
24. Re: Couldn't one core... by Anonymous Coward · 2014-05-07 04:12 · Score: 0
  
  Hey K. S. Kyosuke ya bigmouth: Yer bein called out (why're ya runnin "forrest"?) http://slashdot.org/comments.p...
25. Re: Couldn't one core... by Anonymous Coward · 2014-05-07 04:15 · Score: 0
  
  Hey K. S. Kyosuke ya bigmouth: Yer bein called out (why're ya runnin "forrest"?) http://slashdot.org/comments.p...
26. Re: Couldn't one core... by Anonymous Coward · 2014-05-07 04:19 · Score: 0
  
  Hey K. S. Kyosuke ya bigmouth: Yer bein called out (why're ya runnin "forrest"?) http://slashdot.org/comments.p...
27. Re:Couldn't one core... by metaforest · 2014-05-07 18:58 · Score: 1
  
  Funny you should mention that. Lots of mainframe families were doing that decades ago. APP-LOADER: "Oh! Hey! This is a new code module, I don't have a local copy of the binary I need for this. It appears to also include a generic machine code block for my family of processor cores. No cached binary for me, it was built on a different serial numbered machine.... hold on a sec while I post-compile-schedule the instructions to my local object language and re-link it..... There ya go! This will run like oiled snot on me now! Oh! And I have automagically replaced the old incompatible object-binary with the new binary I just built! Have a nice day!"
  I'd like nice toys like that on the desktop. Closest we get now from any vendor or OS zealot(s) is.... "Can I re-link this for you? It may run faster."
HSA by serviscope_minor · 2014-05-05 07:38 · Score: 1

Did it say anywhere if they're going to juiced with HSA?
nanosecond latency to some bigass stream processors and no risk of memory-scribbling is too much to not want.

--
SJW n. One who posts facts.
Right, because that worked so well by Sycraft-fu · 2014-05-05 07:43 · Score: 1

How's Transmeta doing these days? Oh that's right they are defunct.
That kind of thing doesn't work well for performance.
1. Re:Right, because that worked so well by fuzzyfuzzyfungus · 2014-05-05 07:52 · Score: 2
  
  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.
2. Re:Right, because that worked so well by K.+S.+Kyosuke · 2014-05-05 08:07 · Score: 1
  
  Intel has only shown you what's possible with a large number of advanced low-power transistors. That's still just one design (of the many possible ones) that uses this level of logic integration. Does that mean that it's impossible to do anything better with the same large number of advanced low-power transistors? Do you have any reason to believe that the Transmeta approach (that actually worked better back then) wouldn't work better now for some reason?
  
  --
  Ezekiel 23:20
3. Re:Right, because that worked so well by amorsen · 2014-05-05 08:22 · Score: 5, Interesting
  
  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?
4. Re:Right, because that worked so well by K.+S.+Kyosuke · 2014-05-05 08:35 · Score: 1
  
  These days decoding is approximately free on any CPU with half-decent performance
  In what way? And what do you mean by "decoding"? Do you also include dependency solving, interlocking, reordering etc.? Because what I was thinking about was pushing even more to the SW component. The problem is, CPUs have been widening for quite some time because of our over-reliance on single-threaded SW. But even if it doesn't work nearly as well for eight-issue monsters, given that simple cores like Jaguar, which seem to be practicable if you have many more of them, push you back into the time of "quarter-decent" performance, why couldn't this approach be useful once more? (Sorry for playing a contrarian here, but I'm genuinely puzzled about this.)
  
  --
  Ezekiel 23:20
5. Re:Right, because that worked so well by amorsen · 2014-05-05 08:49 · Score: 4, Interesting
  
  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?
6. Re:Right, because that worked so well by unixisc · 2014-05-05 08:49 · Score: 2
  
  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.
7. Re:Right, because that worked so well by K.+S.+Kyosuke · 2014-05-05 09:03 · Score: 1
  
  I guess you're right on the reorderings, there are unpredictable aspects to the execution trace. But then again, there's the engineering maxim that every extra component has to justify its value to be included in a system. Surely these circuits made sense when Pentium III was competing with P4 was competing with K7. Whether their usefulness is undiminished in low-power parallel systems seems like the question to me, though. There appears to be a law of diminishing returns for everything.
  
  --
  Ezekiel 23:20
8. Re:Right, because that worked so well by Carewolf · 2014-05-05 09:24 · Score: 1
  
  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.
  Actually Intel has recently returned to that. They now keep a small microinstruction cache of decoded instructions around so that loops can be executed more efficiently.
9. Re:Right, because that worked so well by K.+S.+Kyosuke · 2014-05-05 09:42 · Score: 1
  
  Also, I forgot one thing...
  
  You do not know in advance which operands will be available from memory at which time. ... If you want to see an architecture which looks like it has a chance of breaking the limits on single-threaded performance
  Do I really need to know that, or can I just switch to a different thread of execution until then? And do we really need to care about single-threaded performance that much these days? What if I want to program in Go instead of C++? (E.g., what if Google wants 0.5M of new servers for deploying of Go services?) Perhaps some level of "outoforderiness" is desirable, but a lower one would do? I really don't care in what way the performance gets squeezed into my battery-powered devices, and neither do most people who are buying the stuff, as long as it does.
  
  --
  Ezekiel 23:20
10. Re:Right, because that worked so well by amorsen · 2014-05-05 10:21 · Score: 1
  
  Fair enough, but they still choose to have all decoding done in hardware, so they still pay the (rather small) die-space penalty of a complex decoder.
  
  --
  Finally! A year of moderation! Ready for 2019?
11. Re:Right, because that worked so well by amorsen · 2014-05-05 10:30 · Score: 2
  
  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?
12. Re:Right, because that worked so well by UnknownSoldier · 2014-05-05 10:43 · Score: 3, Insightful
  
  > 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?
13. Re:Right, because that worked so well by K.+S.+Kyosuke · 2014-05-05 11:27 · Score: 1
  
  Sun tried it, market penetration near zero.
  That just might have something to do with the ridiculous price they were asking for it, doesn't it?
  
  You can get 12 threads per socket on a desktop Intel CPU, good luck keeping 12 threads busy on mainstream workloads.
  Doesn't seem like that much of an issue to me. I can't think of an application where they wouldn't come in very handy. And I really tried, but nothing came out of it.
  
  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.
  Well, that's good for certain kinds of data parallelism, but probably not for all of them. At least, right now, even though AMD is trying to stretch its usefulness as much as they can.
  
  --
  Ezekiel 23:20
14. Re:Right, because that worked so well by K.+S.+Kyosuke · 2014-05-05 11:32 · Score: 1
  
  Not every task is parallelizable.
  That's a red herring. Many more tasks probably are than most people would think. See Guy Steele's work. I think I even came up with a scheme to run TeX passes using speculative execution (results always correct, and most of the times faster) the other day (the state to keep around fortunately isn't very large).
  
  --
  Ezekiel 23:20
15. Re:Right, because that worked so well by garyebickford · 2014-05-05 14:28 · Score: 2
  
  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/
16. Re:Right, because that worked so well by garyebickford · 2014-05-05 14:30 · Score: 1
  
  Ahh, the good old days. This reminded me of the Motorola 6800's Halt and Catch Fire instruction. :D Tight loops can be ... interesting.
  
  --
  It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
17. Re:Right, because that worked so well by Anonymous Coward · 2014-05-05 20:53 · Score: 0
  
  In area, it's small. But it has quite some latency and the power dissipation density is probably quite high.
  I don't know abou Intel, but one AMD instruction decoder actually had 16 instruction decoders starting on every byte boundary in a 16 byte block and then threw away most of the results to give at most 3 instuctions. This implies a distribution of the instruction stream with a large fanout, which either reduces achievable clock frequency or implies a pipeline stage to provide the fanout.
  And Intel secondary caches are not that small, they are almost the same area as the primary instruction cache, the encoding density is lower: a single x86 cache line can be distributed to up to 3 decoded cache lines. This secondary cache also needs coherency and LRU logic.
  Nothing of this is free, out of the 3 parameters (area, latency, power dissipation), area is probably the less troublesome.
18. Re:Right, because that worked so well by Anonymous Coward · 2014-05-06 02:07 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
19. Re:Right, because that worked so well by Anonymous Coward · 2014-05-06 02:12 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
20. Re:Right, because that worked so well by Anonymous Coward · 2014-05-06 02:21 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
21. Re:Right, because that worked so well by Anonymous Coward · 2014-05-06 02:30 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
22. Re:Right, because that worked so well by Anonymous Coward · 2014-05-07 04:14 · Score: 0
  
  Hey K. S. Kyosuke ya bigmouth: Yer bein called out (why're ya runnin "forrest"?) http://slashdot.org/comments.p...
23. Re:Right, because that worked so well by Anonymous Coward · 2014-05-07 04:21 · Score: 0
  
  Hey K. S. Kyosuke ya bigmouth: Yer bein called out (why're ya runnin "forrest"?) http://slashdot.org/comments.p...
24. Re:Right, because that worked so well by metaforest · 2014-05-07 18:35 · Score: 1
  
  6502 didn't have a HCF instruction but it did have a key 6800 feature that later RISC machines lack. Almost all operations have an implied target. The A register, or in the 6800 the A/B register. The Mill seems to be making a better use of the implied target concept by putting all resultants on The Belt, thus reducing the classic register juggling that happens in complex code threads on all RISC machines. I think that this architecture has some legs. I hope they get some silicon taped out, and get LLVM hammered into shape to deal with a machine that doesn't expcicitly have globally named registers, or state for that matter.
25. Re:Right, because that worked so well by Anonymous Coward · 2014-05-08 05:39 · Score: 0
  
  K. S. Kyosuke: You've been called out (for tossing names) & you ran "forrest" from a fair challenge http://slashdot.org/comments.p...
Been a long time since I cared by asmkm22 · 2014-05-05 07:44 · Score: 1

The last time I truly got excited about AMD was when the K6-2 came out. These days, I just wish AMD would put a focus on power consumption and high quality rather than simply trying to out-core Intel.
1. Re:Been a long time since I cared by werepants · 2014-05-05 07:55 · Score: 5, Insightful
  
  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.
2. Re:Been a long time since I cared by unixisc · 2014-05-05 08:11 · Score: 2
  
  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.
3. Re:Been a long time since I cared by Jaime2 · 2014-05-05 08:12 · Score: 1
  
  But that's only because Intel let the marketing department make engineering decisions and kept making chips with higher and higher clock frequency. As soon as they regained their sanity, they once again dominated the benchmarks.
  I do love how AMD brilliantly capitalized on the blunder. By labeling their chips according to the clock speed of the performance equivalent Intel chip - every time Intel put insane engineering effort into ratcheting the clock up 10% and only getting 1% better performance, AMD simply made their chips a tiny bit faster and labelled theirs the same as Intel's.
4. Re:Been a long time since I cared by aliquis · 2014-05-05 08:18 · Score: 1
  
  K6-2 was so-so.
  Athlon XP and Athlon64 was good in their time.
  Since the days of Pentium-M though ..
5. Re:Been a long time since I cared by jfdavis668 · 2014-05-05 08:20 · Score: 2
  
  How about the AMD386? It ran at 40Mhz. 40!
6. Re:Been a long time since I cared by afidel · 2014-05-05 08:21 · Score: 1
  
  Yup, on the server side AMD was ahead from the first Opteron until Shanghai, and then Intel launch Nehalem and they've been ahead ever since. One the desktop Intel got competitive again with the Core2 but on a performance per $ metric it wasn't until Nehalem that they dominated.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
7. Re:Been a long time since I cared by Anonymous Coward · 2014-05-05 08:31 · Score: 0
  
  That bitch had cache memory too. Internal cache memory on a 386!
8. Re:Been a long time since I cared by DudemanX · 2014-05-05 08:44 · Score: 2
  
  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).
9. Re:Been a long time since I cared by angel'o'sphere · 2014-05-05 09:17 · Score: 0
  
  I ran quake on an 486 DX(2?) 33Mhz just fine.
  More frames per second than the monitor could handle.
  
  --
  Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
10. Re:Been a long time since I cared by werepants · 2014-05-05 09:20 · Score: 1
  
  My personal favorite was the Athlon XP 1700+. The best was date code JIUHB DLT3C, it had documented cases of getting above 4GHz - pretty good considering that it is still a feat to hit that 10 years later. Bought two or three 1700+'s on ebay before I hit the jackpot. Unfortunately, I never managed to put together the water cooling system I had planned, so I never got it over 3 GHz.
11. Re:Been a long time since I cared by Anonymous Coward · 2014-05-05 09:37 · Score: 0
  
  And then there's those of us who actually use all those silly cores:
  Tasks: 226 total, 2 running, 224 sleeping, 0 stopped, 0 zombie
  %Cpu0 : 30.3 us, 1.0 sy, 61.3 ni, 7.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  %Cpu1 : 32.3 us, 1.3 sy, 58.4 ni, 7.6 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
  %Cpu2 : 34.7 us, 1.7 sy, 56.3 ni, 7.0 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
  %Cpu3 : 30.9 us, 1.7 sy, 59.5 ni, 8.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  %Cpu4 : 11.7 us, 0.3 sy, 85.0 ni, 3.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  %Cpu5 : 43.9 us, 1.3 sy, 46.2 ni, 8.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  KiB Mem: 16432068 total, 16098748 used, 333320 free, 6420824 buffers
  KiB Swap: 999420 total, 13260 used, 986160 free. 6430540 cached Mem
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  20367 blah 20 0 4454228 1.545g 37792 S 544.9 9.9 3350:48 ghb ...
12. Re:Been a long time since I cared by Anonymous Coward · 2014-05-05 10:50 · Score: 0
  
  AMD was great from the 386 era, through Pentium IV. They owned low cost CPU's (often by continuing older product lines at higher clock speeds than Intel bothered with), performance per $$$, and often outright performance as well. They were also more aggresive in moving functionality (such as the memory controller) into the CPU. Unfortunately, with the notable exception of the Pentium IV era, they were never competitive with Intel on performance per watt. This deficiency was exacerbated when Intel went to town on power per watt and got more aggressive on pricing, starting with the Pentium M and Core architecture. All that coincided with an market shift to mobile platforms, which worked in Intel's favor. Intel plowed their profits into R&D, widening their power per watt advantage over AMD, and ultimately eclipsing them in performance.
  Last time I needed to rebuild and upgrade my rig (which was a couple years ago, at this point) I was ready to go AMD again, as I always had previously, but reading the benchmarks found that a Sandy Bridge Core i3 was sufficient to outrun the entirety of AMD's product line. And my budget allowed a Core i5... That said, since they bought ATI, AMD has owned the "graphics core in the CPU" title. A hypothetical AMD APU, with x86 AND ARM cores sharing the on-board Radeon GPU would be an intriguing concept.
13. Re:Been a long time since I cared by Anonymous Coward · 2014-05-05 12:08 · Score: 0
  
  That fastest P4 ALWAYS beat antthing amd offered.
14. Re:Been a long time since I cared by asmkm22 · 2014-05-05 12:16 · Score: 1
  
  I didn't say the K6-2 was the peak of AMD; just that it was the last time I really got excited about anything they came out with. AMD did some good stuff during the mid-2000's, but there were other computer upgrades that had more impact on performance -- particularly RAM. Those were the days when adding a stick of RAM was a legitimate means of being able to do amazing things like browse the internet while listening to music... at the same time!. Upgrading from 512 to 2GB was a huge boost in productivity. The CPU's during that time may as well have been soldered on to the motherboard for most people, because you didn't generally upgrade them unless you also needed to upgrade the MB (for better RAM probably).
  The K6-2 era was different, because at that point, the CPU was still a huge bottleneck for things like game performance. Having CPU features like MMX and 3DNOW! was a pretty big deal, and there was a lot of good competition between the two companies.
15. Re:Been a long time since I cared by Anonymous Coward · 2014-05-05 12:38 · Score: 0
  
  I remember from building a computer around 2002, that I really wanted to get an AMD, but the benchmarks weren't that great compared to the P4. Of course you could save a little money, and possibly get more bang for your buck. But the cost difference wasn't that big, and I wanted to actually be fast instead of just efficient or a "good deal." It seemed like AMD was putting all of its money on the Athlon 64, but that didn't help those that didn't want to wait another year for new computer.
16. Re:Been a long time since I cared by Carewolf · 2014-05-05 21:24 · Score: 1
  
  That fastest P4 ALWAYS beat antthing amd offered.
  Certainly in power consumption and temperature :D Though it trailed far behind in performance.
17. Re:Been a long time since I cared by Lonewolf666 · 2014-05-05 21:39 · Score: 2
  
  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
18. Re:Been a long time since I cared by Warma · 2014-05-05 22:11 · Score: 1
  
  I have a really hard time believing this, and would state that your memory does not serve you very well. A 33MHz 486 couldn't handle more complex scenes in DOOM, and definitely not in Quake. I gamed actively at the time when Quake came out, and recall that only much later, on a P233MMX, I could get an fps amount rivaling the screen refresh rate. Any 486 is so much behind that machine, that it's not even funny.
  A low ID number username like you probably won't believe a brat like me, so here's some proof: https://www.youtube.com/watch?...
  The fps is abysmal. The machine would need to be 10-20 times faster to reach a decent fps.
19. Re:Been a long time since I cared by goose-incarnated · 2014-05-05 23:45 · Score: 1
  
  I have a really hard time believing this, and would state that your memory does not serve you very well. A 33MHz 486 couldn't handle more complex scenes in DOOM, and definitely not in Quake. I gamed actively at the time when Quake came out, and recall that only much later, on a P233MMX, I could get an fps amount rivaling the screen refresh rate. Any 486 is so much behind that machine, that it's not even funny.
  A low ID number username like you probably won't believe a brat like me, so here's some proof: https://www.youtube.com/watch?...
  The fps is abysmal. The machine would need to be 10-20 times faster to reach a decent fps.
  Nevermind what some random youtube link says, I ran quake reliably on a 486 dx4 100 (33x3 IIRC) with a 1MB trident graphics card and 8MB of RAM.
  
  --
  I'm a minority race. Save your vitriol for white people.
20. Re:Been a long time since I cared by vampyretech · 2014-05-06 01:28 · Score: 1
  
  Seconded. I ran it on a 486 DX-2 66 with a 1MB Cirrus Logic VLB card. I had to run scitech display doctor to get decent framerates at 800x600, but it worked.
21. Re:Been a long time since I cared by Xest · 2014-05-06 01:41 · Score: 1
  
  "During the P4 days AMD was ahead in almost every category in the benchmarks"
  It was ahead in many categories off the benchmarks too.
  Like how quickly it heats your room up, and how much power it drained.
  I had one but my god in the summer months did I wish I'd gone Intel as I was sat sweltering from the heat of that computer on top of the already high ambient temperature.
22. Re:Been a long time since I cared by RatherBeAnonymous · 2014-05-06 02:16 · Score: 1
  
  K6-2 was good, but the K6-III was much better. It was the first consumer-level CPU with on-die L2 cache. It scared Intel enough that they renamed the PII to PIII (because anything with a 3 in the name is clearly better than anything with a 2 in the name). The down side was that the K6-III overclocked for shit.
23. Re:Been a long time since I cared by RatherBeAnonymous · 2014-05-06 02:19 · Score: 1
  
  I had an AMD 486 DX4 - 120 MHz. It beat the pants off the contemporary Pentium processors.
24. Re:Been a long time since I cared by werepants · 2014-05-06 05:00 · Score: 1
  
  Fair enough. I really enjoyed the early Athlon days, personally. The first computers over 1GHz blew my mind. A K6-II was in the first machine I ever built (or owned). Scraped together pennies to build it, started with a scavenged 528 MB drive that was just barely enough to fit Windows 98 and Starcraft. Good stuff.
25. Re:Been a long time since I cared by angel'o'sphere · 2014-05-06 05:18 · Score: 1
  
  Well,
  it was an EISA PC with a expensive graphics card.
  However I got DX 3 with 100MHz later and one of those famous GForce cards (famous at that time) perhaps I mix the two machienes up.
  FPS was decent, but loading the game or the level TOOK FOR EVER!
  
  --
  Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
26. Re:Been a long time since I cared by Anonymous Coward · 2014-05-06 05:37 · Score: 0
  
  t-bred b's were amazing chips for the time.
Steamroller/Excavator ??? by jbo5112 · 2014-05-05 07:47 · Score: 1

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.
1. Re:Steamroller/Excavator ??? by Kjella · 2014-05-05 08:24 · Score: 2
  
  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
2. Re:Steamroller/Excavator ??? by afidel · 2014-05-05 08:25 · Score: 1
  
  There's an upgrade, FX-9590.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
3. Re:Steamroller/Excavator ??? by K.+S.+Kyosuke · 2014-05-05 09:09 · Score: 3, Funny
  
  When did they start labeling the CPUs with their operating temperature?
  
  --
  Ezekiel 23:20
4. Re:Steamroller/Excavator ??? by jbo5112 · 2014-05-05 09:51 · Score: 1
  
  I didn't have money for a computer upgrade in 2001-2006 (thank you Clinton/Federal Govt. for the Dot-com bubble that burst when I was leaving college). I went from a dual Celeron system (ABIT BP6 motherboard) in mid-1999 to an Athlon-XP that someone gave me in 2004 to a Core 2 Quad Q6600 in 2007. When my motherboard died, I needed something cheap for keeping a lot of programs (including a virtual machine or two) running. I knew 6 slower cores would probably work better for me than 2 faster cores, even if they were hyperthreaded, and the motherboard had better features than Intel (more IO and a planned CPU upgrade).
5. Re:Steamroller/Excavator ??? by jbo5112 · 2014-05-05 10:23 · Score: 1
  
  My motherboard is limited to 140W CPU's. The FX-9590 would require me to buy both a new motherboard and power supply. For that much money, I could get both Core i3-4340 and Core i7-4770K CPU/motherboard combos to upgrade 2 computers or go with a i7-4820K (LGA-2011) in my workstation. Way to deliver AMD!
6. Re:Steamroller/Excavator ??? by Anonymous Coward · 2014-05-05 13:07 · Score: 0
  
  It is a Nobel worth accomplishment to get a chip working reliably while being hotter that the surface of the sun. I mean the chip.
7. Re:Steamroller/Excavator ??? by DuckDodgers · 2014-05-05 13:42 · Score: 3, Insightful
  
  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.
8. Re:Steamroller/Excavator ??? by Anonymous Coward · 2014-05-06 02:15 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
Serious Question by Anonymous Coward · 2014-05-05 07:57 · Score: 4, Interesting

Is AMD just around so Intel doesn't get bogged down by anti-monopoly or antitrust penalties?
1. Re: Serious Question by Anonymous Coward · 2014-05-05 08:05 · Score: 4, Interesting
  
  64 cores per U, 80% intel performance per core, at 12% intel price.
2. Re: Serious Question by Anonymous Coward · 2014-05-05 08:13 · Score: 0
  
  Also 10% and 15% Intel's revenues and stock price respectively.
3. Re: Serious Question by Anonymous Coward · 2014-05-05 08:42 · Score: 0
  
  100% bullshit
4. Re: Serious Question by Junta · 2014-05-05 09:05 · Score: 4, Insightful
  
  Well, something of an oversimplification/exaggeration.
  64 'cores' is 32 piledriver modules. That was a gamble that by and large did not pan out as hoped. For a lot of applications, you must consider those 32 cores. Intel is currently at 12 cores per package versus AMD's 8 per package. Intel is less frequently found with their EP line in a 4 socket configuration because the performance of dual socket can be much higher with Intel's QPI than 4 socket. AMD can't do that topology, so you might as well do 4 socket. Additionally, the memory architecture of Intel tends to cause more dimm slots to be put on a board. AMD's thermals are actually a bit worse than Intel's, so it's not that AMD can be reasonably crammed in but Intel cannot. The pricing disparity is something that Intel chooses at their discretion (their margin is obscene), so if Intel ever gets pressure, they could halve their margin and still be healthy margin-wise.
  I'm hoping this lives up to the legacy of the K7 architecture. K7 architecture left Intel horribly embarrassed and took years to finally catch up with when they launched Nehalem. Bulldozer was a decent experiment and software tooling has improved utilization, but it's still rough. With Intel ahead in both microarchitecture and manufacturing process, AMD is currently left with 'budget' pricing out of desperation as their strategy. This is by no means something to dismiss, but it's certainly less exciting and perhaps not sustainable since their costs are in fact higher than Intel's cost (though Intel's R&D budget is gigantic to fuel that low-cost per-unit advantage, so the difference between gross margin between Intel and AMD is huge, but net margin isn't as drastic). If the bulldozer scheme had worked out well, it could have meant another era of AMD dominance, but it sadly didn't work as well in practice.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
5. Re:Serious Question by Anonymous Coward · 2014-05-05 09:46 · Score: 0
  
  And to power the latest generation of consoles.
  All of them.
  Every
  Single.
  One.
  And none of your wintel fanboi tears will change it.
6. Re:Serious Question by tlhIngan · 2014-05-05 09:56 · Score: 1
  
  Is AMD just around so Intel doesn't get bogged down by anti-monopoly or antitrust penalties?
  Somehow these days, I think it's yes. And I think Intel's lobbing customers AMD's way to ensure that AMD survives. E.g., the current generation of consoles now sport AMD processors. I'm sure Intel would be more than happy to have the business, but not only do they not need it, they see it as a way to give AMD much needed cash for the next few years.
  Hell, I'm sure part of the whole Intel letting others use their fabs thing is to figure out a way to get AMD to use some of their spare capacity. Of course, it has to be done in such a way that it doesn't run afoul of any anti-trust and all that.
  Right now, AMD is in a good spot for Intel - big enough to count as competition, small enough to not really matter..
  You can bet many other companies pay lots of money for a competitor to stay in it - I can think of Google and iAds, for example. Google got AdMob because Apple introduced iAds, yet iAds is completely worthless to any advertiser - it's too expensive, too limited, and all around a bad dead, whereas Google is cheap and easy. And yet, Apple keeps iAds around , despite practically no one supporting it. Apple's killed other stuff for less. Only reason I can see is Google pays Apple for that to keep anti-trust at bay.
7. Re:Serious Question by Kjella · 2014-05-05 11:22 · Score: 2
  
  Somehow these days, I think it's yes. And I think Intel's lobbing customers AMD's way to ensure that AMD survives. E.g., the current generation of consoles now sport AMD processors. I'm sure Intel would be more than happy to have the business, but not only do they not need it, they see it as a way to give AMD much needed cash for the next few years.
  Consoles are primarily about graphics, not CPU power. While Intel's integrated graphics suck somewhat less than they used to, the PS4 has 1152 shaders backed by 8GB DDR5 and Intel has never had anything remotely close to that, maybe a third or quarter of that tops. An Intel CPU with AMD dedicated graphics would be very unlikely since AMD would almost certainly price it so their CPU/GPU combo came out better. So realistically it was AMD vs Intel+nVidia, neither of which like to sell themselves cheap. I don't think you need any market collusion to see AMD winning this one, while it's floating the boat they're not exactly making big money so they probably sold themselves rather cheap.
  
  --
  Live today, because you never know what tomorrow brings
8. Re: Serious Question by Anonymous Coward · 2014-05-05 11:43 · Score: 0
  
  Lies: a pair of Xeon E5-2630 is faster than a pair of Opteron 6272 by 20% or so (its 6 cores are faster than AMD's 16!) or so but it's also 20% cheaper. The Opteron also uses more power (115W vs 95W for the Xeon).
  AMD is totally irrelevant in this day and age. They used to be great CPUs but now they're a very bad choice. Especially with their abysmal single threaded performance and bad performance/watt ratio.
9. Re: Serious Question by Anonymous Coward · 2014-05-05 12:09 · Score: 0
  
  And 2x the power per core! Only 80% the performance in some cases. Plenty of other cases where Intel beat AMD by almost 100%, so more like 50% the speed.
10. Re:Serious Question by Anonymous Coward · 2014-05-05 13:50 · Score: 0
  
  Intel makes CPUs. AMD makes chips. Lots and lots and lots of chips. Far more than Intel could ever dream of.
  Intel makes CPUs and also does some other stuff. AMD does other stuff and also happens to make an x86 CPU.
  When x86 fades into history and Intel goes bankrupt of finds something else to do, AMD will still be making the chips in our phones, microwaves, cars...
11. Re: Serious Question by Anonymous Coward · 2014-05-05 15:05 · Score: 0
  
  Second source principle.
12. Re: Serious Question by serviscope_minor · 2014-05-05 19:58 · Score: 1
  
  Intel is less frequently found with their EP line in a 4 socket configuration because the performance of dual socket can be much higher with Intel's QPI than 4 socket.
  I've not heard of this before. Do you have a link? I'm guessing it's something about just corss connecting all QPI lines between two sockets rather than 4? Also, can't HT do that?
  Intel quad sockets do seem less popular recently. I think AMD are most competitive on that end of servers, especially after memory prices came down so you can get a 512GB 4x server for less than 10k.
  
  --
  SJW n. One who posts facts.
13. Re: Serious Question by Junta · 2014-05-06 01:09 · Score: 1
  
  Unfortunately I do not have a link. I do however know some system designers.
  They designed a 4 socket Opteron system, and did not make a dual socket. It was peculiar to me so I asked why not a dual socket and they said there was no point in a dual socket because there was no performance advantage.
  They also designed both a 4 socket EP system and a 2 socket EP system. I asked why and they said that they could gang up the two QPI links between two sockets for better performance.
  I admittedly did not ask point blank if the two socket opteron couldn't do the same trick and they just didn't bother. It might have just been pushing the core-count marketing bullet as far as they could.
  I think the Bulldozer scheme is actually pretty analagous to NetBurst. NetBurst happened t a time when a processor was almost exclusively measured by the clock frequency. It had theoretical benefits if workloads behaved a certain way. In practice, it pissed away energy and got terrible performance. Bulldozer happened when 'cores on a package' is a major factor in marketing a processor. It got to 'more cores' by replicating only certain facets with shared resources to get incredibly higher core count than Intel. It was similarly a risky move that *could* have panned out if workload acted as they guessed, but an intel core frequently keeps up with 2 amd 'cores' just like a 1 GHz athlon could outperform a 2 Ghz Intel P4.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
14. Re:Serious Question by Anonymous Coward · 2014-05-06 01:45 · Score: 0
  
  Well at least that explains the performance problems that all three of them have.
15. Re:Serious Question by Xest · 2014-05-06 03:06 · Score: 1
  
  AMD, assets: $4.3bn, employees: ~10,000, profit: -$83million
  Intel, assets: $92.4bn, employees: ~107,000, profit: $9.62bn
  Intel is about ten times as big as AMD by every metric (except the negative profit metric - Intel actually makes $10bn profit a year, AMD is just losing money).
  AMD is tiny, it's an irrelevance in the grand scheme of things. Pretending no one would notice Intel's demise whilst AMD will be around long after is comical. Anyway, AMD doesn't even make half the chips you're on about, that's companies like Samsung and Motorola.
Re:Serious Answer by Anonymous Coward · 2014-05-05 08:11 · Score: 0

This has been obvious for some decades. When AMD got technologically ahead of Intel, Intel squashed them with the Core series, which outperformed AMD dramatically. Now, Intel is keeping margins high enough to keep AMD selling chips at a loss most of the time.
Re:Obama lied, patients died by jfdavis668 · 2014-05-05 08:19 · Score: 1

The Obamacare website will work fine when run on these new AMD processors, of course.
Re:Obama lied, patients died by Anonymous Coward · 2014-05-05 08:20 · Score: 0

They could name the new micro-architecture "Obamacore" and it would be relevant. ;-0
Best of luck to them by Dega704 · 2014-05-05 08:36 · Score: 5, Interesting

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.
1. Re:Best of luck to them by arbiter1 · 2014-05-05 08:47 · Score: 1
  
  As of late its been hopeing and claiming their new stuff would be great but when it hits the market it turns out to be not as good as they hoped and back track some of what they said.
2. Re:Best of luck to them by unixisc · 2014-05-05 08:54 · Score: 1
  
  Their manufacturing has always been their Achilles heel. If only they had the fabs that Intel has....
3. Re:Best of luck to them by Bryan+Ischo · 2014-05-05 09:23 · Score: 3, Insightful
  
  I don't get it. Do you, and just about everyone else who has posted in this discussion, only by chips that cost > $200? Because AMD is, and always has been, competitive with Intel in the sub $200 price range.
  Sub $200 chips have, for a very long time, been very fine processors for the vast majority of desktop computer tasks. So for years now, if you're anything close to a mainstream computer user, there has been an AMD part competitive with an Intel part for your needs.
  Of course, once you get to the high end, AMD cannot compete with Intel; but that's only a segment of the market, and it is, in fact, a much smaller segment than the sub $200 segment.
  I personally have a Phenom II x6 that I got for $199 when they first came out (sometime in 2011 I believe) that was, at the time, better on price/performance than any Intel chip for my needs (mostly, parallel compiles of large software products) and absolutely sufficient for any nonintensive task, which is 99% of everything else I do besides compiling.
  Anyway, if you only think of the > $200 segment, why stop there? I'm pretty sure that for > $10,000 there are CPUs made by IBM that Intel cannot possibly compete with.
4. Re:Best of luck to them by marsu_k · 2014-05-05 10:45 · Score: 1
  
  I don't know how much of a profit they're making on their APUs, but they're the winners of the current console generation (somewhat surprisingly, the winner of the previous gen was IBM with PPC/Cell). I'm hoping they stay afloat - they may only be competitive (when it comes to general x86/x64) on very few tasks that require very many cores (and even then probably using more watts at that), but it's never healthy to have a monopoly.
5. Re:Best of luck to them by mbkennel · 2014-05-05 11:03 · Score: 1
  
  | Of course, once you get to the high end, AMD cannot compete with Intel; but that's only a segment of the market, and it is, in fact, a much smaller segment than the sub $200 segment.
  
  From AMD's end, that's a critically important segment since it's where the most money is, and chip design and manufacturing are exceptionally expensive.
6. Re:Best of luck to them by Kjella · 2014-05-05 11:45 · Score: 1
  
  I don't know how much of a profit they're making on their APUs
  Last quarter, they lost $3 million on CPU/APUs so in practice they're breaking even, but revenue is going down which means less and less goes to R&D. Their profits last quarter are a bit from dedicated graphics cards but mostly from console chips. Which is of course better than a loss, but consoles have a very special life cycle with high launch and Christmas sales with little in between so it's unclear how long that'll last.
  
  --
  Live today, because you never know what tomorrow brings
7. Re:Best of luck to them by serviscope_minor · 2014-05-05 20:05 · Score: 1
  
  don't get it. Do you, and just about everyone else who has posted in this discussion, only by chips that cost > $200?
  AMD are also competetive in the quad socket server end of things. Those CPUs cost more like $1000 a pop.
  
  --
  SJW n. One who posts facts.
8. Re:Best of luck to them by Anonymous Coward · 2014-05-06 01:28 · Score: 0
  
  Hey, I had one of those. I had the K6-2 400 MHz model. Eventually I replaced it with a 233 MHz Pentium and the Pentium was faster.
Very likely by Anonymous Coward · 2014-05-05 08:37 · Score: 0

Intel will follow!
Just like they needed to do with x86_64!
Why are people designing cores? by scorp1us · 2014-05-05 08:37 · Score: 1

It seems that it would be fertile territory for genetic algorithms to design the die. Sure, humans need to define the features, but run everything through a genetic algorithm, simulate and let the computer grow its own chips. Perhaps whole chips are not practical, but sub-processing units could do it.

--
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
1. Re:Why are people designing cores? by wiggles · 2014-05-05 08:54 · Score: 1
  
  Pretty sure that firing all of the hot shot CPU designers and having such algorithms design their CPUs for them is how they wound up with the Bulldozer fiasco.
  Looky here.
2. Re:Why are people designing cores? by K.+S.+Kyosuke · 2014-05-05 09:26 · Score: 2
  
  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
3. Re:Why are people designing cores? by Anonymous Coward · 2014-05-05 09:29 · Score: 1
  
  Who modded this up? I work in vlsi CAD. A really huge amount of design work is automated. Very large scale units are fully automated. Cores are still much larger than the largest unit that can be fully automated. There is a trade off between quality you can get from human decision making and speed you can get from automating and there is a limit to how large of a problem can be solved. Intel and recently Apple make better cores by spending human effort where others use automation and perhaps AMD has learned their lesson and has realized that getting crummy product to market sooner is only a good strategy if you are first to market. Designs are broken into blocks of suitable size for automation and then composed from those blocks. People can write behavioral specification for a block in basically C code and then that gets "compiled" into a hardware block complete with physical layout. Every optimization algorithm gets experimented with. Genetic algorithms seem like the greatest thing ever when you first learn about them, but they aren't actually the be all, end all of optimization algorithms. Specifically, they don't scale well to large problems, which is exactly the opposite of what we need to be able to automate the design of an entire core. So the answer to you question is yes and no, but mostly no. I have my own question to pose to you. Why are humans still posting ignorant questions to troll the comments sections of slashdot? I mean, couldn't a genetic algorithm be used to combine different topics and question characteristics to try to maximize the responses to the automated question? Maybe Dice should look into add that as a feature to Beta. Maybe they could create their own answer generator too. That would be great, then the wouldn't need to community at all!
4. Re:Why are people designing cores? by K.+S.+Kyosuke · 2014-05-05 09:52 · Score: 1
  
  Specifically, they don't scale well to large problems, which is exactly the opposite of what we need to be able to automate the design of an entire core.
  
  Well, that's why one should try it with small problems instead! The core I've mentioned above is barely VLSI by modern standards; it has something like 30k gates. Is this still above the limit you mention?
  
  --
  Ezekiel 23:20
5. Re:Why are people designing cores? by rrohbeck · 2014-05-05 10:00 · Score: 1
  
  Nonsense. Code does routing and floor planning, it doesn't design two-core modules.
  Oh and in the current designs the automatic layout saved significant real estate and power compared to hand layouts.
  The article you refer to is utter bullshit.
  
  --
  thegodmovie.com - watch it
6. Re:Why are people designing cores? by Lonewolf666 · 2014-05-05 22:01 · Score: 1
  
  and perhaps AMD has learned their lesson and has realized that getting crummy product to market sooner is only a good strategy if you are first to market
  Hehe, especially as a new x86 CPU is not "first to market" anyway. It competes with a pretty well established line-up of competitors and has to be better than those.
  First to market works only when you have an entirely new kind of product (VHS tapes versus the competition) or overcome a major limitation of the existing product. The last time such a thing happened in the desktop computing world was the AMD64 instruction set. A clear win for AMD. Of course, it also helped that Intel had their Netburst oops at the same time ;-)
  
  --
  C - the footgun of programming languages
7. Re:Why are people designing cores? by Anonymous Coward · 2014-05-06 01:28 · Score: 0
  
  Just look at the floor plans of the AMD's synthesizable cat cores and you see optimization algorithms at work. The reward is ultimately faster time to market for the individual items of a product line and the cost is not obtaining the ultimate performance. FPGA designers have experimented with genetic algorithms in universities at least.
8. Re:Why are people designing cores? by Anonymous Coward · 2014-05-06 02:10 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
9. Re:Why are people designing cores? by Anonymous Coward · 2014-05-06 02:13 · Score: 0
  
  Hey bigmouth: You're being called out (why're you running "forrest"?) http://slashdot.org/comments.p...
stumbling over progress by epine · 2014-05-05 08:47 · Score: 1

It took a long time (ten years?) to get just a basic 32-bit protected mode operating system out to people at large after the hardware (80386) was out.
Double facepalm!! That's one version of the story. In other news, the day after the first Prius was available for sale, there was a global recall on internal combustion engines—the kind of recall where they don't give back.
The hump where protected mode starts to drive real productivity benefit is somewhere above a 486SX/25 with 8 MB of RAM and a 120 MB disk drive. I had a Gateway 2000 laptop exactly like that (monochrome). It even had NetBSD for a few days. Simply not worth it. It had relatively fast video, but not VLB. I didn't even try X Windows.
Later I converted a 486DX/100 with 16 MB of RAM and a 200 MB disk drive into a BSD crash box. That system ran not bad, if you were patient enough. It really could usefully multitask.
Then I upgraded my main system to a P6/200 with 32 MB of RAM (not cheap) and a 640 MB SCSI hard drive (about a dollar per MB) and pair of 19" monitors (about $1000 each) running an early version of NT. This was exactly the point where I said to myself "I'll never go back".
This was not a software issue. The delay in widespread adoption of protected memory operating systems was in large measure caused by a DRAM price cartel.
DRAM price fixing. The American company Micron was the ring-leader as I recall it.

In December 2003, the Department charged Alfred P. Censullo, a Regional Sales Manager for Micron Technology Inc., with obstruction of justice. Censullo pleaded guilty to the charge and admitted to having withheld and altered documents responsive to a grand jury subpoena served on Micron in June 2002.
On October 20, 2004, Infineon also pled guilty. The company was fined $160M for its involvement, then the third largest antitrust fine in US history. Hynix Semiconductor soon took the third position in April 2005 with a $185M criminal penalty after they also admitted guilt. In October 2005, Samsung entered their guilty plea in connection with the cartel.
I remember this extremely well because memory flat-lined at CDN $40/MB for about three years in the mid 1990s.
Of course this is not corruption. It's the invisible hand hard at work.
1. Re:stumbling over progress by K.+S.+Kyosuke · 2014-05-05 09:06 · Score: 1
  
  Well, now it seems that the adoption of heterogeneous systems will be slowed down by the software cartel. Meet the new boss, not the same as the old one but you won't notice the difference. Still, the hardware has to start somewhere, I guess.
  
  --
  Ezekiel 23:20
2. Re:stumbling over progress by Anonymous Coward · 2014-05-05 09:20 · Score: 0
  
  Oh man, good thing we don't have anything like that going on these days.
3. Re:stumbling over progress by operagost · 2014-05-05 09:28 · Score: 2
  
  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.
4. Re:stumbling over progress by dryeo · 2014-05-05 15:25 · Score: 1
  
  As the other poster said, you should have tried OS/2. I had pretty good multi-tasking on a 486DLC at 33Mhz on a good 386 board with 8MBs, localbus and a 120MB drive. It seemed to fly on a 486/100 with 32MBs, even X was fast and it was nice having 3 desktops (X, Win16 and WPS) running at once though you had only one displayed (actually Windows ran seamless with each program in its own session so when they crashed only the program died instead of the system).
  
  --
  https://en.wikipedia.org/wiki/Inverted_totalitarianism
5. Re:stumbling over progress by Anonymous Coward · 2014-05-07 04:24 · Score: 0
  
  Hey K. S. Kyosuke ya bigmouth: Yer bein called out (why're ya runnin "forrest"?) http://slashdot.org/comments.p...
And RISC slowly rediscovers that CISC is better by DutchUncle · 2014-05-05 09:06 · Score: 1

. . . . until the next generation knows not history and thinks they rediscovered RISC . . .
Re:Serious Answer by Junta · 2014-05-05 09:14 · Score: 2

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.
Meanwhile... by Sable+Drakon · 2014-05-05 09:59 · Score: 1

Intel is going to have something on the market that runs more efficiently and with better performance. Try as they might, AMD just can't seem to get their act together for producing a decently performing product since the Athlon II.

--
The Amarri pray for god, the Caldari pray for profit. the Gallente pray for peace, but the Minmatar pray their ships hol
1. Re:Meanwhile... by Tough+Love · 2014-05-05 10:21 · Score: 1, Troll
  
  Which is why consoles don't use AMD at all. Oh wait...
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
2. Re:Meanwhile... by Sable+Drakon · 2014-05-05 10:34 · Score: 2
  
  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
3. Re:Meanwhile... by Tough+Love · 2014-05-05 12:17 · Score: 1, Troll
  
  Excuse me for injecting a note of reality into your rant, but I thought consoles care about heat. Also, aren't "thermals" and "power efficiency" the same thing? Or does that get in the way of your rhetoric.
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
4. Re:Meanwhile... by Anonymous Coward · 2014-05-05 13:15 · Score: 1
  
  My "gaming" PC uses an AMD chip and runs just fine. When you realize that even some of the cheapest CPUs you can buy these days are perfectly capable of running the latest games at 1080p resolutions providing you have a decent video card, Intel doesn't look so impressive anymore. Do you really need 120fps when you can get 100fps for 1/2 the price?
5. Re:Meanwhile... by Tough+Love · 2014-05-05 14:22 · Score: 1
  
  Which is why consoles don't use AMD at all. Oh wait...
  So... intel paying astromods now?
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
amd needs pci-e 3.0 / faster HyperTransport by Joe_Dragon · 2014-05-05 10:18 · Score: 1

or at least give all CPU's 2-3 HT links so you can have 2 or more HT to chipset / HT to pci-e bridges on a 1 cpu board.
Why not... by CTU · 2014-05-05 16:01 · Score: 1

make a gaming CPU...last good gaming chip AMD made was quiet a while ago...so what gives?
FUCK Beta by Anonymous Coward · 2014-05-05 23:51 · Score: 0

Stick fucking beta up your arses.
AMD has superior graphics by Anonymous Coward · 2014-05-06 08:42 · Score: 0

AMD has better graphics than Intel. An Intel chip in consoles would not work, the graphics would be too bad.
Oh FFS by metaforest · 2014-05-07 19:16 · Score: 1

Watch The Mill videos.... It is all spelled out.
You cannot win the Ops/W/$ race by spending resources on O-O-O. You have to be smart about the whole chain. FUs are cheap. Handling optimal cases is expensive in the current regimes. So change the rules. Suddenly difficult problems get easier... Intel and AMD and other incumbents are scared shitless of changing their aging ISAs, and Programming Models. And with good reason... they would be forcing every customer to recompile on version 0.1 releases of new compilers, and working with new hardware spins....
Does anyone now still program on 6800, 6502, or Z-80 for commodity level hardware? No! Because those machines are done. They were invented by people who had no concept of where things were going. Even Intel/AMD are pretty much clueless. They fear changing because it has huge costs. So instead they keep flogging an ISA that is so decrepit that it farts zombies!