Cracking DES with C++ is faster than Java?

[Julie]

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

 

[David Rasmussen]

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

 

[Douglas A. Gwyn]

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?

 

[Liz]

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

or as they say in canada
yaaaaaaaaaaaaaaaaaaaaaaaaaaaa

 

[Claudio Puviani]

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

 

[Jan Panteltje]

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.

 

[Jon Bell]

or as they say in canada
yaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Eh?

 

[Leor Zolman]

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

 

[Tom St Denis]

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

 

[Paul Schlyter]

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

--

 

[Thomas Pornin]

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

 

[Julie]

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

Yep, different Julie.

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

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.

 

[Michael Scovetta]

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

 

[Douglas A. Gwyn]

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!

 

[Julie]

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!

 

[Paul Mensonides]

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

 

[Leor Zolman]

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

 

[Douglas A. Gwyn]

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]

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.