Ok, here is the status. I have a very stable, much faster port
ready to go. It is about 10-15% faster than ecdl-mmx.exe and 25%+
faster than Brian Gladmans MMX Win32 service port. NOTE the source
pool started from Brian Gladmans original console app port.
This port does these things:
- Has a tray icon which changes depending upon points found,
running or paused.
- Menu tied to the tray icon (and a menu on the app face).
- Ability to have many clients all write to the same dist.points
file (many clients running on the same multi-cpu machine, or
many clients on a connected LAN).
- Ability to "auto-start", "Auto send to tray".
- Faster (only tested on Intel Pentiums, PPros, and PII's)
- Better display of stats, etc.
- Proxy ready, Http ready, and batch ready (my preferred method).
- Ability to not show the tray icon (stealth mode). Creation of a
"magic" file will redisplay the tray icon within a few seconds,
when in "stealth" mode. This magic file is c:\wingui_ecdl.visible
- Ability to raise the thread's priority if a screen saver becomes
active. Without this priority change, the screen saver does not
allow the "idle" priority classed thread much time (even on fast
machines). Priority will automatcally revert back to idle within
seconds after the screen saver goes away. (Note this is an option)
- Ability to specify the maximum percentage of CPU used when the
screen saver higher priority is active.
- Ability to specify the maximum percentage of CPU used during
a configurable "business hours" range. NOTE that setting the
max percentage will cause the program to itterate slower, but
may reduce the appearance of lost performace. Some people want
this program to use less CPU while they are using their machines
(my company allowed me more machines if I put in this "feature").
- Ability to ignore the maximum percentage rules on the weekend.
The weekend is defined as Friday after business hours until
Monday before business hours. Both screen saver and "business
hours" priority will be ignored.
- Auto loading of data from an INI file. This helps in setting up
many machines in a lab setting. You can set the entries in the
ini "preload" file to the "correct" values, and then when you
put the software on a pc, simple load this ini file, change
the "name" of the PC, and start running.
- Of course, information is stored in the registry so the next
run will "know" the correct data.
- This program ONLY starts 1 additional thread. This being so,
if you want the program to use multiple CPU's on a multi-CPU
machine, then you need to start more than 1 copy of the
program running. When doing this the programs MUST be located
in separate subdirectories (folders), or they will both find
EXACTLY the same points (waste of CPU cycles). The reason
for having only 1 thread running within each process, is
because there was a big performance hit because of miss
aligned MMX data caused by multi-threading issues.
- On the downside, this program does use considerably more
RAM. I have linked in the C runtime library, and linked in
MFC. There are too many problems with DLL versioning for me
to release the program with a DLL version of MFC. I will be
working on reducing this memory footprint.
*** Timings: (itteration speed at 10th "test" mode point found)
Machine: Intel PII-300 Win98 (NT4 has almost exactly the same times)
ecdl-mmx.exe 89K (1.1.0 Cygwnd32 port)
ecdl-srv.exe 78K (1.1.1 Gladmans service port using -r)
WinGUI_Ecdl.exe 98K (1.1.3 this release)
Note other Intel MMX PC show almost the exact same proportional
differences between the different programs. I don't have any
non-Intel machines (or Celeron's or PIII's) so I am not sure
of the timings on those machines (but would be very interested
in hearing about them).
Currently (as of this email) the binary and source are not
available on the ecdl-108 site (I have sent email to Rob, but
have not yet gotten a reply). If you would like a copy of
the binaries (or source), please email jfoug@kdsi.net. Do
not reply to this email address (it is my work account). I
do not check it on the weekends, so your request will sit in
bit limbo longer than it should.
Jim.
This archive was generated by hypermail 2b29 : Wed Jan 12 2000 - 18:56:35 MET