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
