10 ms·
To reinvent the processor
- Veedrac 7y agoI am reading the comments, and am open to critique or general suggestions. “I found this part confusing” is also very welcome. This is quite an information dense work, and a little rough around the edges, though I am pretty happy with it overall.
- cnasc 7y agoI'm only a little way through it so far, so I'll come back with any questions, but I'd like to thank you for sharing such an interesting read!
- h2odragon 7y agoI almost understand some of these words :) Truly this is fascinating and makes me want to learn about the many things i do not grasp yet. Thank you. > Register hazards are an unavoidable consequence from using a limited number of names to refer to an unbounded to number of source-level values yet I seem to recall seeing compiler writers lament the paucity of registers too. Perhaps "registers" itself as a concept is something we should trade in for named memory spaces or something. gimme instruction level access to all of what is now cache. (chuck all the cache handler logic btw). let me page in and out sections of that to main memory or the inter cpu or io busses, but otherwise its all storage and the real difference is latency. if we want to burn hardware there could be special graded coherency memory areas or transactional or content addressable.
- deepnotderp 7y ago> Perhaps "registers" itself as a concept is something we should trade in for named memory spaces or something Please no, however hard you think register renaming is, memory disambiguation is harder.
- h2odragon 7y agoHey I'll argue for self modifying code if you let me :). Don't let it be ambiguous. I may be trying to express "don't add abstractions" let the hardware limits show, in ignorance of what the hardware limits are.
- ajb 7y agoYou might also be interested in Sophie Wilson's "Generation renaming" scheme. Unfortunately AFAIK the only open description of it is in the patents, which of course are written in patentese: https://patentimages.storage.googleapis.com/e2/c4/39/301ea43095e5c9/EP2937775A1.pdf https://patentimages.storage.googleapis.com/e2/c4/39/301ea43... https://patentimages.storage.googleapis.com/fd/de/de/7fdbc306db9068/EP2937776A3.pdf https://patentimages.storage.googleapis.com/fd/de/de/7fdbc30...
- bullen 7y agoI'm also a little bit behind on the semantics and understanding. From my perspective we need to make the CPU more user friendly first, so I would like a VM (without GC) in silicon. Basically removing the absurdities of the memory and error handling that we get now. I still have no clue if this is possible? Then I think going back to 8-bits and making a purely parallel multi-core processor with segregated transistor memory and shared DRAM would be an interesting idea, just to see how that would work out with today's lithography and memory bottlenecks. Of course you would have to code differently so the programming language would have to change by adding local and remote memory to the variables and explicitly handling concurrency without blocking to the remote memory somehow. Possibly by copying, which is slow, but that memory is already going to be slow. The common path for both of these is lets make things complex in a different ways separately to see if we can make life for programmers better, one by removing frustration and worry the other by keeping the energy efficient scaling and memory speeds going for a tad more.
- timerol 7y agoThis talks about two major performance concerns in CPUs: control flow and memory access. The transition between the two was my favorite part of the article. It's both funny and accurate. "If the previous section gave the impression that, say, control flow is a particularly tough problem, but inventive methods can give powerful and practical tools to tackle it… good, that was the intent. In this section I want you to take that expectation and dash it against the rocks — memory is hard."
- hinkley 7y agoIn the 90’s there was a group experimenting with putting small processors directly on the memory chips and doing data processing there.
- deepnotderp 7y agoBerkeley IRAM
- flohofwoe 7y agoThis is also the idea behind the Pixel Planes rendering architecture from the 80's, they called it "logic-enhanced memory chips". It's not a "universal CPU" on the memory chips, but each chip can "process" and store 128 pixels, where the processing is implemented with a hardwired linear expression. Here's a video on Pixel Planes 4 from 1987: https://www.youtube.com/watch?v=7mzpZ861wEw https://www.youtube.com/watch?v=7mzpZ861wEw
- 7y ago
- raphlinus 7y agoI like the branch-predict / branch-verify split. It reminds me strongly of the ldrex/strex strategy in ARM for splitting (for example) a compare-exchange in two parts, so that in the non-contended case it basically just flows straight through. Having recently done a lot of GPU programming, I'm wondering what your thoughts are on a GPU-like approach, with tons of in-order cores. It's hard to program, but maybe we need to figure that out in order to get performance.
- api 7y agoI lean strongly toward your second paragraph. If we can make many core programming easier I think we can dispense with a ton of complexity and just scale out cores with transistor counts. I think an under researched area is the application of deep learning to compilers. What could be done there for parallelism? We are still kind of stuck in programming models developed back when core frequencies were scaling geometrically. We hit that wall in the early 2000's and still haven't quite assimilated it. We are tackling it at the macro scale of multiple discrete systems via modern devops but the systems (e.g. Kubernetes) are baroque, clunky, and hard to manage.
- deepnotderp 7y agoRegarding deep learning for compilers, at Vathys we're using deep learning in compilers for deep learning code and it works well, achieving pretty good results even compared to human implementations. But it's not that much of a gain and it can often get stuck on some code, especially if it's sufficiently new code. Just as surprisingly, genetic algorithms are almost as good but faster and more robust. Finally, I think people point to examples of much faster hardware accelerated workloads and optimized assembly code that share these characteristics: 1. Are relatively embarrassingly parallel 2. Are relatively control flow light 3. Generally tend to exhibit high compute/bandwith ratios. Hence, you see deep learning hardware, bitcoin mining hardware, optimized compression codec assembly, etc. pointed to as examples of acceleration, but this doesn't apply to all workloads, e.g. a web app.
- jcranmer 7y ago> I think an under researched area is the application of deep learning to compilers. What could be done there for parallelism? I don't think it's under-researched, because we already know that it's only ever going to do a lousy job. The problem of autoparallelization is mostly stymied by difficulty in computing the legality of transformations, and secondarily by the problem of tuning parameters [1]. We've realized that it's easier to just get the users to tell us about these things, sidestepping the problem for the most part. > We are still kind of stuck in programming models developed back when core frequencies were scaling geometrically. The programming model for parallelism is dataflow. We already know that: the tricky thing of parallelism is communication, so annotating all of the edges of communication makes the scheduling problem much, much easier. [1] Theoretically, machine learning is good at tuning parameters. In practice, you get good results with the dumbest algorithms already, and the available headroom for performance is generally swamped by the fact that small changes such as function size can dramatically alter the performance characteristics of code elsewhere in the application.
- ezconnect 7y agoI think the future of CPU will be FPGAs for one software. Hardware will be so cheap that your desktop or whatever computer you have will have lots of FPGAs or logics to run a certain amount of software. You can also allocate some of it for general computing so you can run legacy software.
- jcranmer 7y agoThe problem is that FPGAs just can't drive memory bandwidth. (And FPGA configuration times are obnoxiously long).
- ezconnect 7y agoYou only configure it once when you buy the software, installing software takes time too right now. FPGAs do come with embedded memory with very low latency. Someone will figure it out how to make it faster if things get implemented that way.
- analognoise 7y agoCan't drive memory bandwidth? I can saturate any memory interface with ease. All line rate Ethernet systems (pushing 100+ Gb/s now) are done with FPGAS. What are you talking about?? I can program a kintex ultrascale @ 16 bits transmitted at something like 100Mhz. The system is up fully in less than 5msec from power good. This feature is used in every system where milliseconds count - including military systems. Are you confusing JTAG reconfiguration speeds with production configuration speeds? I'm very confused by what you said, can you elaborate?
- foobiekr 7y agoNPUs like Tomahawk, etc are not FPGAs.
- analognoise 7y agoNot in their final version, no. I see what you meant - I should have said "are developed with". Lemme edit that. https://store.digilentinc.com/netfpga-sume-virtex-7-fpga-development-board/ https://store.digilentinc.com/netfpga-sume-virtex-7-fpga-dev... But for 7k you can get an older design with 4x 10Gbps Ethernet. It's used at Stanford and Cambridge for... High speed network processing research. High speed trading firms almost universally use FPGAs. You can't go faster without custom silicon. But you can sure as shit max out as many DDR and network interfaces as you can physically attach.
- ravenouswolves6 7y agoAlso worth a mention, the Swarm architecture: https://people.csail.mit.edu/sanchez/papers/2015.swarm.micro.pdf https://people.csail.mit.edu/sanchez/papers/2015.swarm.micro...
- gumby 7y agoThe mill folks seem nice (at least the ones I've met) but after 14 years with no silicon and nobody poaching their ideas for other designs, is there actually a there there? Why is there no SiFive for Mill?
- ansible 7y agoSiFive work with the RISC-V architecture, which is completely open, intentionally so. The Mill folks have been careful to patent everything interesting before publicly talking about it.
- bogomipz 7y agoThe author states: >"A Skylake CPU has 348 physical registers per core, split over two different register files." Just looking at some literature on recent Intel I can only see a fraction of this 348 number. I see the following: 16 general purpose registers 6 segment registers 1 flags register 8 x87 registers 16 SSE registers Could someone explain where this 348 registers figure in the post comes from exactly?
- ClassyJacket 7y agoI'm not an expert on this topic, but are there additional registers for the extended instructions like MMX and AVX?
- Nyan 7y agoYou're confusing instruction-set architecture with micro-architecture. The x86-64 ISA defines 16 integer ("logical") registers, for example, however, Skylake has (don't quote me on the figure) 168 physical integer registers. For register renaming to work, you need more physical registers than logical registers because the logical registers need to be mapped to some physical registers, possibly multiple times (e.g. for speculation).
- pkaye 7y agoThose are the architectural registers. Physical registers also include those extra ones needed to implement register renaming to eliminate data dependencies. https://en.wikipedia.org/wiki/Register_renaming#Architectural_versus_physical_registers https://en.wikipedia.org/wiki/Register_renaming#Architectura...
- bogomipz 7y agoThanks, right I was confusing ISA level registers with those at the implementation/micro arch level. Cheers.
- Ericson2314 7y agoI fear the general difficulty of this means nothing will happen...until something really different happens. Let's get our programs in really high level languages in the meantime that will compile to wildly different architectures. I've compiled Haskell to CPUs and Haskell to FPGAs, but idioms don't overlap except for the most foundational libraries (Functor, Applicative, Monad). That's still great, but that's nowhere yet near "let me compile my CRUD app to my FPGA." More FRP for the CPU could change that, though. FPGAs can do self-rewriting circuits since they are programmable.
- Animats 7y agoLink leads to a login page.