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
