Cracking DES with C++ is faster than Java?

[Dez Akin]

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.

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.

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!

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)

 

[David Rasmussen]

(Since the languages do not have a subset/
superset relationship, in general compiling a
C source program with a C++ compiler is not safe.)

Nonsense...

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

More nonsense...

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.

And even more.

/David

 

[Douglas A. Gwyn]

For perf?

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]

Nonsense...

Apparently he thinks he knows more than he
actually does.

 

[tom_usenet]

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.

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

 

[Grumble]

Nonsense...

Incompatibilities Between ISO C and ISO C++
http://david.tribble.com/text/cdiffs.htm

 

[Julie]

(Since the languages do not have a subset/
superset relationship,

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

in general compiling a
C source program with a C++ compiler is not safe.)

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.

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

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.

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.

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.

 

[Mok-Kong Shen]

Nonsense...

[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

 

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

Just as slow as if a C program had registered an equal amount of startup
routines.

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

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.

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

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.

 

[Mok-Kong Shen]

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

[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

 

[Niklas Borson]

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.

type_info structures are only created for "polymorphic" types, i.e.,
types with virtual functions.

 

[Paul Schlyter]

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

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++ */

--

 

[Gregory G Rose]

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.

No, he means that C++ is not a genuine superset of
C. One must get precedence right.

Greg.

 

[Mok-Kong Shen]

No, he means that C++ is not a genuine superset of
C. One must get precedence right.

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

 

[Jerry Coffin]

(e-mail address removed) (Dez Akin) wrote in message
[ ... ]

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)

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.

 

[Julie]

Dez Akin wrote:
[snip]

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)

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.

 

[Tim Smith]

Incompatibilities Between ISO C and ISO C++
http://david.tribble.com/text/cdiffs.htm

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.

 

[Paul Schlyter]

(e-mail address removed) (Dez Akin) wrote in message
[ ... ]

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)

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!

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.

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.

--

 

[Paul Schlyter]

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.

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

--

 

[Phil Carmody]

??? How have you determined that? Do you have any substantive references?

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++?

not, name something that exists in C but not C++ (excluding new C features
introduced since the last C++ standard).

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