[RC5] "sexy" projects

Frank Rival ops at dwc.edu
Sun Mar 1 14:36:19 EST 1998


Daniel Marcotte wrote:
> Actualy the numbers above might be slightly incorrect since the
> release of a new engine (Garsp) which is 3-5 times faster than Gvant.
> I am getting 300,000 nodes/s. from my 7200/90 and almost a million
> nodes/s. from my K6/200. They also have a 64 bit version that truely
> rocks on Alpha's. Right now the engines are written in C, Just think
> how fast it could be if someone like Andrew Meggs roled an assembly
> version :)

	Just as an aside, I've been working on this since DES-II-1 ended as
well, just looking for something my Origin 2000 might do better than
RC5.  As it turns out, without much tuning I'm getting >1Mn/s from this
version of the code.  I talked to Mark Garry about performance
improvements to the code, and suggested assembly.  To say that he didn't
want to go in that direction is an understatement.  This was in private
email, but I don't think he would mind my posting it here:

: Optimizations are possible ... though using assembly would be a bad
: mistake. As it is, the "code" gets translated very effectively by
: current day compilers.  And since C is portable, ideas flow in from
: all over.  Once in assembly, development grinds to a halt because no
: one can work with it easily.
: 
: As far as optimization ideas ... the primary one I can think of is to
: find out what part of the choose array is most beneficial, and then
: expand that portion and reduce other portions.  I.e., I've used a
: "square" 2 dimensional array format.  But we really only need ONE
: entry for choose when the second index is zero (i.e., choose is
: effectively an array as follows:  choose[bits taken array][marks left
: in ruler]).  When there are no marks left in the ruler, choose is
: ALWAYS zero, regardless of the bits already taken.  So if we
: rearranged CHOOSE into a variable "width" 2 dimensional array, we
: could be more efficient given the same RAM requirements.
: 
: I have some other ideas ... but this one is complex enough to
: consider, no?

He did mention another optimization that needs to be done -
multithreading.  I haven't had enough sit-down time with the GARSP code
to really take a look at what could be done, but for those talented
coders out there, this is also a good starting point.  I realize this is
far from the RC5-64 topic, but as a potential D.N project, these
comments could be useful.  I vote we go for it.  All we should need to
do is wrap the communication layer around the current GARSP core and
build for the prospective clients (obviously making changes to all the
keyservers and proxies...) and something should be ready.  Did I make
that sound easy enough? <smirk>

 - Pete
--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list