The only real point of contention I see between the two is that this piece goes on to talk about how it's a selling point that RISC-V can be used for both low-end 10 cent microcontrollers, and high-end multi-core processors running Linux. Personally I don't see the benefit of this since you're going to have to recompile your software anyway, and since all the RISC-V SBCs I'm aware of have significantly worse performance and efficiency than comparably priced ARM SBCs.
Dmitry is talking about high-end application processors that you might find in a mid-range or better laptop, smartphone or server. Armstrong Subero seems to think that anything larger than a "dirt cheap microcontroller" is high-end.
People shouldn't take this the wrong way, but the VexRISC-V cores in Baochip are not "high-end". They are basically as low-end as you can get while still meeting the modern definition of "application core". And that doesn't matter, because being high-end application SoC is not Baochip's design criteria. These cores are actually pretty decent for Baochip's criteria.
The VexRISC-V are implementing the exact style of "classic-RISC" microarchitecture that RISC-V is optimised for. It's basically the optimal niche for RISC-V, before any of the problems start showing up.
I don't think I've ever seen anyone express the opinion that RISC-V can't easily cover the "dirt cheap microcontroller" to "low-end application processor" range, even stretching up into "mid-range application processor". Just that it's really fighting an uphill battle if it ever wants to compete with high-end application processors (and that it's going to struggle in the low-range/mid-range application market because of that).
Anyone who spends $200 million to develop a completely new high-end processor microarchitecture every 3 to 5 years is not going to complain about an ARM license too much. You get freedom with $$.
Not as much freedom as they would get with something open like RISC-V, as ARM have strict rules around private ISA extensions (like how Apple doesn't publicly document AMX). But that extra control is generally a good thing for the health of the wider ARM ecosystem.
RiscV is going to win despite its limitations, simply because they can be worked around freely, and the cost per core is zero. Every major company will be making their own flavor, because it’s the only way they can economically own the product of their work. Not many companies can be Qualcomm or Apple, but when a company invests millions in an architecture, they want it to be an asset on -their- balance sheet. It may not be the best starting point, but it’s the only journey that ends in ownership without starting from scratch.
X86 had dominance for decades not because it’s the best architecture, but because it was the best choice. RiscV doesn’t have to be the best architecture to be the best choice for companies to build on.
This feels right to me. I've worked on embedded systems and OS my whole career and it just doesn't really feel like riscv wins or loses on technical merit to me.
Boots-on-the-ground engineers might grumble but the decisions that matter here just aren't made by them. Otherwise why would we still be using x86 so much?
I've worked on platforms that had barely-functional CPUs, we had to regularly be in touch with the engs that implemented them and they'd regularly go "oh yeah you've found a bug in our memory subsystem". This was kinda annoying for us but those CPUs were cheap as fuck and that opened up business models that weren't otherwise available. This is always gonna be more important than "ah but the CPUs are suboptimal!!"
> None of this is to say that RISC-V is doomed. As I said, I fully expect it to take over the space currently occupied by 8051 as a typical cheap embedded core instantiated when some small amount of logic is needed, or some beefy accelerator or DMA engine needs some mild babysitting. Much like the linux kernel -- the price is right. ARM wants licensing fees, while the RISC-V spec is free, and (this part is key) there are cores out there which can be licensed for free. For situations where performance is not a factor and price is, RISC-V will win simply due to its price. "Good-enough" is a low bar in this case, and RISC-V is of the right height to meet it. And look, this market is not glorious, but it matters and it needs new blood. However, it is important that RISC-V not accidentally think it was chosen for being good. It needs to internalize that it was chosen for being cheap. This is not meant as an insult to cheap small cores -- I've written plenty of assembly for all sorts of shitty cores with shittily designed ISAs. RISC-V is an improvement over PIC and 8051, as little of a compliment as that is.
RISC-V may be suboptimal, but it's a lot better than 8051 and you can use GCC instead of having to buy Keil licenses for all your developers. Meanwhile at the higher end (desktops and higher-end SBCs), you'll still have to pay for a quality out-of-order core even if the ISA is free, and you have to deal with binary compatibility being more important. I can see RISC-V being a massive success on the low end, and displace 8051 and maybe Cortex-M0. However, I don't think this means that it'll be able to displace ARM64 on the high end.
Exactly as you say, x86 is successful coz there are really good x86 CPUs and a SW ecosystem. Not because it's a good arch. Similarly I think, if it wins, RISCV will win because there's enough demand for a nonproprietary ISA, and this trumps basically everything else.
Another way to say this: I've seen internal slide decks about ISA strategy that target C-suites at megacorps. Not once do those slide decks ever go into technical dis/advantages, coz the people steering the 9-figure investments don't give a shit. If you piped up in those meetings and said "RISCV sucks though!!!" you would just be ignored and not invited back.
It's not really any different from startups. Tech stacks matter but there's a huge number of successful companies out there running total garbage and who knows how many perfectly engineered products go out of business every day coz the thing they perfectly engineered was not useful.
He talks about them being the "10c/chip" chip.
Then, there is the CH32v303 https://www.wch-ic.com/products/CH32V303.html, which is the lower end of the chips that support minimal floating point and USB host/client. These ones are a bit more pricey, https://www.lcsc.com/product-detail/C5456849.html at $US1.72 each. The extra price is QFP64 (64 pins, quad flat pack) and more features on the chip, USB, CAN, V4F extension giving one instruction multiply and some floating point operations.
Note that the fact that this chip uses an extension, V4F, for floating point (I think?) is part of the argument of Dmitry's piece on the RISC-V. The chip is pretty low price for a fair bit of power.
They're probably produced in far greater numbers than most off-the-shelf STM32 or CH32V chips. You've got a huge ready market in hobbyist/educational products as well as the commercial products that have used it as a convenient choice.
There's that whole non-profit/educational heritage around them that likely selects for a different set of defaults and features than, say, a MCU designed specifically to be the controller for a SATA SSD or a $19 Roku clone.
They also have a small product range, as compared to the broad product matrix a lot of the more "commercial brand" MCUs come in. I know even the CH32v30x chips come in several variations multiplied by several package options (which vary enough to impact the features you can realistically use on them).
I highly doubt it. The RP2xxx lacks the built-in functionality for use in, say, a car, and it isn't cheap and fully-integrated enough for dime-a-dozen gadget application. They are great for hobbyists due to their low barrier to entry, but there really isn't a niche they serve when it comes to mass-produced electronics.
This.
Just programming a microcontroller is generally a pain, but a pain that hardware manufacturers can deal with, because they have employees with experience, who can read the long datasheets, get proper programmers and run the manufacturers software packages to program everything.
For hobbyists, you're basically limited to arduinos, esp??/??, and rpi picos, only those are guaranteed to have a lot of software support, documentation, easy availability on aliexpress etc. for cheap, and can be made to actually do some stuff in an afternoon of tinkering.
(technically it's the same with proper RPis, where they're the only SBC board (not x86 baed) that you're guaranteed will have at least some software support after 5+ years).
This isn't quite true, though it's true at the RPi's price point. For example, Toradex (disclosure: I work for Toradex) produces the colibri-imx6 system-on-module that can be turned into an SBC with a stock carrier board. It was introduced in 2014, continues to be supported today, and will continue to be supported until 2036. But that level of long-term support and maintenance costs money, and the pricing reflects that.
Conversely, there are a lot more variations within other MCU lineups. Just looking at the WCH CH32v30x datasheet-- a single relatively low-popularity range from a single vendor, the datasheet shows 9 basic models with five different physical form factors, and there are theoretically different SKUs for different temperature ranges, etc.
I think the CH32v303's single V4F core might be slightly more capable than the Hazard 3 cores RISC-V cores (as it has a hardware FPU), but for everything else the RP2354 is probably better (and the ARM cores do have hardware FPUs)
And yeah, it has its PIO modules, but those aren't powerful enough to make up for it. They are fine as an alternative to bitbanging Neopixels, but you can't rely on some hobbyist's vibe-coded weekend PIO project which takes up all the PIO slices and 30% of one core to do application-critical communications.
I would take an RP2000 in a heartbeat for most of my hobbyist products, but for anything professional an STM32 is orders of magnitudes better, and even a CH32v303 looks like a more attractive option at first glance.
> And also, the first application capable chip you can actually trust to be free of unpublished capabilities.
[0] https://www.eff.org/deeplinks/2017/05/intels-management-engi...
The benefit is a unified toolchain. Make a chip, get the entire software toolchain for free.
In the past if you made your own chip you had to write your own assembler, compiler, debugger, etc. Many manufacturers forked gcc but of course it's still a lot of work and the license isn't great (for them, not the user).
This universal compiler toolchain is massive benefit for both the chip makers and the end user.
Sorry I haven't actually read the original article so this is a bit of a driveby.
But, I'm skeptical of this? Surely whichever cloud platform first offers RISC-V compute, the next cloud platforms will ship a CPU that's compatible. Probably they'll be RFTing the same CPU vendors and they won't need to coordinate explicitly for this to happen. Then everyone else building RISC-V servers will essentially be forced to align on the "AWS variant" or whatever.
So yes you'll need a -cloud build of the distro you use but most people are already doing that and the cloud platforms are already providing the infra for distros to ship it (I assume they are also contributing to the -cloud distro builds directly).
RISC-V laptops and phones I could see this being an issue but for server compute it feels like there's gonna be a Schelling point.
(Actually, for phones can't Google just fix this by fiat?)
I though it was mostly: "select a minimal set of packages needed for docker and co", not "recompile all the packages you want in your distro".
But anyway I don't think it matters. The hard part here is having a distro image supply chain, not compiling stuff. If they do need to start compiling loads of stuff they didn't before... They just need to add CPUs.
I always thought that was a case of "the tech is still catching up",[0] but it sounds like there are fundamental issues that prevent performant implementations?
If so... I heard China was investing heavily in RISC-V, which implies that either they're going to have to settle for permanently crippled perf, or find a way around the issues.
--
[0] Making chips is an extremely high tech process with decades of trial and error and proprietary secrets, so this would be the logical explanation to me regardless of architecture. But I'm not hardware guy, so I'd love to hear more about this!
Intel and AMD have proven that if you throw enough money at the problem, you can make fast microarchitectures despite a flawed ISA, and in many ways RISC-V is less flawed than x86. The things we are debating here are more along the lines of minor nitpicks.
The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.
I'd disagree with that, their existence and decades of a head start mean they've been much more well invested but that's one of the things we're starting to see change, even if it's because of what would appear to be political motivations. We're starting to see a lot of investment into it in China because it looks like it's a reasonable way for tech sovereignty against the x86 monopoly. They've got licenses to some older (not sure about newer) AMD processor designs, I think around Zen2 architecture, for one of their major manufacturing firms but that won't easily let them move forward since they've got to do a lot of work to keep it up with compatibility and performance for newer ISA additions and such. That's one of the reasons they've been subsiding development of LoongSong64 and RISC-V to the point where for a while the larger LoongSong64 cores were illegal to export to some countries[0].
And then you've got a lot of other companies building faster RISC-V cores, for yes more embedded style designs but not the usual traditional embedded designs either. You've got TensTorrent working on AI work loads with real hardware out there that at least for ML stuff can compete on inference if you can get your software to run on it, and then you've got Bolt doing similar for GPU workloads[1]. While both of those are closer to embedded since you're not going to use them as a desktop, they're still making really fast RISC-V cores that could be theoretically turned into a standard RVA23 core by adding the missing extensions to make it work. That's of course not trivial but the entrenchment of x86 and arm aren't quite as daunting as they might have originally seemed.
It's still not as fast as I'd like, simply because I want to start seeing some RISC-V mini pcs get made that are fine for a daily driver office pc to happen.
[0] https://www.tomshardware.com/news/china-bans-exports-of-its-...
And yes, there is a bunch of funding being pumped into it. I do have hope that some kind of RISC-V linux workstation will be viable in the next 5 years, without sacrificing too much performance or my wallet. I just wouldn't expect that to translate into making inroads into existing markets where x86 and arm have moats, like android/apple smartphones and more typical desktop/laptop workloads (even on linux).
I wouldn't count the AI/GPU stuff, those are generally pretty simple RISC pipelines with large vector units. Though TensTorrent do actually have a high-performance out-of-order rva23 core [1] that would be able to compete in this space. They are currently selling it as a "core for agentic workloads"
Not quite. RISC-V application class processors are a new development. They are starting from behind but they are improving faster than the competition. The SpacemiT K3 is 4 times faster than the K1 for example. The Alibaba C950 will be about Apple M1 level performance. And even faster designs are already in the works.
RISC-V is not “permenantly crippled”. It will catch up and maybe surpass ARM. It is more an economy of scale issue than anything.
In many ways it's not much different than Linux was in the 1990s. It was cheap and useful, but often not as performant as commercial OSes (UNIX or even windows) until big corporate money came in and started piling resources into it. Distribution fragmentation was also an issue, which could still cause headaches for RISC-V (especially if some companies start adding proprietary performance extensions that others can't). So I think it remains to be seen how RISC-V will pan out (eg will the cloud vendors see enough of an ROI supporting it for higher end computing than buying ARM licences).
Whatever leading-edge fab capacity (mostly TSMC) was available, is now tied up to supply the ongoing AI boom. And will remain so for the foreseeable future. Even if you'd have a RISC-V product for which demand/economics work out, chances are those fabs' order books are filled.
Also: design is done in many places, but actual fabrication of RISC-V SoCs in largely centered in China. Which (afaik) doesn't lack IC fabrication capacity. But does lag in leading-edge fab capacity. So: off to older nodes. Which may hurt perf/W, cost effectiveness or transistor budget. Or pay a premium (pricing products out of markets), limited production, or long lead times.
Of course this affects ARM based & other products too. But they've been in the optimization / mass fabrication / distribution pipeline much longer than most RISC-V based products. Catching up takes time, and top-tier fab capacity being swiped by Nvidia & co doesn't help to shorten that process.
I don't think it's a demand problem. Consumers don't care what powers their phone/tablet/laptop as long as it does its job. So in principle the market is there (yeah.. I understand issues like Google still working on Android-RISC-V, Windows users probably wanting x86 for legacy software etc).
That being said, demand from and via China (which has a geopolitical case for wanting to see risc-v succeed) will probably end up being what drives it forward.
Not having decently performing risc-v chips right now doesn't mean anything other than nobody spent enough time and money on accomplishing that.
But for SiFive's last silicon, the HiFive Premier P550, they claimed a specint2006 of 8.65/GHz. That should put the silicon only about 20% slower than an intel i5-6400. But if you look at geekbench scores it's about an order of magnitude slower.
Correct me if I'm wrong, but Tenstorrent has yet to ship any of their own cores? They do make very similar claims to SiFive.
Personally I'm very skeptical that these cores will be anywhere near Zen 3. I recon their performance claims are based on best-case CPU simulation, rather than a real measurement. I'd expect Raspberry Pi 4 levels of performance, a bit over double SiFive's current state of the art. An impressive improvement, but nowhere near Zen 3.
When I had brief access to a very early P870 devboard running at 2GHz it scored 2% worse than an 2.86GHz Cortex-X1 in the 7-zip benchmark compression (it was a 40% worse in decompression, but that has NEON optimized Arm assembly path and non for RISC-V). Because this was very early hardware still in bringup I expect them to get closer to the announced 2.7GHz.
But yeah, the RISC-V geekbench scores of publically available RISC-V processors are suprizingly low and idk why. Part of it is the lack of RVV support is certain workloads, but that doesn't explain the entire gap. When I looked at ST scalar performance my self it looked more comparible to similarly sized Arm CPUs.
I think I'll have to order a Pi5 (Cortex-A76) and investigate where it performes different to the SpacemiT K3 (SpacemiT X100).
On paper they should be very similar, both 2.4GHz, 4-wide decode, 3xALU, 1xBranch, (although the A76 has those on 4 execution units, while the X100 has 3 with one sharing ALU and Branch support), 2x load/store, 2xFP. The biggest obvious difference (appart from ISA), may be the cache setup after L1, with the K3 having a 4Mib L2 shared between 8 cores (no L3) and the Pi5 having a 512KiB L2 and a 2MB L3 shared between 8 cores.
Well, there is some speculation regarding these chips so no sense arguing too much about it.
That said, the SpacemiT K3 is already faster than a Pi 4 and even substantially faster than a Pi 5 for multi-core and vector stuff. And that is before counting the other 8 “AI cores” it has.
These chips will be quite a bit faster than a K3, so certainly much faster than a Pi 4.
> and even substantially faster than a Pi 5 for multi-core and vector stuff
I'll push back a little on this. It can be faster under certain workloads, but is not universally. It's behind in geekbench https://browser.geekbench.com/v7/cpu/compare/146501?baseline..., and in compilation workloads: https://www.phoronix.com/review/spacemit-k3-pico-itx/3
Because, without neglecting the micro-architecture, we all know how critical the silicon process is for high-end performance.
The point is that RISC-V is not limited to lower performance by the ISA.
Yes, the fundamental problem is the fact that everybody involved in RISC-V wants to sell IP instead of a chip.
The problem with the RISC-V chips in non-embedded contexts (ie desktop or server) has absolutely nothing to do with the instruction set architecture (not entirely true but a really good first approximation). The problem is that performance is strongly dependent upon your high speed interfaces--memory, graphics, PCI, etc. And those blocks need to be strongly integrated in with your CPU interfaces.
However, if you buy a whole bunch of IP blocks and then just wire them together, your performance is going to be sub-par. And this is what every single RISC-V chip that I know of currently is.
It's not beyond someone to sit down and do the required integration like Apple did for ARM. There's just insufficient money in it so nobody is going to expend the engineers.
Riscv took all this information in, and designed a very, very good brick.
how will that pan out over the long term is really unclear and the reality is performance is actually catching up quickly
You cannot buy the company backing RISC-V to take out the competition. And if a RISC-V company stumbles, the ecosystem carries on. But if even one RISC-V company is in the right place at the right time, RISC-V can surge ahead. It is hard to imagine it does not dominate eventually.
But I also think this is an example of a slight disingenuity in RISC-V being referred to as open-source. It's borrowing the clout of open-source software projects where the end user has the freedom to compile them at home. I can't fabricate a CPU at home, I'm still beholden to whatever patents the manufacturer chooses to license. SiFive have a >billion dollar valuation, for a business based on selling licences.
Nowadays nobody will want to work on foundational open source work for free only to enrich everyone else that builds on top of it.
You get these kinds of responses when something is too close to perfection. It suddenly gets judged in a much different light.
What you're less likely to get is the consumer level PC and Laptop systems, as you'll need one large company to set the standard and others to adhere to it. So you could feasibly compile a program for a certain level of RISCV chip and have it run on many vendors processors. As it is there's several companies trying to push ARM for some sort of high end consumer PCs/Laptops but they all require different OSes and the chips aren't equivalent, so you have to compile software separately for those different platforms.
The biggest valid complaint is the lack of dedicated mask registers for vector processing, that's a huge design flaw in the vector instructions since it makes register renaming and shadow registers mandatory. In other words, the problem here is that they didn't stick with the RISC philosophy of making everything explicit.
Compressed instructions are mostly wasted encoding space, but from a performance perspective they don't matter. If they are slow then compilers will treat them as slow legacy instructions and stop using them or they will only emit aligned compressed instructions.
This has always been true, it is just this is one of those projects that gets some people very emotionally invested so such discussions do not happen in public.
See also Android, rust, webassembly, webgpu and so on.
As much as people complain about warts in other ISAs like x86, their design decisions made sense back when they were made (or at least, no one really knew better)
However his points that "cheap parts are a great enabler" and "shipping costs are high to Trinidad and Tobago", while true, don't actually counter the OP's points that "feature determination needs to be universal" and "the instruction set is poorly designed".
Others have said application authors will code to the specific platform, but that's not true of library authors -- they need portability.
Why can the RISC-V team not get basic stuff like feature determination right? No matter how stupid the rest of the instruction set is, I'm with OP that the responsible individuals should retire from the committee.
So it is with the family of mutually incomprehensible ISAs called RISC-V.
Thats being generous. He is spinning this into a 3rd world / 1st world social justice story, while ignoring the technical points dmitry made.
And RISC-V is just starting here with shoestring design and fab budget. Wait till all engineering teams really adopt it like Tenstorrent and NextSilicon and so on.
I assume this is addressing
> and since all the RISC-V SBCs I'm aware of have significantly worse performance and efficiency than comparably priced ARM SBCs.
If so, could you point at specific SBCs that beat ARM SBC perf?
And I will note that the other poster didn't say they beat it, just that there are lots of chips being built. I'd imagine that the cores on the tenstorrent cards would blow all the other arm cores out of the water if you could run the benchmarks on them directly, given the much higher core speeds and memory bandwidth etc.
Any examples of this?
* Tenstorrent Ascalon has a neat optimization for certain LMUL>1 SIMD operations. LMUL=2 effectively unrolls the SIMD operation making it read two SIMD registers from every source and write two SIMD registers to the destination. There are however some instructions where LMUL=2 only needs to write to one registers, those are narrowing instructions (e.g. 64-bit to 32-bit truncation) and comparisons (which write to a LMUL=1 register with packed bits). When those SIMD instructions have to .vx form, which means one argument comes from a GPR, they now only need to write one SIMD register and need to read two SIMD registers. This matches what regular SIMD instructions need and because the silicon for the execution is much cheaper than register file ports, Ascalon can exexute these instructions in a single operation. So you can compare twice as many SIMD elements against a scalar, then you can against another SIMD register.
* Ventana (now under Qualcomm) talked a tiny bit about their fetch-block-optimizer and something that sounded like a L1i-trace cache. The fetch-block-optimizer would go to certain hot L1i entries and "optimize" them, with agressive instruction fusion including fusion of non-adjacent instructions.
* NextSilicon: Idk any details yet, but they said they handled RVC without increasing latency and that they've found a good solution for implement RVV and especially LMUL, which is a challange in out-of-order designs.
* OpenXiangShan: The fastes open-source CPU, is working on doing 2-ahead instruction fetch (the thing Zen5 added).
Now that being said, Ventana was bought by Qualcomm, we know the RISC-V team is still alive, but who knows if we'll ever see anything from that outside of Qualcomm?
The Tenstorrent Ascalon devboard is way behind schedule and on 12nm TSMC instead of a 4nm node the processor was designed for and is now supposed to clock at 1.38GHz. Though I think the delay has more to do with TT management problems then with the actual design.
While the scalar part of OpenXiangShan looks really good, the RVV imolementation is currently basically unusable. They want to have fix for the problems until the end of the year, but we'll have to see.
Good news! It seems they just opened a new PR for a new RVV implementation: https://github.com/OpenXiangShan/XiangShan/pull/6331
I'll have to try out the branch.
The improvement is entirely "we don't have to pay ARM"
Sure there are. If you want to do weird and wacky stuff, try to do it with an ARM and see how fast you get shut down.
> The improvement is entirely "we don't have to pay ARM"
No, it's "we don't have to beg and grovel, or pay ARM."
Of course, in the more distant past, AMD and Intel sued each other a lot. But there have been a dozen or so x86 market entrants. I think the competition has just been brutal.
So, with either one, you could, of course, do a clean-sheet design and hope you don't get sued.
Since ARM has historically only sold IP, they are incredibly jealous of their monopoly for that ISA. Of course, the flip side of it is that if you have enough money, and you beg and grovel enough, you can probably do what you want with their code.
Except, of course, when you can't. Or rather, maybe you can, but they will try really hard to stop you.
For example, Qualcomm, an architecture licensee who had purchased the rights to basically make whatever the fuck ARM they wanted, purchased a startup named Nuvia that also had an architecture license, and started using Nuvia's designs.
ARM sued, just because. They were shut down in court, but the message is clear. They are very aggressive.
Seriously, who needs that shit? Semiconductor market windows are tight enough as it is, and ARM has always acted like "Nice chip you've got there, buddy; shame if you haven't dotted your i's anc crossed your t's on the licensing."
At least with Intel or AMD, you're probably only looking at patent lawsuits, and you could probably do a decent job on a low end machine with techniques that were known 20 years ago.
You could do the same with ARM, of course, but they will sue you just because, to see if they can make you run out of money.
But there are now several RISC-V IP vendors, and ARM can't possibly shut them all down, and companies can develop IP in-house, so there are lots of different designs already out there.
So, at this point, developing a RISC-V processor provides a certain amount of safety in numbers, kind of like swimming in a school of fish, while developing an ARM compatible processor paints a target on your back.
Developing a low-end x86 processor wouldn't attract any legal attention either, but now that the RISC-V ecosystem is big enough, why bother? Decoding all those instructions might be a lot of extra work for no real market share gain.
Developing a high-end x86 processor would probably attract careful scrutiny of exactly how you managed to get that performance and whether you violated any patents to do that. Again, that the same sort of patent scrutiny would happen with bleeding edge RISC-V, but certainly, a fast x86 processor would be higher on the priority list of the Intel and AMD legal departments.
Because, if you look at the current trajectory of RISC-V micro-architectures: they will be competitive, so current hardware big tech will try hard to shut them down. If they are already at Zen3 performance... I run Zen2 and it's already beyond than enough (I miss AVX512 extensions though, hope we'll get often RVA cache line vector instructions on RISC-V).
Look at qualcomm already buying what seems to be a very good RISC-V microarchitecture, wonder what they will do to it (usually, they let it die slowly forcing their good engineers to work on something else).
The right way(TM) would be for ARM to "drop its ISA" and become a microarchitecture designer able to decode and run RISC-V ISA.
Intel and AMD should too. The world would be basically competing micro-archs all with high compatibility at machine code level.
And it seems nobody has been addressing the elephant in the room: x86 is an horrible ISA for a modern CPU, much more worse than RISC-V/ARM. It is only because AMD/Intel throw tons of money with tons of brains to make that horrible ISA performant AND because they are hogging the production capacity of the best silicon process.
There is zero wonders here.
The first issue is on the purely physical level. The fabs (and integrated companies like Intel) fight this one out, and eye each others' patent stacks and maybe exchange a bit of money. This is not something the average Joe can worry about; nobody has the money to build the fab or engage in the chemical and materials research.
The second issue and implication is on the logic and circuitry level. The average Joe is not going to be able to design and test something really big and performant, but many companies (not just Intel, AMD, and ARM) are capable of this, and again, money might change hands, but (aside from things like China) absolute shutting down of competitors is not really going to happen.
So big players will dominate the highest performance market, but at least there are probably a dozen or so of them, so that will provide some pressure on its own.
Lower performance chips (some of which will be more than performant enough for many niches) will probably proliferate. The profit margin on these chips will be cutthroat, because the average Joe can design them, and then needs to negotiate with, e.g. TSMC, to actually build the damn things.
And a lot of innovation will happen in these lower-level chips as well. Expect many startups to be bought by the bigger players to enhance their own patent portfolios. And expect that their competitive prices will also drive down the cost of the most performant chips a bit.
The performance chip companies will have interesting choices to make. Lower the price to knock out the competition below? Or raise the price? If they raise the price too much, their available market will shrink, and then they'll need to raise the price even more.
I don't get how both things can be true. The cost to ship something to Trinidad and Tobago has nothing to do with whether it's ARM or RISC-V; shipping the same weight of either kind of chips should cost exactly the same amount. Yes, maybe the chip cost itself of a particular ARM-based model is $0.15 while the equivalent RISC-V chip costs $0.10, but if the issue (for him and other people who live outside US/Europe) is that shipping costs are orders of magnitude more expensive than the thing being shipped, that chip-cost difference becomes irrelevant.
I think he does make a great point about how fragmentation does give you better optionality: ARM is sort of like cable TV where you have a small number of product categories that each bundle a particular set of features, whereas with RISC-V you design something bespoke that does exactly what you need and nothing more. But again, this isn't going to affect shipping costs.
Aliexpress doesn't do any ID verification hassle. This is all an argument more about distribution and shipping. RISK-V is going to win because getting the parts is insanely cheap and without overhead.
The "fix" is probably Digikey, Mouser, and Segger need to just let buyers check a box where they assume all liability and parts are just thrown in the mail and forgot about - something aliexpress is great at doing.
A quick search for "arm chip" on AliExpress shows lots of results, so I don't think your argument refutes anything I said.
Most of those are going to either be fake, or a clone with all kinds of weird compatibility issues. You might even get recycled chips, scavenged from e-waste.
China makes a huge majority of the world's electronics, and a big chunk of those will have ARM microcontrollers on them. Of course Chinese suppliers can get genuine ARM chips.
China has amazing prices for genuine electronics components from every manufacturer. Including stm32, NXP as well as local arm32 licensees gd32,hk32,XHSC. From which you can buy Cortex-M0+ down to 10-20cents per piece.
Literally anything you can buy in the West, you get for fraction of the price in China, even in small volumes.
If you live in the third world you wouldn't even think about ordering from "western parts supplier", everything is expensive and overpriced and selection is shit (compared to China).
From India obviously not, so you have to pay normal shipping costs.
Living in the US and having free overnight delivery is 1st world luxury
STMicroelectronics also launched the STM32C0 series that is still quite cheap @ ~0.35$/piece.
However, the prices on aliexpress all mishmash so giving a correct quote is impossible as the same chip is sold at wildly different prices by different sellers.
Then probably RISC-V being "open" license is the key to its success, even if the architecture itself is weird.
> From that position, the difference between a ten cent part and a one dollar part is not a rounding error and it is not a detail you get to wave past on the way to the interesting discussion about encodings
Yet earlier:
> I pay anywhere from US $60 to US $200 to ship one dollar chips that people everywhere else get free shipping on
Seems to me that the difference between a 10c chip and a $1 chip are a rounding error when the shipping cost dominates so much?
> I can pick up H417s on the official WCH store on Aliexpress with free shipping and no verification hullabalu.
I think the point is that anyone can make these chips, so there are Chinese sellers who just throw them in a padded envelope and send them out without bothering with all the stuff "serious" vendors do. And because they're cheap enough, if doesn't matter if some get lost in the mail.
If Quintauris successfully makes a RISC-V range for automotive use, there'd probably be margin to clone those and sell at a profit, but skirting automotive certification regulations is a high-risk game that (hopefully!) doesn't have many buyers.
If they make an IoT line, again, there might be margin in it, but you'd be trying to fit in between buyers willing and able to engage with Chinese sellers but for some reason unwilling or unable to engage with existing Chinese sellers of existing IoT RISC-V parts. Quintauris is a very, very long way away from being a "household name" along the lines of STM32 or FTDI.
I don't know why you'd take that as a given when marquee RISC-V microcontrollers are almost universally low-cost, but Arm has pricier marquee parts, thus a bigger opportunity for undercutting the market leader on price with a cloned product.
So per unit shipping collapses with quantity, which is why the part price matters more here, not less. The fixed cost forces you to buy deep, and only the cheap part lets you buy deep. At a dollar a part, 1000 units is a $1060 order nobody here is placing... at ten cents it is $160, and then there are 1000 parts sitting in Trinidad that nobody else has to pay $60 to reach, so you can have enough for a small product run..keep in mind we also currently have US dollar shortage, so you only get allocated a certain amount of US per quarter....
I should also have been explicit that those figures are the Western channels like DigiKey, Mouser, courier from LCSC. WCH officially sells direct on AliExpress with free shipping, which runs on postal consolidation rates that do not price by how remote you are. But that channel is a game of chance. Sometimes things just never come, there is no ARM equivalent either. I cannot buy an STM32 from ST with free shipping to Trinidad, and I cannot trust the aftermarket parts because some of them are fakes, and some vendors do not have this country in their shipping list at all....
The part I care about most is that at ten cents I can hand a student a part they are allowed to destroy. Learning embedded means killing chips, and at a dollar a part a teacher flinches, cause 1 US dollar is about 7 dollars here, and starts supervising instead of letting people find out. And the same goes for me, at ten cents I can experiment and still ship with the part I experimented on....
Ah, I think that explains my confusion (in a different top-level comment[0]).
I read the wording in your article as you getting shipped "a dollar worth of chips" or "a dollar of chips", which to me sounded like you were talking about ordering multiple chips. So I assumed that the per-chip cost for ARM and RISC-V were close enough not to matter too much, and the shipping cost easily dominated.
But now I see it says "one dollar chips" (either I read it wrong initially, or you've updated it since I read it), which makes sense. $1 vs. $0.10 is a big difference at even smallish quantities. (My assumption was that the chip cost difference was more like 1.5x, not 10x.) And while the shipping costs are huge enough to dominate regardless, being able to order 10 chips vs. 100 chips for the same price (and presumably roughly the same shipping cost, even if it is high), is a big deal. The "allowed to destroy" bit is very real.
I thought your argument was about shipping costs, since that's what you focused on so much in the article, but the real issue is still the cost of the chips themselves. The ridiculous shipping cost you have to pay is certainly a factor, but I think a teacher in China would still flinch at giving a student an easily-destroyable $1 part, vs. a $0.10 part, even if their shipping costs are basically nothing.
This is based on history: I remember when x86 performance compared to the DEC Alpha, PA-RISC, SPARC, etc. was a joke. There was a time when, if you wanted real performance, you needed to pony up $20,000-$50,000 for a workstation with a MIPS/PA-RISC/SPARC/Alpha/whatever processor. All these workstations smoked the x86 computers of the era.
However, people were buying x86 computers at a far higher rate, giving Intel (and AMD) the money needed to invest in better chip designs and better fabs. Linux was, at the same time, gaining traction and, around the time the dot-com bubble popped and there were no longer companies with the money needed to get Sun SPARC workstations (or what not) at $50,000 or more a pop to start up a web business, x86 computers running Linux had nearly the same performance at a much lower price. Once the Itanium sank and x86_64 was mainstream, x86_64 was the ISA of choice for performance workstations and servers, and the RISC ISAs that survived were now mainly used in the embedded space. Indeed, ARM was never a high performance RISC processor, and it was the one that took over the embedded space while PA-RISC, Alpha, and SPARC died.
The ISA for what were cheap computers become the highest performance ISA around.
It has been only in the 2020s that RISC processors have gotten x86_64 levels of performance, notably in the the Apple M series of processors. So now ARM, an ISA which was geared for cheap embedded devices, has become a high performance processor, in line with x86.
Right now, RISC-V is mainly being used in cheap embedded components. Considering that x86 and ARM also were made for cheap computing, until becoming the dominant high end processor, history tells us that the cheapest ISA is the one which will become the highest performance one.
RISC-V currently has about the same performance as a high end Raspberry Pi. I predict it will have medium-level PC performance by the end of the 2020s.
x86 hit that sweet spot: 8088/8086 performance nicely between much-weaker, memory constrained 8-bitters and too-expensive SPARK/MIPS/Alpha etc workstations. Then the BIOS situation opening the door for PC clone builders, Intel's good fabbing, and presto: x86 took off. People just bought PCs because economies of scale provided increasing bang/buck compared to other offerings.
ARM: grew steadily in embedded. Then "mobile" became big, ARM was objectively better than x86 there (battery! perf/W), and the market size provided huge $$ royalties that enabled ARM to hire top-talent engineers & improve their next designs. Leaving their competition in the dust. Steadily upping performance lead to things like ARM based laptops & servers.
RISC-V is largely riding the "open" wave. Which does translate into practical advantages like driving down product cost, software support improving fast due to the shared ecosystem, etc. But again: much luck involved - timing of its introduction, cheap FPGA boards becoming available to developers & students, the ISA itself being fairly sane (even called "boring", which is good in this context), its modularity positioning it across a wide range of markets, coumtries like China looking for tech-independence, etc.
This much like ~1850's industrialisation in Britain: ANY one of the factors missing could have lead to failure.
Personally I have high expectations for RISC-V. But regardless how it'll pan out: it's well past critical mass, so it's here to stay.
In the mid 90s, I got myself a DEC Multia (small Alpha-based workstation) to run Linux. It was fast at some things, but useless to browse the newly emerging web. Netscape Navigator wasn't available as an Alpha binary, and the emulated x86 was just as slow as an early Python based browser. Running Netscape on a 486DX3-100 was night and day like visiting the future. Some other native programs went the other way, with the Alpha beating the 486 dearly. But the web browser became more and more significant.
In college, I was also told I should covet Sun hardware. At my first job, I got issued a Sun Ultra workstation of some sort. I was appalled at how slow it was for my FOSS C programming workflows with autoconf/make/gcc etc. I started bringing in a Dell notebook with a Pentium-MMX running Linux, and it ran circles around the Ultra for actual day to day tasks. On the other hand, when I had to run certain commercial tools like Purify, the Sun was useful again.
I also had exposure to supercomputer centers at the time, doing portability work for our HPC codebase. It was often crazy how slow these platforms were for development work. There may have been a little bit of neglect by the vendors or IT groups in terms of what hardware they dedicated as front-end service nodes on these big machines. But, there were also dramatic differneces in the operating system behavior, tuned to get one user-level job running and get out of the way. They were terrible at multitasking, and this showed through in CLI/scripted interactivity too.
Sometimes, I wonder if some of those platforms could have survived if they jumped on the Linux bandwagon and kept developing their hardware. But maybe their fate was sealed because they depended on the bundling of their proprietary OS and hardware, neither of which was able to adapt to the new order...
RISC vendors were in the business of selling hi-end workstations and servers that required their own respective RISC CPU's, which meant that each vendor had its own, in-house CPU design arm and either their own fab or they outsourced the CPU manufacturing to someone else. In a way, the RISC CPU was a by-product of what they sold but never the product they sold alone. Two problems followed.
The CPU design is an expensive process, and keeping one's own fabs up to date with the latest and greatest manufacturing process is even more expensive, especially as the designs and processes advanced. It eventually became prohibitively expensive to maintain one's own fab, and RISC vendors started falling behind the bleeding edge (DEC, Motorola, etc.). IBM managed to get away with it for a time, but eventually, they also divested.
The second problem concerned the outsourcing of the CPU manufacturing. Those RISC vendors (e.g. SGI with their MIPS) who did not have their own fabs had to contract a fab (e.g. NEC). Such a fab would produce a diverse range of microchip products, and a CPU would be just one of them. Which typically meant not the latest and greatest process, but at least a generation behind.
Whereas both Intel and AMD were dedicated CPU design and manufacturing houses (although AMD also divested their fabs later), so they could specifically focus on what mattered for CPU's and for CPU's only.
That said, for Intel and AMD, the CPU was the product, whereas for the RISC vendors, it was not, however important, the CPU was for them.
You surely mean "history tells us that the cheapest and largest-volume ISA is the one which will become the highest performance one".
It's not "RISC" having reached x86 levels; it's ARM variants. They did so with volume that for the first time in modern computing massively exceeded x86's. Apple's PA Semi acquisition has resulted in wizardry, but that wizardry would not have been possible without the massive volumes TSMC enjoys.
In any case, I'm not convinced that the above is sufficient; there has to be some level of technical superiority (or at least reasonably equal-level) as well. Otherwise, some inexpensive microcontroller that is manufactured at 100X the volume of x86 would have taken off. Does RISC-V have enough "goodness" in its design? I do not know.
Qualcomm beat ARM in court and reportedly pays 2-3% royalties where ARM was demanding 5-10% royalties.
Qualcomm's ARM license expires around 2028 with an option to extend to 2033 (for some amount of money). If Qualcomm is locked into ARM when renewal comes up, ARM is going to not only name the higher price, but likely charge even more to recover their lost revenue.
Qualcomm is already designing their own cores and ARM is charging them billions for the privilege. Increasing net profits 2-3% for simply doing the thing you are doing seems like a very easy choice. Increasing net profits 5-10% (maybe more) after the price hike seems like a fiduciary responsibility.
This isn't just talk either. Qualcomm already proposed a RISC-V Znew extension (nearly 300 pages of changes to make the ISA more like ARMv8). They bought Ventana (a company already done with their second very wide RISC-V design). They partnered with other companies to make Quintauris for promoting RISC-V too.
There's a non-zero chance we see a RISC-V design from Qualcomm before 2028 and I believe a near 100% certainty of a RISC-V design before 2033.
In terms of a “theoretically even better ISA”, if anyone has any proposals, I would love to see links to them. In particular, the article “RISC-V: They Should Have Known Better” does not propose an ISA (except mentioning that the author feels AArch64 is much better), so I find its criticisms dubious.
[1] I will make one ISA propsal: x86_64 should have had 32 instead of 16 registers, but 16 registers at least is quite a bit better than the 4-8 registers the 386 had.
APX proposes exactly this along with 3-register syntax and some other things.
There are two big issues IMO.
1. It will take at least 15 years before most software ships with this because unlike something like AVX where you typically just rewrite a small part of your code that needs AVX, APX requires a 100% rewrite to take advantage.
2. APX instructions require an additional byte each time you use them compared to current instructions. I think there are still savings to be found, but they won't be as big as it might seem at first.
Lack of serious incentive combined with decades-long rollout seems a recipe for non-adoption at a time when RISC chips offer these features now.
Is "registers" still a real thing or its just an illusion at this point? I am pretty sure there are "virtual" registers or micro instructions (something like that, I forgot the terminology)
Being able to store, e.g. 10 vs 5, local variables in a larger register file has performance implications[0] strong enough to consider larger register files an advantage.
[0] The reduced number of memory-to-CPU and vice versa data transfers for transient computation results.
You can still run out of value names, though. We rarely run out of them in straight-line code, we sometimes run out in absurd loop code, and we almost always have to do something for our function calls/returns to avoid running out -- we can't just assign each function its own set of value names. This means we need spill/restore instructions, either before and after the call instruction or at the beginning and end of the function. Sometimes both. We also divide our value names into parts that have to be saved by the caller and parts that have to be saved by the callee.
Maybe smarter call/return instructions will help a bit in the future by doing multiple register renames as part of a single instruction in order to make those spills/reloads faster/less necessary/more asynchronous.
Sparc and Itanic tried to do something like that (register stacks), but in a way that ended up being expensive to implement in hardware (high clock speeds were hard) and inflexible in practice -- and also annoying to support for the OS, the compiler, and the debugger.
https://en.wikipedia.org/wiki/Register_renaming ?
But yes, register count is still a thing. Why? If you run out of registers, operations 'spill out' into main memory. Read: L1 (data) cache. Which is fast, but not as fast as CPU registers. And probably uses a lot more transistors & power.
Of course there's limits to that due to # of opcode bits available (eg. 32 regs, 3-operand instruction -> 15 bits needed to encode source & target registers).
Yes, register renaming. What I mean is that why does anyone care still what instruction I am running on? The CPU have its own microops, instruction decoder, its own pipeline, scheduler, etc etc
Why can't you have a CPU that have 1024 registers and pretend that it only have 32?
"[...] and pretend that it only have [sic] 32" is EXACTLY what register renaming is.
Today, almost any fabless manufacturer can order world-class leading semiconductors from TSMC, just like Apple is doing now.
Drawback is that most RISC-V manufacturers are in China, which don't have access to TSMC's manufacturing technology. And Apple is heavily invested in ARM since it owns part of the technology.
It's worth keeping in mind that modern ARM isn't really all that _RISC_, number of instructions in these chips is starting to approach x86_64 territory pretty fast
> The students I want to teach are in the same position, and so are the ones in Nigeria and Bangladesh
It does not take $60 to ship small sub $1 chips from Asia to Nigeria/Bangladesh. These two countries are all on global trade routes (both supply and demand) and the expensive last mile delivery costs are fairly low there too.
The typical bay area centric take has the following vibe:
1. I am among the group of most open minded people
2. I admit mistakes, but I don't change my view, that means I may make the same mistakes next time on a different concrete cases
3. Morally I am among the least corrupted
4. I work for the moderately morally questionable firms with nice paychecks, but my moral views are not tainted a bit
5. I never think on the other's perspectives
https://www.astralcodexten.com/p/the-foothills-of-bay-area-h...
My favorite bit, I think (along with the running gag of the constant use cases/connections that somehow pop up for Epstart’s founder):
> “Would you like to hear more about how copying AI tics helps me keep conversations going?”
> “Uh, sure - wait! No!” You break off and turn around as fast as you can.
If the other entries in the series are anywhere near as good, I’ll have some reading to do now.
Bangladesh is a country in Asia...
In my experience, the only demographic who complains about “Asia = east Asia” are people from South Asia, aka Indians/desis
1. "Asia" and "Asian" are different words, which mean different things.
2. There is a dialectal difference specific to "Asian" between England, where Pakistani immigrants are prominent, and the United States, where they aren't.
The term for East Asian was Oriental which is now considered racist/passé for some obscure reason.
I assume you mean in the US but the 1882 Chinese Exclusion Act makes no mention of race and anti-miscegenation laws speak of Mongolians(presumably to mean people of East Asian ancestry in general).
I think Oriental in the US like the alternative Asiatic applied to all Asians from Istanbul to Vladivostok.
I imagine both the majority of shipments from Asia, and the majority of shipments to Asia, fall into this "nonsensical" category.
So don't even try to find how expensive is bring these to Brazil. Even the $5 orders from JLCPCB become infeasible for hobbyists here due to all the roadblocks.
HN hasn't been Bay Area centric in years. Honestly, most comments and usership on the platform seems to now align with SWE culture in DACH and CEE.
Presumed RISC-V hate is a perfect example of that - the UCs and CSUs have been using RISC-V in their curriculum since the 2010s becuase Patterson is faculty at Cal and most CompArch courses in both systems have been using RISC-V as a result because 61a/b/c are often used as the benchmark curricula wise. An entire generation of Californian computer engineers have been RISC-V fluent as a result.
The hivemind assumption that HN's user base is "venture capital", "tech bro", "founders", and "Silicon Valley" is around 5 years out of date.
Anecdotally, the vast majority of younger (below 30) founders, engineers, VCs, and builders in the Bay have either not heard of HN or quit it within weeks due to toxicity.
I honestly do not get this at all. HN remains very US-centric to me, and especially centric to the mindshare of the Bay Area's IRL conversations, and apart from some takes on tech rights, does not really remind me of my experience in DACH.
>> HN remains very US-centric
Bay Area != US
The Bay Area is its own microcosm of culture and philosophy that diverges significantly from much of the US.
Not making a statement on how prevalent either are on HN, but Bay Area is very much not equivalent to the US.
Extremely. The valley/startup lens is absolutely the dominant one.
The majority of HN's usership, posting, and comment activity occurs during peak EU work hours (3am-9am), stylistic patterns that are common for German-, French, and Polish-native speakers are increasingly prominent (eg. periods and spaces instead of commas in numbers, spacing between quotation marks and words, failing to use context clues to infer timezone), and the fact that IRL conversation topics in the Bay Area tech scene are entirely different from those on HN shows a massive divergence in userbase.
HN "Who wants to get hired" threads are a good example of that as well.
I'd recommend deep diving in the HN scrape dataset on HuggingFace [0]. The site has diverged heavily compared to 2018 or 2012.
[0] - https://huggingface.co/datasets/open-index/hacker-news
" RL conversation topics in the Bay Area tech scene are entirely different from those on HN shows a massive divergence in userbase. " Any proof?
So what does "the majority" mean? 51%? Because that's just saying those 51% occur during EU/UK afternoons and east cost mornings.
For starters, most Bay Area residents are not active on HN on a sunny Sunday afternoon during peak brunch time, a Giants v Rockies game, a social race in the Marina, during the weekend right before college move-in begins for a number of UCs, and the first weekend after the K-12 school year started.
Secondly, the technical conversations on this HN are somewhat divorced from those which are common now. Firstly, no one cares about system cards or micro-level model changes and performance anymore - the name of the game now is eval, harness development, RL/reward engineering, and model-agnostic development.
Thirdly, the vibe change around layoffs the job market is completely different. While there have been plenty of layoffs (and friends and acquaintances of mine have been impacted), most have been able to land jobs within weeks with a similar base/bonus/equity structure.
Furthermore, the Ivy-versus-nonIvy division and rhetoric is nonexistent in the Bay. Everyone here knows a UCLA grad has the exact same opportunties right out of college as a Stanford grad. Most high value careers like startups, PE/VC, big tech, etc recruit from a mix of 20-30 public and private schools that I have listed multiple times on here. And to add to that - "MBAs" as a moniker is nonexistent as most of us who are in decisonmaking roles here in VC, Corporate leadership, and mid-level management are engineers who never did MBAs or any kind of grad school (except our Chinese/Indian peers because of the F1 OPT).
Additonally, most people are levelheaded about AI - they don't deride it as useless but they also don't think it's going to destroy all jobs. On HN you get very black-and-white and highly polarized thinking that AI is only going to lead to X or Y.
And finally, I notice a degree of European anti-Americanism and American anti-Europeanism that is nonexistent in the real world. I have co-hosted events with EU consulates, helped direct European startups to get American funding, and vice versa, and had pretty personal and unfiltered conversations over drinks with pretty high level Europeans and Americans, and the kind of acrimony you see on here is nonexistent IRL.
Not a single mention of pickleball, hyrox, Kdramas, Yemeni coffee, women's basketball, and other stuff currently in the zeitgeist in the Bay is very telling.
Even publications, semianalysis is the only major, decent one in my experience (excluding personal blogs).
Everything is low SNR for AI - have you seen ICML/ICLR/NeurIPS recently?? There is almost no point even going except for meeting people which we do by scheduling talks back and forth every few months anyways.
I also find IRL, then a carefully curated twitter timeline with the politics toggle on the settings page set to off, are the only ways to get high SNR information about AI.
I also feel it's topic-based. On general systems engineering, think databases, OS, architecture, webtech, the SNR on this site is generally amazing. But these days those articles are fewer than before. For example, 2 years back when every other article was about sqlite and postgres, while it was a very unidimensional few months, you could learn a lot from here.
I agree. The thing is, a lot of us moved to Lobsters [0] because of the higher SNR. That is probably the closest to what would be heard amongst engineers in the Bay.
[0] - https://lobste.rs/
" Furthermore, the Ivy-versus-nonIvy division and rhetoric is nonexistent in the Bay. " Non existent in DACH region or CEE because why should it?
" Thirdly, the vibe change around layoffs the job market is completely different. While there have been plenty of layoffs (and friends and acquaintances of mine have been impacted), most have been able to land jobs within weeks with a similar base/bonus/equity structure." I think people with problems are more likely to post and secondly maybe you are convoluting your social circle with the whole SV.
I haven't done the analysis to see whether it's DACH influenced or not but the rhetoric here does not feel Bay Area shaped at all and hasn't for years. It feels like what happens when too many people read about the Valley from too many Techcrunch articles but don't actually live here. It's largely a worldview composed of too many online articles and gripes.
Luma was always a public events app optimized for discovery. Partiful on the other hand was meant to be a a replacement for FB private events when hosting a house party or private gathering. Basically, Luma was always designed for M-F and Partiful was always meant for Sat/Sun.
I like to encounter discussions about German digital health system or the German start up system or neo2. I've never seen them so I doubt it.
Also almost no debates about Polish stuff (Hello neigbours!)
fwiw, my experience is similar. hn has not been about startups, vc funding, or anything in that space for quite a while.
to paraphrase a classic, this place is like a memory of the forum we used to love, and the memory is fading.
Blockchain is all but dead, even the "i've rewritten this thing, it has far less features but it's IN RUST" spam has greatly reduced.
Well, this place (wherever you are) is like a memory of the world we used to love, and the memory is fading... Definitely true too.
You can't expect a place tightly connected to a changing world to stay the same.
His criticisms are entirely valid, because why can't the the thing that has a free spec and will likely dominate that space ... also be good too? Can't we have all the nice things?
The problem is that RISC-V is never going to win at the high end. RISC-V will never have as much money driving it forward as x86 and ARM. As such, the blocks and integration will always lag.
The portion of the market which RISC-V could dominate is the low-end (you know ... the same way ARM climbed up the ladder?) and nobody in charge of RISC-V cares because you have to actually ... SHIP FREAKIN' CHIPS ... and that's, you know, so icky.
And this is the disconnect. Low-end embedded has a bunch of needs and the RISC-V architecture completely whiffs on many of them and has active misfeatures on others while having very little that is actively good in that space.
And many of us are angry about this. It didn't have to be this way.
Qualcomm recently bought Ventana and are looking at paying ARM billions (in addition to their current billions) for the privilege of designing their own cores. They sit on the RISC-V consortium and made proposals like Znew.
We could be seeing a high-performance RISC-V release from Qualcomm quite soon (especially if they can simply swap out the ARM decode for RISC-V).
For example, author claims that saving and restoring all registers in interrupt handler takes too long. But this can be solved alternatively, for example: split register set for use in interrupt and normal code. Or simply add two register banks and allow switching between them (assuming interrupts are not re-enterable). But author claims that ARM is better because it has a "store multiple registers" instruction. It wouldn't help because storing multiple registers still requires multiple bus cycles, and microcontroller probably has a 32-bit bus and no cache, so saving N registers requires N memory cycles - no matter, is it done with a single instruction (ARM), or with multiple (RISC-V). And implementing this ARM instruction makes the core more complicated with little benefit.
As for 3 instructions for array access, in a simple loop a compiler can convert index access to pointer increment.
The real weak points of RISC-V are:
- no trap on integer overflow and invalid FP results . Overflows cause vulnerabilities
- no optimizations for fast context switch, which is required for dumping legacy unsafe monolithic kernels, especially in age of AI actively searching for vulns
- weird vector extensions
In such a simple loop where you access one field in each iteration, yes. If you happen to access more fields, or the same field in different arrays, then you have more pointers to increment.
Maybe I'm missing something important so far...
It definitely could have gone with a less abrasive tone (as entertaining as it is), so it's no wonder it's getting some pushback.
I would say "this could be technically better" vs. "this is already economically better than anything else"
I just think that if you were designing something from scratch, you could actually learn from past lessons, rather than publishing a document saying you learned, and then demonstrating conclusively that you didn’t.
Before this, the author has never recommended others stay away from RISC-V, just stated their own distaste for it and a personal preference to use any other ISA if given a choice.
> I pay anywhere from US $60 to US $200 to ship one dollar chips that people everywhere else get free shipping on
then follows with:
> the difference between a ten cent part and a one dollar part is not a rounding error and it is not a detail you get to wave past on the way to the interesting discussion about encodings.
When shipping is so expensive, doesn't the difference between $1 and $.10 unit cost become less relevant?
Plus, arm cortex-m0+ cores aren't $1, they are also available in $.15-$.30 range.
Westeners like to buy the $.10 CH32V003 as an exercise in minimalism, after all its refreshing to work in an environment with very limited resources. For the same reason people enjoy 1KB demoscene categories.
There's no economics behind it.
Authors argument almost entirely leans on Aliexpress shipping things for "free" to his island. It also has arm cores, but I suppose RISC-V MCUs have smaller odds of being fakes/clones.
Though it feels a bit strange that "I have exceeded the allowed number of requests. (500 times)" when I first clicked the article and I'm pretty sure I don't share the ip of my self-hosted VPN with anyone.
I mean that is not even 10 page view per second. We are not living in 2006. Actually even in 2006 Apache with static page would have been able to handle that on a small VPS. And that is excluding CDN.
This post reminded me of Engineering for Slow Internet (https://brr.fyi/posts/engineering-for-slow-internet), another case where careless assumptions by better-off people can have a huge impact on others.
The 386 and 486 patent should have expired more than 20 years ago. No one tried to open source it. https://github.com/EI2030/Low-power-E-Paper-OS/blob/master/0... There were many companies that had clones in the early 90s, and I wonder whether any of them still have the rights to manufacture them.
" That is a better reason than elegance. and I want to tell Mr Grinberg, that the word priviledge he tosses around in his article also extends beyond the ISA depending on where you are in the world."
Grinberg is an emigre from Ukraine, which isn't the most privileged place in the world. In fact his research articles go deeper than the average software developer in Silicon Valley.
Edit: It also appears Nvidia might also have an x86 license: https://www.nvidia.com/en-us/drivers/uli-m6117c/
Also, https://www.tomshardware.com/pc-components/cpus/intel-licens... (Caveat: The startup is acquainted with the Intel CEO, so it's rare for them to grant the x86 license to non-buddies.)
"Intel provided Rosaic access to an unknown Atom-class core, which enables the company to build its own custom processors based on x86 general-purpose cores, according to the report. The renowned chipmaker plans to ship Rosaic register-transfer level (RTL) code for the Atom processor core, which will let the startup build its custom system-on-chip (SoC) both at Intel Foundry and elsewhere."
What's interesting is that a startup with limited funds would most likely seek a 32-bit x86 license if a) they don't need more than 4GB of RAM, and b), if they don't want to pay AMD for the 64 bit license add-on. :)
OpenFirmware came out of OpenSPARC and is also used by POWER too. Parts of it are used in ARM and RISC-V today (mostly DeviceTree, though arguably quite badly).
Nobody actually wants to make good cores for cheap. Nobody wants to make compatible systems unless forced to. That's why ARM and RISC-V are fragmented messes.
I would personally love to see more Power Systems based projects. Everything is out there, just someone has to want to do something with it.
Fedora Linux even fully supports POWER8+ little-endian systems, and Fedora KDE offers a live ISO you can install on something like a Talos Workstation.
https://lists.libre-soc.org/pipermail/libre-soc-dev/2024-Sep...
Technically just looking at the ISA both SPARC and POWER seem fine enough. So why is nobody interested?
(Talos is interesting but not really an answer to the question, as it seems to be focused on building affordable-ish systems around an existing CPU, not developing new CPU's.)
Also Hitachi's SH-2 & SH-4 patents expired in 2016, so J-core picked up where they left off: https://j-core.org/
MIPS also went open source around 2018: https://www.datacenterknowledge.com/data-center-hardware/mip...
Cyrix famously had to skirt IP laws by using TI and IBM foundries because those two companies had full Intel 3rd party licenses. Cyrix was sued and paid big bucks settlement just to be able to use Intels patent 338 (long expired). Later cross licensing had little to do with Cyrix, and more with National owning crapload of patents they could use to retaliate against Intel - that 1998 deal https://www.intel.com/pressroom/archive/releases/1998/CN0203... resulted in full cross licensing allowing National build straight 1:1 copies of Intel chips if they desired.
When VIA bought Cyrix from National they didnt inherit ANY of those licenses. VIA was sued just as original Cyrix and National did, and once again had to pay big bucks to settle despite just aquiring Centaur with a bunch of patents and Intel license https://www.pinsentmasons.com/out-law/news/intel-and-via-set...
To do that they, at least, should still exist. For most of them this is not the case.
This is especially good if one scopes out a family of ISAs that are ABI compatible such that one can compile down to a semi-pre-optimized portable IR, and just do the last bit per ISA.
And the approach you mentioned here:
> a family of ISAs that are ABI compatible such that one can compile down to a semi-pre-optimized portable IR, and just do the last bit per ISA
I think this is basically WebAssembly and PTX, and one may argue, Java bytecode. Yet look at how much efforts and time it took for WASM runtimes and JVMs to actually produce performant machine code (the "last bit per ISA" you mentioned) for just a couple of architectures! (e.g. X86 and ARM). And I wouldn't surprised if NVIDIA pour even more money on building optimization pipeline from PTX to each of their different uArchs.
I bet it would be pretty easy for a user to interoperate between 67 different drafts of the HTTP spec once they were all written, validated, and library implementations coded. But what would that Cambrian explosion of API revs actually get you?
And while things has died down a lot in the past few years, there is a reason why I wrote the line.
"You do not criticise The Rusted Holy Grail and the Riscy Silver Bullet."
https://rvembedded.com/products/project-lab/
Definitely interested!
RISC-V has put enormous pricing pressure on manufacturers like MicroChip, which is now offering its AVR line of 8-bit MCUs for pennies a piece. Too bad that the 32-bit RISC-V offerings from, among others, WCH are far more powerful at a similar price point.
So, these freight forwarders rent a warehouse in the US, an LLC in the US for paying rent, and give away the address of the warehouse to their customers locally. Customers use the address when shopping online and their packages are dropped off at the warehouse. Then they employ people in the US to collect customer packages in the US into large bags, which are then shipped to the destination country via DHL.
DHL does charge the exorbitant shipping to third world country fees of 35 to 60 to 200 dollars that people here complain about. These fees are the base price for shipping, no matter how small or light the package is.
Then, to recover the fees, packages are handed over to customers at a minimum of 2.50 dollars per pound, per package.
For the business to work, income from these packages has to exceed the shipping cost. In Panama, you can probably fit 100 average packages into a 25 pound bag. That bag costs like 75 dollars to ship from the US to Panama. Then you make 250 dollars when people collect the packages. Local customers trade speed for cost, trading the 35 dollar base shipping price for 2.50 dollars and an extra week of lead time to wait for collection to complete in the US. They also don't have to go to the airport to pick up their packages since the business is ideally close to their house.
Businesses like Temu ship directly from china via companies such as PRS logistics and J&T express so their shipping costs to third world countries are lower and can thus bypass freight forwarders entirely so freight forwarders only remain for items sold within the US, where shipping to third world countries has a base price of at least 35 dollars, and whenever shipping to your country costs that much as a base price, even if it ships from China, or when a business only offers shipping to or within the US.
Sometimes, temu is more expensive than a Freight forwarder, but the user is freed from having to handle any logistics like using a particular address and choosing and registering with a package locker and travelling to pick up packages there and the shipping price remains under 10 dollars. However you still have to use a Freight forwarder for items over 120 dollars such as laptops and some car parts because temu doesn't carry those. Freight forwarding is also done in the exact way described above in China instead of the US because websites like taobao rarely offer overseas shipping. Again employing people in china and renting warehouses near airports there. Freight forwarders also offer marine freight instead of the default air freight.
Of course, renting a warehouse and employing people in the US is expensive by local standards. Worker pay alone is around 1600 dollars vs 600 locally. So, there are only a few freight forwarders which often offer b2b, and then package lockers use their sevices. To the end customer there is no distinction between a package locker and freight forwarder. Some freight forwarders also offer B2C package locker services, others are B2B only.
For example nelcon cargo, Uno express, airbox, mail boxes etc are vertically integrated because they are both B2B and B2C, cft cargo is B2B only. most package lockers do not do freight forwarding themselves and use a B2B service for freight forwarding, the package locker only offers proximity and thus convenience to neighborhood customers. Air freight via Miami international airport is the default, and most freight forwarder warehouses are located near this airport. In China, the bottleneck is not price, but speaking Chinese, so it is often run by locals of Chinese descent and is more niche than shipping from the US. This also means that taobao has a lower shipping volume and thus a smaller local market.
Buyee and Zen market, so called proxy services, are very similar to freight forwarders but the service is allowing foreigners overseas to purchase in Japan because most japanese companies do not offer overseas shipping. And there are a few freight forwarders in china as well.
Without package lockers which is what temu does, you have to coordinate in real time the delivery. Delivery is done during working hours. Not all people have free time to do this because hey are often at work so this results in a high delivery failure rate of 30 percent and logistics companies keep houses and warehouses full of undelivered packages.
And if the user complains because the package could not be delivered near their house, the logistics company assumes a penalty from temu and the user is granted a refund, and they can often pick up the package afterwards.
And taobao has a smaller local market relative to Amazon or other American ecommerce sites because it's in Chinese only and also due to that, Chinese package lockers are rare. However taobao is very cheap even cheaper than temu. Some small businesses buy in bulk from taobao for that reason to resell locally at twice the original sales+shipping price or more. Amazon is by far the most popular e-commerce site in Panama, so much so that yc backed local startups such as cuanto only specialize in artisanal and boutique items like Etsy does.
And of course the LLC is owned by the freight forwarder as a subsidiary or is the freight forwarder's parent company.
Btw, a popular business saying in Panama is that you should always sell at least twice the original purchase price.
It seems freight forwarders are most common in countries like the Bahamas with Laser international freight and Panama where local currency is pegged 1 to 1 to the US dollar, because the value per dollar always remains the same, so buying online is never more expensive due to fluctuating exchange rates.
But they're used in all of Latin America and are very popular in Brazil too with astral freight services. FedEx and ups can be used in place of DHL.
>This is almost satirical.
That's all that needs to be said.
It's like comparing Unity and Godot. Unity is better in every single way but one, you have to license it from a very poorly ran company.
You don't "own" your games, they ship with black box spyware. The pricing for using it can change from day to day.
I swear the Unity C level employs a Magic 8 Ball and consults it for key management decisions.
If you need to edit the Unity Engine source code your looking at a secret additional licensing fee which is certainly unaffordable for hobbyist and most indies.
Vs Godot which is completely free under the MIT license.
Everything about the above can be said for ARM as well.
RISC-V is free for everyone to play with. If you think it sucks you can always fork it and jerryrig it to work on existing hardware.
If you have money you can even get custom hardware for your forked RISC-V.
I very much enjoyed reading this article, I'm optimistic in seeing what OPs students come up with. This is life changing technology that's essentially available to all.
Idk, if your shipping cost is $120, it sounds to me $1 is rounding error.
> A debugger for an ARM part alone a Segger J-Link costs about $600, though I guess for that $100, and add another $100 to ship,so about $200 I could get an EDU edition J-link and no chips or boards. Yaay.
This is bad comparison, you can debug arm soc with <10$ debugger too/
But if you can access to RISC V IC/tools, you can access ARM IC/tools. The Chinese basically spams those ARM IC as many(if not more) as RISC V IC.
To me the author tried to hate ARM for no reason.
I bet they use the same pipeline to produce those chip anyway.
I know I'm not really commenting on any of the technical nuances of RISC-V (my take: trying to be everything to everyone isn't easy, but it can still be worth trying), but I was just so shocked to realize the OP was form the same country.
You have exceeded the allowed number of requests. Your Requests: 500. Request Limit: 500 per minute. Tip: Please wait 60 seconds before trying again.
A 3rd World Embedded Engineer Learns About Caching Generated HTML The Hard Way.
Your Requests: 500 Request Limit: 500 per minute
Would they like a world where Intel is the sole CPU supplier? We were close to that one…
Your Requests: 500 Request Limit: 500 per minute
with no vpn
Does anyone have an archive?
> Simply put, the things a high-end CPU needs are diametrically opposed to the things a small cost-saving microcontroller core needs.
> The conclusion he draws is that no single ISA can serve both ends, and that RISC-V fans are fooling themselves, in theory the premise is true. The conclusion does not follow, and I can show you why from three parts sitting on my desk as we speak.
> CH32V003. This is the cheap "RV32EC" with sixteen registers, no multiplier, no divider, machine mode only,
> CH32H417. A dual core MCU that is unmatched in performance to price point and is at the higher end of the MCU line
> Baochip. A VexRISC-V with an MMU built around a stack thats open from silicon to os Baochip-1x: A Mostly-Open, 22nm SoC for High Assurance Applications
Uh, which one of these is a datacenter server cpu? Or a workstation cpu? Or at least a developer laptop cpu? How about a Raspberry Pi 4 level SBC (supporting latest ubuntu and fedora releases, driving a display that runs a browser and plays video ...)
There's a lot of angry indignation but it seems obvious that Dmitry is quite right about this.
But I found this is where this blog post starts making a lot of sense:
> Has anyone tried adding an MMU to a Cortex-M? The physical tradeoffs are real, the difference is that with RISC-V, the ISA owner does not decide for you where that boundary must be drawn. If you want virtual memory on ARM you license a Cortex-A instead, which is a different core family, a different profile, a different negotiation, and a different royalty.
> Compare what happened with Baochip. The RISC-V privileged specification defines supervisor mode and Sv32 paging as optional things an implementation may provide. VexRISC-V is an open core, somebody added an MMU to it. bunnie built a chip around it and runs a microkernel with real process isolation on it
Yeah, that is a good point. We're still in the low-end specialty realm, but that is real interesting advantage for RISC-V, a good reason for it to exist.
As for shipping to Trinidad and Tobago ... this post is trying too hard to turn this into moral issue, but it seems a bit random (OrangePi cost $30 and shipped free? you can also get arm-based and stuff from the same places), and the vast majority of people don't live on semi-remote islands, it doesn't make sense to consider this kind of accessibility above all else, and it's strange to blame Dmitry for not thinking of you here.
Some serious stuff he builds on top of those chips.
I read the "They Should Have Known Better" article and forgot it. I've seen this before. I know it's hot air and does not matter, and I can't afford to worry about things that don't matter.
When I say I've seen this before, I'm talking about ancient history: controversies so old and so laughable that they've been forgotten. When, for example, AMD handed the world AMD64/X86_64, the same things were said: fragmentation, legacy+flawed ISA, etc. That has not aged well, and "They Should Have Known Better" won't either.
The "fragmentation" argument has no merit. The jumble of extension names and profiles in RISC-V are, in fact, direct evidence that RISC-V is succeeding: it's the RISC-V ecosystem aggressively, collaboratively and successfully tackling pain points and solving them. This is what RISC-V is supposed to be doing, and it's doing it, and empires are being built on it.
Take this part: "The existence of CLIC and various proprietary 'fast IRQ' / auto-stacking extensions is an additional indictment."
CLIC is miraculous. It's an advanced embedded interrupt controller, and it's wonderful: it brings the equivalent of ARM's NVIC to RISC-V, except better. You can implement an extremely efficient scheduler that guarantees deadlock-free concurrency: bare-metal, real-time, hardware-accelerated "Fearless Concurrency," on an MCU with no RTOS![1] Its appeal is so great that, despite still being a draft spec, the leading RISC-V MCU designers are adopting it. Espressif's ESP32-S31 has it, for example. The chaotic emergence of this awesome thing is what is condemned as an "indictment."
Speaking of ESP32-S31, it's going to be a monster when silicon becomes available in quantity. This RV Embedded writing mentions MMUs a lot. Guess what? The S31 has an Sv32 MMU. It can run Linux. Not μClinux. Real Linux. It's already been done twice (that I know of) on the Espressif eval boards. People like Armstrong Subero are going to change the world with it.
That's the froth of RISC-V. The ground is shaking, and the peanut gallery of ISA wizards has no power over it. In a few years, after RISC-V has lain waste to our world of proprietary ISAs and Western IP regime rent seeking, "They Should Have Known Better" will look as silly to everyone as it already looks to me.
Yes, the package will be less friendly to DIY assembly. The greater number of GPIO are definitely welcome however: it's a high feature device and they are needed.
Same reason the southern accent has overlaps with west African dialects.
It sounds like trying to remove authority from the person that criticized it, but I think it is a good idea to focus on the arguments, and not on the ad-hoc assessments and conclude from there whether they are valid or not.
I will read it later, no time now. Thanks for the link anyways.