Slashdot Mirror
Linux Kernel Patch Hints At At 32-Core Support For AMD Zen Chips
New submitter Iamthecheese points to an article which says that a patch published on the Linux Kernel Mailing List indicates that AMD's forthcoming Zen processors will have as many as 32 cores per socket, but notes that while the article's headline says "Confirms," "the article text doesn't bear that out." Still, he writes,
There are hints of such from last year. A leaked patch for the 14 nanometer AMD Zeppelin (Family 17h, Model 00h) reveals support for up to 32 cores. Another blog says pretty much the same thing. We recently discussed an announced 4+8 core AMD chip, but nothing like this.
https://xkcd.com/619/
I hear that rm -rf has some success with that. I'm not sure though as I don't care much for the argument.
Zen is (according to AMD, so I guess it is optimistic) is supposed to bring 40% improvement in instructions per clock. That would put it around Sandy Bridge level. They would have to pull off 100% improvement to be competitive at high levels once again.
Quite wrong about AMD CPUs getting progressively worse.
Intel has outpaced AMD their process technology is more sdvanced allowing them to do magical things like significantly increase performance AND reduce power at the same time...
This also has something to do with Intel's past blocking of AMD products when the K7 Thunderbird was kicking ass. Year later cash strapped AMD agreed to settle the matter to the tune of $2 billion. I'm sure if they had a bit more time and money they could have gotten more.
Now, unsurprisingly Intel's advantage is only this much and not more, most likely because Intel needs AMD to exist. It's a great way to compare and handy not to be declared a monopoly.
So AMD has been improving, albeit at a slower pace than Intel. They can still compete but need to change the approach to fight where they can shine and profit rather than everywhere Intel goes.
A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
I predicted that I will see a kilo-core machine in my lifetime.
Do GPU shader cores count?
Linux already supports 32 cores very well, (Or 1024...) Still, driver support is needed for the details of adressing (up to) 32 cores on that particular architecture. Hence the patch. AMD may or may not turn out a 32-core chip in the near future - but at least their architecture supports that number of cores. Which is a bit interesting. If it turns out too hard to make, expect chips with 12-20 cores and gradually more as production quality ramps up.
CMOS technology, is static meaning that there is no current flow through a gate when it is on or off. Current only flows while the transistor is transitioning states. P = I x V and as I (current) increases, so does power. All 'digital' circuits are actually analog and you can show that I is proportional to frequency squared. Instead of having a power (^) increase in energy use, you have a linear relation.
If the previous max cores per socket was 16, and the value in the kernel needs to be a power of 2, then at most this tells us that they have a 17 (more likely 18 or 20) core CPU on the way.
AMD best hope this CPU has some actual guts to it for performance / power efficiency.
Perhaps cores-schmores is one way to approach this? Lots of small cores with relatively slow clocks, as higher clocks tend to worsen power efficiency. I'm not discounting Intel's success with single-core performance per se, but I sometimes feel it's aimed at speeding up legacy applications, while those with modern OSes and code are happy with the cheaper multicore offerings from AMD.
Escher was the first MC and Giger invented the HR department.
AMD long ago gave up competing on raw CPU performance with Intel. They compete on price and integration. They have better on-board GPUs than Intel, and they cost less. The XBOne and PS4 both use AMD CPUs and GPUs.
The question is if these markets are enough.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Sadly, the vast majority of applications people use in their daily ARE "legacy" applications.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The Thunderbird was nice, but it was more of a price/performance winner than overall performance. A 1GHz Thunderbird ran stable at 1.3GHz and was similar performance to a 2GHz Pentium 4 at a fraction of the cost (particularly as the P4 required RAMBUS DRAM, so you could stick twice as much DDR in Athlon for the same money). It wasn't until the Opteron that AMD really started winning on performance. The integrated DRAM controller was a big win and being first to 64 bits (which, on x86, means more GPRs, sane floating point ISA, and PC-relative addressing) gave them a huge advantage. Unfortunately, they haven't really been competitive since the Core 2, except in market segments where Intel intentionally cripples their offerings (e.g. no more than 2 SATA ports on the Atom Mini-ITX boards to avoid competition with the i3 boards, making AMD the only viable option).
I am TheRaven on Soylent News
You are more optimistic than AMD's marketing department? That's some impressive optimism.
This is like looking at a hardware register in a generic register layout that leaves 8 bits for "core index" and deducing that the manufacturer must be intending on delivering a 256-core CPU.
Then you find the documentation for the specific family and find out that bits 7-3 are "reserved and will be read as zero".
But the driver patch they submitted doesn't make that assumption "just in case".
Because it's easier to plan ahead in the driver than it is to actually deliver a 256-core CPU.
A mobile i5 from 2012, with half as many cores, running at half the clock speed, probably at half the voltage of the Athlon.
You're benching Intel's 17 watt netbook CPU from 2012 versus AMD's 95 watt underdesk spaceheater from 2010, and think that's a good thing for AMD when they nearly tie?
0 1 - just my two bits
True. It seems that AMD learned their lesson when they held the performance crown - while they might be able to outcompete Intel on raw performance and affordability, they'll never be able to afford to compete against Intel's dirty tricks and anticompetive behavior. So instead they target the mainstream and console market, and let those who are actually interested in the price:performance ratio to come to them.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Other than my fairly new laptop, most of what I buy is AMD and I can easily afford the Intel offerings. Though, I usually go with nVidia GPUs when I'm making that choice and not just buying the whole system. I get more than adequate performance for everything I do, at a fine price, and I get to support AMD by doing so. I do buy some Intel products, I'm not some sort of zealot - I don't think. I'm just quite content with AMD and have had good luck with them since I tried my first one back at the K6-II time.
The difference? Well, my laptop is really a mobile workstation and I could probably have bought 5-6 fairly acceptable laptops for what I paid for this. It's nice and I liked it, so I bought it. It's stupidly expensive, however. (Over $5500 before shipping.) So, I think there's a time and place for Intel - it's just that I really don't normally even notice much of, if any, difference in performance anymore. In case you're curious, it's a Titan X4K and yes, yes it is just what I was looking for.
"So long and thanks for all the fish."
Intel's upcoming chips top out at 44 threads:
SKU Name Cores/Threads Base Clock Boost Clock L3 Cache (LLC) TDP
Intel Xeon E5-2699 V4 22/44 2.2 GHz ~3.6 GHz 55 MB 145 W
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I think the solution for the new PC is going to be a combination of both. 4 fast as possible cores; maybe 8. Then massive additional cores at lower clock speeds and simpler design. Most likely implies a hybrid NUMA design with additional performance specs and turntables for the host OS and user level software(games). Probably a few modes of operating. Automatic management and succeeding levels of the OS taking over management.
Think of the slower processors as something akin to a floating point coprocessor. Programmers are lazy. Until the hardware exists and they know they will see a benefit they don't want to program for it. Programming for massive unknown hyperthreading is a hard topic. They will always choose the lowest common denominator.
But having both fast/few and slow/many/efficient changes the game. The fast/few is at the end of it's performance curve life but will live on. It's nice to have a few cores around that run two to three times faster for difficult programs. But having an undetermined number of extra processors sitting around.... programmers won't be able to control themselves when they want more performance.
I can also imagine this extending to mixed architectures such as x86+Arm like we have heard rumors about. CISC+RISC in the same computer; blasphemy. FPGA compute boards and graphics card becoming coprocessors and integrating on a more equal level with the CPU's.
P.S. The future of operating systems is a three tiered approach: Hypervisor->OS->Programs. The hypervisor being something akin to a microkernel. What if instead of building compatibility into successive operating systems you could run them all together and forget about compatibility altogether. With additional software and drivers I can even see compositing. This means we can run FreeBSD, Redhat Linux, Ubuntu, Gentoo, Arch, DOS, Windows 3.1, Windows XP, Windows 7, Windows 8, Windows 10, and GNU Hurd, and multiple x86 and Arm versions of Android all on the same machine. Imagine all those with compositing extensions.... And once you get rid of the browser with Flash and Shockwave 99% of viruses disappear so administration actually gets easier and if you do get a virus you can always rollback; or rollout clones to test software. Also one can setup a file system with features like file versioning and encryption so that programs can't just hijack your data.
The reason I brought up the above is because one can further still extend the hardware with a clustering OS. A business could install such a specialized clustering OS on each of it's desktop machines in the building and then have it's own cloud. Imagine using something like that for rendering and processing video.
At the cache level, usually. I haven't checked, but I would hope that the Linux scheduler is smart enough to know that it's cheaper to migrate a thread between cores on the same die than between dies because the cache is likely to be warmer.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});