Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Cracking DES with C++ is faster than Java?

Reply
Thread Tools

Cracking DES with C++ is faster than Java?

 
 
George Neuner
Guest
Posts: n/a
 
      06-06-2004
On Fri, 4 Jun 2004 12:53:38 +0200, "Branimir Maksimovic"
<(E-Mail Removed)> wrote:

>Most everyone says GC is or should be slower, with no given reason- it's
>assumed but never discussed. Some computer language researchers say
>otherwise.


And they are wrong.

Explicit memory management is provably optimal - it performs the
minimum number of operations required to achieve the result.

In operation, systemic GC wastes effort processing memory which the
programmer knows is in use and would therefore not be touched if
explicitly managed.

With loads of help from the compiler, automatic management can be
tailored to the needs of the individual application. Such tailored
systems can sometimes closely approximate explicit management -
however, they are still largely experimental and the best they could
hope to do would be to equal explicit management.

This is not a criticism of GC ... it's just a statement of fact. I
believe automatic memory management is a Good Thing (TM) - but the
safety and convenience it offers comes with a price.


>Consider what happens when you do a new/malloc: a) the allocator wanders
>through some lists looking for a slot of the right size, then returns you a
>pointer. b) This pointer is pointing to some pretty random place.


This is only true of the most naive implementations. The simple
stuff you see in introductory algorithm books is almost never used in
practice - even the most heavily criticized real implementations have
long been case optimized for typical usage patterns and are far more
complex than the books would have you believe.

There are many excellent heap management algorithms available which
minimize processing time and fragmentation. Take a look at allocators
designed for real time use.


>With GC, a) the allocator doesn't need to look for memory, it knows where it
>is, b) the memory it returns is adjacent to the last bit of memory you
>requested.


This is only true of moving (ie. copying and/or compacting)
collectors. Non moving collectors have exactly the same allocation
search problems as do explicitly managed heaps.

Of late, copying collectors have fallen out of favor for all but the
first generation nursery, where objects tends to die quickly. Modern
generational systems have tended toward non moving collectors for
tenured storage.


>The wandering around part happens not all the time but only at
>garbage collection. And then of course (and depending on the GC algorithm)
>things get moved of course as well.


I suggest you spend some quality time reading about how memory
management really works. A good technology overview can be found in
"Garbage Collection: Algorithms for Dynamic Memory Management",
Richard Jones & Rafael Lins, 1997, Wiley & Sons, Ltd., ISBN
0-471-94148-4. Beyond that there are many papers available on the
current state of the art.

George
--
Send real email to GNEUNER2 at COMCAST o NET
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cracking AD passwords on a domain controller pokhara@yahoo.com Computer Security 1 02-13-2007 02:25 PM
Re: Brute Force Cracking Failed, No Vulnerable Blocks, DVD Decrypter Martino DVD Video 8 02-01-2006 10:09 PM
Re: Help needed on a bibliography of cracking LaDDL Computer Security 1 04-30-2004 06:41 PM
Re: Help needed on a bibliography of cracking Marek Luch Computer Security 0 04-30-2004 06:41 PM
Cracking Up AK Computer Support 11 11-11-2003 06:21 PM



Advertisments