g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014 
<== Date ==> <== Thread ==>

Subject: Re: double buffered waveformRecord
From: Michael Davidsaver <mdavidsaver@bnl.gov>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: core-talk@aps.anl.gov
Date: Fri, 04 Jan 2013 19:08:27 -0500
On 1/4/2013 5:36 PM, Andrew Johnson wrote:
...
I wouldn't regard setting *no_elements and *offset as "playing games", I think
it's perfectly reasonable for a record to implement multiple-buffering by
dividing the data buffer into a series of smaller segments and using *offset
to select the current segment within the buffer.

I was hoping to avoid the need for one big allocation. For just two buffers this isn't an issue, but if one wants a deeper buffer then problems will eventually arise.

Also, I know what I am doing breaks with the arr (array slicing) channel plugin, which assumes the offset will always be [0, NELM).

...
If I've understood your code correctly, it's relying on *undefined behavior*
because you're subtracting pointers to two differently allocated buffers to
calculate the *offset value.  If the C compiler detects this it is quite at
liberty to do anything it likes at that point.

Like I said, abuse.

I am curious though about what 'differently allocated buffers' mean wrt. the C standard?

...
You will need to rename the record type before it has any chance of getting
into Base BTW, but you probably guessed that already...

All of this is highly experimental at this point.

...
I think there may be problems trying to change the pointer, because that's the
fundamental value that the server code uses to identify the field that was
subscribed to — it's the only field-specific parameter the record passes to
db_post_events() so it must match the pointer given out when the subscription
was created.

I was thinking that the replacement pointer would have the same lifetime as the 'offset' provided by get_array_info. So it would be fetched each time, used once, and then discarded.

For the pointer which would live permenently in DBADDR and be used for db_post_events() and similar, I was considering using '(void*)&prec->bptr'. If it isn't being dereferenced then it is just an identifier.


Interesting; have you done any bench-marking of that optimization? - Andrew

So far I have only done some semi-realistic test. I have a single waveform record which has a CP input link to itself and measure the processing rate. This shows a 2x improvement for waveform lengths between 100k and 1M. This drops off for smaller and larger lengths.

The real test will be trying this with a waveform digitizer. We have a SIS3302 VME ADC which I have been trying to push.


Michael


Replies:
Re: double buffered waveformRecord Andrew Johnson
References:
double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Andrew Johnson

Navigate by Date:
Prev: Re: double buffered waveformRecord Andrew Johnson
Next: Re: double buffered waveformRecord Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014 
Navigate by Thread:
Prev: Re: double buffered waveformRecord Andrew Johnson
Next: Re: double buffered waveformRecord Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·