here's the raw data from a seperate run, and slightly different code,
and a different machine.
this is a test with thread(2) channels with T tx procs × R rx procs:
; aux/cpuid -i
Intel(R) Xeon(R) CPU E31230 @ 3.20GHz
; wc -l /dev/sysstat
8 /dev/sysstat
; for(i in 1 2 4 8 16)time 6
> On 22 September 2013 03:55, erik quanstrom wrote:
>
> >
> > new 1.55e10 O=10M=8
> > old 2.74e10
> >
> > new 3.64e10 O=0 M=8
> > old 5.14e10
> >
> > am i doing something fundamental wrong, or are the new locks substantially
On 22 September 2013 03:55, erik quanstrom wrote:
>
> new 1.55e10 O=10M=8
> old 2.74e10
>
> new 3.64e10 O=0 M=8
> old 5.14e10
>
> am i doing something fundamental wrong, or are the new locks substantially
> slower than the ol
> you are missing the reason. read the paper.
the paper in question one assumes is "Semaphores in Plan 9",
Sape Mullender and Russ Cox, IWP9, 2008.
the idea in the paper is the scheduler might hurt, but i don't think
there's any real development of that idea. so it's also possible that
the sched
you are missing the reason. read the paper.
brucee
On 22 September 2013 12:55, erik quanstrom wrote:
> when i measure chan send performance with the attached program with
> the semaphore locks that have been made the default for sources and
> with the old locks, the old locks surprisingly outp
when i measure chan send performance with the attached program with
the semaphore locks that have been made the default for sources and
with the old locks, the old locks surprisingly outperform the new ones
by a large margin.
the test is let O be the number of buffers in the channel, and M be
the
