Cracking DES with C++ is faster than Java?

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

  1. Julie

    Julie Guest

    Hi,

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

    J
     
    Julie, Apr 25, 2004
    #1
    1. Advertising

  2. Julie wrote:
    > Hi,
    >
    > I am going to write a program cracking DES.
    > One says that C++ (actually C) is faster than Java.
    > Is this true?


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

    /David
     
    David Rasmussen, Apr 25, 2004
    #2
    1. Advertising

  3. Julie wrote:
    > One says that C++ (actually C) is faster than Java.


    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
    compiler.

    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
    #3
  4. Julie

    Liz Guest

    "David Rasmussen" <> wrote in message
    news:c6h4hm$i7j$-c.dk...
    > Julie wrote:
    > > Hi,
    > >
    > > I am going to write a program cracking DES.
    > > One says that C++ (actually C) is faster than Java.
    > > Is this true?

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


    or as they say in canada
    yaaaaaaaaaaaaaaaaaaaaaaaaaaaa

    >
    > /David
     
    Liz, Apr 25, 2004
    #4
  5. "Julie" <> wrote
    > Hi,
    >
    > I am going to write a program cracking DES.
    > One says that C++ (actually C) is faster than Java.
    > Is this true?


    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
    #5
  6. On a sunny day (25 Apr 2004 12:37:43 -0700) it happened
    (Julie) wrote in <>:

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

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

    Jon Bell Guest

    In article <OXUic.20330$0u6.3390267@attbi_s03>, Liz <> wrote:
    >
    >"David Rasmussen" <> wrote in message
    >news:c6h4hm$i7j$-c.dk...
    >>
    >> and in general: yes.

    >
    >or as they say in canada
    >yaaaaaaaaaaaaaaaaaaaaaaaaaaaa


    Eh? :)

    --
    Jon Bell <> Presbyterian College
    Dept. of Physics and Computer Science Clinton, South Carolina USA
     
    Jon Bell, Apr 25, 2004
    #7
  8. Julie

    Leor Zolman Guest

    On Sun, 25 Apr 2004 15:52:18 -0400, "Douglas A. Gwyn" <>
    wrote:

    >Julie wrote:
    >> One says that C++ (actually C) is faster than Java.

    >
    >That depends on several factors,
    >but in general, programs coded in C will
    >be slightly faster than if C++ had been used


    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


    >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
    >compiler.
    >
    >Why bother to write a DES cracker when you
    >can obtain one that has already had a lot of
    >development work put into it?


    --
    Leor Zolman --- BD Software --- www.bdsoft.com
    On-Site Training in C/C++, Java, Perl and Unix
    C++ users: download BD Software's free STL Error Message Decryptor at:
    www.bdsoft.com/tools/stlfilt.html
     
    Leor Zolman, Apr 26, 2004
    #8
  9. Julie

    Tom St Denis Guest

    Julie wrote:
    > Hi,
    >
    > I am going to write a program cracking DES.
    > One says that C++ (actually C) is faster than Java.
    > Is this true?
    > Thanks.


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

    Tom
     
    Tom St Denis, Apr 26, 2004
    #9
  10. In article <>,
    Douglas A. Gwyn <> wrote:

    > Julie wrote:
    >
    >> One says that C++ (actually C) is faster than Java.

    >
    > 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 compiler.


    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.

    > Why bother to write a DES cracker when you can obtain one that
    > has already had a lot of development work put into it?


    ....such as a DES hardware chip...

    --
    ----------------------------------------------------------------
    Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
    e-mail: pausch at stockholm dot bostream dot se
    WWW: http://www.stjarnhimlen.se/
    http://home.tiscali.se/pausch/
     
    Paul Schlyter, Apr 26, 2004
    #10
  11. According to Julie <>:
    > I am going to write a program cracking DES.
    > One says that C++ (actually C) is faster than Java.
    > Is this true?


    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
    #11
  12. Julie

    Julie Guest

    Claudio Puviani wrote:
    >
    > "Julie" <> wrote
    > > Hi,
    > >
    > > I am going to write a program cracking DES.
    > > One says that C++ (actually C) is faster than Java.
    > > Is this true?

    >
    > At first I thought you were our resident Julie, but I see that you aren't.


    Yep, different Julie.
     
    Julie, Apr 26, 2004
    #12
  13. Thomas Pornin wrote:
    > According to Julie <>:
    >
    >>I am going to write a program cracking DES.
    >>One says that C++ (actually C) is faster than Java.
    >>Is this true?

    >
    >
    > 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).


    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.

    > 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.


    This is true, although modern JVMs can eliminate bounds checks in many
    cases.

    >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.


    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.
    --
    Daniel Sjöblom
    Remove _NOSPAM to reply by mail
     
    =?ISO-8859-1?Q?Daniel_Sj=F6blom?=, Apr 26, 2004
    #13
  14. Jan Panteltje <> wrote in message news:<c6hbu9$156o$>...
    > On a sunny day (25 Apr 2004 12:37:43 -0700) it happened
    > (Julie) wrote in <>:
    >
    > >Hi,
    > >
    > >I am going to write a program cracking DES.
    > >One says that C++ (actually C) is faster than Java.
    > >Is this true?
    > >Thanks.
    > >
    > >J

    > There are special techniques for DES, most programs
    > are in C and assembler.
    > Jave is snail like.


    This clearly shows poor understanding of Java, especially recently.
    Read up on the subject first:
    http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

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

    -Mike Scovetta
     
    Michael Scovetta, Apr 26, 2004
    #14
  15. Leor Zolman wrote:
    > 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.


    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
    #15
  16. Julie

    Julie Guest

    "Douglas A. Gwyn" wrote:
    >
    > Leor Zolman wrote:
    > > 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.

    >
    > 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!


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

    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
    #16
  17. Julie wrote:
    > "Douglas A. Gwyn" wrote:
    >>
    >> Leor Zolman wrote:
    >>> 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.

    >>
    >> 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!

    >
    > Sorry, but you are comparing two completely different things between
    > the languages.
    >
    > 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!


    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
    possible.

    Regards,
    Paul Mensonides
     
    Paul Mensonides, Apr 27, 2004
    #17
  18. Julie

    Leor Zolman Guest

    "Douglas A. Gwyn" <> wrote in message news:<>...
    > Leor Zolman wrote:
    > > 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.

    >
    > 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.


    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
    C-style.

    > Functions
    > generally have an extra (hidden) argument, which
    > slows down function linkage.


    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)


    > When virtual functions
    > are involved, there is an additional slowdown.


    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 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!


    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
     
    Leor Zolman, Apr 27, 2004
    #18
  19. Julie wrote:
    > 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.


    (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
    #19
  20. Leor Zolman wrote:
    > 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.


    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
    #20
    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. Bart Torbert

    Cracking C structure

    Bart Torbert, Sep 8, 2004, in forum: C Programming
    Replies:
    2
    Views:
    574
    Ira Baxter
    Sep 10, 2004
  2. Carl Dau
    Replies:
    7
    Views:
    400
    John Brawley
    Jan 31, 2008
  3. Elf M. Sternberg

    Cracking prototype.js

    Elf M. Sternberg, Jun 17, 2005, in forum: Javascript
    Replies:
    7
    Views:
    136
    Thomas 'PointedEars' Lahn
    Jul 7, 2005
  4. TheRandomPast

    Cracking hashes with Python

    TheRandomPast, Nov 25, 2013, in forum: Python
    Replies:
    22
    Views:
    362
    Denis McMahon
    Nov 27, 2013
  5. Marc
    Replies:
    0
    Views:
    73
Loading...

Share This Page