Re: Cracking DES with C++ is faster than Java?

From: Paul Schmidt (
Date: 05/02/04

Date: Sat, 01 May 2004 21:51:21 -0400

Bryan Olson wrote:
> Jerry Coffin wrote:
> > My opinions aren't based purely on looking at code produced by C
> > and/or C++ copmilers, but also by various other languages (including
> > Fortran). It's true that Fortran has changed since then as well, but
> > I'm not particularly convinced that the sub-optimal code is due to new
> > language features or anything like that.
> >
> > Now, how do I, on one hand, say that the situation is worse today than
> > it was 20+ years ago, but also agree that optimizer technology has
> > gotten better during that time as well?
> Hey -- there are more important things to optimize than clock-
> cycle counts. I too am old enough to have learned FORTRAN IV,
> and let's not kid the kids: FORTRAN IV sucked! Wasting a few
> machine cycles is one thing, but don't waste large amounts of my
> time and claim to be doing me a favor.

You need to look at conditions of the time though, you could hire a
programmer for $5.00 an hour, computer time cost over $1000 per machine
second, so if wasting 400 hours of programmer time saved 5 machine
seconds you were ahead of the game.

Today we look at different conditions, you can get a year of computer
time for $1,000 but the programmer costs that for a week, so tools need
to be programmer efficient rather then machine efficient. If you waste
5 hours of machine time and save a week of programmer time, your ahead
of the game.

Java becomes more programmer efficient by 2 of the 3Rs (reduce is the
missing one) reuse and recycle, because a class is an independant
entity, you can use the same class over and over again, in different

I think the future will be more descriptive, in that a program will
describe what an object needs to accomplish rather then how the object
does it. The compiler will then figure out how to do that.


> How bad did FORTRAN IV suck? Well, my favorite example is that
> a for-loop (actually a "DO" loop in FORTRAN IV) could not
> execute its body zero times. Even if the condition was false at
> the start, it would go through at least once. Is that as
> awkward as it sounds? Absolutely! Why did they do it? Well,
> the way most machine instruction sets work, one can save a cycle
> or two by testing the condition at the end of the loop, and
> using a conditional jump backwards.
> We have much more *efficient* languages today. C and C++ are
> far from top of the list. Java doesn't crash, but it's still
> notably primitive. My hope for the future is with elegant,
> polymorphic-type-safe languages, such as the ML family, or
> perhaps even more purely functional languages such as Haskell.
> They have yet to make a commercial splash comparable to C/C++ or
> Java, but when tested in coding-competition, they romp.
> In my own grad-school work with ML, I fought long and hard with
> the type-checker. I could take an hour or more just to several
> dozen lines of my code to compile. Still, I like ML; when
> programs did compile, they worked. Logic errors are, or course,
> still possible, and I cannot be certain my programs were
> entirely correct. Nevertheless, I'm impressed: in about a year
> of using ML, *every* known error in my code was caught at
> compile-time.
> --
> --Bryan