From: "Boehm, Hans" <hans_boehm@hp.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] Re: web page on O(1) scheduler
Date: Fri, 23 May 2003 17:48:19 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590723706003@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590723705966@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
Sorry about the typo and misnaming for the test program. I attached the correct version that prints the right labels.
The results I posted did not use NPTL. (Presumably OpenMP wasn't targeted at NPTL either.) I don't think that NPTL has any bearing on the underlying issues that I mentioned, though path lengths are probably a bit shorter. It should also handle contention substantially better, but that wasn't tested.
I did rerun the test case on a 900 MHz Itanium 2 machine with a more recent Debian installation with NPTL. I get 200msecs (20nsecs/iter) with the custom lock, and 768 for pthreads. (With static linking that decreases to 658 for pthreads.) Pthreads (and/or some of the other infrastructure) is clearly getting better, but I don't think the difference will disappear.
I don't have a Xeon with NPTL handy. On an old PPro, the results were 1133 and 4379 msecs for custom and NPTL respectively.
Hans
> -----Original Message-----
> From: Arjan van de Ven [mailto:arjanv@redhat.com]
> Sent: Friday, May 23, 2003 1:31 AM
> To: Hans Boehm
> Cc: Arjan van de Ven; davidm@hpl.hp.com; linux-kernel@vger.kernel.org;
> linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] Re: web page on O(1) scheduler
>
>
> On Thu, May 22, 2003 at 06:07:46PM -0700, Hans Boehm wrote:
> > case.
> >
> > On a 1GHz Itanium 2 I get
> >
> > Custom lock: 180 msecs
> > Custom lock: 1382 msecs
> >
> > On a 2GHz Xeon, I get
> >
> > Custom lock: 646 msecs
> > Custom lock: 1659 msecs
>
> is the pthreads one with nptl ?
>
[-- Attachment #2: time_lock.c --]
[-- Type: application/octet-stream, Size: 1760 bytes --]
#include <pthread.h>
#include <stdio.h>
#include <sys/time.h>
#include "atomic_ops.h"
/* Timing code stolen from Ellis/Kovac/Boehm GCBench. */
#define currentTime() stats_rtclock()
#define elapsedTime(x) (x)
unsigned long
stats_rtclock( void )
{
struct timeval t;
struct timezone tz;
if (gettimeofday( &t, &tz ) == -1)
return 0;
return (t.tv_sec * 1000 + t.tv_usec / 1000);
}
AO_TS_T my_spin_lock = AO_TS_INITIALIZER;
pthread_mutex_t my_pthread_lock = PTHREAD_MUTEX_INITIALIZER;
void spin_lock_ool(AO_TS_T *lock)
{
/* Should repeatly retry the AO_test_and_set_acquire, perhaps */
/* after trying a plain read. Should "exponentially" back off */
/* between tries. For short time periods it should spin, for */
/* medium ones it should use sched_yield, and for longer ones usleep. */
/* For now we punt, since this is a contention-free test. */
abort();
}
inline void spin_lock(AO_TS_T *lock)
{
if (__builtin_expect(AO_test_and_set_acquire(lock) != AO_TS_CLEAR, 0))
spin_lock_ool(lock);
}
inline void spin_unlock(AO_TS_T *lock)
{
AO_CLEAR(lock);
}
int main()
{
unsigned long start_time, end_time;
int i;
start_time = currentTime();
for (i = 0; i < 10000000; ++i) {
spin_lock(&my_spin_lock);
spin_unlock(&my_spin_lock);
}
end_time = currentTime();
fprintf(stderr, "Custom lock: %lu msecs\n",
elapsedTime(end_time - start_time));
start_time = currentTime();
for (i = 0; i < 10000000; ++i) {
pthread_mutex_lock(&my_pthread_lock);
pthread_mutex_unlock(&my_pthread_lock);
}
end_time = currentTime();
fprintf(stderr, "Pthread lock: %lu msecs\n",
elapsedTime(end_time - start_time));
return 0;
}
next prev parent reply other threads:[~2003-05-23 17:48 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-21 9:01 [Linux-ia64] Re: web page on O(1) scheduler Arjan van de Ven
2003-05-21 9:26 ` Mike Galbraith
2003-05-21 9:30 ` Mike Galbraith
2003-05-21 10:40 ` Duraid Madina
2003-05-21 10:43 ` Christoph Hellwig
2003-05-21 15:18 ` David Mosberger
2003-05-21 17:56 ` David Mosberger
2003-05-21 20:46 ` Mike Galbraith
2003-05-22 0:38 ` Rik van Riel
2003-05-22 5:52 ` Mike Galbraith
2003-05-22 9:52 ` Mike Galbraith
2003-05-22 16:25 ` Mike Galbraith
2003-05-22 17:58 ` David Mosberger
2003-05-23 1:07 ` Hans Boehm
2003-05-23 8:30 ` Arjan van de Ven
2003-05-23 17:48 ` Boehm, Hans [this message]
2003-05-23 18:04 ` Davide Libenzi
2003-05-24 0:10 ` Boehm, Hans
2003-05-24 0:20 ` Davide Libenzi
2003-05-24 0:53 ` Boehm, Hans
2003-05-24 5:38 ` Davide Libenzi
2003-05-24 14:43 ` Davide Libenzi
2003-05-24 16:50 ` Hans Boehm
2003-05-24 21:41 ` Davide Libenzi
2003-05-25 9:17 ` Mike Galbraith
-- strict thread matches above, loose matches on Subject: below --
2003-05-24 0:53 Boehm, Hans
2003-05-24 5:38 ` Davide Libenzi
2003-05-24 14:43 ` Davide Libenzi
2003-05-24 0:10 Boehm, Hans
2003-05-24 0:20 ` Davide Libenzi
2003-05-23 17:48 Boehm, Hans
2003-05-23 18:04 ` Davide Libenzi
2003-05-21 6:49 David Mosberger
2003-05-21 9:01 ` Arjan van de Ven
2003-05-21 10:40 ` [Linux-ia64] " Duraid Madina
2003-05-21 10:43 ` Christoph Hellwig
2003-05-21 13:12 ` Arjan van de Ven
2003-05-21 13:51 ` Olivier Galibert
2003-05-28 22:12 ` Bill Davidsen
[not found] ` <Pine.LNX.3.96.1030528180909.21414B-100000@gatekeeper.tmr.c om>
2003-05-29 5:59 ` Mike Galbraith
2003-06-02 8:05 ` Ingo Molnar
2003-06-04 4:07 ` Bill Davidsen
[not found] ` <Pine.LNX.4.44.0306020949520.3375-100000@localhost.localdom ain>
2003-06-02 13:51 ` Mike Galbraith
2003-06-04 3:52 ` Bill Davidsen
2003-06-04 4:55 ` David Schwartz
[not found] ` <Pine.LNX.3.96.1030603234616.16495B-100000@gatekeeper.tmr.c om>
2003-06-04 7:13 ` Mike Galbraith
2003-06-04 15:30 ` Jan Harkes
2003-05-21 19:18 ` Duraid Madina
2003-05-21 20:03 ` Helge Hafting
2003-05-21 22:59 ` Alan Cox
2003-05-23 1:07 ` Hans Boehm
2003-05-23 8:30 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ia64-105590723706003@msgid-missing \
--to=hans_boehm@hp.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.