Cracking DES with C++ is faster than Java?

[Paul Schmidt]

You can do the same with subroutines.....

In many cases you can, however subroutines don't offer a way to protect
data from the general program. I have seen a lot of program bugs that
are caused by this lack of protection. There are various attempts at
curing it, Hungarian notationn was one of them, in a multi-developer
system you could have a central repository of variable names so that
variable names don't overlap, or include the devlopers initials in the
variable names, but don't forget the computer is better at boring
repetativc tasks, then people are. Objects make this process much
easier, in that the object is responsible for it's own data.

....or some new programming paradigm will become popular, making
objects obsolete. You never know what the future will bring....

That is also possible, that in 5 to 10 years time, the object will be
replaced with something else. Probably most likely is that you will use
diagramming tools, to diagram what you want the objects to do, and
then the computer will compile the drawing into machine language. The
software designer would then do the diagrams, and rather then email or
courier them to India or China for coding, will simply compile the
diagrams into code.

Paul

 

[Mok-Kong Shen]

No.

Fortran's subroutine parameters are name-parameters (not
value parameters), i.e. just like the 'int *a' of your C
example. So, if two formal paremeters of that type in a
Fortran subroutine are associated with one and the same
actual parameter, then certain code sequences could cause
the same problem, if the equivalent C function causes problem.

M. K. Shen

 

[Chris McDonald]

Fortran's subroutine parameters are name-parameters (not
value parameters), i.e. just like the 'int *a' of your C
example. So, if two formal paremeters of that type in a
Fortran subroutine are associated with one and the same
actual parameter, then certain code sequences could cause
the same problem, if the equivalent C function causes problem.

I'm sure that you mean 'pass-by-reference', as name-parameters
(pass-by-name) are completely different again (c.f. Algol).

_______________________________________________________________________________
Dr Chris McDonald EMAIL: (e-mail address removed)
School of Computer Science & Software Engineering
The University of Western Australia WWW: http://www.csse.uwa.edu.au/~chris
Crawley, Western Australia, 6009 PH: +61 8 6488 2533, FAX: +61 8 6488 1089

 

[Paul Schlyter]

C doesn't have multidimensional arrays, but it does support
arrays of arrays

C's arrays of arrays are useless here, because you must decide the
number of elements in all dimensions except the last one. In C
you must use pointers to pointers instead, forcing the storage
of a number of pointers, which must be accessed at runtime. THis
slows down the execution of the code.

and other complex structures.

True, C is more versatile. Just a pity they left out that case
of multi-dimensional arrays. C borrowed so many other good
properties from Fortran (efficient code, separate compilation,
static variables, a good set of math functions, floating-point
numbers in single AND double precision) so it could have borrowed
that feature as well.

In essence C was a very good mixture from the beast features of several
languages existing prior to C. I've already listed what it borrowed
from Fortran; from Pascal it borrowed automatic variables and dynamic
allocation of memory, recursion, and structured programming concepts.
And from assembler it borrowed low-level support such as pointers
and bit manipulation. However C didn't borrow object orientation
from Simula...

Using these tools you get a *choice* of how to represent matrices,

In C there's not much of a choice here -- if you want to represent
an arbitrary sized matrix in a way convenient to use, you're
pretty much stuck with the pointer-to-pointer representation.

unlike the native Fortran facility where you're stuck with
whatever the compiler has wired in.

True, C is more versatile, I never argued against that.

In C++ one would normally use a matrix class in order to be
able to apply the standard operators, e.g. + and *.

....and that matrix class would have to be implemented using the same
basic language features which are available in C -- in that respect
C++ does not offer any advantage over C.

--

 

[Paul Schlyter]

In many cases you can, however subroutines don't offer a way to protect
data from the general program. I have seen a lot of program bugs that
are caused by this lack of protection. There are various attempts at
curing it, Hungarian notationn was one of them, in a multi-developer
system you could have a central repository of variable names so that
variable names don't overlap, or include the devlopers initials in the
variable names, but don't forget the computer is better at boring
repetativc tasks, then people are. Objects make this process much
easier, in that the object is responsible for it's own data.

True of course, however there WAS software reuse also before object
orientation. And that was my point.

That is also possible, that in 5 to 10 years time, the object will be
replaced with something else. Probably most likely is that you will use
diagramming tools, to diagram what you want the objects to do, and
then the computer will compile the drawing into machine language. The
software designer would then do the diagrams, and rather then email or
courier them to India or China for coding, will simply compile the
diagrams into code.

