NOTE: If you are a programmer, when you finish this page, you might be interested to wander over to the Identifying Lychrels page or the Wish List page, and see what they are all about....
The following is a brief comparison of the fastest applications which have the ability to run the 196 quest across a network.
I have created a test setup WHICH IS EASIEST FOR ME to administer... The setup below is a configuration that I can have running at any time in my house. I have been playing around with Linux (Suse v10.0) and I expect that some people will argue that it's a better OS for networking. True or false, it doesn't matter. Until I get very familiar with a non-Windows OS, this is the set-up I am stuck with.
The test setup is as follows:1st machine: 2.8GHz Pentium IV (Hyper-threading enabled) with an 800MHz FSB, over-clocked to 2.95GHz, with (2) - 512Mb, 400MHz (PC3200) DDR SDRAM modules (1GB total), total of 220GB hard drive space, running Windows XP pro.
2nd machine: 2.8GHz Pentium IV (Non-Hyper-threading) with 400MHz FSB, with (2) - 512Mb, 400MHz (PC3200) DDR SDRAM modules (1GB total), total of 80GB hard drive space, running Windows XP pro
3rd machine: 900MHz Pentium III with an unknown FSB, with (2) - 128Mb, 133MHz (PC133) RAM modules (256Mb total), total of 40GB hard drive space, running Windows XP pro
All machines are wired together with Cat5 cable, through a 100MBS Netgear router.
NOTE: Some of the apps below take advantage of the P4's Hyper-threading ability, and some do not. I have made no distinction between them on this page. If the app has the ability to utilize hyper-threading or any other "tricks" to gain an advantage in processing I have allowed it and run the app in the fastest method I can get it to run in. This includes running multiple clients on the same machine.
What follows is the fastest time I can manage each app to achieve in any configuration, using the hardware listed above.
The iterations tested below, represent a shallow test of the first 603,567 iterations, (3 - 250,000 digits), and a deep test of 50,000 iterations with a larger starting data file (20,000,000 to 20,020,728 digits).
I think everyone would agree with me, that the deeper test times are of greater importance than the shallow digit times. That is the reason that some apps are listed ahead of others, even though the shallow times are "backwards". I have ranked them based on deep iteration testing...
Unfortunately, right now, I only have Pierre's app to list, but I expect that to change soon, so the format is going to be the same as on the normal Software Comparisons page. :-)
SCREENSHOTS
| Coder's name and Location | 0 - 603,567 Iterations | 48,316,988 - 48,366,988 Iterations | Pierre Laurent - France | 1:09 | 9:43 |
| Coder's Name and Location. | Pierre Laurent - France | ||
| Program Size. | 180 Kb | ||
| Time to reach 603,567 iterations, starting at 0. | 1 Min 09 Sec | ||
| Time to reach 48,366,988 iterations, starting from 48,316,988 | 9 Min 43 Sec | ||
| Run Time Indication | Displays seconds count at screen update. | ||
| Digit Count Monitoring | Displays digit count per command line option. | ||
| Iteration Counter | Displays iteration count per command line option. | ||
| OS Environment | Windows or Linux | ||
| Save Schedule | Autosave on user selectable intervals in seconds. Autosave on user selectable iteration intervals. Save on any iteration count specified. Save on any digit length specified. | ||
| Max Calculation | Reported to be limited to 1 billion digits. | ||
| Versatility | Can be used to test any number for a palindromic solution. | ||
| Comments | The first network capable app, this is the standard everyone will have to live up to. | . | . |
If you have an application that you would like me to compare against these, I'd be happy to be an independent tester for anyone. Sadly, I am limited to DOS or Windows applications.
I have been using different apps for long enough that I have found certain "features" that have become important to me. (Or just really nice to have.) If you are going to send me an app to test, I would ask for the following to be available in your final version. (Well, no one has ever had a "final version" except the people who have decided to stop working on this problem, but you get my idea.) I can test without some of these things, but I would like to have them in place for a functional copy!!
1. Your app MUST be able to read and save a file in ISF format. Details of the format can be found on the File Verification page. If I can't read my existing files, I won't be able to do any deep iteration testing, and the world will never know of your programing genius. This also affects me in file verification. It is VERY important to me.
2. Your app should save on whatever schedule you think is best, by default, but I will ask that you allow it to be able to autosave on user selectable times (in seconds). Saving every 10,000 iterations is great, except that in the shallow numbers, you spend MORE time saving as you do running, and by the time you get to 50,000,000 digits, 10,000 iterations might not be often enough in my opinion. I move the autosave function anywhere between 30 minutes and 2 hours, depending on the weather here in Florida, or if I'm going on vacation or something. If your app doesn't save on a selectable time interval, I probably wouldn't use it in the long run. (But I can easily TEST it, without this function.)
3. Your app should autosave to a unique file name each time. What the name is, I don't care. I'll adapt to whatever name system you choose. But I really want to be able to go back and recalculate a portion of the number if something
goes wrong with my system, or if I just feel like it. (I have done that for verifications!!) I guess the more popular name system that I've seen has been something along the lines of:
StartingNumber_IterationNumber_DigitNumber.isf
This works really well for me, but if you choose something else for your own reasons, that's fine with me. Again, I can test without it, but in the long run, I probably won't ever use another program that doesn't save to a unique file each time.
And if you're worried about filling the hard drive with data.... I go through regularly and purge the directory. I pay very close attention to the capacity of my 196 partition. I lost some data once, because I had filled the drive, and I learned that lesson well!! Besides, as the files get larger.... I'll buy a bigger drive. :-)
4. A time display function is nice. Not NEEDED exactly, and I have seen a lot of different measurements, but it is a nice touch, however it's implemented.
5. Eric Goldstein's standalone app writes a log file of program activity that is a VERY nice addition. A sample log, looks like this:
2003-01-03 19:02:57 Start
2003-01-03 19:02:57 Running as normal executable
2003-01-03 19:02:57 Priority set to 1 (was 1)
2003-01-03 19:02:57 Allocating 1048576 bytes...
2003-01-03 19:02:58 Allocation successful.
2003-01-03
19:02:59 Trying to read e:\196\running\periodic\ISF_Current_196.isf...
2003-01-03 19:02:59 Success. Continuing from iteration 163143316, digits 67526818
2003-01-03 19:02:59 Reallocation needed
2003-01-03 19:02:59 Allocating
68157440 bytes...
2003-01-03 19:02:59 Allocation successful.
2003-01-03 20:02:58 Periodic save at iteration 163173188, digits 67539100
2003-01-03 20:37:49 Suspended.
2003-01-03 20:38:23 Resumed.
2003-01-03 20:38:23
Stopping...
2003-01-03 20:38:23 Periodic save at iteration 163190179, digits 67546167
2003-01-03 20:38:35 Stopped
6. A stop, pause or suspend button that doesn't close the application is VERY important to me. Something to get the app to quit running while I'm trying to run something in LabView or whatever. A lot of times, I don't need to shut the app down for more than a few seconds, like when I do my Excel updates, and I want to be able to see the iterations and digits without opening the file. A suspend or pause button is the best. A stop works well enough, except for the time it's writing the file, and I'm waiting to restart it.
7. Your app MUST autosave on normal exiting. I can teach my girlfriend and her kids how to shut the program down safely, but I don't want them to have to worry about saving before they do so. Every app I have right now has this function. It's almost as important as reading an ISF file format!!
8. A self verification check of some sort is a definite plus!! Ben Despres' MOD-9 check has been documented MANY times to have saved my skin, when something has gone wrong. Eric Sellers and Eric Goldstein both implemented it in their apps, and both apps have "caught themselves" making an error somewhere along the line. For example, Eric Goldstein's app, verifies the file every time it saves or reloads. As a result, when there is an error, it is caught quickly. This is an extremely nice function!!!
9. Do us both a favor, and put a version number somewhere obvious in your app. Something like the title bar works well. This is important for me giving you feedback, so we both know which version is being discussed. I'll most likely keep copies of all the app revisions you send, and this will avoid confusion.
I think most of the other things I look for in an app are pretty "nit-picky". But the user-friendliness is important on any application, and in an environment like mine, where I have to share the computer, it could make all the difference, between running your app, or just testing it, and setting it aside.
I like looking at the different approaches people take, to get to the same result. And secretly, I like the suspense, of testing, to find out if "this one" is going to become the new "Speed King"!!
Send me your applications for testing!!! Like I said... I love the suspense.