Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: V4 design issue: Should primitive data types have well defined precisions?
From: Benjamin Franksen <benjamin.franksen@bessy.de>
To: core-talk@aps.anl.gov
Date: Wed, 22 Jun 2005 15:23:06 +0200
On Wednesday 22 June 2005 14:47, Dalesio, Leo `Bob` wrote:
> >From a functional point of view - the DA approach gives you total
> > flexibility.
>
> What does it do to the complexity of the implementation and the
> performance? Does it have an impact on the server? Or just the client
> side?

It depends. The more primitive types your language supports, the less 
work the DA-CA-bridge has to do converting.

For instance, a native Java server would have to convert requests for 
unsigned types on the server side. A Perl client will probably have to 
do a lot of work in order to convert Perl scalar values to whatever is 
appropriate, taking the server's native type into consideration. 
Similar for most untyped or dynamically types languages.

OTOH, IOCs are probably /not/ going to be implemented in Java. Or Perl 
or Haskell ;-)). And /if/ they are, we will have more severe problems 
with efficiency than those caused by network-native type conversion!

A C/C++ server need not convert primitive types. Regarding complex 
(composite) types, I suggest interfaces should be designed to allow 
efficient implementation in C/C++, as has been the goal with the 
current DA proposal, IIRC.

Ben

References:
RE: V4 design issue: Should primitive data types have well defined precisions? Dalesio, Leo `Bob`

Navigate by Date:
Prev: Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
Next: Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
Next: EPICS V4: Record Processing Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·