5 ms·
I don’t know if Intel has the appetite to attempt another barrel processor. The primary weakness of barrel processors is human; only a handful of people grok h
by jandrewrogers 3y ago
I don’t know if Intel has the appetite to attempt another barrel processor.
The primary weakness of barrel processors is human; only a handful of people grok how to design codes that really exploit their potential. They look deceptively familiar at a code level, because normal code will run okay, but won’t perform well unless you do things that look extremely odd to someone that has only written code for CPUs. It is a weird type of architecture to design data structures and algorithms for and there isn’t a lot of literature on algorithm design for barrel processors.
I love barrel processors and have designed codes for a few different such architectures, starting with the old Tera systems, and became quite good at it. In the hands of someone that knows what they are doing I believe they can be more computationally efficient than just about any other architecture given a similar silicon budget for general purpose computing. However, the reality is that writing efficient code for a barrel processor requires carrying a much more complex model in your head than the equivalent code on a CPU; the economics favors architectures like CPUs where an average engineer can deliver adequate efficiency. At this point, I’ve given up on the idea that I’ll ever see a mainstream barrel processor, despite their strengths from a pure computational efficiency standpoint.
- thesz 3y agoUsing OpenMP is often enough "to really exploit their potential" "to deliver adequate efficiency." Which is what "average engineer" would use.
- sbierwagen 3y agoIf Intel was very bullish on AI, they might be tempted to design arbitrarily complicated architectures and just trust that GPT-6 will be able to write code for it. This was a bet that completely failed for Itanium, but maybe this time...
- sfn42 3y agoI doubt Intel leadership is that naive.
- IshKebab 3y agoThey probably aren't insanely bullish. GPT is a revolution but it's a revolution because it can do "easy" general tasks for the first time, which makes it the first actually useful general purpose AI. But it still can't really design things. It's probably about as far away from being able to design a complex CPU architecture as GPT-4 is from Eliza.
- trashtester 3y agoNvidia released a toolkit to assist chip design a few months ago: https://techmonitor.ai/technology/ai-and-automation/nvidia-ai-chip-design-semiconductor https://techmonitor.ai/technology/ai-and-automation/nvidia-a... Google has been working on AI's to optimize code: https://blog.research.google/2022/07/mlgo-machine-learning-framework-for.html https://blog.research.google/2022/07/mlgo-machine-learning-f... > But it still can't really design things. What do you really mean by "really" in that sentence? In any case, the claim you responeded to was not that the chips would be designed from the ground up by AI, only that AI will enable us to run code on top of chips that are even more complex than current chips.
- IshKebab 3y agoThe Nvidia toolkit you linked is for place & route, which is a much easier task than designing the actual architecture and microarchitecture. It's similar to laying out a PCB. The Google research you linked is using AI to make better decisions about when to apply optimisations. For example when do you inline a function? Which register do you spill? Again this is a very simple (conceptually) low level task. Nothing like writing a compiler for example. > What do you really mean by "really" in that sentence? I mean successfully create complex new designs from scratch.
- rowanG077 3y agoI really wouldn't say it's an easier task at all. It's so intense it's essentially impossible for a human to do from scratch. But it is "just" an optimization problem which is different from designing an architecture.
- sph 3y agoIs GPT-6 the proverbial magic wand that makes all your dreams come true? Because you just hand waved away all the complexity just by name dropping it. Let's get back to Earth for one second...
- BobbyJo 3y agoI think the hand-waving was the point. It was a dig at Intel, accusing them of not having a solid plan.
- JW_00000 3y agoHow could GPT-(arbitrarily large number) learn to write code for an architecture for which there is no training data?
- 317070 3y agoFrom reading the documentation in the context.
- The_Colonel 3y agoThere's an obscene amount of chess literature, yet ChatGPT is mediocre and makes elementary mistakes (invalid moves). This would work only if ChatGPT 6 is AGI, but then it doesn't make much sense to label it as ChatGPT.
- rowanG077 3y agoIf an AGI is a GPT and you can chat with it why wouldn't you call it ChatGPT?
- The_Colonel 3y agoYeah, but that's a big IF. If the actual requirement for this is AGI, then it's clearer to just say AGI instead of ChatGPT which might or might not ever become AGI.
- yk 3y agoBy grokking multi threaded programming of course.
- happycube 3y agoAnd a bet they didn't even know they made for iAPX 432. The ADA compiler was awful optimization-wise, but that came out in an external research paper too late to save it.
- hkgjjgjfjfjfjf 3y ago[dead]
- rbanffy 3y agoWell... This is a research project, and they aren't betting the farm on it. It's not even x86-compatible. And then, it'd require a lot of software rewriting, because we are not used to write for hundreds of threads for context switching is a very expensive operation on modern CPUs. On this CPU a context switch is fast and happens on any operation that makes the CPU wait for memory access, therefore, thinking in terms of hundreds of threads pays off. But, again, this will need some clever OS designs to hide everything under an API existing programs can recognize. It may even be that nothing comes out of it except another lesson on how not to build a computer.
- eternityforest 3y agoWhy do we need x86 compatibility? x86 chips are already fast. Existing programs don't need to see these things at all, they can just act like microservices, and we could load them with an image and call them as black boxes. I would think a lot more work would be done by various accelerator cards by now.
- vGPU 3y agoWhy not just have GPT-6 design the chip to start with?
- AtlasBarfed 3y agoSo the mill is going to be released then, right? Right? Not too psyched to use some proprietary black box compilerthough.
- rbanffy 3y agoThey have been so careful not to leak anything that there is very little interest on it. I completely forgot about them and, if they never launch, I doubt anyone would notice.
- vlovich123 3y agoWhat are the kinds of challenges to write things efficiently? From skimming Wikipedia, it looks like a big challenge is cache pollution. Is it possible that the hit to cache locality is what inhibits uptake? After all, most threads in the OS are sitting idle doing nothing, which means you’re penalized for any “hot code” that’s largely serial (ie typically you have a small number of “hot” applications unless your problem is embarrassingly parallel)
- yvdriess 3y ago> What are the kinds of challenges to write things efficiently? The challenge is mostly that you have to create enough fine-grained parallelism and that per thread performance is relatively low. Amdahl's law is in full effect here, a sequential part is going to bite you hard. That's why each die on this chip has two sequential-performance cores. The graph problems this processor is designed to handle have plenty of parallelism and most of the time those threads will be waiting for (uncached) 8B DRAM accesses. > From skimming Wikipedia, it looks like a big challenge is cache pollution This processor has tiny caches and the programmer decides which accesses are cached. In practice, you cache the thread's stack and do all the large graph accesses un-cached, letting the barrel processor hide the latency. There are very fast scratchpads on this thing for when you do need to exploit locality.
- jhrmnn 3y agoIs it then similar to how utilizing a GPU fully is much harder than utilizing a CPU fully?
- yvdriess 3y agoIn some aspects, yes. Arguably, it's much harder to max GPUs because they have the added difficulty of scheduling and executing by blocks of threads. If not all N threads in a block have their input data ready or are branching differently, you are idling some execution units.
- incrudible 3y agoIt is not hard at all to fully utilize a GPU with a problem that maps well onto that type of architecture. It's impossible to fully utilize a GPU with a problem that does not. A barrel processor would make branching more efficient than on a GPU, at the cost of throughput. The set of problems that are economically interesting and that would strongly profit from that is rather small, hence these processors remain niche. Conversely, the incentive to have problems that map well to a GPU is higher, because they are cheap and ubiquitous.
- jeffreygoesto 3y agoWould you call that "general purpose" still? If the code needs to be so special to leverage the benefits of that design?
- rbanffy 3y agoIn a way, yes - it's no different from scalar CPUs from back when they didn't need to wait for memory. GPUs are specifically designed to operate on vectors.
- yvdriess 3y agoThere's two single threaded cores, but the four multithreaded cores are indeed Tera-style barrel processors. The Tera paper is even cited directly in the PIUMA white paper: https://arxiv.org/abs/2010.06277 https://arxiv.org/abs/2010.06277 edit: s/eight/four
- washadjeffmad 3y agoUnfortunate name. Anyone familiar with the ways PUMA was misapplied in the past might reflexively read that as "Peeeuuw!ma".
- rewmie 3y ago> The primary weakness of barrel processors is human; only a handful of people grok how to design codes that really exploit their potential. They look deceptively familiar at a code level, because normal code will run okay, but won’t perform well unless you do things that look extremely odd to someone that has only written code for CPUs. Nowadays, apps that run straight on baremetal servers are the exception instead of the norm. Some cloud applications favour tech stacks based on high level languages designed to run single-threaded processes on interpreters that abstract all basic data structures, and their bottleneck is IO throughput instead of CPU. Even if this processor is not ideal for all applications, it might just be the ideal tool for cloud applications that need to handle tons of connections and stay idling while waiting for IO operations to go through.
- jacquesm 3y agoWith the advent of GPU coding and the number of people exposed to it there is a chance that enough people are willing and able to try unfamiliar architectures if it gives them an advantage that this just might be viable now.
- throwaway329 3y agoWhat kind of advantage barrel processors give a regular programmer (especially things that can't be done efficiently with CPU/GPU)?
- jacquesm 3y agoMuch closer communication lines between the two, thread level guarantees that would be hard to match otherwise. A barrel processor will 'hit' the threads far more frequently on tasks that would be hard to adapt to a GPU (so for instance, more branching). Though CPU/GPU combinations are slowly moving in that direction anyway. Incidentally, if this sort of thing really interests you: when I was playing around with machine learning my trick to see how efficiently my code was using the GPU was really simple: first I ran a graphics benchmark that maxed out the GPU and measured power consumption. Then I did the same for just the CPU. Afterwards while running my own code I'd compare the ratio between my own code's power draw with the maximum obtained during the benchmarks, this gave a pretty good indication of whether or not I had made some large mistake and showed a nice and steady increase with every optimization step.
- trentnelson 3y agoCould you not also see an impact to run times? If algorithm A draws 100W and runs in 10 seconds, and algo B draws 200W… shouldn’t it be very much sub 10 seconds to warrant being called a better algorithm?
- jacquesm 3y agoNot really, it's an apples-to-oranges comparison. If you ran the same distributed algorithm on a single core you wouldn't see the same speed improvements. These chips are ridiculously efficient because they need far fewer gates to accomplish the same purpose if you have programmed to them specifically. Just like you couldn't simulate a GPU for the same power budget on a CPU. The loss of generality is more than made up for by the increase in efficiency. This is very similar in that respect, but with the caveat that a GPU is even more specialized and so even more efficient. Imagine what kind of performance you could get out of hardware that is task specific. That's why for instance crypto mining went through a very rapid set of iterations: CPU->GPU->ASIC in a matter of a few years with an extremely brief blip of programmable hardware somewhere in there as well (FPGA based miners, approximately 2013). Any loss of generality will result in efficiency and vice versa, the question is whether or not it is economically feasible and there are different points on that line that have resulted in marketable (and profitable) products. But there are also plenty of wrecks.
- CodesInChaos 3y agoBut how does it compare to GPUs for compute tasks (e.g. CUDA)? Both performance and difficulty wise?
- nradov 3y agoThe new Mojo programming language is attempting to deal with such issues by raising the level of abstraction. The compiler and runtime environment are supposed to automatically optimize for major changes in hardware architecture. In practice through I don't know how well that could work for barrel processors. https://www.modular.com/mojo https://www.modular.com/mojo