I don't really understand the author's conclusions about cost and shipping, and how RISC-V is cheaper and more accessible to people outside the US and Europe. He first talks about how getting $1 worth of chips can cost $60-$200 in shipping for him due to his location... but then by the end claims that RISC-V gives him "an architecture that arrives in my country at ten cents a part".
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.
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-V is great for embedded because companies can build it into custom chips with specifically the functionality they need, and because of how cheap it is for low-end use cases since there's no license fees.
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.
> Personally I don't see the benefit of this since you're going to have to recompile your software anyway
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.
Different RISC-V dialects might as well be as different from each other as English is from German. Sure, the cognates, family the resemblance, and common(-ish) alphabet make some things easier, but if you're shipping a manual, you still need to do it both in English and auf Deutsch unless you rely on machine translation.
So it is with the family of mutually incomprehensible ISAs called RISC-V.
Yeah I know this mess in PowerPC. There is IBM Power, there is MPC5xx ISA, there is VLE and and several other dialects. Some processors are doing those some doing others, some needs bit to signal if program runs VLE... just crazy chaos.
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?
* 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.
> 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’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?
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.
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 :)
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$.
I am in Asia, this means nothing, it's the largest continent on earth. I don't pay as much for shipping as the author does, but his struggles are nevertheless relatable: most sellers refuse to ship here, most of those who do want dozens and dozens of dollars for it, and some (few, usually Chinese) sellers save the situation from being completely hopeless.
In my experience, people in the United States often (incorrectly) short hand East Asia as Asia just like the people in the city of New York will often (correctly) short hand New York City as New York.
> In my experience, people in the United States often (incorrectly) short hand East Asia as Asia just like the people in the city of New York will often (correctly) short hand New York City as New York.
In my experience, the only demographic who complains about “Asia = east Asia” are people from South Asia, aka Indians/desis
Ironically (for my generation in the UK at least) "Asian" meant "South Asian" and for a long time we didn't have a useful shorthand for "all parts of Asia"
When the term started out, There was nothing called United States (As a country or its current culture/s). And I am not sure if this happens outside the US anyway.
In the context of microcontrollers and electronics, the likeliest intended meaning was shipping from China, South Korea, Taiwan and perhaps Japan, because that’s where the bulk of the fabs are.
> 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.
> 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.
>HN hasn't been Bay Area centric in years. Honestly, most comments and usership on the platform seems to now align with DACH.
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.
As someone from the DACH region I very much agree with this. I don't see a shift from typical US opinions to opinions often held in the DACH region. Not at all.
> I honestly do not get this at all. HN remains very US-centric to me, and apart from some takes on tech rights, does not really remind me of my experience in DACH.
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.
While I appreciated your source
1.) I doubt 99% of Europeans work during 3am - 9am
2.) At least there can be other reasons:
2a.) EU times and African times are basically the same and Africa has a huge population.
2b.) India is closer timewise to EU/African time zones
2c.) What are about posts afterworks?
" RL conversation topics in the Bay Area tech scene are entirely different from those on HN shows a massive divergence in userbase. "
Any proof?
> 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?
I don't think the Author disagree with what the original article wrote. If anything everything he said seems to reassert what the original article intended to state.
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."
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.
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.
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.
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.
I disagree, compiler optimization and software ecosystem in general already take a really really really long time to build, and I think it'll take longer without a standardized low-level binary interface i.e. ISA to enable rapid distribution.
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.
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.
What exactly does a bespoke ISA buy you? What will justify hundreds of engineers writing a new good one & working through the compiler support?
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?
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.
"Now price the same journey on the other side, forget x86-64 and that duopoly, patent minefield, with multi-thousand dollar debug probes; we'll take a look at ARM."
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.
There are 386 and 486 open source reimplementations in Verilog (see z386 and z486). As far as I know, existing commercial 386/486 chips still manufactured (yes they exist!) are descendants of Cyrix work, not Intel or AMD. Consequently, VIA may be contractually holding those back rather than Intel/AMD doing anything there.
Thanks for that information! I have been interested in getting x86 produced in smaller nanometer (e.g. <32nm). My project: https://ei2030.github.io/FemtoTX/#about
"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. :)
I'll also point out that we've always had better starting points for open source high performance cores. SPARC and POWER both have open ISAs and open-source cores with useful performance. The UltraSPARC T1 and T2 processors were open sourced under the OpenSPARC project. POWER has the OpenPOWER project governing the Power ISA, and IBM itself created Microwatt, Chiselwatt, and the A2I/A2O cores as open source that people can build their own PowerPC systems from.
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.
True, and the only reason I'm partial to x86 and even some older ARMv cores is that there is a huge existing software ecosystem already available, reducing the need to develop new bootloaders and ports, as coding hours aren't free. CISC cores are treated as if they are a dirty word, but are more versatile for covering various applications.
PowerPC at least still has a living ecosystem, even from the bootloader level. GRUB can boot from an OpenFirmware system. There's also yaboot if you hate yourself. ;)
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.
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.
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 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.
A fun fact about ChatGPT and its ilk is the final RL polishing of the responses was outsourced to Nigeria and other places with cheap labor, so the patterns you’re picking up in the article aren’t that the author sounds like ChatGPT, it’s that ChatGPT sounds like the author.
Same reason the southern accent has overlaps with west African dialects.
Just an unlucky spawn point. We need to focus on ourselves. "oh no shipping to some remote island is expensive compared to NYC that has next day free on everything" Well, duh.
Naïve take. We live in a global neoliberal economy, our standards of living are the direct result of introducing scarcity and other forms of exploitation elsewhere while keeping domestic populations largely unaware of how unfair their position is. There is no ethical basis to simply "focus on ourselves" here. We must do the exact opposite.
Let’s take the rationalist approach, then: does the author of this blog post seem like someone who could contribute reasonably to humanity’s future? Does it seem like we might be doing ourselves a disservice by ignoring them, and those like them?
“I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops.”
― Stephen Jay Gould
Edit: y’all really don’t like being told you should care about other people, huh?
It's a distasteful take to be sure. But, what is GP supposed to do?
Frankly I'd rather be told that than the other common but tired SV-resident take of "just hustle, bro, stop sleeping, hustle hustle hustle. Learn to code, take loans from friends and family. Doesn't matter that you're born in a shithole, I was born in a median family myself, we only had one car and we rented our house!!! Just gotta work for it, everybody can achieve it. Those who don't, are clearly not working hard enough."
yo this is actually some really fire reading. i had to read it twice then go back and read the original that he's responding to here. i feel full of wonder right now seeing people who are this deep into compsci debating merits in the marketplace of ideas, there's just so much going on globally with computing that i never even get to see. super fascinating to read about the different constraints at play here even the global socioeconomic ones and how they apply to the chip world in general. it sounds like risc-v's real play is democratizing access to the entire embedded stack
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.
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.
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.
So it is with the family of mutually incomprehensible ISAs called RISC-V.
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?
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.
The improvement is entirely "we don't have to pay ARM"
> 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?
> 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
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?
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.
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?
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."
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.
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
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.
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?
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.
Your Requests: 500 Request Limit: 500 per minute
Your Requests: 500 Request Limit: 500 per minute
with no vpn
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...
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.
[1] https://rtic.rs/2/book/en/
> 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.
https://rvembedded.com/products/project-lab/
Definitely interested!
Does anyone have an archive?
Same reason the southern accent has overlaps with west African dialects.
Some serious stuff he builds on top of those chips.
“I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops.”
― Stephen Jay Gould
Edit: y’all really don’t like being told you should care about other people, huh?
Is that really your take?
Frankly I'd rather be told that than the other common but tired SV-resident take of "just hustle, bro, stop sleeping, hustle hustle hustle. Learn to code, take loans from friends and family. Doesn't matter that you're born in a shithole, I was born in a median family myself, we only had one car and we rented our house!!! Just gotta work for it, everybody can achieve it. Those who don't, are clearly not working hard enough."