Cracking DES with C++ is faster than Java?

D

Douglas A. Gwyn

Julie said:
??? 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).

First off, you are trying to redefine the subsetting issue.
Something that exists in both languages but has different
meaning also demonstrates the lack of subsetting.
Secondly, sizeof'a'>1 "exists" in nearly all conforming
implementations of C but not in C++. Or maybe you would
prefer extern void f();f(42); which "exists" in C but not
in C++. There are numerous other examples.
Again, evidence of such a statement would help.

I already explained some ways in which that happens.
According to what I gather from your arguments, the performance would always be
ordered as, and appreciably different: ASM < C < C++ < Java.

I didn't say "always", but *on average* that is true for
the speed of comparable applications implemented in the
various languages by skilled programmers. There are
other aspects to programming besides execution speed,
however, and anybody who thinks that just one of those
languages should be used for every application is naive.
 
D

Douglas A. Gwyn

Phil said:
... I frequently migrate
my own old C code to C++ with no changes at all.

It is *possible* to write code that will compile
correctly and have the same semantics in both
languages. Presumably you have learned how to
code within this common subset of the two.
However, there is a *lot* of existing C code
that will not compile using a C++ compiler, and
more dangerously there is some existing C code
that will compile using C++ but will produce
different results when executed. People who
are completely unaware of the issues are of
course most likely to fall into that trap.
 
D

Douglas A. Gwyn

Jerry said:
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!

Actually optimizer technology really is substantially better
these days. Any such comparison needs to keep in mind that
Fortran has properties that allow tighter optimization than
is feasible for C on many platforms; for example, C pointer
parameters can alias whereas Fortran array parameters cannot
(acording to the language spec), which permits vectorization
that is not safe for C code. (We have addressed that in C99
by introducing "restrict" qualification.)
Also, hardware has changed in many ways. RISC architectures
are usually harder to program optimally without machine
assistance in allocating registers, for example.
 
E

Erwann ABALEA

??? 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 C, it's not necessary to cast a (void*) into (any_data*). In C, you can
name a variable 'new', 'class', or any other C++-reserved word.
 
E

Erwann ABALEA

Sorry, what is 'precedence' here? If A is subset of B,
then B is superset of A, and vice versa, isn't it?

Just like XML is a superset of HTML, and SGML is a superset of XML, but in
fact, XML is a subset of SGML, since SGML was 'invented' before XML.

Here, the C++ language has been 'invented' after C.
 
M

Mark Wooding

Julie said:
??? How have you determined that?

I can't speak for Doug, but presumably by reading the language standards.
Do you have any substantive references?

The language standards. You might want to read them before being
further ill-informed pronouncements.
If not, name something that exists in C but not C++ (excluding new C
features introduced since the last C++ standard).

A number of old C features which C++ dropped, such as K&R-style function
declarations. Also some more significant differences:

* C allows implicit cast from `void *' to other pointer types (e.g.,
result of `malloc'); C++ requires an explicit cast for some stupid
reason. This is probably the most significant difference, and it's
why most of my C programs aren't C++.

* C's character constants have type `int'; C++'s have type `char'.

* C's structure tags have a separate namespace; C++ puts them in the
main identifier namespace.

