vZOOM Paragraph Correction...
Chris Thomasson
news:7NmdnY7dhYIilpLa...@comcast.com...
> [...]
>
>> http://appcore.home.comcast.net/vzoom/round-1.pdf
>> (page 3/section 3)
>
> These were drafts. Sorry for any typos in there. For the scope of this
> discussion, I would focus on page 3/section 3 of round-1... The logic is
> correct wrt the given scenario.
Ahh shit!
I should not of linked to the pre-alpha one. Actually, there is a logic
error concerning the following paragraph:
Bugged paragraph:
__________________________________________________
Lets briefly compare the per-node solution to a lock-free reader pattern
using the distributed proxy reference counting algorithm. Now the reader
threads could setup a dynamic ratio of searches to synchronization
operations. Lets say the programmer created a synchronization schedule that
allowed for reader threads to execute only 1 synchronization operation for
every, lets say, thousand searches. How does that compare with the per-node
locking scheme that can expose threads to possibly hundreds of lock/unlock
operations per-search? Well, by the time a reader thread in the per-node
locking setup finally completes a thousand searches with an average of
six-hundred lock/unlock operations per-search, it will have executed
approximately sixhundred thousand atomic operations and six-hundred thousand
StoreLoad style memory barriers. When a reader thread in the lock-free
reader pattern completes a thousand searches it will have only executed
four, or less, atomic operations and/or StoreLoad style memory barriers. It
can boil down to an average of twelve-million versus four, or less,
expensive operations perthread, per-thousand-searches. In my option, the
choice is clear: The lock-free reader pattern is a winner.
__________________________________________________
The above paragraph says that 1000 lock-based searches, with an average of
600 lock and unlock's per-search is only 600,000 atomic-ops and 600,000
membars... Well, that is simply NOT true. Since a single lock or unlock
operation usually takes 1 atomic-op and 1 membar; the figure '600,000'
should really be '1,200,000'."
So, the following statement is correct:
A 1000 lock-based searches, with an average of 600 lock/unlock per-search is
usually 1,200,000 atomic ops and 1,200,000 membars, for a total of 2,400,000
operations per-1000-lock-based-searches.
This means that the following statement:
"It can boil down to an average of twelve-million versus four, or less,
expensive operations per-thread, per-thousand-searches."
is wrong. Here is the fix:
It can boil down to an average of 2,400,000 expensive operations per-1000
searches when using lock-based, versus four, or less, expensive operations
using vZOOM for the same load.
Sorry!