RISC-V isn't killing Arm (yet) 

Got to the moon with a calculator. Couldn't get there now if we wanted, too complicated. Go figure that one.

Or complain about data transfer speeds of 150 MB/s. I still remember spending an afternoon backing up the 5 MB hard drive on our first IBM PC to 360K floppies.

​@@JustinEmlay It's easier than ever, if you got money. Apollo missions were glorified PR stunts to one up the USSR.

​@@JustinEmlaynah its easy..they just didnt want to spend too much money on it..

@@JustinEmlay I don't think it's modern software that's holding back a return to the moon, the calculations really are quite basic, it's not magic. Money and rocket designs are a bigger issue.

Well unlike X86 and ARM grew as a business-to-business need inside companies. Most of RISC-V grew in the academic world for the sake of doing it and the intent for people to use it too. It`s awesome how far we have come in that area.

I wouldn't give "ethos" any credit here. Advances in RISCV are purely cynical so far, but it is competition, so that's good at least.

@@ShannonBarber78 I think Samsung's first use was in the camera and the 5G radio in the Galaxy S20. I couldn't find anyone interested in RISC-V when I worked at Samsung Research in 2017, which is one reason I left to join SiFive. Qualcomm says they've been shipping some RISC-V cores in Snapdragon SoCs since 2019 -- 650 million of them they said in December last year. And, yes, the guys at Berkeley ported gcc to RISC-V in parallel with creating it, though several totally incompatible redesigns, and had Linux running pretty early too, in emulation and on FPGAs.

bro, "n*xes" is a slur...

@@BruceHoult It made sense to stop buying ARM solutions for that sort of thing. I'm looking forward to general applications.

RISC-V needs #RedShirtJeff to optimize errant drivers.

😂😂😂😂😂

Damn, this industry made a lot of efforts in almost 40 years

The Cray at least had ECC memory and could be trusted with nuclear weapons design

@@shanent5793 You could run 3 of those and compare results instead. More reliable than ECC and still cheaper.

@@meneldal how do you do those comparisons? If it's over gigabit ethernet you'd be lucky to get a couple megaflops

@@shanent5793you compare the final results not every step. It's not like memory is likely to fail several times within a minute or so.

I can definitely see it eventually taking over in a big way on the low end. Where performance, and even power efficiency, are not that big of a deal, and you need something a touch more capable than a RP2040 from the Pico, but without the costs of an ARM license. Hopefully it won't get stuck in that niche, and instead it can slowly grow into other spaces as it matures.

@@FieryPouncer Milk-V announced recently that in 9 months they are going to release Oasis computer with SG2380 SoC with 16 P670 + 8 x280 SiFive cores, although the latter ones should be mostly used as a NPU and not OS scheduling. Whole mobo costs around 100$ with pre-order coupon and in my opinion it's shockingly spectacular, now we as a community need to develop a nice software ecosystem not to let RISC-V die out

Afaik there is just one MCU with decent market share using a risc v architecture, ESP32 S3 I believe. But I don't think RISC-V will break the ARM dominance in this space. Toolchain, Certification (especially safety) and experience is miles ahead and gets better every year for arm

@@pawe460 Google announced they are working hard to make RISC-V a first tier architecture for Android (next to ARM and X86). And I'm even surprised how many things on Linux already work on RISC-V. I recently tested SimpleScreenRecorder on a VisionFive 2 RISC-V SBC, and I'm pretty sure the author never had RISC-V support in mind.

Then its prolly gonna work its way up tbh. But for now its just gonna be micros and Raspberry pi-like stuff

Anything but to trust google supporting risc v? Yeah sure, google is the one who destroyed android by making it less open source, nowadays android is such a joke os, it almost restricted as iOS. Android being open source is just a scam or pr stunts, not real open source.

Yep :( And nice job on that GPU Pi :D One of these days we'll get a Pi to work with the GPU... and have it mounted in the cooling shroud!

@@JeffGeerling thanks! I'm looking forward to seeing a Pi working with a GPU!

I would looooooove it if they found a way to get CM5 to be same form factor. So much more fun to be had if I had a stable working PCIe Gen 3 lane...

​@@JeffGeerlingconsidering that the old cm4 had 2 dsi and 2 CSI porta and the cm5 has only 2 hybrid ones it might mean that they have some pins free for the piece X1 bus

The main problem is uprooting comparability. ARM filled a needed niche, and by all accounts an "empty" niche. The reason why we won't see x86 fall is due to the last 30yrs of development and the largest amount of focus. Arm has done that for its niche in the mobile phone market and even in the Microcontroller market. Though I would agree in the super small Microcontroller (like remotes), it could have a place due to the lower costs ($0.001 off is a lot for something that costs $0.01 in bulk order) and the lack of legacy need.

I'm afraid you're one of the overhypers. You try to hold it against Arm that it took over 20 years to see an OoO chip, but that's actually just because the first two decades of Arm were the 1980s and the 1990s. In the 80s literally nobody was selling single-chip OoO microprocessors. That began to be a thing in the 90s, but it was far too expensive for a tiny company like Arm. Next, we have to talk about actual ages of the Arm and RISC-V ISAs. RISC-V derives a lot of things from older RISC ISAs, and modern Arm is technically only about 10 years old (counting from first commercial chip). You see, the 64-bit Arm ISA was a complete do-over. You can design dual-mode 32/64-bit Arm cores, but the Arm chips making waves right now (such as Apple's A and M series, and Qualcomm's new Oryon) are 64-bit only. The first commercially available 64-bit Arm was Apple's A7, which shipped in the fall 2013 iPhone refresh. (It was OoO, by the way, so 64-bit Arm went from zero to OoO in one step. Doesn't really mean anything, but you seem to think it's important.) The big problem for anyone who wants to believe RISC-V will inevitably overtake Arm64 is that Arm64 is a very well designed ISA and RISC-V is not. None of the mistakes in RISC-V's design are fatal, they just make it harder to create high performance RISC-V chips, and possibly may result in extra power and/or die area.

It may yet, but on the timescale of decades. Arm has been around for years and years, but really only started taking off when mobile became the dominant form of personal computing.

X86 has been around since the 70's and ARM, 1985.. super fast processor designs with full software support don't appear overnight.

*easier than (comparative)

I don't know why. Download Image-55 (from December '22), burn it to an SD card, insert card, turn it on. That's all I had to do on mine. With more recent OS images you also need to flip one DIP switch of the pair (the one closest to the middle of the board) to the other position. That's again all. There were a couple of images released early this year where you had to do a complicated thing with also re-flashing the onboard eMMC, but either the original Image-55 or a recent one avoids that.

Yes pls!

Did you set the dip switches correctly?

If there is anything that RISC-V has in spades it's passion. ARM being shady and that the ISA is open (don't know if any open-source RISC-V cores have actually been fabbed yet), means that you have fanboys everywhere. There just needs to be enough boards put out there for the critical mass to start snowballing.

The Pi 5 is facing an uphill battle. If it really has only HEVC hardware decoding and no other decoders, that's not nice for a desktop experience. On the other hand, we are still waiting for a proper driver from Imagination Technologies for the RISC-V SBCs. It looks like we can test Vulkan soon on the VisionFive 2 RISC-V SBC. Not sure when we get access to all the hardware video codecs.

Support will never be the same when it comes to commercial software on Linux. Imagine having to support your program on a couple different kernels, several different display servers and audio architectures, half a dozen desktop environments on dozens of distributions, often with 3-4 different release schedules to choose from, it's an absolute nightmare.

⁠​⁠​⁠@@LivingLinuxUphill battle as it ages maybe, but right now the RPi 5 has a months long waitlist for backorders.

Linux devs are embracing RISC-V in a big way. As long as you can run Linux on it, it doesn't really matter what the ISA is. From there, if somebody's able to make a decent profit off of making chips for data centers or SBCs or whatever else, and the potential is definitely there since they don't have to license the ISA, you will see widespread industry and hobbyist adoption. Some big companies are embracing RISC-V for microcontrollers and AI stuff. Apple's been hiring RISC-V people either to work at Apple Silicon or possibly work on porting over their software on somebody else's dev boards. I think we'll see a transition period soon where there are comparable RISC-V and ARM SBCs being sold side-by-side from a number of companies, and then one or the other will eventually achieve dominance. RISC-V likely has the price advantage at the low end, which means we could see more expensive ARM SBCs and less expensive RISC-V SBCs for a while before companies just decide to switch over to RISC-V at the high end too, assuming the performance and efficiency can scale right. This is an area of technology where the low end drives the trajectory since eventually low end chips become good enough for a lot of tasks and most purchasers in the market are very price-conscious.

Cool, wish you have luck! I’m making my own cpu too. At the moment, I will won’t use pipeline method. For the actual model that I’m in development, my method is using positive trigger of the clock, to decode instructions and activate the control unit. Then negative trigger of clock is used to storage/complete. In my next model, pipeline will be implemented for practice, improvements and get abilities.

I forget to tell you that my computer architecture is based on: RISC, Princeton arch, SISD execution.

I think that it IS really good that MilkV is pushing its products out early. So that we can play with them test them and as long as MilkV takes the feedback then the community benefits which will help lift RiscV up. Jeff seemed to be having fun. And we got a cool video as a result.

@@jamesboulton2722 True but it sucks that Jeff ended up with a product that didn't even have a quick start guide up for it yet

Not just Chinese companies. They all put out products prematurely. But that's not always a bad thing, as the other comment here says.

@@jamesboulton2722 I agree, but I've seen it where someone who wants a RPi equivalent for a project and isn't super-in-depth will likely hit a skill/patience gap getting something like this to work. Granted, until this video, this product would likely have been unknown to those exact users, so it's kinda a chicken-egg problem. As long as those promoting the products do what Jeff did here and lay out the process to get it "functional" then I think it's not a bad idea to crowd source bleeding edge products. But I've seen consumer-grade products in big-box stores that get abandoned by developers and so anyone buying them are left with either a mountain of technical work to get it to a base working state or trying to return an open electronic to a retailer who likely doesn't care they're selling dead goods.

I'd sooner support western companies, so I'll stick with the Raspberry Pi products. We've lost enough tech companies as it is.

The community is pretty solid and continuing to grow. There's a lot of enthusiasm for this technology among both industry and hobbyists. In the hobby space it's just very niche and will take a while for the hardcore nerds to provide enough feedback to companies and work out the bugs. From there, we'll get more chips and more SBCs. Major industry partners will adopt it more and more. A few companies will emerge as RISC-V leaders. And then we'll see. I can imagine a company like Apple eventually switching to RISC-V somewhere down the line just to avoid paying for ARM. They've already hired RISC-V specialists, and I'm sure Apple's looking at their nine-figure ARM licensing bill wondering if they might be able to save some of that money. That won't be in five years, but maybe 10 or 15. RISC-V so far is on a much accelerated timeline compared to ARM. We're already seeing it pop up in all sorts of special applications like AI.

Well then good job, number 14!

It's like the ln command, or tar... you do it a thousand times but you still have to look back because it's just not intuitive (at least not to my brain!).

@@JeffGeerling If you are referring to the order of arguments, think ln as cp and imagine you are copying a file. That helped me to finally remember it. cp original.txt copy.txt ln -s original.txt fake_copy_hahaha.txt

RISC-V is rapidly taking over in those sorts of microcontroller applications.

There's a few good boards already, and in the next couple years there's going to be a lot more on the market. They may not be the absolute best, but nerdy folks will buy them to tinker around with, and that will fuel more R&D budgets and more boards. The idea of RISC-V has excitement attached to it that ARM can't hope to match, for the types of people who like to buy these boards. At the same time, the AI market is embracing RISC-V, and lots of big companies are buying in for all sorts of embedded apps. Lots of real world uneasiness is also driving interest in RISC-V (or rather, driving people away from ARM) at those big companies that want to hedge their bets.

Like many new tech things, I think it's partly chicken-and-egg. As more devices come, slowly more software will be ported, and more people will be willing to dip the toes in the water. But that won't mean much on SBCs at least, until there are more competitive RISC-V cores on the market.

It's in the same place that arm was just a decade ago, and free is a pretty good motivator for even faster development.. We have the power of modern processor architecture knowledge on our side as well.

It will really depend on what markets get targeted. Eventually, all of them will be and I think RISC-V will be very competitive.

@@fakecubed truly, for now most RISC-V startups are focusing on low-power, embedded usecases. Baremetal stuff on RV makes a ton of sense at this stage. But I can see it getting into the Android space too eventually

@@suhaskv There's also the Ventana Veyron which aims to provide high performance data center compute. I think we'll see the big three cloud providers offering it before too long like how ARM recently started to be embraced in the cloud. It's apparently competitive with existing hardware using other ISAs, including performance per watt in V1, and V2 will be another leap in performance to hopefully match or better many near-future hardware offerings. The big three can afford to throw enough money to get their custom tech stacks working on it. If Ventana can keep things going like that, RISC-V could be a major player in the cloud.

I had trouble getting my monitor to display anything. Some people had better luck, so it may just have been my older HP monitor not being as compatible... not sure

What CM4 board have you tested that worked with Turing Pi 2 apart from. RPI CM4? I can't seem to find any general info of other brands working on it apart from RK1, Nvidia's.

Qualcomm also laid off a lot of people. So did Intel this year. Looks like bad times are coming for the chips industry in general.

@@LivingLinux Economy in general?

Diversity hires purged

Yeah, been a rough year... though the past few years were also a bit insane with hiring rates and funny money.

You've got me curious, now. What were the flaws in PPC that you saw? I do agree with you that Apple is probably going to end up switching to RISC-V down the line. They will probably (and maybe already have been) start with small RISC-V based chips on their boards controlling batteries and the like, and just not tell people. So much of Apple's hardware is a black box anyway. They could work their way up from there to watches, phones, etc.

@@fakecubed​Posting a detailed analysis of the PPC architecture in a RU-vid comment would probably go to far and RU-vid does not like external links (each time I post a link, no matter what link, no matter what destination, other than RU-vid itself, my comment vanishes within a few minutes). But in a nutshell: PPC basically tried to make everything different than existing architectures of that time and that's rarely ever a good approach, since the only reason to make everything different is when everything sucked but that's never the case. Architectures may have flaws but they are not 100% flawed, as then they would be useless. If you change everything about cars, you end up with a sailboat, which is not a useless product but it is useless if your goal was to design a better car. A GPU is also a useful piece of electronics but it's no replacement for a CPU and incapable of running standard software; at least it could never do so efficiently (of course, you could emulate an entire general purpose CPU within shaders, that would work but would also be very slow). The instruction set of PPC is not designed for normal computer tasks. It's a bit like IA64 (Itanium), which I saw for the very first time and immediately thought "How will a normal, modern UI application ever be able to fully utilize that instruction format or somehow even benefit from it?" I cannot explain that in detail here, but just look at some numbers: ARM has 19 different instruction formats (actually just 18, one is just a special case of all the other ones), PPC has 15 different base formats, with almost each of them have 2 to 4 sub-formats, sometimes 7, yet one has 35 sub-formats. Sure, x86 has more, but x86 is a CISC instruction format, not RISC. The ARM instructions are dense and a single one can combine a condition, a math operation and a logic operation, all in 32 bits; so very common source code constructs will result in a single ARM instruction. On PPC you need 3-6 instructions to achieve the same outcome, again, each 32 bits. RISC-V has only 4 base formats, with 2 extra ones that are just variants of two already in the base set. It's less densely packed than ARM when it comes to function but more densely when it comes to working with data (e.g. intermediates) and RISC-V allows for way more instructions in total, so it doesn't have to stay RISC all the way, it can do things like adding a single instructions that performs a complex operation that would otherwise require plenty of instructions if that should ever be required or vastly beneficial. Also while x86 and ARM both offer 3 different kinds of memory barriers, PPC only has one. This makes it easy to "not pick the wrong one" but it also means that a lot more synchronization must take place than would strictly be necessary, which is an issue if go multi core and want to keep increasing the number of cores. RISC-V has two and both reserve bitfields for future use to make them even more fine grained, if required to increase scalability. There are other things that make it way harder to scale PPC and x86 core-wise than it is for ARM or will be for RISC-V. And even if you can scale the number of cores, there is always the question how often will one core slow down another core which is also ISA dependent, as that prevents a huge number of cores from reaching their full potential. For decades speeding up CPUs mainly meant increasing the clock rate but that isn't the case anymore for over a decade. Today adding more cores is often way simpler to do and here ARM performs really well, as it is very simple to add more cores without requiring a super complex or ultra-fast inter-CPU bus system, that is almost as complex as a CPU itself or is very power consuming. Just compare the CPU bus of x86 server CPUs (with plenty of cores) to the one of x86 consumer CPUs (with way less cores) and you will see what I mean by "complex bus system". And being super relaxed at the memory model surely helps PPC, just as it helps ARM and RISC-V, yet you cannot always be relaxed, you need fences, atomic operations and explicit ordering and here I see PPC struggling more than other RISC architectures; well, Alpha would have performed even worse, but that's a different story. And don't get me wrong, every architecture allows scaling the number of cores, this was just about how much effort that is, how costly it is, how much it will add to power consumption, etc.

Instruction set is free. And everything else may not be. OSs like Linux distros RISC-V versions are free. However most RISC-V hardware designs are not free. RISC-V foundation only provides a free instruction set. Nothing else. Everything else is industry's ecology.

@@catchnkill "However most RISC-V hardware designs are not free." but can be, right? So IF some of hardware setups are free, there is only problem with production?

@@termitektermit7889 But why? Why should someone spend money to develop hardware to gift it to other people? Did you offer such free RISC-V hardware design your own?

@@catchnkill I don't say it must be top1 hardware schema, I don't say it must be you or any specific person, I just say that it would be nice to have some free hardware schema to use (maybe they are) - thanks to that you can "produce" chips (the only problem, would be to actually produce the chips it self). Of course these won't be top chips but they will be enough for most tasks. As you can see by looking around you, normal people benefit only cause some technological progress. And this technological progress is mainly free, the only problem is production. If tech is close then it is slavery. The more independent you are the better the world is looking. The better the world is , the faster the technological progress can be. Time has significant role in this equation. And I'm just curious, cause I have watched some interesting movies like - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Y59hgZ5_7sk.html - for example.

You forgot to mention the RISC-V annual membership and certification fees, without which you can't sell a RISC-V device.

@@AndrewRoberts11 Very true. Also, a note that not all RISC-V designs will work 100% with each other. The one thing ARM does have is that it has to be compatible to some level. RISC-V has a future, but it's still a long way off.

@@AndrewRoberts11 You probably can, but you won't be able to call it RISC-V. Similar things happened with MIPS, meaning that there is an implementation called XBurst which is practically identical to certain MIPS architecture versions. The company responsible later licensed the relevant MIPS technologies, meaning that later products can advertise MIPS compatibility, although they do still use XBurst in their promotional materials. One practical consequence was that they appear to have adopted the official MIPS vector extensions alongside the ones they had devised themselves.

There is a standard (SystemReady), and some Arm systems do have UEFI, like the Ampere system I've done a few videos on (one just last week!). You can download Ubuntu, Debian, Windows, etc (Arm64 build) and run it, no proprietary overlays or specialty images required :)

It should!

A little bit of both; note that the graphics stuff is all rendering on CPU still, it's not hitting the Pi's GPU, so there could be some instructions better optimized for Arm, but it's not making the majority of the difference on Geekbench. YMMV though, all benchmarks are imperfect reflections of actual work :)

@@JeffGeerling yup -I'd assumed that everything in the bench is running on the CPU. As far as optimized instructions I believe SIMD stuff on Arm might be helping? Not sure if the Geekbench stuff uses the Neon instructions. If it does and this specific RISC-V chip does not have the vector extensions or ML stuff like matrix instructions (for tasks like image classification) it would be a strong hardware limit on the achievable performance. Super interested in seeing how this evolves over time. I'll also go lookup the full specs of the RISC-V cores in this to see what extensions are supported.

@@Xankill3r The tough thing is Geekbench's tests are a little vague in how they're represented technically (that's their proprietary mix), so there's no easy way to know what extensions they're using (especially as their suite gets updated). Thus I like to benchmark a bunch of other stuff too. The nice thing is Geekbench is easy, spits out a digestible number, and works on darn near everything without annoying compilation bugs.

Hopefully! I haven't heard from many others with boards yet.

*an eternity (because "eternity" starts with a vowel sound) *finally