* [9fans] userspace semlocks
@ 2013-09-22 2:55 erik quanstrom
2013-09-22 5:48 ` Bruce Ellis
2013-09-23 21:11 ` Charles Forsyth
0 siblings, 2 replies; 6+ messages in thread
From: erik quanstrom @ 2013-09-22 2:55 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
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 number of sending procs, then cycles is the number of machine
cycles required to send 1<<21 messages per proc, and receive them
on a single listener.
on my machine, i get the following raw numbers (averaged over a few tries):
new 1.84e9 cycles O=10 M=1
old 1.10e9
new 4.61e9 O=0 M=1
old 4.38e9
new 1.55e10 O=10 M=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 old ones?
- erik
[-- Attachment #2: chantest.c --]
[-- Type: text/plain, Size: 1043 bytes --]
#include <u.h>
#include <libc.h>
#include <thread.h>
enum {
Ndflt = 1<<21,
Mdflt = 1,
Odflt = 10,
};
N = Ndflt;
M = Mdflt;
O = Odflt;
Channel *c, *endc;
void
sendthread(void*)
{
ulong i;
for(i = 0; i < N; i++)
sendul(c, i);
threadexits("");
}
void
receivethread(void*)
{
int i;
for(i = 0; i <N*M; i++)
recvul(c);
sendul(endc, 1);
threadexits("");
}
void
usage(void)
{
fprint(2, "usage: chantest [-O nbuf] [-M nproc]\n");
exits("usage");
}
void
threadmain(int argc, char **argv)
{
int i;
uvlong t;
ARGBEGIN{
default:
usage();
case 'M':
M = atoi(EARGF(usage()));
break;
case 'O':
O = atoi(EARGF(usage()));
break;
}ARGEND
if(argc > 0)
usage();
t = -nsec();
c = chancreate(sizeof(ulong), O);
endc = chancreate(sizeof(ulong), 0);
proccreate(receivethread, nil, 4*1024);
for(i = 0; i < M; i++)
proccreate(sendthread, (void*)(uintptr)i, 4*1024);
recvul(endc);
t += nsec();
print("%lld\n", t);
threadexits("");
}
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] userspace semlocks
2013-09-22 2:55 [9fans] userspace semlocks erik quanstrom
@ 2013-09-22 5:48 ` Bruce Ellis
2013-09-23 13:56 ` erik quanstrom
2013-09-23 21:11 ` Charles Forsyth
1 sibling, 1 reply; 6+ messages in thread
From: Bruce Ellis @ 2013-09-22 5:48 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
you are missing the reason. read the paper.
brucee
On 22 September 2013 12:55, erik quanstrom <quanstro@quanstro.net> 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 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 number of sending procs, then cycles is the number of machine
> cycles required to send 1<<21 messages per proc, and receive them
> on a single listener.
>
> on my machine, i get the following raw numbers (averaged over a few tries):
>
> new 1.84e9 cycles O=10 M=1
> old 1.10e9
>
> new 4.61e9 O=0 M=1
> old 4.38e9
>
> new 1.55e10 O=10 M=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 old ones?
>
> - erik
[-- Attachment #2: Type: text/html, Size: 1631 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] userspace semlocks
2013-09-22 5:48 ` Bruce Ellis
@ 2013-09-23 13:56 ` erik quanstrom
0 siblings, 0 replies; 6+ messages in thread
From: erik quanstrom @ 2013-09-23 13:56 UTC (permalink / raw)
To: 9fans
> 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 scheduler might not hurt due to some interactions not discussed.
it's also possible that the implementation of semaphores, which
requires two locks in the kernel contended case, and always requires two
calls to seg and validaddr is slower than the old method of sleep(0).
and finally, it's difficult to explain why my results do not square with
Table 2.
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] userspace semlocks
2013-09-22 2:55 [9fans] userspace semlocks erik quanstrom
2013-09-22 5:48 ` Bruce Ellis
@ 2013-09-23 21:11 ` Charles Forsyth
2013-09-23 21:19 ` erik quanstrom
1 sibling, 1 reply; 6+ messages in thread
From: Charles Forsyth @ 2013-09-23 21:11 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
On 22 September 2013 03:55, erik quanstrom <quanstro@quanstro.net> wrote:
>
> new 1.55e10 O=10 M=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 old ones?
>
In those cases, the new times seem to be quite a bit faster, more than they
are slower in the cases you found
slower, which involved only one process (if I understand the tests)
[-- Attachment #2: Type: text/html, Size: 974 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] userspace semlocks
2013-09-23 21:11 ` Charles Forsyth
@ 2013-09-23 21:19 ` erik quanstrom
2013-09-23 22:27 ` erik quanstrom
0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2013-09-23 21:19 UTC (permalink / raw)
To: 9fans
> On 22 September 2013 03:55, erik quanstrom <quanstro@quanstro.net> wrote:
>
> >
> > new 1.55e10 O=10 M=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 old ones?
> >
>
> In those cases, the new times seem to be quite a bit faster, more than they
> are slower in the cases you found
> slower, which involved only one process (if I understand the tests)
data entry error. swap new and old for these cases. i confused myself
by not calling them semlocks and taslocks in the email.
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] userspace semlocks
2013-09-23 21:19 ` erik quanstrom
@ 2013-09-23 22:27 ` erik quanstrom
0 siblings, 0 replies; 6+ messages in thread
From: erik quanstrom @ 2013-09-23 22:27 UTC (permalink / raw)
To: 9fans
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.chantestsem -O0 -R^$i -T^$i>/dev/null
0.00u 0.00s 6.56r 6.chantestsem -O0 -R1 -T1
0.00u 0.00s 12.72r 6.chantestsem -O0 -R2 -T2
0.00u 0.00s 31.46r 6.chantestsem -O0 -R4 -T4
0.00u 0.00s 67.66r 6.chantestsem -O0 -R8 -T8
0.00u 0.00s 149.35r 6.chantestsem -O0 -R16 -T16
; for(i in 1 2 4 8 16)time 6.chantest -O0 -R^$i -T^$i>/dev/null
0.00u 0.00s 6.40r 6.chantest -O0 -R1 -T1
0.00u 0.00s 9.32r 6.chantest -O0 -R2 -T2
0.00u 0.00s 17.63r 6.chantest -O0 -R4 -T4
0.00u 0.00s 45.99r 6.chantest -O0 -R8 -T8
0.00u 0.00s 99.69r 6.chantest -O0 -R16 -T16
- erik
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-23 22:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-22 2:55 [9fans] userspace semlocks erik quanstrom
2013-09-22 5:48 ` Bruce Ellis
2013-09-23 13:56 ` erik quanstrom
2013-09-23 21:11 ` Charles Forsyth
2013-09-23 21:19 ` erik quanstrom
2013-09-23 22:27 ` erik quanstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).