Effective streaming questions

Discussion in 'C++' started by Alexander Adam, Sep 3, 2008.

  1. Hi there!

    I've got a few (more generic) questions for those C++ experts out
    there.

    1. I am trying to store any kind of data (custom PODs, numbers,
    strings etc.) within some kind of stream which consists of an unsigned
    char* array which gets resized whenever needed. Writing and reading is
    done by using a simple memcpy(). Is this the most efficient method
    considering that a single stream might include up to 10 different data
    values within it and for each read/write (which happens very often
    especially the reading) I'll do such a memcpy or is there a better,
    more general approach for such a thing? I am talking specifically
    about a rendering tree storage structure for 2d graphics

    2. What's the fastest and most efficient way to compress / uncompress
    the mentioned streams in memory?

    3. I am using some custom stream implementation for reading which can
    also do unicode conversion on the fly etc. The problem is this: first,
    I am using a virtual base class which defines a virtual ReadWChar()
    function. Next, I do call this function for the whole stream for each
    char which can result in thousands of calls at a time. Now, reading is
    not so of a problem as I am using a buffer underneath but I am more
    concerned of the overhead of the function call. Any thoughts on that?

    4. What's the general overhead considering perfomance of virtual
    classes / functions? To be honest, I am already scared on declaring a
    virtual destructor as I fear that the overall classes' function calls
    will be with lower perfomance or is that simply not true?

    5. Are there any updated perfomance documents out there giving some
    insights and what you can take care from the beginning considering
    modern C++ programming?

    thanks!
    Alex
    Alexander Adam, Sep 3, 2008
    #1
    1. Advertising

  2. Alexander Adam

    red floyd Guest

    On Sep 3, 1:29 am, Alexander Adam <> wrote:
    > Hi there!
    >
    > I've got a few (more generic) questions for those C++ experts out
    > there.
    >
    > 1. I am trying to store any kind of data (custom PODs, numbers,
    > strings etc.) within some kind of stream which consists of an unsigned
    > char* array which gets resized whenever needed. Writing and reading is
    > done by using a simple memcpy(). Is this the most efficient method
    > considering that a single stream might include up to 10 different data
    > values within it and for each read/write (which happens very often
    > especially the reading) I'll do such a memcpy or is there a better,
    > more general approach for such a thing? I am talking specifically
    > about a rendering tree storage structure for 2d graphics
    >
    > 2. What's the fastest and most efficient way to compress / uncompress
    > the mentioned streams in memory?
    >
    > 3. I am using some custom stream implementation for reading which can
    > also do unicode conversion on the fly etc. The problem is this: first,
    > I am using a virtual base class which defines a virtual ReadWChar()
    > function. Next, I do call this function for the whole stream for each
    > char which can result in thousands of calls at a time. Now, reading is
    > not so of a problem as I am using a buffer underneath but I am more
    > concerned of the overhead of the function call. Any thoughts on that?
    >
    > 4. What's the general overhead considering perfomance of virtual
    > classes / functions? To be honest, I am already scared on declaring a
    > virtual destructor as I fear that the overall classes' function calls
    > will be with lower perfomance or is that simply not true?
    >
    > 5. Are there any updated perfomance documents out there giving some
    > insights and what you can take care from the beginning considering
    > modern C++ programming?
    >


    Remove the word "efficient" from your vocabulary. Remember Knuth's
    Law: "Premature Optimization is the Root of All Evil". It's a hell of
    a lot easier to make a correct program fast, than to make a fast,
    incorrect program correct.
    red floyd, Sep 3, 2008
    #2
    1. Advertising

  3. Alexander Adam <> writes:

    > Hi there!
    >
    > I've got a few (more generic) questions for those C++ experts out
    > there.
    >
    > 1. I am trying to store any kind of data (custom PODs, numbers,
    > strings etc.) within some kind of stream which consists of an unsigned
    > char* array which gets resized whenever needed. Writing and reading is
    > done by using a simple memcpy(). Is this the most efficient method
    > considering that a single stream might include up to 10 different data
    > values within it and for each read/write (which happens very often
    > especially the reading) I'll do such a memcpy or is there a better,
    > more general approach for such a thing? I am talking specifically
    > about a rendering tree storage structure for 2d graphics
    >
    > 2. What's the fastest and most efficient way to compress / uncompress
    > the mentioned streams in memory?
    >
    > 3. I am using some custom stream implementation for reading which can
    > also do unicode conversion on the fly etc. The problem is this: first,
    > I am using a virtual base class which defines a virtual ReadWChar()
    > function. Next, I do call this function for the whole stream for each
    > char which can result in thousands of calls at a time. Now, reading is
    > not so of a problem as I am using a buffer underneath but I am more
    > concerned of the overhead of the function call. Any thoughts on that?
    >
    > 4. What's the general overhead considering perfomance of virtual
    > classes / functions? To be honest, I am already scared on declaring a
    > virtual destructor as I fear that the overall classes' function calls
    > will be with lower perfomance or is that simply not true?
    >
    > 5. Are there any updated perfomance documents out there giving some
    > insights and what you can take care from the beginning considering
    > modern C++ programming?


    If you need the last drop of performance and processor efficiency, C++
    is not the language for you. Use assembler, and fine true every
    instruction!

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, Sep 3, 2008
    #3
  4. Alexander Adam

    Guest

    I never noticed virtual calls becoming a problem until I was in the
    millions of operations in a tight loop. Write it as fast as you can
    and then see where it bottlenecks, and improve the bottleneck. Keep
    track of time improvements and you'll get a feel for when you are
    wasting time by optimizing. main thing is don't concat strings :)
    , Sep 3, 2008
    #4
  5. Alexander Adam

    Guest

    dont concat strings in a big loop, I should say.
    , Sep 3, 2008
    #5
  6. Alexander Adam

    James Kanze Guest

    On Sep 3, 5:13 pm, red floyd <> wrote:
    > On Sep 3, 1:29 am, Alexander Adam <> wrote:


    [...]
    > Remove the word "efficient" from your vocabulary.


    No. Just apply it where it makes the most sense, cost-wise.
    Programmer efficiency is critical, for example. Program
    efficiency is generally very relative, and depends on what the
    program will be used for.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Sep 4, 2008
    #6
  7. Alexander Adam

    James Kanze Guest

    On Sep 3, 10:29 am, Alexander Adam <> wrote:
    > I've got a few (more generic) questions for those C++ experts
    > out there.


    > 1. I am trying to store any kind of data (custom PODs, numbers,
    > strings etc.) within some kind of stream which consists of an unsigned
    > char* array which gets resized whenever needed. Writing and reading is
    > done by using a simple memcpy(). Is this the most efficient method
    > considering that a single stream might include up to 10 different data
    > values within it and for each read/write (which happens very often
    > especially the reading) I'll do such a memcpy or is there a better,
    > more general approach for such a thing? I am talking specifically
    > about a rendering tree storage structure for 2d graphics


    I'm not too sure what you mean with regards to streaming here.
    What is the purpose of using an unsigned char*, except if you're
    going to write and read it to some external source (disk or
    network)? And in that case, memcpy doesn't work; there's
    absolutely no guarantee that another program can read what
    you've written.

    > 2. What's the fastest and most efficient way to compress /
    > uncompress the mentioned streams in memory?


    Using a fast and efficient compression algorithm (which may
    depend on the actual data types).

    Note that if you're doing any serious compression downstream,
    the time it takes to serialize (your point 1, above) will be
    negligeable. You might even want to consider a text format.
    (The one time I did this, I output a highly redundant text
    format, piped to gzip.)

    > 3. I am using some custom stream implementation for reading which can
    > also do unicode conversion on the fly etc. The problem is this: first,
    > I am using a virtual base class which defines a virtual ReadWChar()
    > function. Next, I do call this function for the whole stream for each
    > char which can result in thousands of calls at a time. Now, reading is
    > not so of a problem as I am using a buffer underneath but I am more
    > concerned of the overhead of the function call. Any thoughts on that?


    It depends on the system and the compiler. I do this all the
    time, but I suspect that it could make a measurable difference
    on some machines, in some specific cases, but not very often.

    Note too that some (regrettably very few) compilers will use
    profiling data to eliminate critical virtual function calls,
    replacing them with inline versions of the function if the find
    that the same function is actually called most of the time.

    > 4. What's the general overhead considering perfomance of virtual
    > classes / functions?


    Compared to what? On the machines I usually use (Intel, AMD and
    Sparc), an implementation using virtual functions is no more
    expensive than one using switches or other mechanisms, but from
    what I understand, this isn't true on all machines.

    > To be honest, I am already scared on declaring a virtual
    > destructor as I fear that the overall classes' function calls
    > will be with lower perfomance or is that simply not true?


    That's simply not true. Declaring the destructor virtual may
    have a very small impact on destructing the object (but
    typically not measurable), but I know of no compiler where it
    will have any impact on anything else.

    > 5. Are there any updated perfomance documents out there giving
    > some insights and what you can take care from the beginning
    > considering modern C++ programming?


    Probably, but... performance depends enormously on the
    individual machine and compiler. What's true for one
    configuration won't be true for another. From experience, the
    most important thing you can do to ensure sufficient performance
    is to enforce rigorous encapsulation. That way, once you've
    profiled, and found what has to be changed in your code, for
    your configuration, you can change it easily, without having to
    rewrite the entire program.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Sep 4, 2008
    #7
  8. Alexander Adam

    Jerry Coffin Guest

    In article <>,
    says...

    [ ... ]

    > If you need the last drop of performance and processor efficiency, C++
    > is not the language for you. Use assembler, and fine true every
    > instruction!


    It's interesting how the people who give advice like this are _never_
    the same ones who hang out in any of the newsgroups where assembly
    language is topical, and shows that they really know assembly language
    well.

    In reality, somebody who knows what s/he's doing can predict quite well
    what a C or C++ (or Ada, Lisp, etc.) compiler is going to produce for
    most input, and the majority of the time, the compiler produces about
    the same code you'd write by hand. That being the case, writing all that
    code by hand rarely accomplishes anything useful at all.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Sep 7, 2008
    #8
  9. Alexander Adam

    James Kanze Guest

    On Sep 7, 4:19 pm, Jerry Coffin <> wrote:
    > In article <>,
    > says...
    > [ ... ]
    > In reality, somebody who knows what s/he's doing can predict
    > quite well what a C or C++ (or Ada, Lisp, etc.) compiler is
    > going to produce for most input, and the majority of the time,
    > the compiler produces about the same code you'd write by hand.


    With a really good compiler, that's not necessarily true. The
    compiler will produce much better code than you could write by
    hand. (Admittedly most C++ compilers aren't that good. Yet.)

    > That being the case, writing all that code by hand rarely
    > accomplishes anything useful at all.


    Writing everything in assembler is always a waste of time.
    Conceivably, if the profiler shows a problem in one tight loop,
    and all other attempts fail to achieve enough performance,
    rewriting that one loop in assembler might accomplish something,
    assuming you know the machine very, very well.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Sep 7, 2008
    #9
  10. Alexander Adam

    Jerry Coffin Guest

    In article <7b2ad5ae-f0c8-40da-9ac8-f2aa1087e5f5
    @f36g2000hsa.googlegroups.com>, says...

    [ ... ]

    > With a really good compiler, that's not necessarily true. The
    > compiler will produce much better code than you could write by
    > hand. (Admittedly most C++ compilers aren't that good. Yet.)


    Sadly, I've yet to see any compiler for any language for which that was
    true. Most compilers do better than most people realize, but a decent
    (not even great) assembly language programmer virtually never has any
    difficulty doing better. OTOH, you're unlikely to get a _significant_
    improvement except by knowing quite a bit and/or dealing with relatively
    unusual situations.

    > > That being the case, writing all that code by hand rarely
    > > accomplishes anything useful at all.

    >
    > Writing everything in assembler is always a waste of time.


    I'd agree that it's true 99.9% (and maybe even add another '9' or two on
    the end) of the time, but not quite always. An obvious example would be
    a talking greeting card. Here the price of even a small amount of memory
    is a significant percentage of the overall price, and there's little
    enough product differentiation that one being even marginally less
    expensive than another could lead to essentially shutting the second out
    of the market entirely.

    IOW, using a higher level language for even part of the final product
    virtually guarantees failure. OTOH, I'm the first to admit that such
    situations are _quite_ unusual, to put it mildly. For typical desktop
    and/or server applications, the situation is entirely different.

    > Conceivably, if the profiler shows a problem in one tight loop,
    > and all other attempts fail to achieve enough performance,
    > rewriting that one loop in assembler might accomplish something,
    > assuming you know the machine very, very well.


    I've written enough assembly language to be able to say with reasonable
    certainty that the situation's a bit more positive than that -- if you
    know the assembly language _reasonably_ well, and find a justification
    for doing so, you can pretty much guarantee doing better than any
    compiler around today.

    You just need to be aware of what you're getting into: not only is it
    extra work and produces fragile output, but it tends to be obsolete a
    _lot_ sooner than something written in a higher level language. A minor
    change in microarchitecture can render your careful optimizations
    entirely obsolete without a second thought!

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Sep 8, 2008
    #10
  11. Alexander Adam

    James Kanze Guest

    On Sep 8, 1:17 am, Jerry Coffin <> wrote:
    > In article <7b2ad5ae-f0c8-40da-9ac8-f2aa1087e5f5
    > @f36g2000hsa.googlegroups.com>, says...


    > [ ... ]
    > > With a really good compiler, that's not necessarily true. The
    > > compiler will produce much better code than you could write by
    > > hand. (Admittedly most C++ compilers aren't that good. Yet.)


    > Sadly, I've yet to see any compiler for any language for which
    > that was true. Most compilers do better than most people
    > realize, but a decent (not even great) assembly language
    > programmer virtually never has any difficulty doing better.


    Globally, or locally. I've actually used a Fortran compiler
    that did better than assembler programmers globally. Locally,
    of course, for some specific constructs, it could be beaten, but
    an assembler programmer's memory (e.g. with regard to what's in
    each register) isn't as good as that of the compiler.

    I suspect that it depends on the architecture as well. A
    machine with complicated timing constraints in the pipeline and
    a lot of registers favors the compiler; a machine with few
    registers and relatively few issues concerning the pipeline
    (Intel?) favors the programmer.

    > OTOH, you're unlikely to get a _significant_ improvement
    > except by knowing quite a bit and/or dealing with relatively
    > unusual situations.


    It's the dealing with unusual situations which really pays off.
    If the machine supports decimal arithmetic at the hardware
    level, for example, a few well placed lines of assembler will
    make all the difference in a BigDecimal class.

    > > > That being the case, writing all that code by hand rarely
    > > > accomplishes anything useful at all.


    > > Writing everything in assembler is always a waste of time.


    > I'd agree that it's true 99.9% (and maybe even add another '9'
    > or two on the end) of the time, but not quite always. An
    > obvious example would be a talking greeting card. Here the
    > price of even a small amount of memory is a significant
    > percentage of the overall price, and there's little enough
    > product differentiation that one being even marginally less
    > expensive than another could lead to essentially shutting the
    > second out of the market entirely.


    Agreed. I'd forgotten about things like that.

    > IOW, using a higher level language for even part of the final
    > product virtually guarantees failure. OTOH, I'm the first to
    > admit that such situations are _quite_ unusual, to put it
    > mildly.


    Maybe not that unusual, but in such cases, you generally don't
    have the option of C++ anyway. (You might have C, but even
    that's not really certain.

    > For typical desktop and/or server applications, the
    > situation is entirely different.


    > > Conceivably, if the profiler shows a problem in one tight
    > > loop, and all other attempts fail to achieve enough
    > > performance, rewriting that one loop in assembler might
    > > accomplish something, assuming you know the machine very,
    > > very well.


    > I've written enough assembly language to be able to say with
    > reasonable certainty that the situation's a bit more positive
    > than that -- if you know the assembly language _reasonably_
    > well, and find a justification for doing so, you can pretty
    > much guarantee doing better than any compiler around today.


    For a single loop, perhaps, and even then, I'm not really
    convinced. I know that I couldn't improve most of the loops
    generated by the Fortran compiler on the Perkin-Elmer (formally
    Interdata) 8/32, and I knew the assembler and the processor well
    enough to teach it, and to write drivers and such.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Sep 8, 2008
    #11
    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. Joe Buick

    Effective Email Marketing

    Joe Buick, Nov 29, 2004, in forum: VHDL
    Replies:
    0
    Views:
    463
    Joe Buick
    Nov 29, 2004
  2. Andrew FPGA
    Replies:
    14
    Views:
    1,146
    Jim Lewis
    Oct 5, 2005
  3. Mazen
    Replies:
    0
    Views:
    376
    Mazen
    Jul 11, 2003
  4. Replies:
    3
    Views:
    380
    cwdjrxyz
    Jan 26, 2006
  5. Guillaume Dargaud

    Streaming xml questions

    Guillaume Dargaud, Feb 23, 2004, in forum: XML
    Replies:
    1
    Views:
    337
    Patrick TJ McPhee
    Feb 23, 2004
Loading...

Share This Page