Jay Pipes wrote:
Once again, Herb Sutter has written an excellent article in his
parallel computing series, this time discussing hardware architecture,
both historically and future trends, and what it means for folks like
Drizzle contributors interested in designing software that doesn't
suck on systems with more, but simpler, cores.
http://www.ddj.com/go-parallel/article/showArticle.jhtml?articleID=219200099
Highly recommended reading.
Take that with a grain of salt when applying to database servers. Much
of the thrust of Intel and other "parallel" initiatives is to
parallelize serial applications to exploit multi-core processors, an
environment where the target number of threads is less than or equal to
the number of processors. Database servers are a quite different world
-- one in which the number of client threads almost always exceeds the
number of processors. Techniques that work on the first case -- spin
locks, for example -- are serious mistakes in the second case.
Specifically, a database server must manage transaction contention,
which dictates the use of shared data structures at one level or
another. A single parallelized app, on the other hand, can design
per-thread data structures that eliminate cache or memory contention.
The difference in design is night and day.
The goal for database servers is not to optimize the speed of a single
database request (that's easy -- a single top level mutex does the
trick) but to maximize throughput while providing a substantial degree
of fairness to the active threads/clients, all the while enabling a
requisite amount of flexibility to support online changes to metadata,
dynamic self-tuning, etc.
There is an incredible amount of "incredible information" floating
around the web. A casual Google search, for example, will explain that
read/write locks are expensive and mutexes are cheap. This is
nonsense. Both read/write locks and mutexes can be seized and released
with a single interlocked instruction. It will also explain that spin
locks reduce thread switches, ignoring the fact that in a database
system a spin lock will not only CPU cycles, but block the thread
holding a lock from releasing it.
So, in short, it is a terrible mistake to confuse techniques that work
for CGI generation with technology suitable for database servers.
--
Jim Starkey
Sent from Shearwater, off
the coast of New England
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
