On Sat, Jan 4, 2020 at 2:59 AM Howard Chu <h...@symas.com> wrote:

> Keith Medcalf wrote:
> >
> > Indeed turning off memstatus leads to a 500% (from ~3s to ~0.5s)
> performance increase.
> > Changing the threading mode or the indirection level of the mutexes
> calls seems to have no significant effect.
> >
> Goes to show - publishing benchmark results without investigating why they
> are what
> they are is mostly pointless. When you suspect mutex contention is a
> significant
> factor, you should use something like mutrace to confirm your suspicion
> first.
>
> Fundamentally there ought to be no performance difference between running
> a 64-threaded
> server on a 64-threaded CPU vs 64 single-threaded processes. In practice,
> the single
> process with 64 threads ought to be slightly faster, due to less context
> switch overhead
> between threads, but if nothing else in the system is contending for CPU
> then context
> switching shouldn't even be an issue.
>

but, if the mutex lock always does a 'sched_yield' when the locking fails,
then a failure to lock isn't just a stutter in the thread, but can result
in at least 2 more context switches every time.  Probably something simpler
like a simple InterlockedExchange() call in a loop could maintain locking,
and affect performance much less; since it sounds like the actual lock
duration is really only a few clocks anyway.  Could wish there was a way to
pause execution without giving up execution context...


>
> --
>   -- Howard Chu
>   CTO, Symas Corp.           http://www.symas.com
>   Director, Highland Sun     http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to