Automatic code generators have been another "dream of the future" for
decades now. I particularly remember one program, written for the
gool ol' Apple II 8-bit microcomputer in the early 1980's. That
program was called "The Last One", suggesting it was the last program
which ever had to be written. What did it do? It asked the user for
a number of parameters for some administrative program, and then it
did output Applesoft Basic code for that program...... Needless to
say, it didn't at all end all futher software development....

The interesting thing about the future is that it cannot be
predicted. So whenever one envisions computer software and hardware
10-20 years into the future, think back some decades instead and
think about what people back then imagined about our times:

Around 1950, IBM estimated the world market of computers to some 5
machines.

Around 1970, DEC thought there was absolutely no need for personal
computers.

Around 1980, Bill Gates made his now famous statement that 640 kBytes
was more memory than anyone would ever need.

Around 1983-1985, the programming language Ada was envisioned to,
within 5-10 years, take over virtually all software development. At
the same time, there were very high hopes for Japan's "5'th
generation" computers, based on the language Prolog.

Around 1990, Bill Gates thought that OS/2 would run on most personal
computers in the late 1990's.

And so on and so on ......

--

 

[Paul Schlyter]

Fortran's subroutine parameters are name-parameters (not
value parameters),

No - they are reference parameters. Algol had value parameters, but
they were so complex to implement and not of that much use so they
were abandoned in later programming languages.

i.e. just like the 'int *a' of your C example.

That's an implementation of a reference parameter. If you wanted to
try passing the equivalent of a name parameter in C, the parameter
declaration would look something like

struct name_parameter_a *a

where the struct could be defined as something like:

struct name_parameter_a
{
int (*reference_a)();
void (*assign_to_a)(int value);
};

Name parameters were usually implemented as "thunks", i.e. pointers
to pieces of code which computed the parameter, i.e. implemented the
semantics of the name parameter.

So, if two formal paremeters of that type in a
Fortran subroutine are associated with one and the same
actual parameter, then certain code sequences could cause
the same problem, if the equivalent C function causes problem.

The well-known aliasing problem....

--

 

[Mok-Kong Shen]

I'm sure that you mean 'pass-by-reference', as name-parameters
(pass-by-name) are completely different again (c.f. Algol).

You are certainly right. Thanks for the correction.

M. K. Shen

 

[Mok-Kong Shen]

No - they are reference parameters. Algol had value parameters, but
they were so complex to implement and not of that much use so they
were abandoned in later programming languages.




That's an implementation of a reference parameter. If you wanted to
try passing the equivalent of a name parameter in C, the parameter
declaration would look something like

struct name_parameter_a *a

where the struct could be defined as something like:

struct name_parameter_a
{
int (*reference_a)();
void (*assign_to_a)(int value);
};

Name parameters were usually implemented as "thunks", i.e. pointers
to pieces of code which computed the parameter, i.e. implemented the
semantics of the name parameter.

Chris McDonald had immediately pointed out my using the
wrong term.

The well-known aliasing problem....

So in Fortran there do exist aliasing problems just like
in C and C++, contrary to what you previous claimed. BTW,
in the newer standard versions of Fortran (starting with
Fortran95), one could also have value-parameters.

M. K. Shen

 

[Douglas A. Gwyn]

In C there's not much of a choice here -- if you want to represent
an arbitrary sized matrix in a way convenient to use, you're
pretty much stuck with the pointer-to-pointer representation.

Wrong. You could allocate a 1-dimensional array
of length M*N. Indexing would involve the same
kind of multiplication that most Fortrans have
to do. Presumably one would pretty up the code
by using macros, e.g.:
#define a(i,j) a[(i)+N*(j)] // N could
// be a parameter
As I said, with C one has a choice: row or column
vectors, or index arithmetic.

...and that matrix class would have to be implemented using the same
basic language features which are available in C -- in that respect
C++ does not offer any advantage over C.

a = b + c; e = f * g; // much better than in C

 

[Paul Schlyter]

The well-known aliasing problem....

So in Fortran there do exist aliasing problems just like
in C and C++, contrary to what you previous claimed. BTW,[/QUOTE]

The possibility of aliasing problems are hard to completely avoid
when calling a function with several reference parameters. And
you could also do "interesting" things with EQUIVALENCE, however
that would merely confuse a human reader of the code, the
compiler would be able to keep track of that.

At least the aliasing problems in Fortran are much less severe;
you cannot for instance have a dangling reference to a variable
which has gone out of scope. In C and C++ you can easily do that.

in the newer standard versions of Fortran (starting with
Fortran95), one could also have value-parameters.

True ... F95 is actually a language quite different from F77.

