Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Single-chip processors have reached their limits

spectrum.ieee.org

Post reply on HN
Print view View original

141–150 of 159 posts

Re: Single-chip processors have reached their limits

#141

Post by pfdietz »

hvidgaard wrote: post #129
tgamblin wrote: post #119

Earlier quoted context omitted.

All of this is true, but I’ll just be nitpicky to make a point: > Does a future event's processing circumstances maybe depend on all events received up until now? In a parallel prefix sum, the final sum does depend on all prior inputs, but a good parallel implementation runs in O(log(n)) time. It is, of course, not a total ordering problem, but that’s not obvious at first glance — I’ve always thought it was a beautif…

It's a very simple example and knowing that addition is commutative, it's obvious that there is no ordering.

Prefix sum depends on associativity, not commutativity.

Re: Single-chip processors have reached their limits

#142

Post by adhesive_wombat »

RugnirViking wrote: post #140
adhesive_wombat wrote: post #77

Earlier quoted context omitted.

If that rabbit hole appeals, the ITRS reports (now called IRDS[2]) are very good mid-level, year-by-year summary of the state of the art in chipmaking, including upcoming challenges and future directions. > Being able to print something in nanometers is an overlooked technical achievement for human manufacturing. IMO, a semiconductor fab probably is the highest human achievement in terms of process engineering. Not o…

is it the same reports accessed by the process in https://irds.ieee.org/home/how-to-download-irds ?

For IRDS, yes.

Re: Single-chip processors have reached their limits

#143

Post by josefx »

ReactiveJelly wrote: post #111
AnthonyMouse wrote: post #92

Earlier quoted context omitted.

The alternative is speculative execution. If you can guess what the result is going to be, you can proceed to the next calculation and you get there faster if it turns out you were right. If you have parallel processors, you can stop guessing and just proceed under both assumptions concurrently and throw out the result that was wrong when you find out which one it was. This is going to be less efficient, but if your…

Except that synchronizing two or more cores is, as a rule of thumb, too expensive to do per-instruction?

It would have to be done on the same hidden low level register manipulation as current speculation already does. Instead of rolling back to the wrong branch and starting over you would just drop it and continue with the correct computation.

The issue would be if you have a slow (value load from memory) and a fast (cached value) branch, currently only the most often used one gets predicted, so if you always hit the fast branch the predictor will never touch the slow branch. I think if you evaluate both in parallel you end up having no way to avoid the penalties introduced by the slow path. Imagine having your CPU cache constantly invalidated by code that never "runs".

Re: Single-chip processors have reached their limits

#144

Post by gotaquestion »

astrange wrote: post #134
gotaquestion wrote: post #87

Earlier quoted context omitted.

The problem is AMP is very hard to program and debug. In embedded, one core is a scheduler and another is doing some real-time task (like arm BIG.little). In larger automotive heterogeneous compute platform, typically they are all treated as accelerators, or with bespoke Tier-1 integration (or like NVIDIA Xavier). And on top of that, OEMs always want to "reclaim" those spare cycles when the other AMP cores are underu…

M1 is an AMP design, as is every iPhone SoC. It works well although you’ll be surprised if you try to run an SMP workload on every single core.

Yes, I actually said this in my original post: Arm BIG.little works, which is what M1 is, and embedded works well, which are SoCs. It is much more difficult in AMP systems that aren't necessary only the same die, like automotive Tier 1 products.

Re: Single-chip processors have reached their limits

#146

Post by sliken »

paulmd wrote: post #104
sliken wrote: post #64

Earlier quoted context omitted.

AMD Epyc is (AFAIK) what popularized the term. Their current design has a memory controller (PCIe controller, 8 x 64 bit channels of ram, etc) and 8 chiplets which are pretty much just 8 cores and a infinity fabric connection for a cache coherent connection to other CPUs (in the same or other sockets) and dram. So generally Epyc come with some multiple of 8 CPUs enabled (1 per chiplet) and the latency between cores o…

> So generally Epyc come with some multiple of 8 CPUs enabled (1 per chiplet) Not quite, AMD does use values other than 8 cores-per-CCD in Epyc as well. Take the 7402P, that's a 24C SKU, if you did that as "3 8-core chiplets" then you would only have 3 quadrants = 6 memory channels and 48 PCIe lanes. Those are done with 4 chiplets of 6 cores each. Same for 48C SKUs. AMD also has a number of "frequency-optimized"/"cac…

