Ok. That's what I was wondering about.
Daniel Wexler <[email protected]> wrote: >I think you should *not* assume ARM is slow. 8 cores are here now, and >more >are coming. It will be more confusing to alter the semantic assumptions >for >a FastMutex. > >On Sat, Mar 23, 2013 at 9:43 PM, Larry Gritz <[email protected]> wrote: > >> Dan's solution is a perfectly good "word-for-word" translation, but >> another thing to consider is what the best solution is for ARM (and >the >> typical platform using ARM). If the ARM-based machines are likely to >be >> not super fast, not have many cores, and be very power sensitive >> (preferring to block rather than spin), it may be better to just rig >it so >> that on ARM, it always uses a true mutex rather than a spin lock. >> >> >> >> On Mar 23, 2013, at 5:56 PM, Larry Gritz wrote: >> >> Their first proposed idea was just to change the #ifdef so that for >ARM, >> it would not attempt to insert any delay at all. That will work, but >may >> not be optimal (the idea here is to not spin too fast, allow just a >bit >> reduction of contention on the atomic). >> >> Dan Wexler's solution is to use 'nop' instead of pause. I don't know >> enough about the ARM architecture to know if this is any better, but >I >> can't imagine that it's worse than doing nothing. I suspect this is >the >> superior solution. Dan, I don't suppose you'd care to contribute >back your >> ARM fixes? >> >> In the redhat link, they also mention using usleep, I think that >would be >> a very bad idea. The idea is to wait a few cycles; usleep will wait >a >> minimum of microseconds. Surely that will ruin the performance of the >spin >> locks, making them no faster than an ordinary blocking mutex. >> >> -- lg >> >> >> On Mar 23, 2013, at 5:45 PM, Daniel Wexler wrote: >> >> I used a nop asm instruction to get it to work for me on ARM, though >I'm >> not sure if it is any better than their solution. >> >> On Fri, Mar 22, 2013 at 7:28 PM, Richard Shaw ><[email protected]>wrote: >> >>> There is an arm specific group within Fedora going through all the >>> packages and seeing what will build and what needs fixing. They ran >>> into an issue with the "_asm pause" assembler instruction and filed >a >>> bug[1]. >>> >>> If you have time could you take a look at their proposed fixes and >let >>> me know if it's a good idea or if there's a better one. >>> >>> Thanks, >>> Richard >>> >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=924932 >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >Oiio-dev mailing list >[email protected] >http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