--

 

[Paul Schlyter]

In C there's not much of a choice here -- if you want to represent
an arbitrary sized matrix in a way convenient to use, you're
pretty much stuck with the pointer-to-pointer representation.

Wrong. You could allocate a 1-dimensional array
of length M*N. Indexing would involve the same
kind of multiplication that most Fortrans have
to do. Presumably one would pretty up the code
by using macros, e.g.:
#define a(i,j) a[(i)+N*(j)] // N could
// be a parameter
As I said, with C one has a choice: row or column
vectors, or index arithmetic.

Yes you can do that --- but that won't take you past this problem:
how will you declare that matrix inverting function in order to make
it convenient for the code calling it? Consider this:

double A[25][25], B[100][100];

....... code to fill the matrices with suitable values .......

matinv(A,25);
matinv(B,100);

How would you declare matinv() in order to be able to conveniently
call it with a matrix of any size? Without having to dabble with
typecasts or endure parameter type mismatch warnings from the
compiler (which will become errors if the code is to be compiled
as C++)? You cannot declare it as:

void matinv( double A[][], int Asize );

because that's illegal syntax. And you cannot declare it as:

void matinv( double **A, int Asize );

because that would most certainly crash the program when matinv()
would be called. You could declare it as:

void matinv( double A[], int Asize );

or as:

void matinv( double *A, int Asize );

and then dabble around with your macros, but that would require
the calls to be done as:

matinv((double *)A,25);
matinv((double *)B,100);

and that's ugly.

a = b + c; e = f * g; // much better than in C

I'm sorry but inverting a matrix cannot be done simply by matrix
addition and multiplication of whole matrices -- you'll have to
fiddle around with individual matrix elements.

Also: the notation is merely a syntactic convenience, it does not
produce any better code.

--

 

[Andrew Swallow]

[snip]

Around 1983-1985, the programming language Ada was envisioned to,
within 5-10 years, take over virtually all software development. At

Nightmare though. ADA is still being used in the latest military aircraft.

Andrew Swallow

 

[Lassi =?iso-8859-1?Q?Hippel=E4inen?=]

Paul Schlyter wrote:

Around 1950, IBM estimated the world market of computers to some 5
machines.

Around 1970, DEC thought there was absolutely no need for personal
computers.

That was Ken Olsen, not the whole DEC...

Around 1980, Bill Gates made his now famous statement that 640 kBytes
was more memory than anyone would ever need.

Even though I'd be among the first to spank the man if he came may way,
in this case I must defend him. He didn't say that 640k should be
enough, he said that the increase from 64k to 640k would last for four
to five years only.
http://www.urbanlegends.com/celebrities/bill.gates/gates_memory.html

Around 1983-1985, the programming language Ada was envisioned to,
within 5-10 years, take over virtually all software development. At
the same time, there were very high hopes for Japan's "5'th
generation" computers, based on the language Prolog.

Until they proved that Prolog isn't scalable...

Around 1990, Bill Gates thought that OS/2 would run on most personal
computers in the late 1990's.

Probably not. OS/2 was a pay job. Gates used the money to develop
Windows.

-- Lassi

 

[Douglas A. Gwyn]

void matinv( double *A, int Asize );
and then dabble around with your macros, but that would require
the calls to be done as:
matinv((double *)A,25);

No, no such cast is necessary.
You seem to be assuming (part of the time)
that an array of arrays is being used, not
a single array with index computation as I
specified originally.

I'm sorry but inverting a matrix cannot be done simply by matrix
addition and multiplication of whole matrices -- you'll have to
fiddle around with individual matrix elements.

You have to "fiddle with individual matrix
elements" to correctly implement multiplication
also. This is *not a problem* when using C++.
One would need to pick a notation for the
inverse; if you want something simpler than a
function call, perhaps the ~ unary operator
would be a good choice:
q = s * (r * ~s); // probably
// should adopt left-operating
// convention instead, to avoid
// having to use parentheses
Let's see you do that in Fortran!

Also: the notation is merely a syntactic convenience, it does not
produce any better code.

No, the optimum code for the operation is
the optimum code for the operation. Who
argued otherwise?

 

[Paul Schlyter]

Paul Schlyter wrote:


That was Ken Olsen, not the whole DEC...

It's rarely, if ever, each and every employer who disagrees with
such statements. Most employers probably don't have an opinion about
it even.

Even though I'd be among the first to spank the man if he came may way,
in this case I must defend him. He didn't say that 640k should be
enough, he said that the increase from 64k to 640k would last for four
to five years only.
http://www.urbanlegends.com/celebrities/bill.gates/gates_memory.html

