Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Severe loss of performance due to new signal handling (fwd)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alexander S. Usov <A.S.Usov@k...>
Subject: Re: [Caml-list] Severe loss of performance due to new signal handling (fwd)
On Wednesday 22 March 2006 00:53, Brian Hurt wrote:
> 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).

$ ./a.out
Minimum time for a rdtsc instruction (in clocks): 88
Minimum time for a read_and_clear() + rdtsc (in clocks): 248

$ grep 'model name' /proc/cpu
model name      : Intel(R) Pentium(R) 4 CPU 2.00GHz


-- 
Best regards,
  Alexander.