Cracking DES with C++ is faster than Java?

Discussion in 'C++' started by Julie, Apr 25, 2004.

  1. Julie

    Dez Akin Guest

    Most compilers today arent so stupid; Also C++ has a number of
    features that make it 'faster' than C in a number of cases, such as
    functor inlining, and compile time code generation. std::sort will
    allways run faster than qsort.
    For perf? The tightest inner loops perhaps, given that we're talking
    about crypto with very deterministic algorithms. It lends itself to
    SIMD instruction extentions that most compilers don't exploit.

    Optimizers are getting smarter though, and I suspect in not too many
    years it will be a waste of time to attempt to out-do the optimizer.
    In a couple of decades at the most I suspect it will be impossible for
    any human to outperform an optimizer. (Massalin's superoptimizer led
    to Denali, which I imagine will lead to more generic optimal code
    approximators)
     
    Dez Akin, Apr 27, 2004
    #21
    1. Advertisements

  2. More nonsense...
    And even more.

    /David
     
    David Rasmussen, Apr 27, 2004
    #22
    1. Advertisements

  3. No. There are some things that simply cannot be coded
    in any high-level language. For example, much of the
    stuff that an embedded processor has to do before
    starting to process the actual application.
     
    Douglas A. Gwyn, Apr 27, 2004
    #23
  4. Apparently he thinks he knows more than he
    actually does.
     
    Douglas A. Gwyn, Apr 27, 2004
    #24
  5. Julie

    tom_usenet Guest

    A carefully coded C++ solution will likely outperform a C one, unless
    extremely verbose and unmaintainable C code is used (i.e. no libraries
    - inline implementation of sorts!).

    C++ has a number of performance advantages over C, such as type based
    alias analysis, inline functions, etc. The ability to write efficient
    generic library components in C++ that give similar performance to
    inline code is a major boon over C (e.g. std::sort vs qsort, Blitz++
    vs equivalent C libraries).

    Obviously C99 fights back with "restrict" and "inline", but without
    templates it's always going to lag in the performant (speedwise)
    generic libraries area.

    Tom
     
    tom_usenet, Apr 27, 2004
    #25
  6. Julie

    Grumble Guest

    Grumble, Apr 27, 2004
    #26
  7. Julie

    Julie Guest

    ??? How have you determined that? Do you have any substantive references? If
    not, name something that exists in C but not C++ (excluding new C features
    introduced since the last C++ standard).
    This was a toy example, not a mandate. The fact still stands, compiling a C
    program w/ a C++ compiler will result in virtually the same executable code,
    there is no intrinsic penalty for C features in C++.

    If you still feel that this is not the case, please provide some facts,
    evidence, or substantive references to back up your argument.
    Again, evidence of such a statement would help. Aside from compiler QOI
    issues, could you please point out anything in the standard or supporting
    documentation that indicates that C++ is larger and slower for a executable
    that uses C constructs.
    Right, but as soon as you use a feature in one language that isn't in the
    other, you can no longer make a comparison.

    Regardless, you bring up 'objects'. These can be compared across languages
    such as:

    C:
    struct of function pointers and an instance pointer to simulate (non-virtual)
    class instance

    C++:
    standard (non-virtual) class instance

    ASM:
    hand-coded structure, probably not too different from the method used in the C
    implementation

    Java:
    standard class instance

    All of these have approximately the same behavior, as far as the language
    permits.

    I suspect (merely stating that I haven't built a test harness for the above
    tests) that ASM, C, and C++ all perform virtually the same for this example,
    and Java is consistently slower.

    According to what I gather from your arguments, the performance would always be
    ordered as, and appreciably different: ASM < C < C++ < Java.
     
    Julie, Apr 27, 2004
    #27
  8. [snip]

    If I don't err, there can be codes that are valid in both
    C and C++ but have different meanings according to the
    respective standards. If you happen to have such and have
    them compiled once as C and the other time as C++, you might
    get into difficulties under circumstances.

    M. K. Shen
     
    Mok-Kong Shen, Apr 27, 2004
    #28
  9. Julie

    Julie Guest

    Just as slow as if a C program had registered an equal amount of startup
    routines.
    Standalone functions *never* have an extra hidden argument. Non-static class
    member functions (methods) do have the 'this' pointer passed around as function
    calls are made.
    Not a slowdown, but a difference in behavior. You can't compare a regular (C)
    function w/ a class method or virtual method, they just don't compare.
     
    Julie, Apr 27, 2004
    #29
  10. [snip]

    What Gwyn meant is, I suppose, that C is not a genuine subset
    of C++, no more nor less. See the pointer given in Grumble's
    post.

    M. K. Shen
     
    Mok-Kong Shen, Apr 27, 2004
    #30
  11. type_info structures are only created for "polymorphic" types, i.e.,
    types with virtual functions.
     
    Niklas Borson, Apr 27, 2004
    #31
  12. There are a number of ways to write code which is valid C (i.e. C-89)
    but illegal C++:


    1. C has fewer reserved words which can be used as identifiers:

    int class, template, try, catch;

    Such declarations are illegal in C++.



    2. In C this is legal:

    char a[6] = "123456";

    In C++ the array must be large enough also for the terminating NUL of
    the string constant.



    3. In C, struct tags and typedef symbols are in different name spaces
    but in C++ they are in the same name space. Thus this is legal in
    C but illegal in C++:

    typedef int type;

    struct type
    {
    type memb; // int
    struct type * next; // struct pointer
    };

    void foo(type t, int i)
    {
    int type;
    struct type s;

    type = i + t + sizeof(type);
    s.memb = type;
    }


    The code below is valid both in C and C++ but the semantics will be different:

    int sz = 80;

    int size(void)
    {
    struct sz
    { ... };

    return sizeof(sz); /* sizeof(int) in C, */
    /* sizeof(struct sz) in C++ */
    }



    4. C++ requires a cast when assigning a void pointer to another
    kind of pointer; C does not require that:

    char *p = malloc(1234); /* Legal C, illegal C++ */

    --
     
    Paul Schlyter, Apr 27, 2004
    #32
  13. No, he means that C++ is not a genuine superset of
    C. One must get precedence right.

    Greg.
     
    Gregory G Rose, Apr 27, 2004
    #33
  14. Sorry, what is 'precedence' here? If A is subset of B,
    then B is superset of A, and vice versa, isn't it?

    M. K. Shen
     
    Mok-Kong Shen, Apr 28, 2004
    #34
  15. Julie

    Jerry Coffin Guest

    (Dez Akin) wrote in message
    [ ... ]
    Hmm...an interesting proposition. I've been hearing variations on
    this theme since (at least) the FORTRAN IV days.

    If anything, it looks to me like thie situation is getting worse: I
    don't think I've looked at anything in the last 5 years that was
    nearly AS CLOSE to optimal as Control Data's FORTRAN IV compiler
    typically produced 20+ years ago!

    Part of this may be that I've gotten better at writing assembly
    language, but frankly I rather doubt it -- I doubt that the extra
    experience has compensated for the simple fact that I don't write
    assembly code nearly as often anymore.
     
    Jerry Coffin, Apr 28, 2004
    #35
  16. Julie

    Julie Guest

    Dez Akin wrote:
    [snip]
    I don't buy that.

    If processing unit architecture stayed the same during that time, then you
    would have an argument.

    However, each time a processor is revved, new features, behaviors, opcodes,
    etc. are added. At that point, the compiler writer must then decide on what
    feature to incorporate, if at all, let alone optimizations.

    It will always be possible to out-do the optimizer, however the value of such
    has been steadily decreasing as processor speeds have increased.
     
    Julie, Apr 28, 2004
    #36
  17. Julie

    Tim Smith Guest

    You'll have to be more specific. A random sampling of a few of the
    incompatibilities there turned up nothing that would make it not safe to
    compile a C program with a C++ compiler. For example, C now has long long
    and C++ does not. So...if you try to compile a C program that uses that on
    a C++ compiler that has not had it added as an extension, you'll get an
    error, and have to port your code.

    I would take "not safe" as being things that *will* compile, but whose
    runtime behavior is different in a way that can break the program.
     
    Tim Smith, Apr 28, 2004
    #37
  18. Programming languages have evolved a bit since FORTRAN IV. If all
    we had was still FORTRAN IV, I'm convinced that almost no-one would
    be able to write assembly code outperforming the output from a
    modern FORTRAN IV compiler.

    The programming language FORTRAN was designed with one goal being the
    highest priority: to produce efficient machine code. When John
    Backus implemented the FORTRAN I compiler back in 1957, programmers
    were skeptical of high-level languages in general -- they were
    usually convinced that the efficiency of the generated code would be
    terrible or, at best, bad. Remember that at this time, computer were,
    by today's standards, extremely slow. In addition, computer time did
    cost a lot of money, perhaps half-a-dollar for every CPU second or
    so. Therefore efficient programs were of a very high priority;
    in comparison, programmer time was cheap.

    FORTRAN I did succeed in producing code almost as efficient as
    hand-written code by a skilled programmer, and as a result high-level
    languages got accepted. Later, when computers got more powerful and
    CPU time got much cheaper, the priorities changed: when the
    programmer time got more expensive than the CPU time, it became
    sensible to design high-level languages to ease program development
    rather than to produce efficient machine code.

    Therefore the situation is probably "worse" today: the code
    produced by, say, a Java compiler is definitely much less
    efficient than the code produced by a FORTRAN IV compiler.
    But OTOH the complex programs written in today's HLL's could
    never reasonably have been implemented in FORTRAN IV, a
    language which even lacks recursion.

    Finally, if your program includes some text processing (which
    virtually every modern program does to some extent), FORTRAN IV would
    be a hopeless language to use, since it lacks string variables. To
    do text processing in FORTRAN IV, you must put text in numerical
    variables, and keep track of how many characters fits in a machine
    word. And to port such a program from a computer where, say, 4
    character fits in a word to another computer where, say, 10
    characters fits in a word would be a nightmare if the program does
    non-trivial text processing. In such a case it's highly likely that
    the text processing parts of the FORTRAN IV program will produce code
    with bad efficiency.

    --
     
    Paul Schlyter, Apr 28, 2004
    #38
  19. The code snippet below will compile both as C and as C++, but the
    semantics will be different in C and in C++:


    int sz = 80;

    int size(void)
    {
    struct sz
    { ... };

    return sizeof(sz); // sizeof(int) in C,
    // sizeof(struct sz) in C++
    }


    Actually this example could be used to have the code determine,
    at runtime, whether it has been compiled as C or as C++.

    --
     
    Paul Schlyter, Apr 28, 2004
    #39
  20. Julie

    Phil Carmody Guest

    How about the standards? Doug is more well aware of the standard than most.
    How about the section in Stroustrup that covers things that used to be legal
    in C that aren't legal in C++?
    There are hundreds of examples.

    Dumb examples, which you should have been able to work out yourself, would
    be major changes to language structure such as:

    - Use of C++-only keywords as variable names is legal in C,
    int class;

    - Change in comment syntax, the ability in trad C to have a /*comment*/
    immmediately after a division symbol.
    i = x//**/y
    ;

    However, I'd disagree with Doug's "in general" - unless he means
    "given arbitrary source by other people". I frequently migrate
    my own old C code to C++ with no changes at all. I don't remember
    the last time I encountered _any_ of the many issues.
    In general, for me, it is perfectly safe to compile as C++ the code
    that I have previously been compiling as C. I know others who
    migrate code safely too. In fact in general, people I know migrate
    code safely.

    Phil
     
    Phil Carmody, Apr 28, 2004
    #40
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.