OK, I stand corrected. However he made a few other goofs in that
statement - he claimed that:

- 16-bit computers has 640K address space

- Intel gave us 32-bit computers

Apparently, he's never worked with mainframes....

Until they proved that Prolog isn't scalable...


Probably not. OS/2 was a pay job. Gates used the money to develop
Windows.

I read that in the book "Inside OS/2" by Gordon Letwin, which was one
of the chief designers of OS/2. The foreword to that book was
written by Bill Gates (at least the book said so), and there he said
that he expected OS/2 to become the mainstrean OS among micros in the
years to come. But that was probab ly before the conflict between
Microsoft and IBM which stopped the cooperation between those two
companies.

--

 

[Paul Schlyter]

No, no such cast is necessary.
You seem to be assuming (part of the time) that an array of arrays
is being used, not a single array with index computation as I
specified originally.

Precisely! Arrays of arrays or pointers-to-pointers are the most
natural ways to reprecent matrices in C. To "roll them out" as a
single array is a kludge, which makes life harder for the application
programmer who is to use that matrix inversion routine. And it's one
reason to prefer Fortran over C for such an application.

You have to "fiddle with individual matrix elements" to correctly
implement multiplication also.

THose who design and build hardware need to worry about that, yes.

This is *not a problem* when using C++. One would need to pick a
notation for the inverse; if you want something simpler than a
function call, perhaps the ~ unary operator would be a good choice:

q = s * (r * ~s); // probably
// should adopt left-operating
// convention instead, to avoid
// having to use parentheses
Let's see you do that in Fortran!

In Fortran-90 and -95 that is quite straight-forward, since the
standard operators of that language can work on arrays and matrices
as well. It could look something like this:

q = s * (r * .INVERT. s)

or, if you prefer a function call:

q = s * (r * INVERT(s) )

Yep, in Fortran-90/95 you can define genuinely new operators and
not merely reuse the old operators for new data type. And a user
defined operator in Fortran-90/95 is a dot, followed by an
arbitrary alphabetic string, and terminated with a dot. This
follows the logic of the traditional operators .AND. .OR. .NOT.
but extends the syntax so that any name can be placed between
the dots: .ANY_OPERATOR_NAME_OF_MY_CHOICE.

In addition, for those running a vectorized computer, a Fortran-90/95
compiler will generate parallell code for computations involving a
whole matrix. Perhaps there are vectorized C or C++ compilers as
well, but due to the much more severe aliasing problems in C and C++,
producing good parallell code is much much harder in C/C++.

Perhaps now you can start to understand why people running heavy
number crunching Fortran programs aren't interested in switching to
C++ just because that language is a better choice in non-numerical
applications.

--

 

[Douglas A. Gwyn]

Precisely! Arrays of arrays or pointers-to-pointers are the most
natural ways to reprecent matrices in C. To "roll them out" as a
single array is a kludge, which makes life harder for the application
programmer who is to use that matrix inversion routine. And it's one
reason to prefer Fortran over C for such an application.

