Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • One man's trash is another man's treasure. The mistake is being absolute and ignoring this fact.

    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.

  • Original HN discussion referenced:https://news.ycombinator.com/item?id=49298035
    by kqr2
  • Nice read!

    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 got that too and couldn't read the site.
  • I think it’s telling the site owner, not us.
  • I lost the thread of his argument when he brought up the shipping expense:

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

  • Difference between $1 and $.10 is always irrelevant unless you're mass manufacturing, which I presume you aren't on a remote island.

    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.

  • The difference is shipping from the us to shipping from china. From the us you pay 200 dollars for a 1 dollar arm processor due to shipping. From china you pay 4 dollars in shipping for a 10 cent processor. Apparently buying arm processors in china is not reliable and of course you wouldn't buy a RISC v processor in the us due to shipping costs when shipping from china is 50 times cheaper.
  • To me it feels like the difference in positions is "this could be made better" vs. "but this is already so much better than before". Both are right.

    Maybe I'm missing something important so far...

  • Yeah the complaints in the original article are valid, but it's like complaints about Android or iOS. There are plenty of valid complaints against either, but neither is strictly better than the other.
  • At least for me, I agree with both of the things you said. RISCV is a significant improvement on a lot of of the status quo in situations where it is currently getting design wins. But it also could’ve been a lot better in simple ways that should have been thought of.
  • Maybe. I'm not sure if the original author's intent was to say how risc-v could be better or to say it is bad and people should use other (proprietary) ISAs instead.
  • > the difference in positions is "this could be made better" vs. "but this is already so much better than before"

    I would say "this could be technically better" vs. "this is already economically better than anything else"

  • I was thinking the same. RISC-V is certainly impressive and I'm glad we have it, but the original article isn't wrong in its complaints either.

    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.

  • > He derives the case for the chip and then spends the rest of the article annoyed that the chip exists. This is almost satirical.

    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?

  • Because the people driving the RISC-V ISA all care about delivering IP and not chips and, as such, only care about the high end portion of the market.

    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.

  • Because 'good' is rather subjective when it comes to ISAs.
  • I disagree with some points in "RISC-V They Should Have Known Better".

    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

  • > As for 3 instructions for array access, in a simple loop a compiler can convert index access to pointer increment.

    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.

  • I love the article, it's a breath of fresh air compared to the usual bay area centric takes. However there's just one issue:

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

  • So, you are calling the author a liar?
  • > it's a breath of fresh air compared to the usual bay area centric takes...

    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.

  • > It does not take $60 to ship small sub $1 chips from Asia to Nigeria/Bangladesh

    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.

  • > from Asia to Nigeria/Bangladesh.

    Bangladesh is a country in Asia...

  • i don't know how trustworthy rateships.com is, but according to them shipping costs to nigeria and trinidad are similar. and as for the last mile, the cost probably goes up because local shipping is rather unsafe (higher rate of theft of packages).
  • It could be bureocratic barriers. For example, Turkey recently changed importing laws so that anything(even stuff sent to you for free) from outside the country is subject to tariffs & import costs. Importing a cheap component worth 1$ costs like 300$.
  • Is this comment on shipping costs from Asia to Nigeria/Bangladesh based on your experience? If there is a less expensive way then share the approach to help others :)
  • This is a bay area centric take on a non bay area centric take.

    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

  • I believe there will come a day when RISC-V has comparable or better performance than ARM and x86_64.

    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.

  • Competing RISC designs tanked for a number of reasons, but not just because Intel and AMD started pumping money into their products.

    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.