| Vis a vi processor affinity: There is some undocumented (or at least
obscurely documented) way to do this. There has also been talk of making
it a more clearly documented and supported capability, and of adding a
variation called "soft affinity" in which you try to always run a process
on the same processor, but it can migrate around at some level of
granularity (like, gee we really want to run this on processor 3 but it
has a 3 deep queue of computable processes waiting, so let's migrate our
process to processor 1 for the duration)..
Vis a vi SYBASE: VMS doesn't recognize threads at the moment. The
finest granularity it understands is a process. What SYBASE must be
doing is taking 1 logical process and spliting it over a small number of
physical processes. Since they already conceptually used threads
internally, my guess is that having those threads run in separate
processes was not a super difficult task.
By the way, Rdb's recent 193.76 TPC-B benchmark was WITHOUT processor
affinity. It was run with processor affinity as well, and performed
slightly LOWER. This was a surprise because (in theory) processor
affinity allows for better cache hit rates than letting processes float
between processors. The cost of processor affinity is that one processor
could be very busy with jobs queued up waiting while the others remain idle
(which is why people think in terms of implementing soft affinity). Some
internal running of Rdb benchmarks have show benefits from processor
affinity, others haven't....
Hal
|