Cracking DES with C++ is faster than Java?

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

  1. Julie

    Julie Guest


    I am going to write a program cracking DES.
    One says that C++ (actually C) is faster than Java.
    Is this true?

    Julie, Apr 25, 2004
    1. Advertisements

  2. It depends on the implementation (i.e. the compiler), but in practice
    and in general: yes.

    David Rasmussen, Apr 25, 2004
    1. Advertisements

  3. That depends on several factors,
    but in general, programs coded in C will
    be slightly faster than if C++ had been used
    and noticeably faster than if Java were used.
    However, the fastest DES crackers tend to use
    some assembly language in order to exploit
    available hardware instructions that are not
    likely to be used in code generated by a

    Why bother to write a DES cracker when you
    can obtain one that has already had a lot of
    development work put into it?
    Douglas A. Gwyn, Apr 25, 2004
  4. Julie

    Liz Guest

    or as they say in canada
    Liz, Apr 25, 2004
  5. At first I thought you were our resident Julie, but I see that you aren't.

    The aspect of Java that's inherently slow is the management of object
    creation/allocation/copying. If your DES cracker works strictly with a raw
    array of bytes and your compiler generates reasonable code (some compilers,
    like GNU Java, can generate native executables), there's a good possibility
    that the difference in execution times could be negligible. However, if you
    introduce object creation into the mix or target a JVM that has no JIT
    compilation, you're just handing the victory to C++ on a silver platter.

    Claudio Puviani
    Claudio Puviani, Apr 25, 2004
  6. There are special techniques for DES, most programs
    are in C and assembler.
    Jave is snail like.
    Jan Panteltje, Apr 25, 2004
  7. Julie

    Jon Bell Guest

    Eh? :)
    Jon Bell, Apr 25, 2004
  8. Julie

    Leor Zolman Guest

    Why do you say that? C++ was designed so as "not to leave room for a
    lower-level language" (including C), so I can't imagine how anything you
    code in C would become slower as a result of adaptation to / compilation
    under C++ ... unless you go from a superior C compiler to an inferior C++
    compiler, of course.
    Leor Zolman, Apr 26, 2004
  9. Julie

    Tom St Denis Guest

    It can be. If you don't know why you really ought to take a step back
    and learn some computer science...

    Tom St Denis, Apr 26, 2004
  10. No -- the fastest DES crackers use dedicated DES hardware, and then
    it doesn't matter that much whether you use assembler or C to "talk"
    to that hardware. DES as an algorithm was designed to be implemented
    in hardware, and that's why software implementations of DES are so
    slow. Later algorithms (e.g. AES) are usually designed to be
    implemented on common microprocessors, and that's why software
    implementations of these are so much faster than software
    implementations of DES.
    ....such as a DES hardware chip...

    Paul Schlyter, Apr 26, 2004
  11. Usually, Java is compiled into bytecode, which is somehow native code
    for a "virtual machine". When the program is executed, the bytecode is
    compiled into native code (by the "JIT" compiler). That compilation
    handles only local optimizations, and is not good as other types of
    optimizations (such as inlining). Besides, Java is designed so as to be
    "safe", therefore all array accesses are checked with regards to the
    array length. This slows down Java much. On pure integer computations
    (such as DES cracking), you may expect a factor of 3 between a Java
    implementation and an optimized C (or C++) implementation.

    Of course, since most applications are I/O constrained, or limited by
    the memory bandwidth, that slowdown factor is of little importance,
    except for the very few routines which require raw cpu power. A DES
    cracker is a very uncommon application.

    Besides, you can get much worse performance, both with Java and C, if
    you do not know what happens "under the hood". For instance, using
    dynamic memory allocation (new, malloc()...) inside the inner loop can
    kill speed very effectively. If you want to produce optimized code,
    you have to take care of the fine details.

    As for C vs C++, this is a long debated issue. The C++ model can put
    some limitations on the compiler (for instance, exceptions have to
    work out their way through the stack frames, which means that the
    compiler cannot become too fancy with them) but it can also provide the
    programmer with syntaxic constructions which help in building optimized
    code. A very good C programmer and a very good C++ programmer, both
    using proper tools, will produce programs of similar performance. On
    some architecture (such as the PC), a very good assembly programmer will
    beat both (at the cost of much reduced portability).

    --Thomas Pornin
    Thomas Pornin, Apr 26, 2004
  12. Julie

    Julie Guest

    Yep, different Julie.
    Julie, Apr 26, 2004
  13. The JVM from Sun is actually very good at inlining, and it can also
    inline virtual methods if it can prove that a method is not overridden.
    This is true, although modern JVMs can eliminate bounds checks in many
    Sounds about right. I see no point in writing a DES cracker in Java. The
    features that make java good (oo, safety, portability, ease of use) are
    of no use in such a program, especially as it is not hard to write a
    safe, portable C or C++ program for this task.
    =?ISO-8859-1?Q?Daniel_Sj=F6blom?=, Apr 26, 2004
  14. This clearly shows poor understanding of Java, especially recently.
    Read up on the subject first:

    or google your own benchmarks. C/C++ certainly has some advantages,
    Java is certainly no "snail".

    -Mike Scovetta
    Michael Scovetta, Apr 26, 2004
  15. C++ has several features that force the runtime to
    use more time. Just the need to run through the
    table of static initializers before beginning
    program execution is already a slowdown. Functions
    generally have an extra (hidden) argument, which
    slows down function linkage. When virtual functions
    are involved, there is an additional slowdown.

    There is always room for a lower-level language.
    In the past couple of years much of my programming
    has been of necessity in assembly language!
    Douglas A. Gwyn, Apr 26, 2004
  16. Julie

    Julie Guest

    Sorry, but you are comparing two completely different things between the

    What is being talked about is if you take a C source file and create an
    executable, then take that same source file and compile it as C++, you will end
    up w/ (virtually) identical executables.

    C++ specific features can't be compared w/ C, simply because they do not exist
    in C!
    Julie, Apr 27, 2004
  17. Well one possible difference is type_info structures for every user defined type
    which can increase executable size if not optimized--which is not always

    Paul Mensonides
    Paul Mensonides, Apr 27, 2004
  18. Julie

    Leor Zolman Guest

    Okay, let's call that a possible one-time hit at start up, but
    generally speaking you're going to pay the same start-up costs for
    run-time initialization whether they end up being C++-style or
    You mean passing the "this" pointer? But that's just a matter of
    semantics; if you need such a "parameter" in C, it goes into the
    argument/parameter lists, and if you don't, neither do you need it in
    C++ (you just use non-member functions)

    And if you need a similar dispatch mechanism in a C program, it may
    very well run even slower, but not likely any faster. Again, in C++
    you don't pay for what you do not use or need. If you /need/ virtual
    functions, you need that functionality. If not, you don't, and neither
    do you pay for it.
    There may be reasons to code something in assembly, but I still find
    it difficult to believe that there would need to be room for /C/ in
    any self-respecting C++ environment. And moving code from C to C++
    should never incur any palpable performance penalty.
    Leor Zolman, Apr 27, 2004
  19. (Since the languages do not have a subset/
    superset relationship, in general compiling a
    C source program with a C++ compiler is not safe.)

    There is more overhead (both space and time)
    even for a C-looking program compiled with C++.

    However, the question was about developing a
    specific application using various PLs. If you
    choose C++, then presumably you will make
    essential use of features specific to that
    language. Objects, for example.
    Douglas A. Gwyn, Apr 27, 2004
  20. The question was about the performance to be
    expected when a single language is used, not
    about combining pieces done in several languages.
    I gave an accurate answer to the question.
    Douglas A. Gwyn, Apr 27, 2004
    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.