9 ms·
Linus Torvalds says RISC-V will make the same mistakes as Arm and x86
- __s 2y agoBad headline, he prefaces the statement with "I fear", `says` could've been written `fears` It's realistic to expect RISC-V's execution won't be (& hasn't been) flawless The context is re spectre
- brudgers 2y agoTorvalds has experiences of sufficient breadth and depth such that it is not unreasonable to take his concerns about reconciling hardware and software as being the concerns of an expert. And of course these days Torvalds tends to be more tactful in his criticisms than when he was younger.
- ksec 2y agoExactly this. A lot of people forgot or didn't know he used to work in CPU hardware ( Transmeta ) too. >And of course these days Torvalds tends to be more tactful in his criticisms than when he was younger. And that is why he has been very careful about RUST and RISC-V. And just on the parents notes, > It's realistic to expect RISC-V's execution won't be (& hasn't been) flawless Except most of the RISC-V supporter has been claiming every RISC-V execution are flawless.
- brucehoult 2y ago> Except most of the RISC-V supporter has been claiming every RISC-V execution are flawless. No-nothings, perhaps. RISC-V cores are being designed by probably a couple of dozen companies, and chips made by many more (SiFive for example has 100+ customers for their cores). All of them have a list of more or less serious errata, just like every Arm and x86 chip. The strength is in the diversity, in the freedom to experiment and innovate, in the shared software ecosystem, in the security of knowing that if your chip vendor goes out of business for any reason (bankruptcy, change of plans, being acquired...) there will always be another vendor you can turn to. Unlike the people who were depending on Itanium, DEC Alpha, Motorola 68000, z80 and dozens of others.
- bitwize 2y agoThis. I keep hearing from Amiga people how the Amiga "coulda been a contenda" in this day and age of computing if only Commodore weren't so mismanaged. If only Commodore hadn't bought Amiga Inc. in the first place and the brilliant, revolutionary Jay Miner were allowed to market his designs on his own terms without being beholden to some evil corporate overlord who wanted to squeeze them for profit. If only. If only. But it was clear, from the late 1980s, that the PC was going to win because it was not under the control of a single corporation. Indeed, it was winning despite IBM beginning to fumble the ball. All corporations, in the long run, tend toward mismanagement that can totally sink a platform if it's under their control. It happened to Commodore, Atari, Symbolics, SGI, it almost happened to Apple in the 90s, and it looks like it might happen to Raspberry Pi in the near future. But when there's an open standard on which companies can compete even as they interoperate, the platform thrives, and things unimaginable to its originators can be built upon it. RISC-V brings this quality to the chip architecture and ISA, the same way Linux brought it to operating systems and the combination of x86, ISA/PCI bus, and BIOS/UEFI interface brought it to the general system design. It's not perfect, and no implementation of it is going to be perfect, but RISC-V really is gonna change everything.
- brucehoult 2y agoI regret I have only one upvote to give.
- throw0101c 2y ago> The strength is in the diversity, in the freedom to experiment and innovate, in the shared software ecosystem Does RISC-V have a standardized device discovery mechanism? One critique of ARM (?) I've heard is that for every maker of chips one has to basically re-invent the wheel on bus discover and then on-bus device discovery.
- 15155 2y agoDevice tree seems to be standard fare, just like ARM.
- Vinnl 2y agoI haven't read anything, but if he said "I fear that" rather than "I think that", that's the difference between cautioning against and predicting. The headline makes it seem like he was predicting.
- fooblaster 2y agoLinus continues to be wrong about CPU hardware now, just as he was back then. See for example in the past his continued insistence that ISA does not matter at all for performance. One need only look at the huge single threaded performance and efficiency of apple M cores (10 wide instruction fetch) relative any x86 to to see that that statement is not true. I don't think I would take his hardware assertions as gospel.
- yjftsjthsd-h 2y ago> See for example in the past his continued insistence that ISA does not matter at all for performance. One need only look at the huge single threaded performance and efficiency of apple M cores (10 wide instruction fetch) relative any x86 to to see that that statement is not true. Your argument is that ISA impacts performance... and your example is ARM, which went from worse performance than x86 across the board to having an implementation that sometimes beats x86 because one company made a better implementation than everyone else? That seems like a great example showing that ISAs aren't the primary factor in performance.
- fooblaster 2y agoApples chips utterly dominate in performance per watt versus x86. Arm64s simple fixed length instruction set is absolutely central in this. Qualcomm now exceeding Intel in their mobile chips is further evidence ISA is critically important. In the data center this is also happening with graviton 4 and eventually grace hopper. Anyway, my point isn't that implementation does not effect performance. Of course it does. My point was that Linus has asserted ISA is irrelevant to performance, and that only implementation matters. That assertion does not hold up.
- snvzz 2y ago>Arm64s simple fixed length instruction set is absolutely central in this. Note that doing variable instruction length is not an issue per-se as proven by more dense, yet still easy to decode RISC-V. The way x86 does it, however, is very costly to decode and overall awful.
- monocasa 2y agoI'm not sure he's talking about the cores themselves. What's more likely IMO is the ecosystem choices like preboot environment.
- colinstone 2y agoNone of Torvalds direct quotes use the word fear at all Torvalds is quoted as saying “I suspect…” The article author qualified such with the use of “fear” We need a quiz before comments are posted; did you read the article? And ask for written context about a random segment.
- __s 2y agoI watched the whole discussion https://m.youtube.com/watch?v=cPvRIWXNgaM&t=450 https://m.youtube.com/watch?v=cPvRIWXNgaM&t=450 > My fear is that... Get off my lawn
- ChrisArchitect 2y agoSource video/interview: https://news.ycombinator.com/item?id=40944164 https://news.ycombinator.com/item?id=40944164
- RecycledEle 2y agoCan someone please create an instruction set where the entire instruction set is implemented (even if in microcode) on every processor that uses that instruction set? Have you looked at RISC-V or x64? They are messes of instruction set extensions, most of which reuse the same opcodes. We have terabytes of disk space and gigabytes of RAM. We can afford a few extra bits in the opcode.
- nullc 2y agoIs that really valuable? Stuff like clz implemented as slow emulation is arguably worse than useless because the application specific fallback can easily be faster than the emulation of the generic opcode. If the operation is slow you still have to have detection and fallback. Unless you don't care about the performance, in which case you could just never use the fancy instruction at all.
- dzaima 2y agoAs a more modern example, pdep & pext (BMI2) on Zen 2 and Zen 3 are extremely slow, even though they're technically supported. Thus any code wanting to actually use those for anything is essentially required to add a "But actually! If I'm running on Zen 2/3, pretend pdep/pext do not exist". If you want every CPU to support every instruction without caring about perf, you could just have the OS emulate it on hitting illegal-instruction; perf isn't gonna be that different given that nothing would be using any of the potentially-slow instructions anyway and the ISA might as well not even have it in the first place. It just solves absolutely nothing to technically support everything.
- radford-neal 2y ago"If you want every CPU to support every instruction..," That does indeed seem nice. As long as there's an easy way to enquire about whether an instruction is slow or not, it means that all the software runs, and the software that knows about issues with some instructions runs as fast as it would without support for those instructions. The only downside is the effort put into writing emulations of the instructions, which seems small in context.
- sylware 2y ago[dead]
- llm_trw 2y agoOne thing that I learned when becoming a senior engineer is that if the layer above you is profitable enough you should build substandard implementations in your layer that match the abstractions of the above layer. Overall the system will perform much better than if you optimize for whatever the bottleneck on your layer is.
- AndrewOMartin 2y agoThere sounds like a decent amount of insight here, but it's a little vague for me. Could you give a bit more detail, possibly a worked example?
- vanjajaja1 2y agoapple added hw instructions to m1 chips just for the obj c reference counting use case. claimed up to 15% boost. technically this is a violation of separation of concerns, but if it delivers results then it delivers results
- afiori 2y agoIf those instruction act like a macro that is faster than the expanded instructions then it is not really a just a tradeoff. If the instruction were to have some magical one-off effect it would be a violation.
- llm_trw 2y agoSure. Assume you're writing an OS from scratch that will be used by people, rather than by servers in a data center. Building the system to be as responsive as possible at the lowest possible latency is what you should do. Even if you're burning half your CPU cycles on busy work waiting for user input. Ignore how much more throughput you could have with a traditional OS. Users get a lot less annoyed by a job that takes 20 minutes instead of 10 than by a window which takes 3 seconds to resize. This goes against every instinct that engineers have, because you're not optimizing for the scarce resource on your layer - cpu cycles above. The way I got around that brain damage was to find what metric matters to the ultimate user and trace it back to the layers I had control over, then optimize the hell out of it.
- olalonde 2y agoWhich mistakes is he referring to concretely?
- incomingpain 2y agoNot exactly nostradamus to predict things wont go perfectly. But that's the thing about history, it gives you a chance not to make the same mistakes. Will RISCV have learnt history?
- rany_ 2y ago> RISC-V is an open-standard ISA for processors that is slowly gaining traction, especially in China, where some tech companies are using it to bypass America’s sanctions on the country. I really don't like that narrative, it doesn't even make sense as MIPS already exists and is more than sufficient for the applications RISC-V is being used in. The same could be said about Linux but it's obvious how ridiculous it would be to bring that up.
- throw0101c 2y ago>> […] where some tech companies are using it to bypass America’s sanctions on the country. > I really don't like that narrative, it doesn't even make sense as MIPS already exists and is more than sufficient for the applications RISC-V is being used in. Is it a "narrative" if some Chinese tech companies are actually using it for such a purpose? And even MIPS-the-company is moving to RISC-V: > Computer architecture courses in universities and technical schools often study the MIPS architecture.[9] The architecture greatly influenced later RISC architectures such as Alpha. In March 2021, MIPS announced that the development of the MIPS architecture had ended as the company is making the transition to RISC-V.[10] * https://en.wikipedia.org/wiki/MIPS_architecture https://en.wikipedia.org/wiki/MIPS_architecture > In May 2022, MIPS previewed its first RISC-V CPU IP cores, the eVocore P8700 and I8500 multiprocessors.[9] In December 2022, MIPS announced availability of the P8700.[10] * https://en.wikipedia.org/wiki/MIPS_Technologies https://en.wikipedia.org/wiki/MIPS_Technologies
- rany_ 2y ago> Is it a "narrative" if some Chinese tech companies are actually using it for such a purpose? I'm not saying that the narrative is wrong, it's just absurd to bring it up when introducing RISC-V. The same could be said about Linux but it's very clear how WRONG it would be to introduce Linux by saying "Linux is being used to bypass US sanctions". > And even MIPS-the-company is moving to RISC-V: I didn't know that, but what I meant to say is that MIPS ISA is open and could be used instead. There's nothing special about RISC-V.
- 2y ago
- monkeydust 2y agoAny offers on how long it will it be before were talking about Windows RISC-V machines? I just upgraded my 6 year old Lenovo X1 and was pretty close to pulling the trigger on an ARM (Snapdragon) machine but felt too unproven and I knew there would be software issues for some of the things I needed to do so sticking with x86 (AMD). I can easily see the decision next time going the other way or even RISC-V if the sofware is there to match.
- phkahler 2y ago>> Any offers on how long it will it be before were talking about Windows RISC-V machines? I'm betting Android will be there first.
- snvzz 2y agoWe know Microsoft is working on it, but that's about it. All bets are off as for when, but I would expect it to show up alongside capable hardware.
- nickorlow 2y ago1. Want a simpler ISA 2. Build it 3. Realize adding a complex instruction that's weird can really boost performance in key use cases 4. Repeat 3 until someone thinks your ISA is overcomplicated and makes a new one
- vimsee 2y agoAnd not only for Instruction Set Architectures. I feel this might be the case for software too. 1. Want a simpler application 2. Write it 3. Realize adding complex code that's weird can really boost performance 4. Repeat 3 until someone thinks your application is overcomplicated and makes a new one I guess the moral here is that computers are complicated and trying to avoid complexity is hard or infeasible.
- adlpz 2y agoExcept it's not performance usually, it's just features. And then it gets bloated. And someone things they don't need all that crap. But turns out they did.
- Mrdarknezz 2y agoI feel like there are massive industries that exist just because of this
- BariumBlue 2y agoEhh the issue is features tacked on w/out regards to existing ones. Lotta apps like that end up with multiple ways to do the exact same thing but with very slightly different use cases
- llamaLord 2y agoJira has entered the chat...
- bluGill 2y agoEveryone uses about 5% of the features of their word processors, but it is a different subset for everyone so all features are needed by someone and most get equal useage.
- neonsunset 2y agoThey had one job: make it similar to ARMv8-A but not too similar to give ARM any ideas. Look at SSE4/AVX2 and NEON and make sufficiently similar vector extensions to that as well. So far RISC-V has failed miserably at both. "Just solve it in decoder", "just fuse common idioms", "just make vsetvli fast". Sure. Not like designers of ARMv8 or X86S had decades of prior experience to make better decisions.
- onjectic 2y ago"Just solve it in decoder" is a perfectly valid approach for now, and if this turns out to be unrealistic then they can go ahead and add a conditional move extension or whatever it is. It’s far easier to add things to interfaces than remove them. One mistake they have made that may bite them later is their compressed instructions extension. It takes up far too much of the instruction set space for the amount of utility it provides, even on microcontrollers in my opinion. It also introduces lots of edge cases around word alignment across cache and memory protection boundaries.
- brucehoult 2y agoPoint of order! The RISC-V C extension takes up 75% of the opcode space. The 16 bit Thumb1 instructions take up 87.5% of the ARMv7 opcode space. Not to mention predication taking up 92.75% of the classic ARMv1-ARMv6 instruction set. RISC-V has comparatively twice as much "32 bit" opcode space as ARMv7, and 3.45x more than classic ARM A32.
- brucehoult 2y agoPoint of order! The core of the RISC-V ISA was already designed by the time ARMv8-A was announced on 27 October 2011. I don't think anyone anticipated it -- certainly I remember it being a complete surprise to me. Here is the RISC-V design as at 13 May 2011: https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2011-62.... Compare that to the design eventually ratified in 2019 and you'll find some changes in details, but not in concept. - instructions encodings changed to e.g. put rd on the right next to the opcode and the MSBs of literals on the left. - J and JAL are now combined - JALR had three versions (in func3) to distinguish call / return / others. This is now done as a convention which registers are used in rd and rs1. (It matters only for a return address prediction stack, an advanced feature) - RDNPC (get address of next instruction) later turned into AUIPC (which includes adding an offset to the PC) - on the other hand, it already has the very RISC-V feature of loads using rd and rs1 while stores use rs1 and rs2 (and the offset split up differently). Most other ISAs (including all Arm ISAs) use the same register fields for loads and stores and the offset in the same place, resulting in either loads using rs2 as the destination or stores using rd as a source! Seriously, other than the changes mentioned above, this document looks just like the final RV32G/RV64G spec from ratification in 2019. (I didn't check the floating point instructions in detail). As for SIMD -- RISC-V was designed as the control processor for an advanced length agnostic vector processor. F*ck fixed length SIMD.
- notepad0x90 2y agoit sounds to me like complex instructions are unavoidable unless the use case is restricted to microcontrollers. A modern ISA should CPU feature flags that allow implementers to disable complex and expensive instruction sets. Would it be fair to day that ARM for example is a CISC/RISC hybrid, where armv8-a is full on CISC but armv8-m is RISC proper? But that's what I'm suggesting anyways.
- FredFS456 2y agoDid you mean the other way around? -m is intended for simple(r) microcontrollers whereas -a is intended for application processors.
- notepad0x90 2y agosorry, yeah I meant the other way around.
- hajile 2y agoYou are conflating complex with niche. RISC embraces niche while avoiding complex. iAPX432 has examples of complex with stuff like OOP, garbage collection, and even data structures baked into the ISA. These instructions are very complex and take massive numbers of cycles to complete. In contrast, a bunch of bit manipulation instructions are niche, but any one of them can complete in just 1 or maybe 2 cycles. Same with something like AES where even x86 has a RISC-like approach where you call a couple simple instructions to setup, then you call a simple instruction (1-2 cycles) for each round then call some simple finalization instructions. Each instruction is niche, but not complex.
- notepad0x90 2y agomaybe i was conflating the two, but my point was cost of implementation. niche or not,minimizing hardware cost is important to consumers and vendors alike. On the other hand, for general purpose computing, complex instructions can provide a performance boost, as do "niche" instruction sets that may not necessarily complex as you put it. Since ARM doesn't actually make the hardware, it should let vendors select which feature sets they want to implement based on their requirements, ARM programs can then test the value of these static registers before attempting conditional execution.
- deleted 2y ago[deleted]
- rldjbpin 2y agothe "futuristic world if <X> was true" meme fully applies to the core idea that sw guys don't get the hw (and vice versa). even more true for the business people that leave no room for bridging the gap. abstractions exist for a reason but it is refreshing to see some examples where researchers leverage the underlying hw architecture (see mamba architecture that works around GPU design - https://news.ycombinator.com/item?id=38932350 https://news.ycombinator.com/item?id=38932350). but we can do so much more instead of pushing the new version of the existing process node.