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: 25+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox