10 ms·
Microsoft ports Windows 10, Linux to homegrown “E2” CPU design
- PeCaN 8y agoI like that this architecture tackles a large problem in existing architectures, which Mike Pall put rather nicely: > All modern and advanced compilers convert source code through various stages and representation into an internal data-flow representation, usually a variant of SSA. The compiler backend converts that back to an imperative representation, i.e. machine code. That entails many complicated transforms e.g. register allocation, instruction selection, instruction scheduling and so on. Lots of heuristics are used to tame their NP-complete nature. That implies missing some optimization opportunities, of course. > OTOH a modern CPU uses super-scalar and out-of-order execution. So the first thing it has to do, is to perform data-flow analysis on the machine code to turn that back into an (implicit) data-flow representation! Otherwise the CPU cannot analyze the dependencies between instructions. > Sounds wasteful? Oh, yes, it is. Mainly due to the impedance loss between the various stages, representations and abstractions. https://www.freelists.org/post/luajit/Ramblings-on-languages-and-architectures-was-Re-any-benefit-to-throwing-off-lua51-constraints https://www.freelists.org/post/luajit/Ramblings-on-languages...
- tinus_hn 8y agoThe obvious answer is to completely to the instructions the cpu uses internally. That would mean recompiling for every cpu revision though.
- therein 8y agoI have a feeling where they were going with that was to push the internal data-flow representation to the CPU and have it figure out the register allocation, instruction selection and scheduling etc. right before execution.
- warkdarrior 8y agoItanium 2.0?
- caf 8y agoIt's not exactly clear what you mean by that comment, but this is almost the polar opposite of the Itanium approach, which was to push the low-level execution unit scheduling right up the stack to the compiler.
- zokier 8y agoYeah, it was "obvious" to Intel too when they made Itanium. And the rest is history. > the "Itanium" approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write - Donald Knuth, source: http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856
- kllrnohj 8y agoNo, because the CPU has information the compiler doesn't. The compiler throws away useful information while it compiles, yes, but the CPU gets new information at runtime which the compiler doesn't have.
- petecox 8y agoWasn't that the idea behind Transmeta - to JIT x86 operations in response to runtime feedback?
- rwmj 8y agoIt was the idea behind HP Dynamo. There's a good article here spoiled by the bitrotted formatting: http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1.html http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1.... It looks better if you use Firefox Reader view.
- kllrnohj 8y agoNvidia's Project Denver also attempted something similar. It shipped in the form of the HTC Nexus 9, but it wasn't any faster than the competition in benchmarks (where you'd expect a JIT to shine). In the real world it's even worse because JITs are not good for responsiveness, particularly JITs that are not scheduled by the kernel and are unable to be scheduled behind important work. The CPU just randomly stopped running code to run a JIT instead. But I was more just talking about things like branch predictors. You can be informed by runtime data without being a full on JIT, which is the world very nearly every modern CPU lives in these days.
- zik 8y agoThat approach has (sort of) been tried before for superscalar architectures. VLIW architectures were the Next Big Thing in the early 1990s. The general idea is that the machine code explicitly told the CPU what to do with each of its execution units. It seems like a good idea. Intel released their i860 processor and waited for the cash to roll in. The trouble was that because the machine code is pretty specific to the internal structure of the CPU every time they released a new major revision of the CPU the existing executables all had to be recompiled. All of their customers needed to get an entirely new OS, new third party software, they had to recompile all their own code, everything. This proved too much of a burden for many and popularity of the architecture suffered. The other problem of these kinds of architectures is that they're quite inefficient at encoding code with lacks inherent parallelism. The instructions are long and most of them have to be NOPs if most of the execution units are idle - which is a lot of the time. This code bloat in turn wastes memory bandwidth and instruction cache space, making them overall not as efficient at using precious cache space as architectures with more compact instructions.
- gm-conspiracy 8y agoKind of interesting to thing of the CPU as just another peripheral.
- ksec 8y agoThat was in the 90s though. We haven't had much "design" in CPU for 5 years. We are stuck with 4-5Ghz max, IPC seems to have its limit. And now we ran into security issues with too much clever hardware optimisation. And it seems recompiling is relatively easy enough for servers? Where everything are in controlled environment?
- cityhomesteader 8y agoThat introduces portability and cpu update issues. One of the reasons for high level languages and the trends in virtual machine/runtimes ( JVM, .Net ) is to decouple the hardware and the software to increase portability and stability and of course productivity. It's a tremendous logical gain in exchange for some physical performance loss. The trends have been clear for the past few decades. I don't the the pendulum swinging in the other direction any time soon.
- still_grokking 8y agoNo, it wouldn't mean recompiling for every CPU revision. Today's CPUs contains a kind of JIT compiler implemented in hardware. There is no reason why this JIT compiler couldn't be implemented in Software. A lot of business-software runs already in some kind of VM, with a JIT compiler. This JIT compilers could easily spit out the hardware depended low-level code instead of e.g. x64 ASM. So a new hardware revision would only require an update to the runtime's JIT compiler. I think IBM is doing something similar for decades now with their mainframes. "Native" executable are "only" some byte-code so you don't ever need to recompile your applications when you upgrade the hardware.
- gmueckl 8y agoCompiler hints for data dependencies between groups of instructions sounds very much like the mistake that sank the Itanium. What is different this time around?
- wmf 8y agoIn VLIW like Itanium, the compiler had to determine not only instruction dependencies but it had to fully schedule when each instruction would execute, even though critical information like cache access time cannot be known by the compiler. In EDGE architectures the processor still does dynamic "out of order" instruction scheduling which gives much better performance.
- twoodfin 8y agoI haven’t read the relevant papers, but I imagine they were targeting something that presented more like a fine-grained MIMD and less like VLIW. That is, many tiny cores with independent execution pipelines, not a few large cores with very wide paths of functional units.
- PeCaN 8y agoThat wasn't a mistake, and Itanium did just fine. Circa 2008 the fastest database servers in the world ran on Itanium.
- _ph_ 8y agoIndeed, and it would be interesting to see how the most recent Itanium would perform if it would be ported to the current 14nm process instead of 32nm. While it once was considered to be a monster chip in transistor count , it no longer is.
- cptskippy 8y agoDidn't Itanium suffer from the same issues as the Netburst architecture?
- 8y ago
- TimTheTinker 8y agoJust in case you missed it, there's an update at the bottom to the effect that work on E2 has wound down and there aren't any plans to turn it into a product: > After publication, a spokeswoman for Microsoft got back to us with some extra details. "E2 is currently a research project, and there are currently no plans to productize it," she said. > "E2 has been a research project where we did a bunch of engineering to understand whether this type of architecture could actually run a real stack, and we have wound down the Qualcomm partnership since the research questions have been answered." > As for the missing webpage, she added: "Given much of the research work has wound down, we decided to take down the web page to minimize assumptions that this research would be in conflict with our existing silicon partners. > "We expect to be able to incorporate learnings from the work into our ongoing research."
- ChicagoDave 8y agoThey don’t want to scare the piss out of their current silicon partners. Who knows what will come of this, but I’m doubtful it’s nothing.
- chx 8y agoSort of blackmail what comes out of this. You can say to Intel, if you don't give us a nice enough discount for the current order of 100 000 Xeons for Azure, we will go back to these plans and eventually your revenue stream will dry up.
- mankash666 8y agoWhile that may be true for something that's more production ready (like an AMD or Qualcomm chip), this project seems unlikely to affect negotiations. However, it's likely to cause panic at Intel for the long term. It may prompt Intel to move into Microsoft's territory, or partner more closely with competing OS vendors (chrome?)
- dmitrygr 8y agoSounds a lot like...the Itanic
- legulere 8y agoOne big problem with the Itanic was that the compilers weren't (yet) smart enough to produce good code for it. This does not seem that much of a problem here, as it seems pretty close to how compilers keep immediate representation anyway.
- ultimoo 8y ago> E2 uses an instruction set architecture known as explicit data graph execution, aka EDGE which isn't to be confused with Microsoft's Edge browser. I chuckled at this one.
- toasterlovin 8y agoLet us give thanks that Ballmer is no longer around. He woulda made sure it was named Windows.
- cptskippy 8y agoOr .NET
- deleted 8y ago[deleted]
- paulgdp 8y agoHow similar is this architecture to the Mill? https://en.wikipedia.org/wiki/Mill_architecture https://en.wikipedia.org/wiki/Mill_architecture
- Symmetry 8y agoIt's unrelated except to the extent that both are communicating the dependency chain to the processor through the ISA in a way other than sequential order.
- solomatov 8y agoThis system seems to be the same as VLIW: https://en.wikipedia.org/wiki/Very_long_instruction_word https://en.wikipedia.org/wiki/Very_long_instruction_word
- Symmetry 8y agoLike VLIW there's a notion of explicit parallelism but unlike VLIW there isn't a strict prescribed order of execution.
- _chris_ 8y agoVLIW compilers construct a "bundle" of instructions which are to be executed simultaneously, and thus must be completely independent of each other. The VLIW compiler must further space "bundles" apart such that any use-bubbles are respected (i.e., a load won't be ready for 3 cycles, etc.). EDGE compilers construct "blocks", each made up of many instructions which are tightly connected, and send the block to an execution cluster which will dynamically schedule each instruction within the block as it sees fit. Communication of dependencies across blocks is more expensive. Hopefully there is enough parallelism across blocks that you can execute multiple blocks simultaneously, in addition to ILP within the block itself.
- solomatov 8y agoThat's really good news. We need more progress in CPU design.
- Symmetry 8y agoHere's the Wikiepdia page on EDGE: https://en.wikipedia.org/wiki/Explicit_data_graph_execution https://en.wikipedia.org/wiki/Explicit_data_graph_execution This seems to be a fairly close descendant of the older dataflow designs that also inspired out of order computing. The problem with dataflow processors, as I understand it, was that the fact that they weren't pretending to execute instructions in order meant that they didn't provide for the precise exceptions you need for memory protection, multiplexing across threads, etc. Is there a standard EDGE solution to that?
- adrianratnapala 8y agoWhat is interesting is that the new breed if timing attacks show that the the pretense of ordering isn't as tight as we had imagined. So maybe we might once gain prefer processors like this because the software is going to have to deal with that complexity anyway.
- deepnotderp 8y agoNot that I know of, one of the THE problems with TRIPS/EDGE was the imprecise exceptions.
- andreiw 8y agoOn a related note, another interesting CPU design - http://multiclet.com/index.php/en/support/general-technical-information http://multiclet.com/index.php/en/support/general-technical-...
- Digital-Citizen 8y agoSo Microsoft is highlighting the value of software freedom and the harm of software non-freedom: we're all granted permission to port free software (as Microsoft claims to have done with the Linux kernel, BusyBox, and more) but only Microsoft -- the proprietor -- is allowed to port Windows. So long as we value software freedom we can take steps to defend software freedom and continue to see practical gains. But proprietary software leads us to a dead-end waiting for a willing proprietor to do something for us (and thus providing a result we cannot trust).
- TimTheTinker 8y agoI see this proprietary/free duality as a fundamental weakness of copyright law and intellectual-property-based business models. As things currently stand, software that provides the most value to society also often happens to make the least money (and vice versa). To truly prosper, I wonder if society will somehow have to move beyond copyrights, patents, and intellectual property rights as they currently exist. I’m not sure what the solution is, but a recent HN post caught my attention — it was about how quickly Germany caught up to England’s industrialization in the 19th century when books weren’t copyrightable. This may provide a clue. [1] [1] https://news.ycombinator.com/item?id=17329345 https://news.ycombinator.com/item?id=17329345
- jankotek 8y agoMicrosoft is pretty open compared to competitors. It has long history of providing Windows source code to universities (I recall Win2000). It also provides debug symbols for its libraries. Try to get source code for Apple, Amazon or Google products...
- scruffyherder 8y agoLike Darwin source code? Granted they don't make it very easy to run, but it can be done with a HELL of a lot of effort.
- bch 8y agoI’m not a hardware expert, so I’m not sure how interesting this is here, but along the lines of MS architectures and FOSS operating systems, see also their work w eMIPS and NetBSD[0] [0] https://blog.netbsd.org/tnf/entry/support_for_microsoft_emips_extensible https://blog.netbsd.org/tnf/entry/support_for_microsoft_emip...
- fulafel 8y agoThis is written in a baby-talk style but scroll to the end, there are links to research publications.
- zaarn 8y agoPeople interested in VLIW (or EDGE, which sounds like VLIW but less strict) should also checkout the Mill architecture. The designers claim a 10x speedup compared to existing processors. Their presentations are online on youtube, esp. the security related ones are amazing since they throw away alot of current design in x86/ARM CPUs.
- ahartmetz 8y agoThey claim a 10x power / performance advantage actually, what I gather is that it's supposed to be higher performance at much lower power. It isn't out of order and so it has to wait a long time in case of last-level cache misses. But it has insane throughput when it doesn't have to wait for memory. Most likely they'll mitigate the waiting problem by hyperthreading. GPUs do extreme hyperthreading to stay busy without any kind of out-of-order execution.
- deepnotderp 8y agoTo be fair, they've addressed memory access issues, and have proposed "deferred loads" (works well: http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf) and other thus far unnamed techniques for mitigating it.