Re: Contribute a RISC-V 64 JIT backend
Logan Chien <[email protected]> Mon, 15 Jan 2024 21:02:37 -0800
| Newsgroups | gmane.comp.python.pypy |
|---|---|
| Message-ID | <CALQyFuBf4-LudaskLCZoxdUj8+P8GXub-J5L983GofduXE0jiA@mail.gmail.com> |
--===============5162805799135005940== Content-Type: multipart/alternative; boundary="000000000000a7d206060f090a05" --000000000000a7d206060f090a05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Logan Chien <tzuhsiang.chien@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=E2=80=AFAM Maciej Fijalkowski <fijall@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 <[email protected]> >> 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? A= s >> > > far as I know this has been experimental all along and isn't normall= y >> > > enabled in a standard PyPy. (I may be wrong about that.) >> > >> > Well, if the vector extension is not enabled by default even for x86-6= 4 >> backend, then I will have to conduct more survey, planning, and designin= g. >> 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=E2=80=AFAM Armin Rigo <[email protected]= m> wrote: >> >> >> >> Hi Logan, >> >> >> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <[email protected]> >> 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 onl= y >> 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 fi= rst >> (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 o= f >> >> 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=C3=B4t, >> >> >> >> Armin Rigo >> > >> > _______________________________________________ >> > pypy-dev mailing list -- [email protected] >> > To unsubscribe send an email to [email protected] >> > https://mail.python.org/mailman3/lists/pypy-dev.python.org/ >> > Member address: [email protected] >> > --000000000000a7d206060f090a05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I have good news: the RI= SC-V backend can pass as many unit tests as the AArch64 backend.=C2=A0 I go= t vmprof and codemap working this weekend.=C2=A0 I also completed a full tr= anslation and got a workable pypy executable.</div><div><br></div><div>I ha= ve two questions now:</div><div><br></div><div>1. Are there other test suit= es that I can check for the correctness?</div><div>2. How do we measure the= performance?=C2=A0 Do we have a command line that can run all benchmarks?<= /div><div><br></div><div>Thank you in advance.</div><div><br></div><div>Reg= ards,</div><div>Logan</div><div><br></div><div>p.s. All changes are at: <a = href=3D"https://github.com/loganchien/pypy/tree/rv64">https://github.com/lo= ganchien/pypy/tree/rv64</a></div></div><br><div class=3D"gmail_quote"><div = dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 15, 2024 at 8:54=E2=80=AFPM Lo= gan Chien <<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>> wrote:<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Maciej,</div><div><br><= /div><div>Thank you for your information.=C2=A0 Let me conduct more surveys= .=C2=A0 Thanks.</div><div><br></div><div>Regards,</div><div>Logan<br></div>= </div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">= On Thu, Jan 11, 2024 at 2:44=E2=80=AFAM Maciej Fijalkowski <<a href=3D"m= ailto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<b= r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Logan<br> <br> As far as I remember (and neither Armin nor I did any major pypy<br> development recently), the vectorization was never really something we<br> got to work to the point where it was worth it. In theory, having<br> vectorized operations like numpy arrays to compile to vectorized CPU<br> instructions would be glorious, but in practice it never worked well<br> enough for us to enable it by default.<br> <br> Best,<br> Maciej<br> <br> On Wed, 10 Jan 2024 at 08:39, Logan Chien <<a href=3D"mailto:tzuhsiang.c= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<= br> ><br> > Hi Armin,<br> ><br> > > About the V extension, I'm not sure it would be helpful; do y= ou plan<br> > > to use it in the same way as our x86-64 vector extension support?= =C2=A0 As<br> > > far as I know this has been experimental all along and isn't = normally<br> > > enabled in a standard PyPy.=C2=A0 (I may be wrong about that.)<br= > ><br> > Well, if the vector extension is not enabled by default even for x86-6= 4 backend, then I will have to conduct more survey, planning, and designing= .=C2=A0 I haven't read the vectorization code yet.<br> ><br> > Anyway, I will finish the basic JIT first.<br> ><br> > Regards,<br> > Logan<br> ><br> > On Tue, Jan 9, 2024 at 2:22=E2=80=AFAM Armin Rigo <<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>> wrot= e:<br> >><br> >> Hi Logan,<br> >><br> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <<a href=3D"mailto:tzu= [email protected]" target=3D"_blank">[email protected]</a>>= wrote:<br> >> > Currently, I only target RV64 IMAD:<br> >> ><br> >> > I - Base instruction set<br> >> > M - Integer multiplication<br> >> > A - Atomic (used by call_release_gil)<br> >> > D - Double precision floating point arithmetic<br> >> ><br> >> > I don't use the C (compress) extension for now because it= may complicate the branch offset calculation and register allocation.<br> >> ><br> >> > I plan to support the V (vector) extension after I finish the= basic JIT support.=C2=A0 But there are some unknowns.=C2=A0 I am not sure = whether (a) I want to detect the availability of the V extension dynamicall= y (thus sharing the same pypy executable) or (b) build different executable= s for different combinations of extensions.=C2=A0 Also, I don't have a = development board that supports the V extension.=C2=A0 I am searching for o= ne.<br> >> ><br> >> > Another remote goal is to support RV32IMAF (singlefloats) or = RV32IMAD.=C2=A0 In RISC-V, 32-bit and 64-bit ISAs are quite similar.=C2=A0 = The only difference is on LW/SW (32-bit) vs. LD/SD (64-bit) and some specia= l instructions for 64-bit (e.g. ADDW).=C2=A0 I isolated many of them into l= oad_int/store_int helper functions so that it will be easy to swap implemen= tations.=C2=A0 However, I am not sure if we have to change the object align= ment in `malloc_nursery*` (to ensure we align to multiples of `double`).=C2= =A0 Also, I am not sure whether it is common for RV32 cores to include the = D extension.=C2=A0 But, anyway, RV32 will be a lower priority for me becaus= e 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).<br> >><br> >> Cool!=C2=A0 Here are a few thoughts I had when I looked at some RI= SC-V<br> >> early documents long ago (warning, it may be outdated):<br> >><br> >> Yes, not using the "compress" extension is probably a go= od approach.<br> >> That looks like something a compiler might do, but it's quite = a bit of<br> >> work both implementation-wise, and it's unclear if it would he= lp anyway here.<br> >><br> >> About the V extension, I'm not sure it would be helpful; do yo= u plan<br> >> to use it in the same way as our x86-64 vector extension support?= =C2=A0 As<br> >> far as I know this has been experimental all along and isn't n= ormally<br> >> enabled in a standard PyPy.=C2=A0 (I may be wrong about that.)<br> >><br> >> Singlefloats: we don't do any arithmetic on singlefloats with = the JIT,<br> >> but it has got a few instructions to pack/unpack double floats int= o<br> >> single floats or to call a C-compiled function with singlefloat<br= > >> arguments.=C2=A0 That's not optional, though I admit I don'= ;t know how a C<br> >> compiler compiles these operations if floats are not supported by = the<br> >> hardware.=C2=A0 But as usual, you can just write a tiny C program = and see.<br> >><br> >> I agree that RV32 can be a more remote goal for now.=C2=A0 It shou= ld<br> >> simplify a lot of stuff if you can just assume a 64-bit environmen= t.<br> >> Plus all the other points you mention: the hardware may not suppor= t<br> >> doubles, and may not be supported by Debian...<br> >><br> >><br> >> A bient=C3=B4t,<br> >><br> >> Armin Rigo<br> ><br> > _______________________________________________<br> > pypy-dev mailing list -- <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a><br> > To unsubscribe send an email to <a href=3D"mailto:pypy-dev-leave@pytho= n.org" target=3D"_blank">[email protected]</a><br> > <a href=3D"https://mail.python.org/mailman3/lists/pypy-dev.python.org/= " rel=3D"noreferrer" target=3D"_blank">https://mail.python.org/mailman3/lis= ts/pypy-dev.python.org/</a><br> > Member address: <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> </blockquote></div> </blockquote></div> --000000000000a7d206060f090a05-- --===============5162805799135005940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pypy-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/pypy-dev.python.org/ Member address: [email protected] --===============5162805799135005940==--