Heh, right, I did say generally.

The 7453, 7443, 7413, and 7313p have less than 8 chiplets (the 7xx3 chips are Milan/Zen3). I don't believe any of them have less then full memory bandwidth, unlike the previous generation. The spec sheet mentioned PCIe x 128 for all of them as well.

Re: Single-chip processors have reached their limits

#147

Post by paulmd »

sliken wrote: post #146
paulmd wrote: post #104

Earlier quoted context omitted.

> So generally Epyc come with some multiple of 8 CPUs enabled (1 per chiplet) Not quite, AMD does use values other than 8 cores-per-CCD in Epyc as well. Take the 7402P, that's a 24C SKU, if you did that as "3 8-core chiplets" then you would only have 3 quadrants = 6 memory channels and 48 PCIe lanes. Those are done with 4 chiplets of 6 cores each. Same for 48C SKUs. AMD also has a number of "frequency-optimized"/"cac…

Heh, right, I did say generally. The 7453, 7443, 7413, and 7313p have less than 8 chiplets (the 7xx3 chips are Milan/Zen3). I don't believe any of them have less then full memory bandwidth, unlike the previous generation. The spec sheet mentioned PCIe x 128 for all of them as well.

> The spec sheet mentioned PCIe x 128 for all of them as well.

Due to the way they've sliced it, you always get full PCIe PHYs (128 lanes) just like you get full memory PHYs. They literally only gimped the memory bandwidth, like the controllers are gone but the PHYs remain and the other 4 controllers can use all of the PHYs. It's kinda weird, I don't think I've seen it done like that before.

Incidentally though this probably does mean some weirdness with locality at those extremes though - half of your lanes don't have any CPU cores locally and everything they do is running through the quadrant-interconnect.

Re: Single-chip processors have reached their limits

#148

Post by sliken »

paulmd wrote: post #147
sliken wrote: post #146

Earlier quoted context omitted.

Heh, right, I did say generally. The 7453, 7443, 7413, and 7313p have less than 8 chiplets (the 7xx3 chips are Milan/Zen3). I don't believe any of them have less then full memory bandwidth, unlike the previous generation. The spec sheet mentioned PCIe x 128 for all of them as well.

> The spec sheet mentioned PCIe x 128 for all of them as well. Due to the way they've sliced it, you always get full PCIe PHYs (128 lanes) just like you get full memory PHYs. They literally only gimped the memory bandwidth , like the controllers are gone but the PHYs remain and the other 4 controllers can use all of the PHYs. It's kinda weird, I don't think I've seen it done like that before. Incidentally though this…

"They literally only gimped the memory bandwidth".

As I mentioned looks like all the less than 8 chiplet Epycs in the current Zen3/Milan generation look like they have the full memory bandwidth.

Re: Single-chip processors have reached their limits

#149

Post by paulmd »

sliken wrote: post #148
paulmd wrote: post #147

Earlier quoted context omitted.

> The spec sheet mentioned PCIe x 128 for all of them as well. Due to the way they've sliced it, you always get full PCIe PHYs (128 lanes) just like you get full memory PHYs. They literally only gimped the memory bandwidth , like the controllers are gone but the PHYs remain and the other 4 controllers can use all of the PHYs. It's kinda weird, I don't think I've seen it done like that before. Incidentally though this…

"They literally only gimped the memory bandwidth". As I mentioned looks like all the less than 8 chiplet Epycs in the current Zen3/Milan generation look like they have the full memory bandwidth.

No need to get defensive (on behalf of a multibillion-dollar corporation), I'm just more curious about how exactly they did the quad-channel SKUs in Rome.

Re: Single-chip processors have reached their limits

#150

Post by eslaught »

apbytes wrote: post #126
eslaught wrote: post #121

Earlier quoted context omitted.

Like the sibling comments have indicated, many apparently sequential computations are actually parallelizable. I'll just add finite automata as another example in this category. On the surface it looks quite sequential (process one input at a time), but there are nice parallel algorithms that you can even implement on a GPU! So yeah, there's a lot of nonobvious parallelism in the world. Just because something seems s…

Wait what‽ Do you have any resources you can point to for parallelism in finite automata?

It's been a while, but here are a couple things I found on Google for the search "finite automata gpu":

https://github.com/vqd8a/DFAGE

https://onlinelibrary.wiley.com/doi/epdf/10.1002/stvr.1796

Post reply on HN