Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A third world engineer responds to “RISC-V: They should have known better”

rvembedded.com

Post reply on HN
Print view View original

161–170 of 350 posts

Re: A third world engineer responds to “RISC-V: They should have known better”

#161

Post by camel-cdr »

rowanG077 wrote: post #133
999900000999 wrote: post #124

>He derives the case for the chip and then spends the rest of the article annoyed that the chip exists. >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 s…

I'm not a professional game maker. But having used unity in anger in the past I found Godot a breath of fresh air. What unity really wins with is the unity asset store.

Which may actually be a good analogy. One thing I've seen rarely discussed is existing expertise/experiance, existing varification/tooling and existing quality reference implementations. Arm wins in all of the above over RISC-V currently, if you have the money to license from/work with Arm.

Re: A third world engineer responds to “RISC-V: They should have known better”

#162

Post by 986aignan »

logdahl wrote: post #130
egypturnash wrote: post #100

Rate Limit Exceeded Too Many Requests 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. https://archive.md/9FaRC

I haven't seen this before, but this ReCAPTCHA required "mobile verification" from me, and asked me to download an app. Oh what a world we live in...

It's been unevenly rolled out, but is mostly Google using attestation to tighten their grip.

https://news.ycombinator.com/item?id=48143997

Re: A third world engineer responds to “RISC-V: They should have known better”

#163

Post by madushan1000 »

andai wrote: post #146
ndiddy wrote: post #66

I think he's kind of speaking past the original author. The original piece is basically about how the author doesn't think that RISC-V will take off outside embedded, because of some design decisions that lead to poor performance compared to ARM64 and because so much of the ISA being optional means that there's too much fragmentation to make binary distribution feasible. Meanwhile, this piece is mainly about how RISC…

Interesting. So I've seen a lot of reviews of RISC-V machines and they seem to be a decade or more behind in terms of performance. 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 permanentl…

x86 is a horrible architecture, but most of the modern high performance processors are x86. They're only now getting around to making comparatively performant ARM chips.

Not having decently performing risc-v chips right now doesn't mean anything other than nobody spent enough time and money on accomplishing that.

Re: A third world engineer responds to “RISC-V: They should have known better”

#164

Post by simcop2387 »

phire wrote: post #152
andai wrote: post #146

Earlier quoted context omitted.

Interesting. So I've seen a lot of reviews of RISC-V machines and they seem to be a decade or more behind in terms of performance. 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 permanentl…

No. 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.

> 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-...

[1] https://bolt.graphics/

Re: A third world engineer responds to “RISC-V: They should have known better”

#166

Post by kelnos »

armstrongsubero wrote: post #126
cupantae wrote: post #84

Earlier quoted context omitted.

I’d really like an explanation here if the author is reading. And how does shipping cost scale with quantity? Can you get that to be small per unit on big orders?

Hi there, shipping has a floor and then it scales, but it scales far slower than the order does.... so if you buy like one resistor from DigiKey or Mouser, that starts around $60, a hundred resistors costs about the same if you add chips and weight and it climbs from there, but $60 is the floor no matter how small the order.... So per unit shipping collapses with quantity, which is why the part price matters more her…

> at ten cents I can hand a student a part they are allowed to destroy. [...] at a dollar a part a teacher flinches

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.

[0] https://news.ycombinator.com/item?id=49323318

Re: A third world engineer responds to “RISC-V: They should have known better”

#167

Post by simcop2387 »

yjftsjthsd-h wrote: post #98
whateverboat wrote: post #85

Earlier quoted context omitted.

The huge number of companies building RISC-V chips and really crazy optimizations that they are doing in all kinds of spaces are a very real counterweight to your notion. 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.

> The huge number of companies building RISC-V chips and really crazy optimizations that they are doing in all kinds of spaces are a very real counterweight to your notion. 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?

Take a look at some of the really new ones, like the Milk-V Jupiter 2 based around the SpaceMIT K3[0]. Single core is still lacking but the multi-core isn't all that far behind a pi5 (350 vs 900 single core and 1700 vs 2100 multicore in a geekbench beta version).

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.

[0] https://youtu.be/vSKA6thLI1U?t=993

Re: A third world engineer responds to “RISC-V: They should have known better”

#168

Post by acutelittlebox »

ploxiln wrote: post #77

This blog post is very defensive and argumentative, which I guess is fair considering Dmitry's post is similarly inflammatory, but most of it was really not convincing: > 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…

the author just focused on his personal experiences regarding RISC-V and what he's been able to see himself as an embedded developer. there's already RISC-V SBCs that are on par with the Raspberry Pi 5 and in terms of IPC the best RISC-V cores are only lagging 5 years or less behind the best x86 and ARM cores.

Re: A third world engineer responds to “RISC-V: They should have known better”

#169

Post by codedokode »

logdahl wrote: post #130
egypturnash wrote: post #100

Rate Limit Exceeded Too Many Requests 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. https://archive.md/9FaRC

I haven't seen this before, but this ReCAPTCHA required "mobile verification" from me, and asked me to download an app. Oh what a world we live in...

Find traffic lights for me. If it required an app, I would close the page.

Re: A third world engineer responds to “RISC-V: They should have known better”

#170

Post by ChickeNES »

kelnos wrote: post #114
Ericson2314 wrote: post #88

My perspective using Nix is that it's hardly worth standardizing ISAs. Recompiling software is easy and we should have a Cambrian explosion of different designs. 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.

An explosion of ISAs means the available talent for writing optimizing compilers will be stretched much more thinly. Unpopular ISAs will have slow, buggy codegen, and the popular ones will suffer somewhat, too.

It's 2026, "available talent" is my weekly allowance of tokens from OpenAI and Anthropic...
Post reply on HN