Info for using 64-bit source

The latest version is 1.2.1.

Source code is in v121/ecdl2-97.c or v121/ecdl2-97.c.gz.

The only significant change from 1.2.0 is that the alternate email address (for use when email to bounces) is now

Other changes from 1.2.0 are negligeable: cosmetic changes to warning messages and comments.

There is no need to upgrade if you're already happily running 1.2.0.

Good luck,

> ecdl2-97.c
Purpose: Fast arithmetic for computing discrete logs on elliptic curves.
Copyright: Robert J. Harley, 1997-1999.
Legalese: This source code is subject to the GNU Public License (v2).

This is ECDL64, version 1.2.1.

Consult the following URL for more information:


Do this:

cc -O2 ecdl2-97.c -o ecdl
mkdir `uname -n`
cd `uname -n`
nice ../ecdl mail `whoami` MyTeam `uname -n` `uname -m` `uname -s` > log &

Detailed instructions

1. Compiling

Compile with something like:

gcc ecdl2-97.c -o ecdl -O2 -freg-struct-return -mcpu=<chip>
cc ecdl2-97.c -o ecdl -O5 -non_shared -tune <chip>

NB: <chip> is ev4, ev5 or ev6 for Alpha 2106x, 21164 or 21264 families respectively.

You can test the binary like this:

./ecdl test me Testers bla bla bla

The test output should match the sample below except for the number of iterations per second.

If the program complains that it cannot find sendmail, you can add -DSENDMAIL='"/usr/sbin/sendmail"' or something similar.

NB: Beware if you compile on Digital Unix with -non_shared and run on Linux. The program uses popen() to run sendmail; when compiled on Digital Unix popen() looks for /sbin/sh whereas Linux has /bin/sh instead. You will have to create an appropriate link or else use batch mode (see below).

Test output follows:

ECDL64, version: 121.
Mode ...... test
User ...... me
Team ...... Testers
Machine ... bla
Hardware .. bla
OS ........ bla
Comment ... none
Generating 20 new starting points.
Computing iterations...
Iterations during this run = 618880 at 342373 per second.
Iterations during this run = 1258740 at 342351 per second.
Iterations during this run = 3412500 at 342286 per second.
Iterations during this run = 4034280 at 342205 per second.
Iterations during this run = 4649860 at 342157 per second.
Iterations during this run = 4694540 at 342126 per second.
Iterations during this run = 4787300 at 342093 per second.
[...and so on...]

2. Optimising

Good speeds on Alpha are roughly 100 k iterations per second for a 300 MHz EV4, 350 k for 500 MHz EV5 and 450 k for 500 MHz EV6. Best results are obtained with gcc 2.95 or Compaq cc >= 5.7. A 333 MHz UltraSPARC-IIi running Solaris 7 gets 200 k with Sun's cc 5.0.

You can compile with various optimisation flags to maximise speed before starting on the real calculations. You can try adding -DALT_PROD to the compilation flags to use a slightly different implementation of a speed critical function. It might be a little faster (then again, maybe not).

You can also try tweaking the value of PARAL. Just add -DPARAL=24, for instance. The default is 20 and useful values are roughly in the range 10 to 32. Note that the test output will no longer exactly match the sample given above.

3. Starting up

When you're ready to start up: on each machine you want to run on make a directory for that machine, cd into it and go.

mkdir `uname -n`
cd `uname -n`
unlimit cputime || (echo Using ulimit instead; ulimit -t unlimited)
nohup nice +15 ../ecdl [...arguments, see below...] > log &

NB: Some shells need nice -15 instead. If you have a machine with several CPUs, make a directory for each CPU and start up an ecdl process in each one.

The arguments have the following syntax:

ecdl <mode> <user> <team> <machine> <hardware> <OS> { <comment> }

<mode>: Either test, mail, alt or batch.
<user>: Something to identify you by e.g., your email address.
<team>: Name of the team you are on e.g., one you just made up!
<machine>: The machine name e.g., as given by uname -n.
<hardware>: The machine hardware type e.g., as given by uname -m.
<OS>: The OS name e.g., as given by uname -s.
<comment>: Optional extra text.

None of these fields should contain the | character but they can contain spaces and stuff as long as you use 'single quotes' around the fields concerned on the command line.


ecdl mail 'Robert Harley' INRIA corton '500 MHz 21164a' Linux
ecdl mail biff@skool 'Hackerz from Hell' `uname -n` `uname -m` `uname -s`
ecdl batch anon 'Anonymous People' bla bla bla 'Yo dude, check this out!'

Test mode quickly produces some (useless) output to stdout along with info on iterations per second. This allows you to check that your binary is OK, to compare compiler optimisation flags etc.

Mail mode emails a result back to every few hours or so (as well as writing it to stdout). INRIA's excessively aggressive spam filters might refuse the email; in that case switch to alt mode which sends to instead.

For machines not permanently connected to the Net, batch mode only writes the results to stdout, so you should redirect that to a log file and email the file (or just the new lines at the end of it) by hand once in a while. Beware of mailers that wrap long lines, though!

4. Shutting down (and saved states)

When the program is running it saves its internal state in a file (called from time to time. The reason each machine should have its own directory is to avoid the saved states getting mixed up! If you want to stop the program, the best way is to find it's PID (first column of the ps output) and send the TERM signal which causes it to save its state and exit:

ps x | grep ecdl
kill -TERM <the PID>

When you restart in the same directory:

nohup nice +15 ../ecdl [...arguments...] >> log &

the program will look for the saved state file. If no saved state is found it will generate a new state and work from there. If one is found, the program reads it, and continues where it left off. Note that it would be wasteful to use a given saved state on more than one CPU because work would just be duplicated. Note also that test mode does not mess with the saved state.