Performance vs. Design (long)

Discussion in 'C Programming' started by Case, Jun 24, 2004.

  1. Case

    Case Guest

    I've had some discussions with colleagues about the
    API of a module for sending/receiving messages on a
    network connection.

    On both ends are different applications, each having
    their own internal way of storing the data which has
    to be communicated (using a common data protocol).

    I proposed to use a common interface, having the face
    of the network data protocol (XYZ). Many fields in the
    protocol message are optional. I proposed to use a
    bit-field structure. To prevent one extra copy of
    large chucks of data, I proposed to use pointers.

    typedef struct
    {
    unsigned int number1 : 1;
    unsigned int number2 : 1;
    unsigned int much_data : 8; /* > 0 means length */
    } XYZ_ind;

    typedef struct
    {
    int number1;
    int number2;
    char *much_data;
    XYX_ind_t ind;
    } XYZ_data_t;

    void XYZ_send(XYZ_data_t *data); /* encodes, then sends */

    The receiving side uses a callback, with similar prototype.

    Both sides will now have to convert their own internal format
    to a XYZ_data_t structure. This creates a clea[n|r] interface,
    making the XYZ module independent of either side.


    The 'opposing' idea is to not specify a common interface for
    all users. So, no XYZ_data_t. Instead of one shared XYZ_send(),
    there will be two: A_send(A_data_t *) and B_send(B_data *).
    Instead of one module, there will be three.

    The only advantage above having a real interface, is performance:
    no conversion between internal format to XYZ_data_t (which is not
    much more than assignments). The A_send() and B_send() will both
    encode the message in their own way, and right away.


    Yes, we are working on time-critical stuff, but I have the feeling
    that this second approach falls in the 97% of the 'premature opti-
    mization, being the root of all evil'. I estimated that the clean
    interface may add about 1/1000 to the execution time.

    Any thoughts on this issue?

    Case
    Case, Jun 24, 2004
    #1
    1. Advertising

  2. Case

    CBFalconer Guest

    Case wrote:
    >
    > I've had some discussions with colleagues about the
    > API of a module for sending/receiving messages on a
    > network connection.
    >
    > On both ends are different applications, each having
    > their own internal way of storing the data which has
    > to be communicated (using a common data protocol).
    >
    > I proposed to use a common interface, having the face
    > of the network data protocol (XYZ). Many fields in the
    > protocol message are optional. I proposed to use a
    > bit-field structure. To prevent one extra copy of
    > large chucks of data, I proposed to use pointers.
    >
    > typedef struct
    > {
    > unsigned int number1 : 1;
    > unsigned int number2 : 1;
    > unsigned int much_data : 8; /* > 0 means length */
    > } XYZ_ind;
    >

    .... snip ...
    > mization, being the root of all evil'. I estimated that the
    > clean interface may add about 1/1000 to the execution time.
    >
    > Any thoughts on this issue?


    What clean interface? One bit numbers don't carry much
    information, and I have a tough time envisioning much_data crammed
    into 8 bits. Also, bit fields are inherently non-portable, even
    between generations of the same compiler on the same hardware.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Jun 24, 2004
    #2
    1. Advertising

  3. Case

    Dan Pop Guest

    In <> CBFalconer <> writes:

    >into 8 bits. Also, bit fields are inherently non-portable, even

    ^^^^
    >between generations of the same compiler on the same hardware.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Care to provide a couple of concrete examples? I have a hard time
    imagining an implementor screwing his user base...

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Jun 24, 2004
    #3
  4. Case

    Case Guest

    CBFalconer wrote:
    > Case wrote:
    >
    >>I've had some discussions with colleagues about the
    >>API of a module for sending/receiving messages on a
    >>network connection.
    >>
    >>On both ends are different applications, each having
    >>their own internal way of storing the data which has
    >>to be communicated (using a common data protocol).
    >>
    >>I proposed to use a common interface, having the face
    >>of the network data protocol (XYZ). Many fields in the
    >>protocol message are optional. I proposed to use a
    >>bit-field structure. To prevent one extra copy of
    >>large chucks of data, I proposed to use pointers.
    >>
    >>typedef struct
    >>{
    >> unsigned int number1 : 1;
    >> unsigned int number2 : 1;
    >> unsigned int much_data : 8; /* > 0 means length */
    >>} XYZ_ind;
    >>

    >
    > ... snip ...
    >
    >>mization, being the root of all evil'. I estimated that the
    >>clean interface may add about 1/1000 to the execution time.
    >>
    >>Any thoughts on this issue?

    >
    >
    > What clean interface? One bit numbers don't carry much
    > information, and I have a tough time envisioning much_data crammed
    > into 8 bits. Also, bit fields are inherently non-portable, even
    > between generations of the same compiler on the same hardware.
    >


    XYZ_ind contains presence/length indicators for the actual
    structure members, which have the same name.

    Case
    Case, Jun 24, 2004
    #4
  5. Case

    Alan Balmer Guest

    On Thu, 24 Jun 2004 13:26:24 +0200, Case <> wrote:

    >I've had some discussions with colleagues about the
    >API of a module for sending/receiving messages on a
    >network connection.
    >
    >On both ends are different applications, each having
    >their own internal way of storing the data which has
    >to be communicated (using a common data protocol).
    >
    >I proposed to use a common interface, having the face
    >of the network data protocol (XYZ). Many fields in the
    >protocol message are optional. I proposed to use a
    >bit-field structure. To prevent one extra copy of
    >large chucks of data, I proposed to use pointers.
    >
    >typedef struct
    >{
    > unsigned int number1 : 1;
    > unsigned int number2 : 1;
    > unsigned int much_data : 8; /* > 0 means length */
    >} XYZ_ind;
    >
    >typedef struct
    >{
    > int number1;
    > int number2;
    > char *much_data;
    > XYX_ind_t ind;
    >} XYZ_data_t;
    >
    >void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
    >

    I wouldn't use the bit fields. Aside from their portability problems,
    they will probably be less efficient - the transmission time saved
    will be less than the additional processing time.
    [OT]
    Communications protocols typically send the message size first, making
    it easy to grab the entire message in two reads, and making it easy to
    send variable size messages, or change your mind about the message
    size.
    I assume that your send routine is sending the data that much_data
    points to, not the pointer itself.

    >The receiving side uses a callback, with similar prototype.
    >
    >Both sides will now have to convert their own internal format
    >to a XYZ_data_t structure. This creates a clea[n|r] interface,
    >making the XYZ module independent of either side.
    >
    >
    >The 'opposing' idea is to not specify a common interface for
    >all users. So, no XYZ_data_t. Instead of one shared XYZ_send(),
    >there will be two: A_send(A_data_t *) and B_send(B_data *).
    >Instead of one module, there will be three.
    >
    >The only advantage above having a real interface, is performance:
    >no conversion between internal format to XYZ_data_t (which is not
    >much more than assignments). The A_send() and B_send() will both
    >encode the message in their own way, and right away.
    >
    >
    >Yes, we are working on time-critical stuff, but I have the feeling
    >that this second approach falls in the 97% of the 'premature opti-
    >mization, being the root of all evil'. I estimated that the clean
    >interface may add about 1/1000 to the execution time.
    >
    >Any thoughts on this issue?
    >
    >Case


    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, Jun 24, 2004
    #5
  6. Case

    Case - Guest

    Alan Balmer wrote:
    > On Thu, 24 Jun 2004 13:26:24 +0200, Case <> wrote:
    >>I've had some discussions with colleagues about the
    >>API of a module for sending/receiving messages on a
    >>network connection.
    >>
    >>On both ends are different applications, each having
    >>their own internal way of storing the data which has
    >>to be communicated (using a common data protocol).
    >>
    >>I proposed to use a common interface, having the face
    >>of the network data protocol (XYZ). Many fields in the
    >>protocol message are optional. I proposed to use a
    >>bit-field structure. To prevent one extra copy of
    >>large chucks of data, I proposed to use pointers.
    >>
    >>typedef struct
    >>{
    >> unsigned int number1 : 1;
    >> unsigned int number2 : 1;
    >> unsigned int much_data : 8; /* > 0 means length */
    >>} XYZ_ind;
    >>
    >>typedef struct
    >>{
    >> int number1;
    >> int number2;
    >> char *much_data;
    >> XYX_ind_t ind;
    >>} XYZ_data_t;
    >>
    >>void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
    >>

    >
    > I wouldn't use the bit fields. Aside from their portability problems,
    > they will probably be less efficient - the transmission time saved
    > will be less than the additional processing time.
    > [OT]
    > Communications protocols typically send the message size first, making
    > it easy to grab the entire message in two reads, and making it easy to
    > send variable size messages, or change your mind about the message
    > size.
    > I assume that your send routine is sending the data that much_data
    > points to, not the pointer itself.


    I think I am so much in this design, that I forgot to
    mention essentials for understanding it for outsiders.
    Sorry about this people. I don't send the XYZ_ind_t
    field, which is only used to indicate which fields of
    the actual data in the rest of the struct needs to be
    send.

    I decided to use bit-fields because of their small size
    compared to using a set of booleans (i.e., int's). This
    is because I need to initializa all indicators to 0;
    again a matter of performance. In my real aplication
    there are about 40 optional fields, of which less than
    half are actually being used on average.

    In my view, bit-fields are not that performance demanding
    compared to using int's set to 0 or 1. What do you think?

    Case
    Case -, Jun 24, 2004
    #6
  7. On Thu, 24 Jun 2004, Case - wrote:
    > >>
    > >>typedef struct
    > >>{
    > >> unsigned int number1 : 1;
    > >> unsigned int number2 : 1;
    > >> unsigned int much_data : 8; /* > 0 means length */
    > >>} XYZ_ind;

    > >
    > > I wouldn't use the bit fields.

    [...]
    > I decided to use bit-fields because of their small size
    > compared to using a set of booleans (i.e., int's). This
    > is because I need to initializa all indicators to 0;
    > again a matter of performance. In my real aplication
    > there are about 40 optional fields, of which less than
    > half are actually being used on average.
    >
    > In my view, bit-fields are not that performance demanding
    > compared to using int's set to 0 or 1. What do you think?


    I would use a set of flags, myself.

    struct XYZ_ind
    {
    unsigned long fields;
    int much_data;
    };

    #define FIELD_NUMBER1 0x0001
    #define FIELD_NUMBER2 0x0002
    #define FIELD_FOO 0x0004
    [...]

    Then instead of 'if (x->number1)' you would write
    'if (x->fields & FIELD_NUMBER1)'. Extra typing, but guaranteed to
    be small (unlike bit-fields, AFAIK) and pretty fast in practice.
    And bitwise flags are IMHO less obscure than bit-fields, although
    you could argue both ways, I suppose.

    And of course initializing all your flags to zero becomes a single
    assignment, instead of 32 assignments. That's a plus.

    If you need more than 32 flags, just add a 'fields2' member to
    your struct. If it sounds reasonable, you might segregate the
    flags by purpose, e.g.

    unsigned int header_flags;
    unsigned int encoding_flags;
    unsigned int message_flags;
    unsigned int network_flags;
    [...]

    HTH,
    -Arthur
    Arthur J. O'Dwyer, Jun 24, 2004
    #7
  8. In article <40db244b$0$62399$>,
    Case - <> wrote:

    > I decided to use bit-fields because of their small size
    > compared to using a set of booleans (i.e., int's). This
    > is because I need to initializa all indicators to 0;
    > again a matter of performance. In my real aplication
    > there are about 40 optional fields, of which less than
    > half are actually being used on average.
    >
    > In my view, bit-fields are not that performance demanding
    > compared to using int's set to 0 or 1. What do you think?


    Bit fields are inherently non-portable. To maximise portability, send a
    sequence of unsigned char values with values from 0 to 255. Instead of
    bit-fields, use the eight bits in the unsigned char.

    Otherwise, at the very least you will end up having to define your
    structs in different ways depending on the compiler.
    Christian Bau, Jun 24, 2004
    #8
  9. "Case -" <> wrote in message
    news:40db244b$0$62399$...
    > Alan Balmer wrote:
    > > On Thu, 24 Jun 2004 13:26:24 +0200, Case <> wrote:
    > >>I've had some discussions with colleagues about the
    > >>API of a module for sending/receiving messages on a
    > >>network connection.
    > >>
    > >>On both ends are different applications, each having
    > >>their own internal way of storing the data which has
    > >>to be communicated (using a common data protocol).
    > >>
    > >>I proposed to use a common interface, having the face
    > >>of the network data protocol (XYZ). Many fields in the
    > >>protocol message are optional. I proposed to use a
    > >>bit-field structure. To prevent one extra copy of
    > >>large chucks of data, I proposed to use pointers.
    > >>
    > >>typedef struct
    > >>{
    > >> unsigned int number1 : 1;
    > >> unsigned int number2 : 1;
    > >> unsigned int much_data : 8; /* > 0 means length */
    > >>} XYZ_ind;
    > >>
    > >>typedef struct
    > >>{
    > >> int number1;
    > >> int number2;
    > >> char *much_data;
    > >> XYX_ind_t ind;
    > >>} XYZ_data_t;
    > >>
    > >>void XYZ_send(XYZ_data_t *data); /* encodes, then sends */
    > >>

    > >
    > > I wouldn't use the bit fields. Aside from their portability

    problems,
    > > they will probably be less efficient - the transmission time saved
    > > will be less than the additional processing time.
    > > [OT]
    > > Communications protocols typically send the message size first,

    making
    > > it easy to grab the entire message in two reads, and making it easy

    to
    > > send variable size messages, or change your mind about the message
    > > size.
    > > I assume that your send routine is sending the data that much_data
    > > points to, not the pointer itself.

    >
    > I think I am so much in this design, that I forgot to
    > mention essentials for understanding it for outsiders.
    > Sorry about this people. I don't send the XYZ_ind_t
    > field, which is only used to indicate which fields of
    > the actual data in the rest of the struct needs to be
    > send.
    >
    > I decided to use bit-fields because of their small size
    > compared to using a set of booleans (i.e., int's). This
    > is because I need to initializa all indicators to 0;
    > again a matter of performance. In my real aplication
    > there are about 40 optional fields, of which less than
    > half are actually being used on average.
    >
    > In my view, bit-fields are not that performance demanding
    > compared to using int's set to 0 or 1. What do you think?
    >

    It depends upon the processor. Some processors have built-in
    bit-handling instructions; some do not. Most mid- to high-range
    processors handle ints much more efficiently than they handle individual
    bits.

    Travis
    Travis Breitkreutz, Jun 25, 2004
    #9
  10. I would use flags either.
    --
    Felipe Magno de Almeida
    Ciencia da Computacao - Unicamp
    - UIN: 146989862
    Cause Rock and Roll can never die.
    "if you want to learn something really well, teach it to a computer."
    What is Communism?
    Answer: "Communism is the doctrine of the conditions of the liberation
    of the proletariat." (by Karl Marx)
    Felipe Magno de Almeida, Jul 17, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George Marsaglia

    Assigning unsigned long to unsigned long long

    George Marsaglia, Jul 8, 2003, in forum: C Programming
    Replies:
    1
    Views:
    653
    Eric Sosman
    Jul 8, 2003
  2. Daniel Rudy

    unsigned long long int to long double

    Daniel Rudy, Sep 19, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,170
    Peter Shaggy Haywood
    Sep 20, 2005
  3. Mathieu Dutour

    long long and long

    Mathieu Dutour, Jul 17, 2007, in forum: C Programming
    Replies:
    4
    Views:
    456
    santosh
    Jul 24, 2007
  4. Bart C

    Use of Long and Long Long

    Bart C, Jan 9, 2008, in forum: C Programming
    Replies:
    27
    Views:
    776
    Peter Nilsson
    Jan 15, 2008
  5. veryhotsausage
    Replies:
    1
    Views:
    1,770
    veryhotsausage
    Jul 4, 2008
Loading...

Share This Page