* C++ reserves a number of new keywords, most heinously `import', but
also `template', `class', etc.; these are normal identifiers in C.
Also, `wchar_t' is a built-in type in C++, but not in C.

-- [mdw]
 
A

Andrew Swallow

[snip]
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!
Computers can access fixed locations in memory
faster that relative locations. Recursion requires
local variables to be stored on the stack, i.e. to
be accessed using relative locations. Data structures
on the heap are even more complicated to access.

Dynamic storage is very bad, you can see the computer
stop for several thousand million clock cycles whilst the
garbage collector tries to find some more memory.

Andrew Swallow
 
E

Ernst Lippe

[snip]
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!
Computers can access fixed locations in memory
faster that relative locations.

I assume that with "fixed location" you mean addresses that are known at link
time, when the executable is produced.

I don't think that your statement is true in general, it all depends on the
circumstances. One of the disadvantages of using absolute memory addresses is
that the size of instruction must always be larger than the number of bits in
the address space. Many CPU's have built-in support for addressing
small-sized offsets to a stack-pointer and in general the size of these
instructions is smaller than the size of the instructions that use absolute
addresses. When the instruction is longer, either it will take more time to
fetch it from memory, or it will decrease the effective number of instructions
that can be held in the instruction cache.

Even on CPU architectures where both types of instructions have the same size,
there may not be any difference in execution speed. For most modern CPU's
memory access is the main bottle-neck. Simple arithmetic operations to
registers, such as adding a small offset, are so fast relative to the time it
takes to fetch/store the contents of some address in memory, that there is no
difference. Also, virtually all modern computers have memory caches, and the
performance depends heavily on whether the contents are available in the
cache. But for the memory cache there is no difference between a fixed address
and an address that has been computed dynamically, the only thing that is
important if that address has been used recently.

Recursion requires
local variables to be stored on the stack, i.e. to
be accessed using relative locations.

The overhead of allowing recursion (if any) is minimal on modern
CPU's. Anyhow, all modern programming languages (even Fortran) allow it, so
apparently language designers believe that the benefits are sufficiently
important.
Data structures
on the heap are even more complicated to access.

In most cases this statement is false, in most computers data structures on
the heap are simply identified by their address which is not more complicated
than using absolute addresses or locations on the stack. I have the feeling
that you believe that heaps only occur in languages, that have a relocating
garbage collector (see below), but it is standard usage to refer to the memory
area from which dynamically sized memory is allocated as "the heap". For
example, the malloc in C uses a heap.

Dynamic storage is very bad, you can see the computer
stop for several thousand million clock cycles whilst the
garbage collector tries to find some more memory.

What do you mean by dynamic storage? The standard meaning of the term is
storage where the actual memory size of an object is not known at compile
time. This is pretty common in most computer languages, and in most cases this
is not at all a performance problem.

You are probably referring to relocating garbage collectors that can change
the actual memory addresses where objects are located. Traditionally, these
used to have the problems that you describe, but there have been important
improvements (generation scavenging, multi-threading) and most of these
problems have disappeared.

Anyhow, I don't think that your argument that fixed addresses are
faster is very relevant. Virtually all computer programs are written
with procedures that can accept varying arguments (that was already
the case for these old Fortran programs). So there are hardly any instances
where computers actually use fixed addresses, because most code
relies on variables that have been passed as arguments instead of
global variables.

Ernst Lippe
 
J

Julie

Mark said:
I can't speak for Doug, but presumably by reading the language standards.


The language standards. You might want to read them before being
further ill-informed pronouncements.

I'm asking the PP to post substantive references to HIS COMMENTS. It isn't my
responsibility to justify others comments, it is theirs. My responsibility is
to justify my comments.

Do you have any references to the standards that explicitly state that C++ is
*NOT* essentially a superset of C?
If not, name something that exists in C but not C++ (excluding new C
features introduced since the last C++ standard).

A number of old C features which C++ dropped, such as K&R-style function
declarations. Also some more significant differences:

* C allows implicit cast from `void *' to other pointer types (e.g.,
result of `malloc'); C++ requires an explicit cast for some stupid
reason. This is probably the most significant difference, and it's
why most of my C programs aren't C++.

* C's character constants have type `int'; C++'s have type `char'.

* C's structure tags have a separate namespace; C++ puts them in the
main identifier namespace.

* C++ reserves a number of new keywords, most heinously `import', but
also `template', `class', etc.; these are normal identifiers in C.
Also, `wchar_t' is a built-in type in C++, but not in C.

-- [mdw]

It seems that most of the respondents have soon forgotten what we are talking
about. Doug said that there isn't a sub/super set relationship between C and
C++, and I questioned him on that.

Take this for example:
* C++ reserves a number of new keywords, most heinously `import', but
also `template', `class', etc.; these are normal identifiers in C.
Also, `wchar_t' is a built-in type in C++, but not in C.

*EXACTLY* -- C++ contains C, and then extends it -- hence, a SUPERSET. Your
examples only justify that C++ is a superset of C.

Excepting the few syntactic differences here and there, mostly for type safety,
C++ is definitely a superset of C, and that is by design.

Read section B2 of the Appendix of TC++PL:

http://www.filibeto.org/sun/lib/development/c++_iiird/appB.pdf
 
M

Mok-Kong Shen

Erwann said:
Just like XML is a superset of HTML, and SGML is a superset of XML, but in
fact, XML is a subset of SGML, since SGML was 'invented' before XML.

Here, the C++ language has been 'invented' after C.

But what has 'precedence' to do with correctness of one
statement with respect to a logically 'equivalent' one?
Should one also consider that only one of the following
sentences is 'allowed' in view of 'precedence'?

Elisabeth is the daughter of Mary.

Mary is the mother of Elisabeth.

Note that there is well one 'precedence' relation between
these two persons.

M. K. Shen
 
T

Tom St Denis

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


Compare that with what BS says in TC++PL:

http://www.filibeto.org/sun/lib/development/c++_iiird/appB.pdf

Um I just read that PDF. The PDF seems to agree that there are valid
[albeit of questionable usage] C statements that are not valid in C++
[and vice versa].

I don't see how that contradicts what Douglas said.

Tom
 
A

Andrew Swallow

Ernst Lippe said:
[snip]
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!
Computers can access fixed locations in memory
faster that relative locations.

I assume that with "fixed location" you mean addresses that are known at link
time, when the executable is produced.

I don't think that your statement is true in general, it all depends on the
circumstances. One of the disadvantages of using absolute memory addresses is
that the size of instruction must always be larger than the number of bits in
the address space. Many CPU's have built-in support for addressing
small-sized offsets to a stack-pointer and in general the size of these
instructions is smaller than the size of the instructions that use absolute
addresses. When the instruction is longer, either it will take more time to
fetch it from memory, or it will decrease the effective number of instructions
that can be held in the instruction cache.

Do not forget the time it required to load the pointers.
Even on CPU architectures where both types of instructions have the same size,
there may not be any difference in execution speed. For most modern CPU's
memory access is the main bottle-neck. Simple arithmetic operations to
registers, such as adding a small offset, are so fast relative to the time it
takes to fetch/store the contents of some address in memory, that there is no
difference. Also, virtually all modern computers have memory caches, and the
performance depends heavily on whether the contents are available in the
cache. But for the memory cache there is no difference between a fixed address
and an address that has been computed dynamically, the only thing that is
important if that address has been used recently.



The overhead of allowing recursion (if any) is minimal on modern
CPU's. Anyhow, all modern programming languages (even Fortran) allow it, so
apparently language designers believe that the benefits are sufficiently
important.

Fortran IV did not support recursion. It was even designed
so that its compilers did not need to use recursion. One of
the reason that only simple calculations were permitted in
array subscripts.
In most cases this statement is false, in most computers data structures on
the heap are simply identified by their address which is not more complicated
than using absolute addresses or locations on the stack. I have the feeling
that you believe that heaps only occur in languages, that have a relocating
garbage collector (see below), but it is standard usage to refer to the memory
area from which dynamically sized memory is allocated as "the heap". For
example, the malloc in C uses a heap.

As a user of programs written in C I have noticed. It does
not matter if the runtime garbage collector is in the program
or the operating system, both its time delays and probability
of failure are still there. A construct that is definitely not
suitable for use in realtime or safety critical programs.
What do you mean by dynamic storage? The standard meaning of the term is
storage where the actual memory size of an object is not known at compile
time. This is pretty common in most computer languages, and in most cases this
is not at all a performance problem.

You are probably referring to relocating garbage collectors that can change
the actual memory addresses where objects are located. Traditionally, these
used to have the problems that you describe, but there have been important
improvements (generation scavenging, multi-threading) and most of these
problems have disappeared.

Only yesterday did I saw my PC crash because of a stack
overflow.
Anyhow, I don't think that your argument that fixed addresses are
faster is very relevant. Virtually all computer programs are written
with procedures that can accept varying arguments (that was already
the case for these old Fortran programs). So there are hardly any instances
where computers actually use fixed addresses, because most code
relies on variables that have been passed as arguments instead of
global variables.

One of the speed optimisations Fortran programmers made
was to pass global variables around in the common blocks
rather that as parameters.
Ernst Lippe

Andrew Swallow
 
J

Julie

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


Compare that with what BS says in TC++PL:

http://www.filibeto.org/sun/lib/development/c++_iiird/appB.pdf

Um I just read that PDF. The PDF seems to agree that there are valid
[albeit of questionable usage] C statements that are not valid in C++
[and vice versa].

I don't see how that contradicts what Douglas said.

Step by step, then:

Douglas A. Gwyn wrote:

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

TC++PL, Bjarne Stroustrup, Appendix
B.2 C/C++ Compatibility
With minor exceptions, C++ is a superset of C. Most
differences stem from C++'s greater emphasis on type
checking. Well-written C programs tend to be C++
programs as well. All differences between C++ and C
can be diagnosed by a compiler.

Even simpler yet:

Doug: "do not have a subset/superset relationship"

Bjarne: "C++ is a superset of C"

Doug: "in general compiling a C source program with a
C++ compiler is not safe"

Bjarne: "Well-written C programs tend to be C++
programs as well"

Simplest:

They contradict.
 
T

Tom St Denis

Julie said:
Even simpler yet:

Doug: "do not have a subset/superset relationship"

They don't.
Bjarne: "C++ is a superset of C"

"With Minor exceptions pi is equal to 3".
Doug: "in general compiling a C source program with a
C++ compiler is not safe"

Bjarne: "Well-written C programs tend to be C++
programs as well"

From a cryptographers point of view.
Simplest:

They contradict.

No. You're misreporting Bjarne.

Tom
 
C

Claudio Puviani

Julie said:
Do you have any references to the standards that
explicitly state that C++ is *NOT* essentially a
superset of C?

All of Appendix B of ISO/IEC 14882:2003 (the standard) is dedicated to
differences between C and C++. It cites many differences. Here's just one among
many:

/* valid in C, but NOT in C++ */
int i;
int i; // second definition violates C++'s ODR, but is OK in C

The appendix cites many more, but it only takes one to cause C++ to not be a
superset of C.
It seems that most of the respondents have soon
forgotten what we are talking about. Doug said
that there isn't a sub/super set relationship
between C and C++, and I questioned him on that.

It's not enough for C++ to be compatible with MOST C code to name it a superset.
It has to be compatible with ALL valid C code. "All women" is not a superset of
"three women and one man".
*EXACTLY* -- C++ contains C, and then extends it --
hence, a SUPERSET.

WRONG! Read Appendix B and Chapter 1 of the standard. It's clearly stated that
C++ is BASED ON C, not that it contains C as a subset.
Excepting the few syntactic differences here and
there, mostly for type safety, C++ is definitely
a superset of C, and that is by design.

You're either being argumentative for the sake of arguing or you don't understand
the meaning of "superset". There is no "mostly" in set theory. Either it's a
superset, or it's not. There is a very large intersection between C and C++, but
there is NO containment relationship. NONE. NADA. You don't get to have a
"personal opinion" or your own "perspective" on mathematical axioms.

Claudio Puviani
 
J

Jerry Coffin

[ ... ]

IMO, basing any decision about DES on this paper is a mistake.

First of all, the conclusions that it draws are mostly based on an 80%
confidence level. In most cases, a 95% confidence level is the
minimum that's considered meaningful, and in more demanding
situations, a 99% confidence level may be required. To look at things
from the opposite direction, there's roughly a 20% chance that any
conclusion you see in this paper is based on pure chance.

Second, some of the data was collected in ways that render it highly
suspect to start with (a fact acknoledged, but IMO insufficiently
emphasized in the paper).

Finally, and probably most importantly, this examines solutions to
only one problem -- and a problem with little relationship to DES at
that. As such, even if the data had been collected more carefully,
and enough more data had been collected to support conclusions, those
conclusions would still mean little or nothing about the task at hand
anyway.

Now, don't get me wrong: I'm not, at any point, saying that its
conclusions are necessarily wrong -- only that we have insufficient
evidence to believe they're right, and even if they were it would be
inapplicable to the question at hand.
 
J

Julie

Claudio said:
All of Appendix B of ISO/IEC 14882:2003 (the standard) is dedicated to
differences between C and C++. It cites many differences. Here's just one among
many:

/* valid in C, but NOT in C++ */
int i;
int i; // second definition violates C++'s ODR, but is OK in C

The appendix cites many more, but it only takes one to cause C++ to not be a
superset of C.

True in absolute terms. I was talking in figurative (looser) terms.
It's not enough for C++ to be compatible with MOST C code to name it a superset.
It has to be compatible with ALL valid C code. "All women" is not a superset of
"three women and one man".


WRONG! Read Appendix B and Chapter 1 of the standard. It's clearly stated that
C++ is BASED ON C, not that it contains C as a subset.

Fine, I shall read it (later).
You're either being argumentative for the sake of arguing or you don't understand
the meaning of "superset". There is no "mostly" in set theory. Either it's a
superset, or it's not. There is a very large intersection between C and C++, but
there is NO containment relationship. NONE. NADA. You don't get to have a
"personal opinion" or your own "perspective" on mathematical axioms.

I understand set theory just fine. I wasn't talking in explicit mathematical
terms, but approximate figurative terms. Further, I was essentially
regurgitating Bjarne in TC++PL, Appendix, B2:

"With minor exceptions, C++ is a superset of C."

Honestly, I'm not interested in arguing about the minutiae of the various
comments relating to what is and what isn't a superset/subset. Conceptually,
C++ is a superset of C, explicitly (in pure mathematic set theory terms), it is
not. If you or anyone disagrees, feel free to take it up w/ Bjarne.
 
J

Julie

Tom said:
They don't.


"With Minor exceptions pi is equal to 3".


From a cryptographers point of view.


No. You're misreporting Bjarne.

Tom

How can I be 'misreporting' Bjarne when I provided the *explicit* context in
which he made the statements?

If you feel further disagreement on the topic, feel free to discuss it w/
Bjarne, as I have no interest in battling over the explicit minutiae of pure
set theory. FWIW, my comments are based on the *conceptual* idea of
superset/subset.
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top