Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Strange performance results -- any ideas?
From: Korhonen Timo <Timo.Korhonen@psi.ch>
To: Matthieu Bec <mbec@gmto.org>
Cc: tech-talk@aps.anl.gov
Date: Tue, 19 Jun 2012 18:04:28 +0200
This is probably a silly question, but is this reproducible (every run gives more or less the same results)?

best regards,

Timo



Matthieu Bec wrote:

We'd need to know more about the test to make better judgement but guess. bigger arrays = more bytes to process = CPU might throttle up seeing there is more work = improved throughput

Regards,
Matthieu

On 6/19/12 8:35 AM, Till Straumann wrote:
On 06/19/2012 10:33 AM, Matthieu Bec wrote:
Hello Dirk,

CPU throttling? That often comes enabled by default if your platform
supports it.
Again - why would the throughput improve as your arrays get
bigger that 4k?

T.

Regards,
Matthieu

On 6/19/12 2:54 AM, Dirk Zimoch wrote:
Hi all,

I am testing the performance of array parsing with StreamDevice on a
Linux system. I am reading strings like "3.1415,3.1415,...\n" into a
waveform record with FTVL=DOUBLE. The input is via TCP from localhost.

I found a very strange duration/size relationship:
size 1 duration: 423 time/element: 423.0
size 2 duration: 234 time/element: 117.0
size 4 duration: 229 time/element: 57.2
size 8 duration: 239 time/element: 29.9
size 16 duration: 238 time/element: 14.9
size 32 duration: 259 time/element: 8.1
size 64 duration: 281 time/element: 4.4
size 128 duration: 312 time/element: 2.4
size 256 duration: 397 time/element: 1.6
size 512 duration: 552 time/element: 1.1
size 1024 duration: 40023 time/element: 39.1
size 2048 duration: 41450 time/element: 20.2
size 4096 duration: 41678 time/element: 10.2
size 8192 duration: 5579 time/element: 0.7
size 16384 duration: 10947 time/element: 0.7
size 32768 duration: 21826 time/element: 0.7
size 65536 duration: 43508 time/element: 0.7
size 131072 duration: 77358 time/element: 0.6
size 262144 duration: 138533 time/element: 0.5
size 524288 duration: 275591 time/element: 0.5
size 1048576 duration: 518404 time/element: 0.5

All times are in 1e-6 seconds. Time is measured on the server. The clock starts before sending the string and stops after the waveform sends back
an acknowledge.

Protocol: {in "%f"; out "%(NORD)d";}

I understand that for small arrays, the time is dominated by overhead
and stays more or less constant.

But does anyone have an idea why is there this strange performance drop
for sizes between 1024 and 4096 elements?

Dirk



--
Timo Korhonen PSI (Paul Scherrer Institut, http://www.psi.ch) CH-5232 Villigen PSI tel + 41- 56 3103262 fax + 41 - 56 310 5090 e-mail: timo.korhonen@psi.ch


References:
Strange performance results -- any ideas? Dirk Zimoch
Re: Strange performance results -- any ideas? Matthieu Bec
Re: Strange performance results -- any ideas? Till Straumann
Re: Strange performance results -- any ideas? Matthieu Bec

Navigate by Date:
Prev: Re: Strange performance results -- any ideas? Matthieu Bec
Next: Re: Strange performance results -- any ideas? Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Strange performance results -- any ideas? Matthieu Bec
Next: Re: Strange performance results -- any ideas? Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·