Another C++ performance article

Discussion in 'C++' started by Cholo Lennon, Jan 24, 2012.

  1. Cholo Lennon

    Cholo Lennon Guest

    Cholo Lennon, Jan 24, 2012
    #1
    1. Advertising

  2. Cholo Lennon

    Jorgen Grahn Guest

    On Tue, 2012-01-24, Cholo Lennon wrote:
    > May be this post is a bit off topic:
    >
    > Do you think this article is fair with C++?
    >
    > http://www.codeproject.com/Articles/304935/Operation-Performance-Evaluation


    "Investigating the cost of an operation in cycles within a real
    world, i.e., no peak, performance measurement of C#, C++, Java,
    Fortran and JavaScript"

    It's on topic, meaningless, and will be discussed here ad nauseum,
    just like all other benchmarks have in the past.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jan 24, 2012
    #2
    1. Advertising

  3. Cholo Lennon

    MikeWhy Guest

    "Jorgen Grahn" <> wrote in message
    news:...
    > On Tue, 2012-01-24, Cholo Lennon wrote:
    >> May be this post is a bit off topic:
    >>
    >> Do you think this article is fair with C++?
    >>
    >> http://www.codeproject.com/Articles/304935/Operation-Performance-Evaluation

    >
    > "Investigating the cost of an operation in cycles within a real
    > world, i.e., no peak, performance measurement of C#, C++, Java,
    > Fortran and JavaScript"
    >
    > It's on topic, meaningless, and will be discussed here ad nauseum,
    > just like all other benchmarks have in the past.


    I'll start... The reason to examine computation overhead is an overriding
    concern about system performance. I care much more about total throughput
    and latency rather than cycle counts of individual arithmetic operations.
    The benchmark is simplistic, uninteresting, and unenlightening by failing to
    exercise and account for memory bandwidth, cache misses, and instruction
    order optimizations available on modern processors.

    Real world computation intensive applications will run in multiple threads,
    not all involved in computation. Hyperthreading might or might not prove
    meaningful in the analysis. A truly good optimizer can leverage the
    consecutive locations of parallel arrays of values, to minimize stalling on
    cache misses. Throughput will almost certainly differ with more than the 3
    values involved, and again if the related values are stored as cache line
    aligned structs rather than separate arrays.

    More to the point, and not at all incidentally, the benchmark test is
    trivially and ideally suited for implementation in CUDA or other gpGPU. It
    falls into the category of being embarrassingly parallel. Even a clumsy
    implementation effectively measures memory bandwidth rather than computation
    cost.

    With this as context, the better metric of efficiency is percentage
    occupancy of available memory bandwidth, not the cycle cost of individual
    arithmetic operations. A benchmark that would interest me is one that
    relates memory bandwith to throughput of various implementations in CUDA,
    arrays, packed structs, and CPU (not GPU) threading schemes.
     
    MikeWhy, Jan 24, 2012
    #3
  4. Cholo Lennon

    Cholo Lennon Guest

    On 24/01/2012 18:27, MikeWhy wrote:

    > The benchmark is simplistic, uninteresting, and
    > unenlightening by failing to exercise and account for memory bandwidth,
    > cache misses, and instruction order optimizations available on modern
    > processors.
    >


    I thought the same at first glance. That's why I wanted to share it here
    in order to confirm my initial opinion: Another test where an author
    fails to set up a valid benchmark/experiment. The benchmark is very
    simple and general. The funny side is the article has received almost
    five stars from the readers.


    --
    Cholo Lennon
    Bs.As.
    ARG
     
    Cholo Lennon, Jan 24, 2012
    #4
  5. Cholo Lennon

    Bo Persson Guest

    Bo Persson, Jan 24, 2012
    #5
  6. Cholo Lennon <> wrote:
    > Do you think this article is fair with C++?


    IMO no benchmark between more than one programming language is fair for
    any of those languages (except for the winner in that particular benchmark,
    of course).

    Different programming languages tend to require different approaches
    when talking about efficient code. One of the most common mistakes in
    a multi-language benchmark is to try to match the code as exactly as
    possible in all the languages, using as similar constructs as possible
    in each one of them. (It's a rather common misconception that "implement
    the same task in all the languages" means "match every single construct
    as closely as possible in each language".) This will invariably favor
    some of the languages over the others, where such constructs will
    invariably not be the most optimal way to implement the task.

    Also, more often than not, the creator of the multi-language benchmark
    will be very proficient in one or two of the languages, and significantly
    less experienced with the rest. This naturally gives an edge to those
    languages he's more experienced with.

    If each of the implementations is made by a very competent programmer
    in said language, the benchmark may become a bit fairer. Even then, there
    may be different opinions even among experts what is the "best" way to
    implement something. Also, quite often, if this gives a more favorable
    result to a disliked language, the argument will usually shift towards
    the implementation in the popular language being "simpler" and "much
    easier to implement" and "doesn't require you to know so much about the
    intricacies of the language" and so on.
     
    Juha Nieminen, Jan 25, 2012
    #6
    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. jm
    Replies:
    1
    Views:
    529
    alien2_51
    Dec 12, 2003
  2. Grant Edwards

    Another "Go is Python-like" article.

    Grant Edwards, May 21, 2010, in forum: Python
    Replies:
    6
    Views:
    249
    Patrick Maupin
    May 23, 2010
  3. james_b
    Replies:
    0
    Views:
    108
    james_b
    Aug 23, 2003
  4. Tom Copeland
    Replies:
    5
    Views:
    161
    Scott Barron
    Dec 10, 2004
  5. pat eyler
    Replies:
    2
    Views:
    138
    pat eyler
    Aug 12, 2005
Loading...

Share This Page