ASM vs portable code [WAS: Re: Java DES breaker?]

["Peter Trei" <trei@process.com>]

Ray Arachelian <sunder@brainlink.com> wrote:
> On Wed, 11 Dec 1996, Dr.Dimitri Vulis KOTM wrote:
> 
> > I happen to have a Sparc 20 box and a Linux box and a SCO box, and ActiveX
> > won't work on any of those. I also work with a bunch of other equipment
> > that's much faster than a PC, but doesn't run browsers. (Most of it is not
> > connected to the 'net for security reasons, but that's besides the point.)
> 
> Right, and Active X, if those machies were on the web, would not be 
> supported.
>  
> > If Bill's client is sure to run the platforms that MS IE runs on, then this is
> > not a consideration.
> 
> Correct, however there is one thing you have forgotten... (next paragraph)
> 
> > Interpreted FORTH bytestream (which is what Java is) may be "doing quite well"
> > when drawing GUI gizmos and widgets, but it can't get anywhere near the
> > performance of hand-optimizer assembler that you can stick into ActiveX.
> 
> While ActiveX does support hand optmized assembler, there are Java 
> JustInTime compilers which take JVM bytecodes and turn'em into raw 
> assembler.  They aren't hand optimized, they are natively compiled code, 
> but they are native code non the less.  A good optimizing compiler may 
> not be 100% as cool and as fast as hand optmized code, BUT it'll be 
> almost as fast.  And Java will run on just about EVERY platform out there.
> And that is a bigger, more important point than a 10%-25% increase in 
> power over non-optimized code.
> 
> Besides, I'm not arguing AGAINST an ActiveX client, there's no reason 
> why there can't be both Java and ActiveX clients out there since there is 
> both a compatibilty issue and a speed increase with ActiveX.

While I'm reluctant to ever find myself in the same corner as
Vulis, he has a point. As one of the few folks on this list who
actually writes code, I say that hand-optimized assembler will
beat machine generated code every time.

I have figures to back me up.

As some of you know, I've been working on a DES key recovery tool.
I'm have both portable C and x86 assembler versions. They
are currently identical, except that the guts of the DES round is 
written in "C" in one, and hand-optimized Pentium assembler in 
the other. 

For this test, I modified the code to cut out the delays associated 
with incrementing the key schedule, leaving the most of the 
crunching in the DES decryption. Both versions were compiled 
under Visual C++ 4.0, with Optimizations set to 'Maximize speed', 
and inlines to 'any suitable', and run on a 90MHz Digital 
Celebris 590 under WinNT 3.51.

Averaging several runs:

"C":   102,300 crypts/sec
ASM:   238,000 crypts/sec

With Java, it's possible to add native code methods to the 
interpreter, though this requires extra work by the user - 
it's harder than 'click on this link to run my reely 
kool applet'. This violates the Java sandbox, and requires 
the user to  make trust decisions on the methods they 
are adding.

ActiveX lets you add and run native code with a click, but
again involves trust decisions.

My philosophy is 'the more the merrier'. I'd like to see
people work on DES Key Recovery on a large number
of platforms - we just need to standardize on the input
and output formats.

Peter Trei
trei@process.com     

Peter Trei
Senior Software Engineer
Purveyor Development Team                                
Process Software Corporation
http://www.process.com
trei@process.com