3 ms·
As the cores get individually weaker and more power efficient, eventually what you end up with is a middling GPU with an x86 identity crisis.
by pixelpoet 3y ago
As the cores get individually weaker and more power efficient, eventually what you end up with is a middling GPU with an x86 identity crisis.
- rbanffy 3y agoOTOH, it'll be a GPU that can host a whole lot of cloud applications at the same time. Or compile lots of code in parallel. Or run a browser.
- treprinum 3y agoIt won't have infinite memory channels, so you end up with 32 cores fighting for memory access on each channel.
- rbanffy 3y agoI wonder how Linux deals with lots of cores with large-ish scratchpads. You can also add lots of memory channels as well - this is not a desktop part after all - you'll find them in datacenters.
- JonChesterfield 3y agoThere is really significant convergent evolution between x64 and amdgpu. An x64 core running two threads is very like a gpu core running four threads from a stack of a hundred or so. One speculates to hide memory latency, the other shuffles threads between cycles to hide memory latency. One has ~64 byte wide vector ops, one has ~256 byte wide vector ops. I have a pet theory that the significant difference is the cache coherency model.
- fock 3y agopreviously called Xeon Phi.
- keyringlight 3y agoI'm probably forgetting some vital details, but isn't that getting similar to Larrabee? As I recall that was where intel seemed to be exploring other uses for their Atom CPUs and were trying to push as many as they could into one processor. One of the uses they prototyped was a GPU, or a large multi-threaded (x86)software renderer rather than going through a regular 3D acceleration API. I remember reading that part of the challenge was that Larrabee was a system itself, so a developer needed to boot something like BSD before providing it with code to get useful output. This was around the time AMD was experimenting with 'fusion' after their purchase of AMD, and exploring how to push different different parts of an application to the relevant processor in their CPU+GPU products. That's in addition to the other Xeon Phi accelerators they did. Obviously Sierra Forest is a regular CPU, but it seems there's a bit of "history doesn't repeat, but it rhymes"
- whaleofatw2022 3y agoXeon Phi came in a Socketed form where it could be a main CPU IIRC. Can't remember if it had a lower max core count across SKUs but at least one popular vtuber got hands on one.
- treprinum 3y agoI have a 68-core socketed Xeon Phi and there were also 72-core ones.
- smallmancontrov 3y agoThese days CPU vs GPU isn't about the number of ALUs or cores, it's about the latency hiding strategy. A GPU assumes oodles of similar threads are running at the same time, so the moment one blocks on a memory access another can be rotated in. It's hyper-hyper-hyper-hyper-...-hyper threaded. Meanwhile, a CPU is just hyper-threaded, if that, and instead it tries to be clever about prefetching, speculative execution, and the like. So long as some important applications have tons of similar threads and some have very few threads, it will probably make sense to specialize.
- pixelpoet 3y agoYep, I see it as latency vs throughput optimisation, particularly wrt memory subsystem. What I was pointing out is, x86 is not well suited to GPU execution; Intel tried that with Larrabee. Moreover, in the latest generation Nvidia chips you have 72-96mb L2 cache and 2.5ghz+ clock speed, so it's remarkably capable per-thread. At some point, and I think 256 cores might be the ballpark, you're committing to using so many threads that you're probably mostly interested in high throughput. (I'm writing commercial path tracers so my bias is obvious!)
- adgjlsfhk1 3y agoone thing with high that cpus is you can use them to claw back against OS latency. you can do things like pin 128 cores for your application, 64 for your networking, 32 for disk IO and 32 general purpose, and keep the OS from scheduling other programs on the critical cores for running your program.
- AnthonyMouse 3y agoGPUs are for parallel instructions. You want to do a ton of matrix multiplication. Multi-core CPUs are for parallel processes. You want to host a ton of virtual machines and they all care about branch prediction and cache latency more than throughput.
- sudosysgen 3y agoThe big difference is that CPU cores are truly independent. GPU "cores" aren't, a group must be running exactly the same instructions at exactly the same time, and they share registers. Also, CPU cores tend to have speculative execution, GPUs don't. So long as GPU threads have to run in a warp, they will be fundamentally very different from a CPU core, no matter how weak, strong, or power efficient.