Re: History of and support for std::basic_string::back()
On Thursday, 8 August 2013 10:04:07 UTC+1, Paavo Helde wrote:
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
news:slrnl06isd.2m9.grahn+nntp@frailea.sa.invalid:
My main desktop is an early (~2003) single-core AMD64. I'm happy
it hasn't been declared obsolete (because it works very well) but
at the same time I can't help wondering how much better it would
run if libraries and compilers didn't take SMP into account.
All the synchronization finally comes down to the hardware level, and the
hardware ultimately decides how large overhead it causes. Presumably
hardware makes this as fast as possible, so if something is not needed on
given hardware it would not cause any overhead.
The hardware has to deal with compromizes too. It's trivial to
design hardware where the cost of synchronization is zero (and
this has been the case for most of the hardware I've worked on,
through out most of my career). Just use a single core, and
don't pipeline anything. Most hardware is designed to optimize
the cases which don't require synchronization, however, with the
result that synchronization ends up being expensive.
On Intel architecture I think this used to be the cost of the LOCK
assembler prefix. On some hardware the LOCK prefix would be just a non-op
and there would appear an overhead of having a number of unneeded LOCK
prefix bytes in the executable code, which makes it marginally slower to
pump through the CPU. Interestingly enough, Intel has defined LOCK
redundant for some instructions like XCHG, meaning that even this overhead
is not there any more.
No. It assumes that the only use of these instructions will be
cases where the lock is needed. As implemented on most Intel (I
think---I've not checked all of the documentation), the LOCK
implies a memory fence: all preceding writes will finish before
starting the instruction it controls, and all writes in the
instruction will finish before the next instruction is executed.
(If it doesn't, then you still need the fences in a lock free
algorithm.)
--
James