In C the element of array a index by i and j is expressed
as a(i,j) (using the approach I suggested, which mimics
Fortran's usual index arithmetic). In FORTRAN it would
be A(I,J). The matrix inversion in C would be mxinv(a,n)
and in FORTRAN it would be MXINV(A,N). How is this
appreciably harder in C than in FORTRAN?

THose who design and build hardware need to worry about that, yes.

Whoever implements (in the *one* place) a function has
to take care of the details. Any programmer worth his
salt has a support library already in place that
implements all the common data structures, include many
that have no built-in support in Fortran. Of course
the user normally doesn't have to know the details.

In addition, for those running a vectorized computer, a Fortran-90/95
compiler will generate parallell code for computations involving a
whole matrix. Perhaps there are vectorized C or C++ compilers as
well, but due to the much more severe aliasing problems in C and C++,
producing good parallell code is much much harder in C/C++.

Which is why C99 introduced restrict qualfication.
C is more flexible, thus harder to optimize without
some hints from the programmer.

Perhaps now you can start to understand why people running heavy
number crunching Fortran programs aren't interested in switching to
C++ just because that language is a better choice in non-numerical
applications.

I already understand that quite well, including
reasons you did not touch on.

 

[Jerry Coffin]

(e-mail address removed) (Paul Schlyter) wrote in message
[ ... ]

Your view and my view are not contradicting one another other. Indeed
Fortran has little real advantage for most work, since most work isn't
heavy number crunching.

Even within heavy number crunching -- there may be (probably are) some
specific tasks for which Fortran provides real advantages but it seems
pretty clear to me that C++ can be competitive for quite a few number
crunching tasks. For a few interesting data points, consider:

Matrix multiplication with MTL:

http://www.osl.iu.edu/research/mtl/performance.php3

Variety of tasks with Blitz++:

http://www.oonumerics.org/blitz/benchmarks/

FFTs with FFFTW versus various other FFTs:

http://www.fftw.org/speed/

IMO, these support my original statement -- C and C++ can compete with
Fortran, even within Fortran's area of specialization. They doesn't
_always_ beat Fortran by any means, and on average may even be
slightly slower overall -- but I'm not even certain of that, and if
they do end up slower on average, I'm pretty sure it's by a fairly
small margin.

FFFTW probably shows up the best of these: almost every time it loses,
it's not to something written in Fortran; rather, it's to hand-tuned
assembly language code directly from a processor vendor -- and
sometimes it even beats those!

Unfortunately, there are few C99 implementations out there. Do
you know any C99 available for supercomputers, for instance?

Cray says their current C compiler conforms with C99 (the X1 is
probably the fastest "production" computer available).

HP claims that Compaq C 6.5 for AlphaServers conforms with C99.

I haven't been able to find anything from NEC or IBM saying whether
their compilers conform with C99 or not -- so it's probably reasonable
to guess at "not".

Glancing through the rest of the top 10 on the Top500 supercomputer
site, it looks like the majority are based on Intel or AMD chips that
have C99 compilers, though it's possible that these machines are
customized to the point that they need custom compilers and/or
libraries to achieve full functionality.

.... try the standard problem of writing a subroutine to invert a
matrix of arbitrary size.

I haven't seen a benchmark specifically related to this task alone,
but unless I'm mis-reading the annotations, it looks like the Blitz++
benchmarks include at least some matrix inversion, and it seems to be
quite competitive.

Fortran has had the ability to pass a
2-dimensional array of arbitrary size to subroutines for decades. In
C++ you cannot do that -- you'll have to play games with pointers to
acheive similar functionality. That's why I once wrote the amalloc()
function (it's written in C-89 but compilable in C++), freely
available at http://www.snippets.org

There are quite a few matrix libraries in C++ that deal directly with
two- (and three-) dimensional matrices. Internally, they clearly have
to break this down to something simpler, but except on (unusual) array
processing machines that actually use 2-D or 3-D addressing, the same
is true with Fortran.

[ ... ]

I guess real programmers want real problems, or else they'll get
bored. Try to put a very skilled engineer on an accounting job
and you'll probably see similar results....

Perhaps so -- nonetheless, if you want accounting to get done, you
need to get somebody to do it. Trying to use tools that are only
usable by people who refuse to work on that problem rarely produces a
useful result.

In the end, I mostly agree -- just for example, I suppose there's a
comp.lang.cobol, but I'm pretty sure you won't find any posts from me
in there, and if you do, they're cross-posts from somewhere else. My
lack of interest, however, is hardly the final final word that it's
worthless!

 

[Phil Carmody]

FFTs with FFFTW versus various other FFTs:

http://www.fftw.org/speed/

Always to be read with
http://cr.yp.to/djbfft/bench-notes.html
as a rider.

IMO, these support my original statement -- C and C++ can compete with
Fortran, even within Fortran's area of specialization. They doesn't
_always_ beat Fortran by any means, and on average may even be
slightly slower overall -- but I'm not even certain of that, and if
they do end up slower on average, I'm pretty sure it's by a fairly
small margin.

FFFTW probably shows up the best of these: almost every time it loses,
it's not to something written in Fortran; rather, it's to hand-tuned
assembly language code directly from a processor vendor -- and
sometimes it even beats those!

FFTW, where it overlaps, seems to alway loses to DJBFFT. For the routines
used in my bignum-arithmetic-based projects, by a factor of 2-3. DJBFFT
is _entirely_ C. Of course, this reinforces your statement. I just think
your plaudits would be better placed complimenting DJB's use of the
language.


Phil

 

[Jerry Coffin]

Always to be read with
http://cr.yp.to/djbfft/bench-notes.html
as a rider.
Okay.

FFTW, where it overlaps, seems to alway loses to DJBFFT. For the routines
used in my bignum-arithmetic-based projects, by a factor of 2-3. DJBFFT
is _entirely_ C. Of course, this reinforces your statement. I just think
your plaudits would be better placed complimenting DJB's use of the
language.

Okay, that sounds perfectly reasonable to me.