Re: smrproxy v2

On 11/24/24 15:14, jseigh wrote:

On 11/23/24 11:10, jseigh wrote:

On 11/21/24 15:17, jseigh wrote:

>
Ok, smrproxy lock/unlock is down to 0.6 nanoseconds now,
about what the C version was.
>

 I've been using cpu time to measure performance. That's ok
for lock-free/wait-free locking.  For normal mutexes and
shared locks, it doesn't measure wait time so those didn't
look as bad as they really were.  You can add logic
to measure how long it takes to acquire a lock but that
adds significant overhead.
 

Some timings with 128 reader threads
unsafe        52.983 nsecs (      0.000)     860.576 nsecs (      0.000)
smr           54.714 nsecs (      1.732)     882.356 nsecs (     21.780)
smrlite       53.149 nsecs (      0.166)     870.066 nsecs (      9.490)
arc          739.833 nsecs (    686.850)  11,988.289 nsecs ( 11,127.713)
rwlock     1,078.306 nsecs (  1,025.323)  17,309.882 nsecs ( 16,449.306)
mutex      3,203.034 nsecs (  3,150.052)  51,479.407 nsecs ( 50,618.831)
The first column is cpu time, third column is elapsed time.
unsafe is without any synchronized reader access.   The
value in parentheses is the unsafe access time subtracted
out to separate out the synchronization overheads.  smrlite is
smr proxy with thread_local overhead.  So smrproxy lock/unlock
by itself is about 0.1 - 0.2 nanoseconds.
I'm going to drop working on the whole proxy interface thing.  The
application can decide if it wants to hardcode a dependency on a
particular 3rd party libarary implementation or abstract it out
to a more portable api.
Joe Seigh