Re: About the volatile and MESI Protocal
Gregg Wonderly via Concurrency-interest <[email protected]> Sat, 19 Feb 2022 19:59:29 -0600
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <[email protected]> |
--===============5057426367730159652== Content-Type: multipart/alternative; boundary=Apple-Mail-526AB61F-9DF3-49B1-B874-86EB22C73EA5 Content-Transfer-Encoding: 7bit --Apple-Mail-526AB61F-9DF3-49B1-B874-86EB22C73EA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Total order is how the software reads. The total order problem for the hard= ware is a deficiency in how we=E2=80=99ve designed hardware systems. Ideall= y we=E2=80=99d have data flow compilers and FPGAs that could execute much fa= ster with all the performance possible. As AI and NN research continues to p= ut pressure on hardware performance we will move past these horrible hardwar= e designs! Gregg=20 Sent from my iPhone > On Feb 19, 2022, at 5:34 PM, Alex Otenko via Concurrency-interest <concurr= [email protected]> wrote: >=20 > =EF=BB=BF > Likewise it has been discussed multiple times that this is not just an opt= imisation of some obscure case. >=20 > The alternative to JMM is to have total order for all memory accesses. Thi= s obviously does not scale with the number of CPUs. You have to define some s= mall number of accesses that have to be ordered totally, so that the majorit= y of accesses don't have total order. >=20 >=20 > Alex >=20 >> On Sat, 19 Feb 2022, 23:24 Gregg Wonderly via Concurrency-interest, <conc= [email protected]> wrote: >> This is what compiler writers believe to be awesome optimization. It can i= nvalidate software systems randomly, because the compiler can rewrite the ge= nerated instruction stream in one branch of code when you=E2=80=99ve made ch= anges in another branch. >>=20 >> There=E2=80=99s been all kinds of fucysion about this on this list snd el= sewhere. Realistically, this is why you will find most Java developers with= any real amount of experience with this problem now declare all class s ops= variables as either final or obliterated so that the compiler will stop gen= erating surprise rewrites of your logic into something that does not represe= nt the readable software written. >>=20 >> Gregg Wonderly >>=20 >> Sent from my iPhone >>=20 >> > On Feb 19, 2022, at 4:31 AM, Florian Weimer via Concurrency-interest <c= [email protected]> wrote: >> >=20 >> > =EF=BB=BF* Nathan Reynolds via Concurrency-interest: >> >=20 >> >> Without volatile or fences, JIT is free to hoist the "if (bChanged =3D= =3D >> >> !bChanged)" out of the for loop. If for some reason JIT decides to no= t >> >> hoist, JIT could also load bChanged into a single register each iterat= ion >> >> and then execute "if (bChanged =3D=3D !bChanged)" using the value in t= he single >> >> register. On the other hand, if JIT is smart enough, it can get rid o= f the >> >> if statement and block altogether since it can never be true according= to >> >> the Java Memory Model. Since this is very unlike a real code scenario= , I >> >> doubt JIT has been enhanced for this last case. >> >=20 >> > I don't think this is a property of the memory model, it merely >> > follows from choices Java implementation have made regarding compiler >> > barriers for volatile field access. >> > _______________________________________________ >> > Concurrency-interest mailing list >> > [email protected] >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest >>=20 >> _______________________________________________ >> Concurrency-interest mailing list >> [email protected] >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest > _______________________________________________ > Concurrency-interest mailing list > [email protected] > http://cs.oswego.edu/mailman/listinfo/concurrency-interest --Apple-Mail-526AB61F-9DF3-49B1-B874-86EB22C73EA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto">Total order is how the software reads. &nbs= p;The total order problem for the hardware is a deficiency in how we=E2=80=99= ve designed hardware systems. Ideally we=E2=80=99d have data flow comp= ilers and FPGAs that could execute much faster with all the performance poss= ible. As AI and NN research continues to put pressure on hardware perf= ormance we will move past these horrible hardware designs!<div><br></div><di= v>Gregg <br><br><div dir=3D"ltr">Sent from my iPhone</div><div dir=3D"l= tr"><br><blockquote type=3D"cite">On Feb 19, 2022, at 5:34 PM, Alex Otenko v= ia Concurrency-interest <[email protected]> wrote:<br= ><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF= <div dir=3D"auto">Likewise it has been discussed multiple times that this is= not just an optimisation of some obscure case.<div dir=3D"auto"><br></div><= div dir=3D"auto">The alternative to JMM is to have total order for all memor= y accesses. This obviously does not scale with the number of CPUs. You have t= o define some small number of accesses that have to be ordered totally, so t= hat the majority of accesses don't have total order.</div><div dir=3D"auto">= <br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Alex</div></div><br>= <div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 19 = Feb 2022, 23:24 Gregg Wonderly via Concurrency-interest, <<a href=3D"mail= to:[email protected]">[email protected]</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex">This is what compiler wri= ters believe to be awesome optimization. It can invalidate software systems r= andomly, because the compiler can rewrite the generated instruction stream i= n one branch of code when you=E2=80=99ve made changes in another branch.<br>= <br> There=E2=80=99s been all kinds of fucysion about this on this list snd elsew= here. Realistically, this is why you will find most Java developers wi= th any real amount of experience with this problem now declare all class s o= ps variables as either final or obliterated so that the compiler will stop g= enerating surprise rewrites of your logic into something that does not repre= sent the readable software written.<br> <br> Gregg Wonderly<br> <br> Sent from my iPhone<br> <br> > On Feb 19, 2022, at 4:31 AM, Florian Weimer via Concurrency-interest &l= t;<a href=3D"mailto:[email protected]" target=3D"_blank" re= l=3D"noreferrer">[email protected]</a>> wrote:<br> > <br> > =EF=BB=BF* Nathan Reynolds via Concurrency-interest:<br> > <br> >> Without volatile or fences, JIT is free to hoist the "if (bChanged =3D= =3D<br> >> !bChanged)" out of the for loop. If for some reason JIT decid= es to not<br> >> hoist, JIT could also load bChanged into a single register each ite= ration<br> >> and then execute "if (bChanged =3D=3D !bChanged)" using the value i= n the single<br> >> register. On the other hand, if JIT is smart enough, it can g= et rid of the<br> >> if statement and block altogether since it can never be true accord= ing to<br> >> the Java Memory Model. Since this is very unlike a real code s= cenario, I<br> >> doubt JIT has been enhanced for this last case.<br> > <br> > I don't think this is a property of the memory model, it merely<br> > follows from choices Java implementation have made regarding compiler<b= r> > barriers for volatile field access.<br> > _______________________________________________<br> > Concurrency-interest mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_blank"= rel=3D"noreferrer">[email protected]</a><br> > <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" r= el=3D"noreferrer noreferrer" target=3D"_blank">http://cs.oswego.edu/mailman/= listinfo/concurrency-interest</a><br> <br> _______________________________________________<br> Concurrency-interest mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D= "noreferrer">[email protected]</a><br> <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel=3D= "noreferrer noreferrer" target=3D"_blank">http://cs.oswego.edu/mailman/listi= nfo/concurrency-interest</a><br> </blockquote></div> <span>_______________________________________________</span><br><span>Concur= rency-interest mailing list</span><br><span>[email protected]= du</span><br><span>http://cs.oswego.edu/mailman/listinfo/concurrency-interes= t</span><br></div></blockquote></div></body></html>= --Apple-Mail-526AB61F-9DF3-49B1-B874-86EB22C73EA5-- --===============5057426367730159652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest --===============5057426367730159652==--