RISC-V Support #6559
Comments
|
@advancedwebdeveloper thank you for the reminder, I'll label this as a feature request for now. I think it may be realistic to assume that we will migrate to LLVM 11 at some point in 2021. |
esc
changed the title
|
@esc , you didn't elaborate about RISC-V arch. |
|
We are not likely to add official support for RISC-V in 2021 (given how small the ecosystem of Linux users on RISC-V is right now), but we are likely to move llvmlite support to LLVM 11, which it sounds like will help users who want to experiment with RISC-V. |
|
CC @palmer-dabbelt , in case if there would be any concrete ideas |
|
I didn't read the big thing at the top (I was just linked here, I didn't even know what numba is) so I'm really just replying to the "we're not adding RISC-V support in 2021" comment: Obviously I'd love for people to start adding proper support for RISC-V to various software projects, that's kind of my thing, but we're really not at the point yet where RISC-V is suitable for serious use and I very much doubt we'll be there any time in 2021. While I think there's likely to be at least one Linux-capable RISC-V development board produced in large enough quantities (and sold at a low enough price) that regular developers can have access to RISC-V hardware. That said, I also think that we're (at a minimum) a few years away from anything that's even remotely viable in production -- while the software ecosystem isn't there yet, I think we've largely outpaced the development of the standards. Certainly anything in 2021 will require non-standard extensions to function in a reasonably capacity as a product, which makes software support somewhat difficult as non-standard extensions are really an unknown quantity. The above holds for any software project interested in portability between different RISC-V implementations, but there are additional wrinkles for various classes of applications. All I know about Numba is the name and GitHub tag line, but my guess is that you're only really interested in running on platforms that perform reasonably well on dense tensor problems. There's really no way to perform acceptably on that class of problems (FP or integer) without some form of explicit data parallelism, and that's a long way off for RISC-V. Right now there are two competing data parallel standards tracks (P for SIMD, and V for Cray-stile vector), with multiple incompatible (and end-of-life) versions of these extensions being implemented by various vendors. I think it's unlikely that standards around explicit data parallelism settle down in 2021, but even if they do we're stuck waiting on at least one hardware development cycle before implementations begin to coalesce around something that can be supported long-term. That said, it is probably worth starting a discussion as to what sort of requirements you might want to put on a RISC-V port before accepting it. Across the board we'd essentially decided "we only support ratified extensions in RISC-V ports" a few years ago, but given the pace at which the RISC-V foundation produces standards that's becoming a headache for everyone and I think it's likely that many projects change that policy over the next year or so. The RISC-V software ecosystem is a lot bigger than it was before so it's unlikely we have a single ecosystem-wide policy, but most projects appear to be moving towards a "support draft extensions, but rapidly deprecate them" sort of thing -- for example: in QEMU we're supporting draft extensions but deprecating them after a single release, so we only have to support a single version at a time. I actually think that's a bad policy, as it makes draft extensions all but impossible to build upon, but when push comes to shove there just isn't enough manpower behind the RISC-V software ecosystem to do anything better right now and given the pressure most open source developers have to get their code merged it's likely to be a common approach. I'd love to see if my assumptions about the direct users of the software I work on start to think through what it would actually take to bring up a port, as something like GCC or QEMU doesn't really do anything until it's a useful tool for folks like you. Sorry if I'm bursting anyone's bubble here. There's nothing I'd love more than to say "ya, go for it, RISC-V is all ready to use" but that just wouldn't be honest right now. |
|
I don't think Numba needs parallel instructions to be interesting (although if LLVM autovectorization passes can generate those when they are available, that's great). Many of our users are happy just to get single thread performance in Python that they would normally have to go to C or FORTRAN for. Basically, if there is traditional user Linux userspace and C/C++ compiler, someone will probably want to use Numba. That said, I agree that this isn't going to be a priority until there is more adoption of RISC-V by an audience who might like to use Python and do some light numerical computing. We'll keep an eye on RISC-V for sure, though. |
|
@palmer-dabbelt thanks for the extensive commentary. Regardless of RISC-V we will probably try and migrate to LLVM 11 in 2021 anyway. |
|
Could you prepare something like a patch source tree for your currently supported LLVM 10? Here is what I got, during an attempt to install Numba:
. I tried to perform installation yesterday - but the script found "llvmlite" pip3 package available, which was reported as a conflicting one. |
|
I tried to check via pip3:
@PiotrZierhoffer , what is your process in porting https://github.com/conda/conda-build to RISC-V ? |
You can re-open #4732 |
|
I am using
|
|
|
@palmer-dabbelt , I think I found the first concrete bug:
|
|
So JIT can't work - and tests can't run, too. |
|
|
@advancedwebdeveloper your best bet to obtain a copy of https://llvmlite.readthedocs.io/en/latest/admin-guide/install.html#building-manually Different versions of LLVM need different patches. You can find exactly which patches you need here: https://github.com/numba/llvmlite/blob/master/conda-recipes/llvmdev/meta.yaml#L32-L50
|
|
@advancedwebdeveloper I'm affraid we did not pursue this topic |
|
@palmer-dabbelt @advancedwebdeveloper @esc @seibert I'm interested in making llvmlite (and hence Numba) work on RISC-V Linux as a personal project, but at present my free time for such a project is quite limited... Assuming a reasonable completeness of LLVM and JIT support for RISC-V I'd hope that making it work (perhaps as a prototype rather than a production-ready port) wouldn't be too great an effort. I don't have a RISC-V dev board, but I'd already considered how this could be done, and my plan would have been to try and make it work under QEMU first. |
|
Having done the port to the ARM ISA, the strategy that seemed to provide the quickest path was to build everything from scratch and hack things into a development environment as needed. Avoid Practically, this would mean:
Building this stack is complicated, often requires a lot of debugging and also many rebuilds of the entire stack. Things which are going to cause immediate issues are:
I also would expect the QEMU route @gmarkall suggested to be a quicker route to assessing the viability of the stack than trying on real hardware. Hope this helps. |
|
@seibert , LLVM has few different associated JIT related projects (some are sub-projects of LLVM - other are external ones). Which RISC-V hardware would you involve? ASIC SoC or soft-CPU/FPGA? |
|
@advancedwebdeveloper FYI: with 0.54.0 (currently available as RC2) LLVM 11 will be enabled on all supported platforms. See also: https://numba.discourse.group/t/numba-0-54-0-rc2-and-llvmlite-v0-37-0-rc2/810/6 |
|
I need to write up some more details somewhere, but I've reached the point where a proof-of-concept is working such that: @njit
def f(a, b):
return a + b
print(f(1, 2))successfully runs on RISC-V and prints
Building these branches and executing the final line being (presumably) the interesting one. I did this on an Ubuntu 22.04 install inside QEMU, but I'm considering ordering a VisionFive 2 8GB to have a proper go at Numba for RISC-V in the new year (I'm expecting that the experience of using that would be a little more pleasant than QEMU, but someone please correct me if I'm delusional here). There's quite a bit of work to do from here to "Numba is ready for RISC-V" mainly because we need to move to LLVM 15 and from MCJIT to ORCJIT to JIT on RISC-V. Note that this would be a personal project and my personal time is extremely limited, so I want to make clear that this isn't something that I'm guaranteed to get anywhere with, and there are no plans for any official RISC-V support in Numba at present. But, at least there's a little positive sign here 🙂 |
|
Note: I've just edited the title to reflect the fact that this issue is really about RISC-V support. We moved to LLVM 11 a while back, and will be on LLVM 14 for the next release. |
Hi.
It doesn't seem that you have migrated - so I am reminding about the current situation:
Hence that I am using
under https://en.opensuse.org/openSUSE:RISC-V
.
The text was updated successfully, but these errors were encountered: