Cracking DES with C++ is faster than Java?

Discussion in 'C++' started by Julie, Apr 25, 2004.

  1. Julie

    Paul Schmidt Guest

    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.
    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 Schmidt, May 3, 2004
    1. Advertisements

  2. 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
    Mok-Kong Shen, May 3, 2004
    1. Advertisements

  3. 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:
    School of Computer Science & Software Engineering
    The University of Western Australia WWW:
    Crawley, Western Australia, 6009 PH: +61 8 6488 2533, FAX: +61 8 6488 1089
    Chris McDonald, May 3, 2004
  4. 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.
    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... :)
    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.
    True, C is more versatile, I never argued against that.
    ....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, May 3, 2004
  5. True of course, however there WAS software reuse also before object
    orientation. And that was my point.

    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

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

    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, May 3, 2004
  6. 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.

    The well-known aliasing problem....

    Paul Schlyter, May 3, 2004
  7. You are certainly right. Thanks for the correction.

    M. K. Shen
    Mok-Kong Shen, May 3, 2004
  8. Chris McDonald had immediately pointed out my using the
    wrong term.
    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
    Mok-Kong Shen, May 3, 2004
  9. 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.
    a = b + c; e = f * g; // much better than in C
    Douglas A. Gwyn, May 4, 2004
  10. 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.

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

    Paul Schlyter, May 4, 2004
  11. 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 .......


    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.

    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.

    Paul Schlyter, May 4, 2004
  12. [snip]
    Nightmare though. ADA is still being used in the latest military aircraft.

    Andrew Swallow
    Andrew Swallow, May 4, 2004
  13. Paul Schlyter wrote:
    That was Ken Olsen, not the whole DEC...
    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.
    Until they proved that Prolog isn't scalable...
    Probably not. OS/2 was a pay job. Gates used the money to develop

    -- Lassi
    Lassi =?iso-8859-1?Q?Hippel=E4inen?=, May 4, 2004
  14. 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.
    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!
    No, the optimum code for the operation is
    the optimum code for the operation. Who
    argued otherwise?
    Douglas A. Gwyn, May 4, 2004
  15. 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.
    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....

    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

    Paul Schlyter, May 4, 2004
  16. 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.

    THose who design and build hardware need to worry about that, yes.
    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

    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

    Paul Schlyter, May 4, 2004
  17. 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?
    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.
    Which is why C99 introduced restrict qualfication.
    C is more flexible, thus harder to optimize without
    some hints from the programmer.
    I already understand that quite well, including
    reasons you did not touch on.
    Douglas A. Gwyn, May 4, 2004
  18. Julie

    Jerry Coffin Guest

    (Paul Schlyter) wrote in message
    [ ... ]
    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:

    Variety of tasks with Blitz++:

    FFTs with FFFTW versus various other FFTs:

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

    [ ... ]
    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! :)
    Jerry Coffin, May 5, 2004
  19. Julie

    Phil Carmody Guest

    Always to be read with
    as a rider.
    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

    Phil Carmody, May 5, 2004
  20. Julie

    Jerry Coffin Guest

    Okay, that sounds perfectly reasonable to me.
    Jerry Coffin, May 5, 2004
    1. Advertisements

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