Re: Contribute a RISC-V 64 JIT backend
Logan Chien <[email protected]> Mon, 22 Jan 2024 22:19:35 -0800
| Newsgroups | gmane.comp.python.pypy |
|---|---|
| Message-ID | <CALQyFuDEZaxkfT9RgY5WRUOh-Ksh4Z48Hm-5nKH9C9XSERicjw@mail.gmail.com> |
--===============8179910587010137173== Content-Type: multipart/alternative; boundary="000000000000dba32c060f96ee55" --000000000000dba32c060f96ee55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Maciej Thank you for the information. It sounds like a good idea to run this before I go to sleep. Other updates: I didn't make progress last weekend. I spent last weekend revising the code generator for integer immediate load (replace up-to-eight-instructions with pc-relative load instructions). I will try them in the upcoming weekends. Regards, Logan On Sun, Jan 21, 2024 at 10:36=E2=80=AFPM Maciej Fijalkowski <[email protected]= om> wrote: > 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 <[email protected]> > 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=E2=80=AFPM Logan Chien <tzuhsiang.chien@gm= ail.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@gma= il.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 w= e > >>> 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? > 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=E2=80=AFAM Armin Rigo <armin.rigo@gmail= .com> > wrote: > >>> >> > >>> >> Hi Logan, > >>> >> > >>> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <[email protected]= m> > 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 fir= st > (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 approac= h. > >>> >> That looks like something a compiler might do, but it's quite a bi= t > 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 pl= an > >>> >> 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 int= o > >>> >> 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 environmen= t. > >>> >> Plus all the other points you mention: the hardware may not suppor= t > >>> >> 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] > --000000000000dba32c060f96ee55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Maciej</div><div><br></div><div>Thank you for the = information.=C2=A0 It sounds like a good idea to run this before I go to sl= eep.</div><div><br></div><div>Other updates:</div><div><br></div><div>I did= n't make progress last weekend.=C2=A0 I spent last weekend revising the= code generator for integer immediate load (replace up-to-eight-instruction= s with pc-relative load instructions).=C2=A0 I will try them in the upcomin= g weekends.<br></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 Sun, Jan 21, 2024 at 10:36=E2=80=AFPM Maciej Fijalkowski <<a href=3D"= mailto:[email protected]">[email protected]</a>> wrote:<br></div><blockquo= te 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> Additionally to what Matti says, there are random fuzzing tests like<br> test_ll_random.py in jit/backend/test. Run those for longer than the<br> default (e.g. whole night) to see if they find issues<br> <br> Best,<br> Maciej Fijalkowski<br> <br> On Tue, 16 Jan 2024 at 07:02, Logan Chien <<a href=3D"mailto:tzuhsiang.c= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<= br> ><br> > Hi,<br> ><br> > I have good news: the RISC-V backend can pass as many unit tests as th= e AArch64 backend.=C2=A0 I got vmprof and codemap working this weekend.=C2= =A0 I also completed a full translation and got a workable pypy executable.= <br> ><br> > I have two questions now:<br> ><br> > 1. Are there other test suites that I can check for the correctness?<b= r> > 2. How do we measure the performance?=C2=A0 Do we have a command line = that can run all benchmarks?<br> ><br> > Thank you in advance.<br> ><br> > Regards,<br> > Logan<br> ><br> > p.s. All changes are at: <a href=3D"https://github.com/loganchien/pypy= /tree/rv64" rel=3D"noreferrer" target=3D"_blank">https://github.com/loganch= ien/pypy/tree/rv64</a><br> ><br> > On Mon, Jan 15, 2024 at 8:54=E2=80=AFPM Logan Chien <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]<= /a>> wrote:<br> >><br> >> Hi Maciej,<br> >><br> >> Thank you for your information.=C2=A0 Let me conduct more surveys.= =C2=A0 Thanks.<br> >><br> >> Regards,<br> >> Logan<br> >><br> >> On Thu, Jan 11, 2024 at 2:44=E2=80=AFAM Maciej Fijalkowski <<a = href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>= wrote:<br> >>><br> >>> Hi Logan<br> >>><br> >>> As far as I remember (and neither Armin nor I did any major py= py<br> >>> development recently), the vectorization was never really some= thing we<br> >>> got to work to the point where it was worth it. In theory, hav= ing<br> >>> vectorized operations like numpy arrays to compile to vectoriz= ed CPU<br> >>> instructions would be glorious, but in practice it never worke= d 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"mailt= o:[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 you plan<br> >>> > > to use it in the same way as our x86-64 vector exten= sion support?=C2=A0 As<br> >>> > > far as I know this has been experimental all along a= nd isn't normally<br> >>> > > enabled in a standard PyPy.=C2=A0 (I may be wrong ab= out that.)<br> >>> ><br> >>> > Well, if the vector extension is not enabled by default e= ven for x86-64 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"mailto:[email protected]" target=3D"_blank">[email protected]= </a>> wrote:<br> >>> >><br> >>> >> Hi Logan,<br> >>> >><br> >>> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <<a href= =3D"mailto:[email protected]" target=3D"_blank">tzuhsiang.chien@gma= il.com</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<b= r> >>> >> ><br> >>> >> > I don't use the C (compress) extension for n= ow because it may complicate the branch offset calculation and register all= ocation.<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 extensi= on dynamically (thus sharing the same pypy executable) or (b) build differe= nt executables for different combinations of extensions.=C2=A0 Also, I don&= #39;t have a development board that supports the V extension.=C2=A0 I am se= arching for one.<br> >>> >> ><br> >>> >> > Another remote goal is to support RV32IMAF (sing= lefloats) or RV32IMAD.=C2=A0 In RISC-V, 32-bit and 64-bit ISAs are quite si= milar.=C2=A0 The only difference is on LW/SW (32-bit) vs. LD/SD (64-bit) an= d some special instructions for 64-bit (e.g. ADDW).=C2=A0 I isolated many o= f them into load_int/store_int helper functions so that it will be easy to = swap implementations.=C2=A0 However, I am not sure if we have to change the= object alignment 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 because I will have to figure out how to build a RV32 root filesyste= m 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 look= ed at some RISC-V<br> >>> >> early documents long ago (warning, it may be outdated= ):<br> >>> >><br> >>> >> Yes, not using the "compress" extension is = probably a good 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 i= f it would help anyway here.<br> >>> >><br> >>> >> About the V extension, I'm not sure it would be h= elpful; do you plan<br> >>> >> to use it in the same way as our x86-64 vector extens= ion support?=C2=A0 As<br> >>> >> far as I know this has been experimental all along an= d isn't normally<br> >>> >> enabled in a standard PyPy.=C2=A0 (I may be wrong abo= ut that.)<br> >>> >><br> >>> >> Singlefloats: we don't do any arithmetic on singl= efloats with the JIT,<br> >>> >> but it has got a few instructions to pack/unpack doub= le floats into<br> >>> >> single floats or to call a C-compiled function with s= inglefloat<br> >>> >> arguments.=C2=A0 That's not optional, though I ad= mit 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 ti= ny C program and see.<br> >>> >><br> >>> >> I agree that RV32 can be a more remote goal for now.= =C2=A0 It should<br> >>> >> simplify a lot of stuff if you can just assume a 64-b= it environment.<br> >>> >> Plus all the other points you mention: the hardware m= ay not support<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:pypy-dev@pytho= n.org" target=3D"_blank">[email protected]</a><br> >>> > To unsubscribe send an email to <a href=3D"mailto:pypy-de= [email protected]" target=3D"_blank">[email protected]</a><br> >>> > <a href=3D"https://mail.python.org/mailman3/lists/pypy-de= v.python.org/" rel=3D"noreferrer" target=3D"_blank">https://mail.python.org= /mailman3/lists/pypy-dev.python.org/</a><br> >>> > Member address: <a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a><br> </blockquote></div> --000000000000dba32c060f96ee55-- --===============8179910587010137173== 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] --===============8179910587010137173==--