Hi Logan Additionally to what Matti says, there are random fuzzing tests like test_ll_random.py in jit/backend/test. Run those for longer than the default (e.g. whole night) to see if they find issues
Best, Maciej Fijalkowski On Tue, 16 Jan 2024 at 07:02, Logan Chien <tzuhsiang.ch...@gmail.com> wrote: > > Hi, > > I have good news: the RISC-V backend can pass as many unit tests as the > AArch64 backend. I got vmprof and codemap working this weekend. I also > completed a full translation and got a workable pypy executable. > > I have two questions now: > > 1. Are there other test suites that I can check for the correctness? > 2. How do we measure the performance? Do we have a command line that can run > all benchmarks? > > Thank you in advance. > > Regards, > Logan > > p.s. All changes are at: https://github.com/loganchien/pypy/tree/rv64 > > On Mon, Jan 15, 2024 at 8:54 PM Logan Chien <tzuhsiang.ch...@gmail.com> wrote: >> >> Hi Maciej, >> >> Thank you for your information. Let me conduct more surveys. Thanks. >> >> Regards, >> Logan >> >> On Thu, Jan 11, 2024 at 2:44 AM Maciej Fijalkowski <fij...@gmail.com> wrote: >>> >>> Hi Logan >>> >>> As far as I remember (and neither Armin nor I did any major pypy >>> development recently), the vectorization was never really something we >>> got to work to the point where it was worth it. In theory, having >>> vectorized operations like numpy arrays to compile to vectorized CPU >>> instructions would be glorious, but in practice it never worked well >>> enough for us to enable it by default. >>> >>> Best, >>> Maciej >>> >>> On Wed, 10 Jan 2024 at 08:39, Logan Chien <tzuhsiang.ch...@gmail.com> wrote: >>> > >>> > Hi Armin, >>> > >>> > > About the V extension, I'm not sure it would be helpful; do you plan >>> > > to use it in the same way as our x86-64 vector extension support? As >>> > > far as I know this has been experimental all along and isn't normally >>> > > enabled in a standard PyPy. (I may be wrong about that.) >>> > >>> > Well, if the vector extension is not enabled by default even for x86-64 >>> > backend, then I will have to conduct more survey, planning, and >>> > designing. I haven't read the vectorization code yet. >>> > >>> > Anyway, I will finish the basic JIT first. >>> > >>> > Regards, >>> > Logan >>> > >>> > On Tue, Jan 9, 2024 at 2:22 AM Armin Rigo <armin.r...@gmail.com> wrote: >>> >> >>> >> Hi Logan, >>> >> >>> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <tzuhsiang.ch...@gmail.com> >>> >> wrote: >>> >> > Currently, I only target RV64 IMAD: >>> >> > >>> >> > I - Base instruction set >>> >> > M - Integer multiplication >>> >> > A - Atomic (used by call_release_gil) >>> >> > D - Double precision floating point arithmetic >>> >> > >>> >> > I don't use the C (compress) extension for now because it may >>> >> > complicate the branch offset calculation and register allocation. >>> >> > >>> >> > I plan to support the V (vector) extension after I finish the basic >>> >> > JIT support. But there are some unknowns. I am not sure whether (a) >>> >> > I want to detect the availability of the V extension dynamically (thus >>> >> > sharing the same pypy executable) or (b) build different executables >>> >> > for different combinations of extensions. Also, I don't have a >>> >> > development board that supports the V extension. I am searching for >>> >> > one. >>> >> > >>> >> > Another remote goal is to support RV32IMAF (singlefloats) or RV32IMAD. >>> >> > In RISC-V, 32-bit and 64-bit ISAs are quite similar. The only >>> >> > difference is on LW/SW (32-bit) vs. LD/SD (64-bit) and some special >>> >> > instructions for 64-bit (e.g. ADDW). I isolated many of them into >>> >> > load_int/store_int helper functions so that it will be easy to swap >>> >> > implementations. However, I am not sure if we have to change the >>> >> > object alignment in `malloc_nursery*` (to ensure we align to multiples >>> >> > of `double`). Also, I am not sure whether it is common for RV32 cores >>> >> > to include the D extension. But, anyway, RV32 will be a lower >>> >> > priority for me because I will have to figure out how to build a RV32 >>> >> > root filesystem first (p.s. Debian doesn't (officially) support RV32 >>> >> > as of writing). >>> >> >>> >> Cool! Here are a few thoughts I had when I looked at some RISC-V >>> >> early documents long ago (warning, it may be outdated): >>> >> >>> >> Yes, not using the "compress" extension is probably a good approach. >>> >> That looks like something a compiler might do, but it's quite a bit of >>> >> work both implementation-wise, and it's unclear if it would help anyway >>> >> here. >>> >> >>> >> About the V extension, I'm not sure it would be helpful; do you plan >>> >> to use it in the same way as our x86-64 vector extension support? As >>> >> far as I know this has been experimental all along and isn't normally >>> >> enabled in a standard PyPy. (I may be wrong about that.) >>> >> >>> >> Singlefloats: we don't do any arithmetic on singlefloats with the JIT, >>> >> but it has got a few instructions to pack/unpack double floats into >>> >> single floats or to call a C-compiled function with singlefloat >>> >> arguments. That's not optional, though I admit I don't know how a C >>> >> compiler compiles these operations if floats are not supported by the >>> >> hardware. But as usual, you can just write a tiny C program and see. >>> >> >>> >> I agree that RV32 can be a more remote goal for now. It should >>> >> simplify a lot of stuff if you can just assume a 64-bit environment. >>> >> Plus all the other points you mention: the hardware may not support >>> >> doubles, and may not be supported by Debian... >>> >> >>> >> >>> >> A bientôt, >>> >> >>> >> Armin Rigo >>> > >>> > _______________________________________________ >>> > pypy-dev mailing list -- pypy-dev@python.org >>> > To unsubscribe send an email to pypy-dev-le...@python.org >>> > https://mail.python.org/mailman3/lists/pypy-dev.python.org/ >>> > Member address: fij...@gmail.com _______________________________________________ pypy-dev mailing list -- pypy-dev@python.org To unsubscribe send an email to pypy-dev-le...@python.org https://mail.python.org/mailman3/lists/pypy-dev.python.org/ Member address: arch...@mail-archive.com
