Posted Aug 12, 2012 16:16 UTC (Sun) by quanstro (guest, #77996)
In reply to: ACCESS_ONCE() by daglwn
Parent article: ACCESS_ONCE()
in the example given in the op, there was no reason for the read to be in the
loop, except if it might change. the compiler made the assumption that the
coder was wrong. that might not be a useful assumption.
as i see it, the trade-off here is non-standard constructions, and the
principle of least surprise for performance.
i'm not convinced of the claim that this is always a win.
the compiler i use on a daily basis does not do strength reduction or optimize
away indirection. it assumes you know what you're doing. i don't notice that
it is slower. i also don't have to worry that the compiler will break my
drivers by "optimizing" them.
(never mind that with modern intel cpus, strength reduction can be a loss due
to microop caching.)
i think this is a good trade off for my case because it avoids obtuse, and
non-portable constructions that can be hard to remember to apply. that is,
for most code, developer time is more expensive than run time.
just my two cents, and i realize that there are cases in the linux kernel
where complex macros need this sort of optimization. but perhaps that's
complexity begetting itself.