4 ms·
Milk-V Titan: A $329 8-Core 64-bit RISC-V mini-ITX board with PCIe Gen4x16
- throwaway85825 9mo agoUntil the risc v ecosystem receives upstreamed and maintained support it's going to be a hard sell vs x86 that 'just works'.
- alexrp 9mo agoMost people would be better off waiting for the multiple RVA23 boards that are supposed to come out this year, at least if they don't want to be stuck running custom vendor distros. "RVA23 except V" at this price point and at this point in time is a pretty bad value proposition. It's honestly a bit hard to understand why they bothered with this one. No hate for the Milk-V folks; I have 4 Jupiters sitting next to me running in Zig's CI. But hopefully they'll have something RVA23-compliant out soon (SpacemiT K3?).
- irusensei 9mo agoI feel this is becoming a bit of a tech urban legend such as ZFS requires ECC. As far as I understand the RVA23 requirement is an ubuntu thing only and only for current non LTS and future releases. Current LTS doesn't have such requirements and neither other distributions such as Fedora and Debian that support riscv64. So no, you are not stuck running custom vendor distros because of this but more because the other weird device drivers and boot systems that have no mainline support.
- alexrp 9mo agoI'm fairly sure I recall Fedora folks signaling that they intend to move to RVA23 as soon as hardware becomes generally available. It is of course possible that Debian sticks with RV64GC for the long term, but I seriously doubt it. It's just too much performance to leave on the table for a relatively new port, especially when RVA23 will (very) soon be the expected baseline for general-purpose RISC-V systems.
- rwmj 9mo agoAs someone from the Fedora/RISC-V project, it'll depend on what our users want. We cannot support both RV64GC and RVA23 (because we don't have the build or software infra to do it) so we have to be careful when we move. Doing something like building with RV64GC generally but having targeted optimizations - perhaps two kernel variants and some libraries - might be possible, but also isn't easy. Things are different for CentOS / RHEL where we'll be able to move to RVA23 (and beyond) much more aggressively.
- znpy 9mo agoFirst things first: thank you for your work. That being said: does it make sense to keep a nee but low performance platform alive? As the platform is new and likely doesn’t have many users, wouldn’t it make sense to nudge (as in “gently push”) users towards a higher performance platform? Chances are the low-performance platform will die anyway, and fedora will not be exploiting the full offering of the high performance platform.
- rwmj 9mo agoIt's about what users think in our forums: https://discussion.fedoraproject.org/tag/risc-v-sig https://discussion.fedoraproject.org/tag/risc-v-sig
- fweimer 9mo agoI'm not completely sure, but I suspect Fedora will stick to the current baseline for quite some time. But the baseline is quite minimal. It's biased towards efficient emulation of the instructions in portable C code. I'm not sure why anyone would target an enterprise distribution to that. On the other hand, even RVA23 is quite poor at signed overflow checking. Like MIPS before it, RISC-V is a bet that we're going to write software in C-like languages for a long time.
- IshKebab 9mo ago> On the other hand, even RVA23 is quite poor at signed overflow checking. On the other hand it avoids integer flags which is nice. I doubt it makes a measurable performance impact either way on modern OoO CPUs. There's going to be no data dependence on the extra instructions needed to calculate overflow except for the branch, which will be predicted not-taken, so the other instructions after it will basically always run speculatively in parallel with the overflow-checking instructions.
- fweimer 9mo agoIt's nice for a C simulator to avoid condition codes. It's not so nice if you want consistent overflow checks (e.g., for automatically overflowing from fixnums to bignums). Even with XNOR (which isn't even part of RVA23, if I recall correctly), the sequence for doing an overflow check is quite messy. On AArch64 and x86-64, it's just the operation followed by a conditional jump: https://godbolt.org/z/968Eb1dh1 https://godbolt.org/z/968Eb1dh1
- adgjlsfhk1 9mo agoNon-flag based overflow checks are still pretty cheap. The overflow check is only 1 extra instruction for unsigned (both add and multiply), and 3/4 extra for signed overflow (see https://godbolt.org/z/nq1nb5Whr https://godbolt.org/z/nq1nb5Whr for details). It's also worth noting that in many cases, the overflow checks will be removable or simplify-able by the compiler entirely (e.g. if you're adding 1 or know the sign of one of the operands etc). As such, the extra couple instructions are likely worthwhile if it makes designing a wider core easier. Signed overflow instructions would be reasonable to add, but it's not like modern high performance cores are bottlenecked by scalar instructions that don't touch memory anyway.
- IshKebab 9mo agoI don't think you'll be able to get away from custom distros even with RVA23. It solves the problem of binary compatibility - everything compiled for RVA23 should be pretty portable at the instruction level (won't help with the usual glibc nonsense of course). But RVA23 doesn't help with the hardware layer - it's going to be exactly the same as ARM SBCs where there's no hardware discovery mechanism and everything has to be hard-coded in the Linux device tree. You still need a custom distro for Raspberry Pi for example. I believe there has been some progress in getting RISC-V ACPI support, and there's at least the intent of making mconfigptr do something useful - for a while there was a "unified discovery" task group, but it seems like there just wasn't enough manpower behind it and it disbanded. https://github.com/riscvarchive/configuration-structure/blob/master/charter.pdf https://github.com/riscvarchive/configuration-structure/blob... https://riscv.atlassian.net/browse/RVG-50 https://riscv.atlassian.net/browse/RVG-50
- alexrp 9mo ago> You still need a custom distro for Raspberry Pi for example. Are you sure that's still the case? I just checked the Raspberry Pi Imager and I see several "stock" distro options that aren't Raspbian. Regardless, I take your point that we're reliant on vendors actually doing the upstreaming work for device trees (and drivers). But so far the recognizable players in the RISC-V space do all(?) seem to be doing that, so for now I remain hopeful that we can avoid the Arm mess.
- IshKebab 9mo agoI'm not totally sure, but I would imagine those stock distros actually have dedicated packages for Raspberry Pi kernel images. See this for example: https://www.phoronix.com/news/Raspberry-Pi-5-Ethernet-Linux https://www.phoronix.com/news/Raspberry-Pi-5-Ethernet-Linux If you look at the patch series, it's directly adding information about the address of the ethernet device. That's the sort of thing that would be discovered automatically in the x86 world. It wouldn't need to be hard-coded into the kernel for each individual board that is supported.
- camel-cdr 9mo ago> But hopefully they'll have something RVA23-compliant out soon (SpacemiT K3?). A handful of developers already have access to SpacemiT K3 hardware, which is indeed RVA23 compliant and already runs Ubuntu 26.04. geekbench: https://browser.geekbench.com/v6/cpu/16145076 https://browser.geekbench.com/v6/cpu/16145076 rvv-bench: https://camel-cdr.github.io/rvv-bench-results/spacemit_x100/index.html https://camel-cdr.github.io/rvv-bench-results/spacemit_x100/... (which as instruction throughput measurements and more)
- ahoka 9mo agoThis is around the performance of a Core 2 Duo, if I understand correctly?
- camel-cdr 9mo agoThe single core performance is roughly in the middle between Pi4 Cortex-A72 and Pi5 Cortex-A76. It's slightly faster than a 3GHz Core 2 Dua in scalar single threaded performance, but it has 8 cores instead of two and more SIMD performance. There are also 8 additional SpacemiT-A100 cores with 1024-bit wide vectors, which are more like an additional accelerator. The geekbench score is a bit lower than it should be, because at least three benchmarks are still missing SIMD acceleration on RISC-V (File Compression, Asset Compression, Ray Tracer), and the HTML5 browser test is also missing optimizations. I'd estimate it should be able to get to the 500 range with comparable optimization to other architectures. The Milk-V Titan mention in the original post is actually slightly faster in scalar performance, but has no RISC-V Vector support at all, which causes it's geekbench score to be way lower.
- ahoka 9mo agoThat’s actually decent, thanks.
- oxxoxoxooo 9mo agoDo you happen to know how does one access/use those A100 cores?
- fulafel 9mo agoIs it really this much slower than a Raspberry Pi 5? https://browser.geekbench.com/v5/cpu/compare/23667112?baseline=23629891 https://browser.geekbench.com/v5/cpu/compare/23667112?baseli... tldr; 236 vs 666 single core score
- normie3000 9mo agoFrom your link it seems to be 3x slower. It's not clear to me why this comparison is relevant.
- fulafel 9mo agoI was wondering about the value proposition. But I guess it's a more like a dev / tinkering board then.
- moffkalast 9mo agoYep, the Pi 5 is an ARM though and you have to license the architecture to use it. RISC-V is open source, but currently sucks in pretty much all aspects compared to any other. This is still way in the early dev and build support phase.
- fweimer 9mo agoFor integer workloads it seems closer to 60% of RPi 5 performance. There are some benchmarks that depend on vector support or dedicated CPU instructions for good results, and they skew the results.
- 6SixTy 9mo agoA TL;DR doesn't explain everything. The Milk-V Titan doesn't have Vector instructions or crypto, while the Pi 5 does. It's very clearly a broken benchmark. This is why a bunch of RISC-V people won't buy boards without RV Vector instructions.
- fulafel 9mo agoIt's a broken benchmark since the CPU's shortcomings affect the results..?
- Findecanor 9mo agoI've noticed that the sentence “Compliant with RVA23 excluding V extension” has apparently been a bit confusing to some reporters in the tech press lately. It means that the UR-DP1000 chip would have been RVA23-compliant if only it had supported the V (Vector) extension. The Vector extension is mandatory in the RVA23 profile. There are other chips out there even closer to being RVA23-compliant, that have V but not a couple of scalar extensions. The latter have been emulated in software using trap handlers, but there was a significant performance penalty. V is such a big extension, with many instructions and requiring more resources, that I don't think that it would be worth the effort.
- fidotron 9mo ago> The latter have been emulated in software using trap handlers, but there was a significant performance penalty. This is a thing SoC vendors have done before without informing their customers until it's way too late. Quite a few players in that industry really do have shockingly poor ethical standards.
- PunchyHamster 9mo agoI'm sure it is in footnote in datasheet
- fidotron 9mo agoNo, they really are that grimy and will pull tricks like this until you call them out on them. They will then issue errata later, after millions of devices have been shipped.
- reactordev 9mo agoIn 6pt mandarin.
- fweimer 9mo agoI'm not sure if it's intentional. AWS doesn't have CPU features in their EC2 product documentation, either. It doesn't necessarily mean that they can disable CPU features for instances covered by existing customer contracts.
- dwood_dev 9mo agoI'm surprised we have not seen more investment into RISC-V from Chinese firms. I would think they want to decouple from ARM and the west in general as a dependency. Maybe they view the coup of ARM China as having secured ARM for the time being and not as much pressure? Either way, it's currently hard to be excited about RISC-V ITX boards with performance below that of a RPi5. I can go on AliExpress right now and buy a mini itx board with a Ryzen 9 7845HX for the same price.
- crote 9mo agoChina also has LoongArch.
- 6SixTy 9mo agoLoongArch is a weird mix of MIPS and RISC-V. There's not much that would be gained by investing a whole bunch into LoongArch that couldn't also be done to RISC-V, if at all.
- pantalaimon 9mo agoLoongArch has the advantage that they don't need to rely on a committee, they can just do things as they see fit. The 2023 3A6000 already reached the performance of this RISC-V board
- 6SixTy 9mo agoThing about RISC-V is that there are technically no barriers on doing as you see fit, but there's very clearly defined lines where community support isn't guaranteed, like custom extensions or screwing with already ratified extensions. We actually don't know a lot about the UR-DP1000 chip, while we do know quite a bit about the 3A6000 because of Chips and Cheese. This makes a thorough analysis of the crimes committed within the core architecture of the UR chip more of speculation than a coherent discussion. But we do know: 1. The UR-DP1000 does not have any Vector instructions 2. UR only has a 4 way OOO design, while the 3A6k is 6 way OOO 3. The cache architecture of the UR is more complicated, with 4 cores sharing 4MB L3 per cluster (2 clusters total), and a 16MB global L4 where the 3A6k doesn't have this 4. The UR chip doesn't have SMT
- singinishi 9mo agoSo slow.
- webdevver 9mo agoriscv is going to start having brand issues with these hardware offerings (if it doesn't already.) sure, prototypes are good. but maybe it shouldn't be sold as a general product, because it implies that the sellers deem it a good product (when it obviously isn't.) maybe it should be a closed offering, e.g. we're only making 1000, and we're only sending them to select few specialists/reviewers.
- easygenes 9mo agoAs a point of comparison, the Radxa Orion O6 shipped a year ago as a 12 core ARMv9 board on same form factor and TDP, for $100 less, with 5x the single core performance (and including a competent iGPU, NPU and VPU). These are very much developer/tinkerer only boards as is.
- mkesper 9mo agoBut it's not really a good board, sadly: https://github.com/geerlingguy/sbc-reviews/issues/62#issuecomment-2856395490 https://github.com/geerlingguy/sbc-reviews/issues/62#issueco... https://github.com/System64fumo/linux/blob/main/hardware/devices/arm/radxa/orion/orion.md https://github.com/System64fumo/linux/blob/main/hardware/dev...
- easygenes 9mo agoIt is actually a very good board, and now has a fully supported platform on mainline. Those are very out of date. https://github.com/Sky1-Linux/ https://github.com/Sky1-Linux/
- fc417fc802 9mo agoIt appears to cost about twice as much as the Titan these days. Not sure if that's RAM, tariffs, or something else.
- easygenes 9mo ago
- drob518 9mo agoThe good: eight cores. The bad: it’s slow and still no V extension. On the bright side, it uses DDR4, so you might be able to find RAM for it. “Titan” feels like some wishful over marketing.
- fnord77 9mo agoKinda pricey? You can get an entire M4 Mac Mini for $499
- justaboutanyone 9mo agoWhere are the RVA23 boards that have been hinted at for so long?
- Sparkyte 9mo agoConsidering you can get a more core dense package on x86 for that price it is better to wait. 2.0ghz isn’t a whole lot of performance for RISC-V system.
- flykespice 9mo agoReally, I don't get why would anyone buy these priced RISC-V development boards over much cheaper ARM-based variants that are faster. What is the target audience for these development boards anyway?
- 15155 9mo agoPeople who think "it's open source bro! Boo ARM!" without understanding how peripheral IP works.
- roughly 9mo agoThese are still very early days for RISC-V, but I’m always happy to see things progress in this space. No, this isn’t a viable desktop for the average consumer, but if it makes the architecture more accessible for the types of weirdos who tend to pave the way for the rest of us, it’s good.
- TheRealPomax 9mo agoBut why are we still slapping on woefully tiny stock coolers that spin so fast your room sounds like an RC racing arena?
- dev_l1x_be 9mo agoI just got a Milkv Mars and it is bit rough around the edges. Discord group helped me to get a Debian running on it but I would not say it was simple or easy to get it working.
- russnes 9mo agoWhat are the chances this will outperform ARM based computers in the next 15 years? Will we get Macbook airs with this in the fourties?