From: Brian Hurt <bhurt@spnz.org>
To: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Severe loss of performance due to new signal handling (fwd)
Date: Tue, 21 Mar 2006 17:53:03 -0600 (CST) [thread overview]
Message-ID: <Pine.LNX.4.63.0603211752460.10435@localhost.localdomain> (raw)
[-- Attachment #1: Type: TEXT/PLAIN, Size: 968 bytes --]
Opps- didn't intend this message to be off-list.
---------- Forwarded message ----------
Date: Tue, 21 Mar 2006 16:32:51 -0600 (CST)
From: Brian Hurt <bhurt@spnz.org>
To: Robert Roessler <roessler@rftp.com>
Subject: Re: [Caml-list] Severe loss of performance due to new signal handling
On Tue, 21 Mar 2006, Robert Roessler wrote:
> Well, I *thought* there was a marked absence of "bit-level parallelism" in
> the signal-handling... ;)
>
> So the "expense" of individual atomic operations is not really what is at the
> heart of this performance problem...
Hmm. Maybe not. I'm measuring a 4 clock cycle cost for a xchgl, both with and
without a lock on my Athlon XP 1.8GHz. See attached code. Naturally, this is a
uniprocessor machine and the memory location is in L1 cache (or will be soon),
and no contention, so this is definately best case. 4 clocks is about rights
for a read and a write to L1 cache (each L1 cache access taking 2 clocks).
Brian
[-- Attachment #2: Type: TEXT/X-CSRC, Size: 1369 bytes --]
#include <stdio.h>
#include <pthread.h>
#include <semaphore.h>
#if !defined(__GNUC__) && !defined(__i386__)
#error This code only works with GCC/i386.
#endif
/* The reason this only works under GNU C and the x86 is we're using the
* rdtsc instruction.
*/
static inline unsigned long long rdtsc() {
unsigned long long rval;
asm volatile ("rdtsc" : "=A" (rval));
return rval;
}
static inline unsigned long read_and_clear(unsigned long * ptr) {
unsigned long rval;
asm volatile ("lock xchgl %0, %1" : "=r" (rval), "+m" (*ptr) : "0" (0));
return rval;
}
int main(void) {
int i;
volatile unsigned long trash;
unsigned long val = 1;
unsigned long long start, stop, time, min;
/* Time how long a rdtsc takes- we do this ten times and take the
* cheapest run.
*/
min = ~0ull;
for (i = 0; i < 10; ++i) {
start = rdtsc();
trash = 0;
stop = rdtsc();
time = stop - start;
if (time < min) {
min = time;
}
}
printf("Minimum time for a rdtsc instruction (in clocks): %llu\n", min);
min = ~0ull;
for (i = 0; i < 10; ++i) {
val = 1;
start = rdtsc();
trash = read_and_clear(&val);
stop = rdtsc();
time = stop - start;
if (time < min) {
min = time;
}
}
printf("Minimum time for a read_and_clear() + rdtsc (in clocks): %llu\n", min);
return 0;
}
next reply other threads:[~2006-03-21 23:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-21 23:53 Brian Hurt [this message]
2006-03-22 9:20 ` Alexander S. Usov
2006-03-22 10:56 ` Robert Roessler
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=Pine.LNX.4.63.0603211752460.10435@localhost.localdomain \
--to=bhurt@spnz.org \
--cc=caml-list@inria.fr \
/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