11 ms·
To reinvent the processor (2019)
- keepquestioning 4y agoWe will need to reinvent the processor to accomplish the goal of AGI.
- JonChesterfield 4y agoThat seems unlikely, at least assuming AGI is a computable function. What limitations in current processors look blocking to you?
- zupa-hu 4y agoSpeed might well be one.
- AnimalMuppet 4y agoIf it can be computed, it can be computed slowly. (Of course, if we have to make N iterations to get at a working design, and N is really large, then speed would make a massive difference as to when we get there...)
- keepquestioning 4y agoAnalog CPUs.
- freemint 4y agoAnalog CPUs are a horrible idea. You do not want security checks to be analog. Analog accelerators are great idea. The analog world is where security goes to cry and die. Just think of RowHanmer
- throwaway14356 4y agoautonomousnanobots
- javajosh 4y agoI feel bad that I really don't understand any of this. My mental model of what a CPU does stops at the assembly level, and intuitively feels like (and looks like) doing some convolution on an image - e.g. a local, nodal point moving through a bitmap, leaving behind the wake of some set of operations, a smear, with some of that smear propagating forward. But now I realize that all of these models are a middling-high level picture of a CPU's side effect, not it's operation - the manner in which it combines it's operands is, effectively, voodoo. But voodoo with which I am comfortable, for reasons involving NAND gates and Alan Turing, but I wonder: should I be so comfortable?
- silisili 4y agoVery, very few people understand what a CPU truly does. We all have differing understandings, yours probably about like mine, if not better. Once you feel you understand perfectly how it works, Keller comes along and says that you can run the same program 100 times, and it'll never execute the same way twice. Anymore, I just treat it like a black box I'm glad to not have to bargain with.
- moffkalast 4y agoALU, I've come to bargain! ALU, I've come to bargain! ...
- magicalhippo 4y agoI found NandGame[1] to really help illustrate just how a simple CPU operates. The bottom-up approach was great at demystifying the various sub-units and how they come together to form a CPU. Of course, modern CPUs are incredibly more complex, but most appear to function like a really fast, simple CPU. [1]: https://www.nandgame.com/ https://www.nandgame.com/
- bear8642 4y agoThis and Nand2tetris course both excellent resources
- 4y ago
- gbrown_ 4y agoPrevious discussion https://news.ycombinator.com/item?id=19885901 https://news.ycombinator.com/item?id=19885901
- deleted 4y ago[deleted]
- Quequau 4y agoSo I guess "The Mill" processor isn't really being worked on any more?
- rbanffy 4y agoI wouldn’t be surprised. It’s a very ambitious goal to do on someone’s own. It’s not a monumental task: it’s a directed graph of interdependent monumental tasks, each needing to be perfectly executed. My bet is that they’ll end with a sizeable number of patents, at least.
- Quequau 4y agoSo I suppose that end game is those patents getting bought by some big name semi manufacturer and quietly incorporated into future chips using different terminology... and then folks will smugly talk about what a terrible idea it all was.
- Findecanor 4y agoI believe they are just being quiet. Their series of talks is over. In December front-man Ivan Godard wrote [1] on their forum that they are holding off on twenty-something patents so as not to "start the clock" on them. And they can't talk about anything on the forum that is not yet filed. [1]: <https://millcomputing.com/topic/project-still-alive/ https://millcomputing.com/topic/project-still-alive/>
- baking 4y ago
- 082349872349872 4y agoSo, at a SW level the equivalent to HW's "no single static scheduling works in the face of $ misses" is "no single static scheduling works in the face of blocked IO"[0], and the practical solution for the latter has proven to involve (instead of forcing the kernel to be sufficiently smart about processes' access patterns) exposing nonblocking IO to userland, why not allow the ISA to query[1] if an L1 access is currently viable (enabling dispatch to different static schedules)? [0] on a tangent: is the fact that modern cloud development uses copious amounts of Terraform et.al., explaining what is hooked up where[2], just an epiphenomenon of Conway's law? Or is there something more fundamental driving this particular pendulum swing? [1] sure, there may have been security concerns before, but now doesn't the Spectre family imply that adversaries can exploit the $ state anyway? [2] resembling nothing so much as text file versions of the "system diagrams" people used to draw in the 1960's with green plastic stencils: https://americanhistory.si.edu/sites/default/files/ogmt_admin/image_upload/header_AHB2012q05401.jpg https://americanhistory.si.edu/sites/default/files/ogmt_admi... Or would JCL cards be a closer analogy?
- JonChesterfield 4y ago> why not allow the ISA to query[1] if an L1 access is currently viable Well that's interesting. Query/branch on whether some address is presently in a given cache line, with more fun if one can test whether whether that line is exclusive/shared etc. The hardware definitely knows that, though the information may be stale immediately after providing it. Selling that to the hardware guys would mean finding a compelling use case. I expect modifying the cache coherency implementation is done reluctantly. I can't think of one where whether a single line is resident is worth branching on, and querying whether N are present doesn't really fit the ISA model. Further up the stack though, whether a given page is currently in memory (as opposed to swapped out) is a similar sort of thing, where one might want to prefetch it while doing other work. That might not be worth a syscall though. So I love the suggestion but can't see the return on the silicon investment.
- 082349872349872 4y agoNot sure if the cache coherency model would need to be changed: I had been thinking of an OP like "LOAD dest, address, flag", where either dest would be loaded from address from L1, or would be set to an arbitrary value on miss (with flag being set to indicate which happened). https://www.kernel.org/doc/Documentation/vm/pagemap.txt https://www.kernel.org/doc/Documentation/vm/pagemap.txt ?
- still_grokking 4y agoReinvent? Without any substantial improvement? A truly "reinvented" CPU would use a reconfigurable coarse grained data flow approach, directly available to the programmer, instead of "yet another command stream based von Neumann machine", imho. (Actually something that is in parts already at the heart of modern CPUs; only that nothing of that is available directly to the programmer, where it would be actually useful, which is utter nonsense of course; and that it's not reconfigurable; the compiler can't construct pipelines on the fly; not even the hardware build-in JIT, which can be found in every modern CPU, which tries to translate that misfortunate command stream into a data-flow graph inside the CPU as good as it can—of course after we deleted all information about that data-flow that we collected during compilation—can't do that ;-). Makes sense? No? Doesn't matter. Current CPUs work like that. Because we just "can't" fix our software! Thank you, C/C++). Only switching from command-stream to data-flow could overcome the von Neumann bottleneck. Also only by such a switch asynchronous clockless designs would be feasible (which are the only way to overcome the power-wall in the long run). "Fun" thing is that to some extend such data-flow hardware is available today. Because it's the only kind of hardware that scales into dimensions where truly powerful AI applications are possible. Only that almost nobody thinks about how to make this kind of almost maximally efficient hardware applicable to general purpose computations. But that would be in fact trivially simple: Just rewrite the world in some new kind of data-flow language (which needs to get invented first, of course). Ah, and when we're at it, don't forget to use balanced ternary for your new kind of computer—as this is the most efficient and beautiful system for computing hardware.
- le-mark 4y agoThis reads like a hand wavy reference to some sort of programmable systolic array thing. A current example in this vein is googles TPU ai accelerators. Note they get drastic increase in performance by drastically limiting precision (read small values and registers, a specific computation requiring limited operations) hence massive reduction in transistors per computational element. Ok fine; but for statefull calculations that need to load and or store information per compuatational element it’s not the win one might think. Specifically memory bandwidth can be the limitation. In these cases modern GPUs are really really hard to beat.
- phkahler 4y ago>> I’m tired of the dominance of the out-of-order processor. They are large and wasteful, the ever-popular x86 is especially poor, and they are hard to understand. Their voodoo would be more appreciated if they pushed better at the limits of computation, but it’s obvious that the problems people solve have a latent inaccessible parallelism far in excess of what an out-of-order core can extract. One thing I find interesting is the recent focus on branch predictors. OoO designs like Zen and *Lake have been seeing performance improvements due to better branch prediction (and going back, things like trace cache) which strongly suggests that flow control is very important and therefore, data-parallel code is not the majority. There is no architecture that optimally fits "general purpose computing" so we have OoO, Vector instructions, Hyper Threading, Multi-core, GPUs, and TPUs. My hope is that GPU/TPU/ML will converge on something that is very good at all 3. But maybe my hope there is due to my lack of hands-on with those.
- touisteur 4y agoWhat I'm seeing right now (my feeling about new silicon) is numerous simple cores with varied memory access patterns (stream processing, large scratchpad, systolic things, message passing over crazy fabrics...) and little to no silicium dedicated to handling complex data access patterns or complex control flow. The main motivation seems to be 'easy to tape out in one go' which is great in a sense (you get new hw faster & cheaper, with far less risk). We're seeing exploration on how to break even the gpu model's upcoming limits. Sparse algebra, taskgraph/dataflow oriented prepared or JITed pipelines, and lots of work expected from the compiler and the developer. Even the tensor or rt on nvidia gpus are strange specialized beasts there, difficult to use, especially in generic ways. Seems like a decade of niche optimisation work on dozens of new architectures is coming...