8 ms·
A CPU is a compiler
- lionkor 4y agoThey both practically translate and optimize, so yeah, that makes sense.
- spyremeown 4y agoAny recommendations of books on compiler optimizations?
- nickcw 4y agoChip designers have noticed this similarity in the past have and attempted to push some of the work done by the CPU back into the compiler. Itanium and the Mill CPU both work(ed) like this I believe.
- MayeulC 4y agoYou can argue that it's the RISC approach, to some extent.
- terafo 4y agoMill CPU never existed in silicon, so there are questions to that. But IIRC Ivan said that they didn't do anything that compilers didn't do already for DPSs. He specifically mentioned that they don't want to be like Itanic.
- tormeh 4y agoThis will never work due to incentive structure, unless the compiler devs are working for the same company that makes the CPU. Otherwise, compiler devs will target a lowest common denominator and call it a day. And even if the compiler devs perfectly support new CPU instructions, compiler users usually want a single binary that can run on as many CPUs as possible, and so will use the lowest common denominator once again. Currently, your CPU will 99% of the time run basic AMD64 instructions, regardless of its capabilities. So Intel and AMD try to make their CPUs really good at running AMD64 code.
- avianes 4y ago> unless the compiler devs are working for the same company that makes the CPU Every CPU manufacturing company have a compile team. > This will never work VLIW processors do work, and for a while now. This type of architecture performs better for data-intensive workloads, so you don't see them in the general-purpose world. But if you are talking about Mill, yes it will never work.
- JonChesterfield 4y agoVLIW works _really_ well if you have deterministic memory timings, e.g. DSP/risc style architectures, and you're up for writing a complicated compiler.
- ahartmetz 4y ago> But if you are talking about Mill, yes it will never work. Maybe Mill Computing won't pull it off, but why do you think the approach is bad? It seems sufficiently different from Itanium to not have the exact same problems.
- marcosdumay 4y agoThey don't have a "deliver at all costs" philosophy and they are creating a new and different CPU architecture from scratch, a task where even teams oriented at delivering at all costs tend to almost always fail. The architecture itself looks very good. If it was built in a way similar to RISC-V, it would probably become very influential. (But then, I'm not sure you can create something that innovative by the same procedures RISC-V was created.)
- JonChesterfield 4y agoAll of them. And the compiler engineers try to push work into the CPU.
- lanstin 4y agoI used to enjoy the Mill CPU videos. Is there some good post-mortem explaining what happened to that project?
- ahartmetz 4y agoIt is reportedly still alive according to their website, but it's not very convincing.
- yencabulator 4y agohttps://millcomputing.com/topic/what-is-your-roadmap-for-2023/ https://millcomputing.com/topic/what-is-your-roadmap-for-202... https://millcomputing.com/topic/on-the-lack-of-progress-reports-from-the-mill-project/ https://millcomputing.com/topic/on-the-lack-of-progress-repo...
- nodemaker 4y agoCompilers all the way down!
- aaronrobert 4y agoInteresting point. CPU designers and compiler experts have worked almost the same way to optimize the execution performance.
- nobody0 4y agoand an interpreter
- mhh__ 4y agoIntel made a processor with a GC in hardware once
- moonchild 4y agoso did sun - https://web.archive.org/web/20061230133753im_/http://research.sun.com/techrep/2005/smli_tr-2005-143.pdf https://web.archive.org/web/20061230133753im_/http://researc... and david bacon (et al) - https://files.catbox.moe/bipg79.pdf https://files.catbox.moe/bipg79.pdf
- Gordonjcp 4y agoLinn (the hifi people, not the drum machine people) made a CPU called "Rekursiv" (because they like odd spelling like that) which had objects and GC implemented in hardware, on a couple of very large custom chips on VMEBus boards. These were horrendously expensive and were to be plugged into a Sun 3 box, making it all quite breathtakingly spendy. When Sun brought out their SPARC hardware the language they run was ported to that, and ran about four times faster clock-for-clock. You can gain some measure of the Rekursiv's success from the fact that the only complete machine known to still exist can be found on the bottom of the Forth and Clyde Canal, somewhere around the Possil Road Aqueduct.
- ethanwillis 4y agoIt's all just specific instances of the post correspondence problem!!
- PaulHoule 4y agoAn advanced interpreter has many features of a compiler. For instance there is the kind of simple interpreter that I know how to write off the top of my head which evaluates the nodes of an expression tree which is horribly inefficient. Then there is something like Python which "compiles" code to bytecode which is then interpreted by a "virtual machine". That kind of system admits very complex optimizations about as far you as can imagine, including compiling some of the bytecode all the way to machine code the way PyPy or the JVM does it. Note most interpretations of the Intel architectures break complex instructions up into RISC-like "micro-ops", which is a bit like bytecode interpretation. One of the biggest concerns in a modern CPU is that memory accesses are very slow relative to a CPU cycle so you want to be executing a large number of instructions at a time to hide the latency of memory access. Intel's failed Itanium had the compiler try to explicitly schedule this but it didn't work because the compiler can't know ahead of time (for general purpose code) what is in what level of the cache and what isn't -- and in a worse case scenario this can hang up not only one instruction but many other instructions that depend on the result of that instruction, ether because they really depend on the result or because the CPU gets hung up. The CPU, on the other hand, does know, and can be opportunistic about taking advantage of available parallelism.
- DeathArrow 4y ago> The CPU, on the other hand, does know, and can be opportunistic about taking advantage of available parallelism. Isn't Apple M1 much wider than x86?
- PaulHoule 4y agoLike ARM, there are many implementations of the x86. Intel has all the various "creeks" and "lakes", AMD has various implementations and there have been others like Cyrix. If there's a serious problem w/ the x86 architecture it's that the instructions are variable length from 1 to 14 bytes so if you wanted to build a decoder that fetches, say, 5 instructions at a time it would have to read 70 bytes. It has to run very quickly, ideally it doesn't consume a lot of power, so it is going to take up a lot of die area and if you want to make it wider still it is a challenge. Intel and AMD do really well despite this and the long instructions mean you can build all sorts of acceleration into the CPU which can make up for this (some of why the double-pumped AVX512 is effective on AMD's latest is that even when it s getting work down at AVX256 speeds at the core, it is wasting fewer resources dealing with instructions.)
- hardware2win 4y agoWriting compiler in normal, high levels langs is non trivial, I do wonder how this CPU code looks like
- pjmlp 4y agoDepends on what you pick. ML, Lisp, and Logic derived languages are all relatively easy. Hence why on my degree their were forbidden for compiler assignments, even though we had a strong ML and Prolog set of lectures in programming languages I and II, LP II. We were supposed to earn the compiler design assignment, from the professor´s point of view. Although the year I took it, it was about the time Java was being introduced, so doing it with Java, SableCC while not as easy wasn't that harder, specially following alongside the Tiger book.
- kazinator 4y agoWow, that is awful. For compiler writing, you should use a good language for that purpose, so that the hard parts of the program are the actual compilation algorithms, not debugging segfaults in a graph structure or whatever, or wasting time on electricity-and-running-water infrastructural code whose existence should be taken for granted. There is plenty of "cred" to be earned without that; you can still be pulling your hair out debugging a compiler written in Lisp, find years-old bugs in it and so on. I don't know anything else about your ex-prof other than what you have in the comment, but based on that, my Ouija board's planchette is edging toward "insufferable asshole". Mental note: be sure not to be that guy if you ever turn professor.
- pjmlp 4y agoUnfortunately universities are full of such folks. Our Physics III was even worse, it was one of those that was proud of hard it was to go through his final semester exam. Thankfully they tend to be a minority, I also met several that became an a good example of how teaching should be like.
- DeathArrow 4y agoEvery software is a compiler. It takes mouse clicks and keyboard presses and converts them into machine code.
- kaba0 4y agoNo, most software is existing machine code, your clicks only “navigate” inside its control flow. They never create any new code.
- mananaysiempre 4y agoThis is not terribly hard, though,—Forth implementations have long explored[1] the road from emiting a list of VM instructions (“token threading”) to emitting a list of VM instruction implementation entry points (“direct threading”, although “indirect threading” arguably fits this as well) to emitting a stream of call instructions targeting said entry points (“subroutine threading”) to copying the implementation bodies into the stream (“inline threading”). With sufficient dedication, you can even cut out the bodies from the binary the compiler of your high-level implementation language produced, to piggyback on its target support. Gforth[2] among others does this in the land of Forth, but the more well-known implementation is perhaps the dyngen code generator[3] used in Qemu before the switch to TCG in version 0.10. Generating machine code isn’t difficult, and neither is modifying a (low-level) bytecode generator to do it[4]. Generaring good machine code is difficult. [1] http://www.bradrodriguez.com/papers/moving1.htm http://www.bradrodriguez.com/papers/moving1.htm [2] https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Dynamic-Superinstructions.html https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Dyn... [3] https://gitlab.com/qemu-project/qemu/-/blob/v0.9.1/qemu-tech.texi#L289 https://gitlab.com/qemu-project/qemu/-/blob/v0.9.1/qemu-tech..., rendered as https://web.archive.org/web/20081120011949if_/http://bellard.org/qemu/qemu-tech.html#SEC9 https://web.archive.org/web/20081120011949if_/http://bellard... [4] https://github.com/EarlGray/c4/blob/master/JIT.md https://github.com/EarlGray/c4/blob/master/JIT.md
- titzer 4y agoNice comparison. I think register renaming is more like doing SSA renaming on a trace than register allocation, though.
- uticus 4y ago> Branch probability analysis | Branch prediction > Peephole optimisations, idioms | Idioms From the software side, what is it exactly that makes it so difficult to write a higher-level language that must be optimized, instead of a language that already exposes the optimizations in a friendly way? ("higher-level language" meaning c, not python or something)
- Pet_Ant 4y agoWell the low-level implementations differ from cpu-to-cpu. Even between Itanium releases the width changes. They don't want to get bound to a single implementation as techniques improve and new approaches are found. Otherwise, each time they discover something new they'd have to release a new ISA and backwards compatibility was the most commercially influential aspect of a chip. Now, it used to be that super-computer were made with custom chips, with custom ISAs, but the advantage of mass consumer parts is too high. So in general the decoupling of implementation and programming language allows for enough wiggle room to allow independent evolution without being rigidly coupled.
- avianes 4y agoNot sure what is exactly your thought, since the optimizations you quote don't really takes advantage of any exposed optimization feature of the language. Are your asking why we could not expose optimization feature (e.g. branch hint to replace branch-prediction) in the programming language ? Are you asking if it's difficult for a compiler to optimize some type of high-level languages ? Since "higher-level" language is C in your question, what the "language that already exposes the optimizations in a friendly way" ? Are you thinking the CPU µop as a language ?
- JonChesterfield 4y agoThe literal answer is that compilers are really easy to write when the source and destination language are the same and you don't want any optimisation. E.g. write the x64 machine code out as raw bytes and cat is good enough to turn it into x64 machine code. Difficulty increases as the source and target languages become less similar, as more ambitious performance optimisations are attempted, as more comprehensive type/lint/warning style systems are implemented and as performance constraints on the compiler itself tighten. So a compiler that takes imprecise scribblings, spots errors in them, and emits asymptotically perfect machine code for heterogenous distributed systems in real time is quite dramatically more complicated than cat.
- uticus 4y agoDomain was previously elrond.net (redirects to outerproduct.net). Previous submission to HN is a jewel: "Why no one should use AT&T syntax ever, for any reason, under any circumstances" https://news.ycombinator.com/item?id=26122532 https://news.ycombinator.com/item?id=26122532
- pjmlp 4y agoWhen down that route once, about 20 years ago, never again.
- AnimalMuppet 4y agoA jewel? Um... I'd call it a rant, myself. Not even a very well-grounded rant.
- mshockwave 4y agosame...I feel weird because I learned AT&T syntax since day 1. And even with that, I think Intel syntax is just another way of writing, period. No hard feeling at all. Don't quite understand why the author is so...pissed.
- gandalfgeek 4y agoIf you remember the Transmeta chips from the early 2000s they literally were compilers. Took in x86 binaries but JITed them to an internal RISC instruction set.
- vardump 4y agoI think that's how pretty much all of the high-performance desktop & server CPUs operate now.
- Pet_Ant 4y agoWas it even possible to write Transmeta-native code?
- mschaef 4y agoAt least if you were Transmeta. Not sure they ever made the ability publicly available. That would've been fairly contrary to their core message.
- wzdd 4y agoThe x86-to-vliw transformation was implemented in software. See https://en.wikipedia.org/wiki/Transmeta https://en.wikipedia.org/wiki/Transmeta under "code morphing software". Similar to Rosetta.
- HALtheWise 4y agoNvidia's Denver ARM CPUs do the same thing
- CalChris 4y agoWritten by pretty much the same people.
- susam 4y agoIf we are okay to admit that CPU is a compiler (or an interpreter), can I say that self-printing machine code like https://susam.net/blog/self-printing-machine-code.html https://susam.net/blog/self-printing-machine-code.html is a CPU quine?
- nayuki 4y agoI can't recall the quote or source, but it went something like: A CPU is a compiler that transforms a serial instruction stream to a wide (acyclic) graph of data dependencies. This refers to concepts like out-of-order execution, superscalar processing, functional unit scheduling, and register renaming.
- mmphosis 4y agoOn the surface a "modern" x86 is an interpreter/compiler. Why can't we jit/compile directly to quecto code?
- alfor 4y agoThe merging of both compiler (cpu and software) is the main reason of the success of Nvidia. Make the chip simpler and more parallel (way more cores) Make the compiler smarter to better use the capabilities of the hardware. Watching Jim Keller interview made me realise how much transistors are wasted because the cpu is trying to predict what the code is going to do. There is an insane amount of complexity in chips trying to make single threaded code fast when what need the most cpu time in our code is usually parallels problem. Maybe Triton will break that paradigm and will allow diverse parallels hardware to emerge and be used effectively.
- bippingchip 4y agoBut don't underestimate how much 'middleware' there is in Cuda/CuDNN, NCCL etc. A lot of it is not in the compiler, but much more in hand crafted, carefully optimised libraries. As an example: there are so many low level ways to run a conv2D kernel on a SIMT machine, but CuDNN will pick the best option for you based on the card you have, and the tensor sizes you are using.
- bhawks 4y agoThe failure of the Itanium highlights the danger of tilting too much complexity into the software / compiler space. It was very difficult to make a compiler which could generate parallelizable machine code and that lead to very disappointing performance for most software.
- pjmlp 4y agoIt only failed, because of AMD being allowed to come up with AMD64. If x86 was Intel only, Itanium would have been eventually pushed everywhere no matter what.
- mhh__ 4y agoThis is kind of gibberish IMO. A nice introduction to some similarities but the details and constraints are quite different. Transmeta however...
- JoeAltmaier 4y agoI'm not sure where in that article the re-write-microcode feature lies? That is, modern CPUs can write microcode for instruction sequences, not just single opcodes. Which is almost exactly what a compiler is, if you substitute 'op code sequence' for 'source code sequence'.
- uconnectlol 4y ago... unfortunately.