mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2008-12-27, 21:49   #1
Freightyard
 
Nov 2008
San Luis Obispo CA

27 Posts
Default George: Prime95 DLL possible?

What would you think about modularizing the code into one or more DLLs? The purpose would be to separate the prime95 math core from the GUI code. Various applications (Windows desktop, Windows service, web interface) could then all rely on one DLL core, but each provide separate and/or unique user interfaces. Additionally, they might provide different or modernized storage for results, worktodo, etc.

With a core DLL provided by you, others could create various applications using a standard calling interface; thus, the source code would not need to be released.

This would add manpower to the programming effort and let others utilize their talents to produce a higher-quality application, perhaps with such features as an installer, auto-updates, improved GUI, or other ideas.

I'm just guessing the code is written in C, which is easily ported to a DLL. I would likely write a .NET wrapper that could be integrated into a fancier GUI or Windows Service with an HTTP GUI.

Your own maintenence would be eased as the application would be broken into individual components (GUI, prime core, networking core (GIMPS), data persistance (storage)).

Thoughts?

Last fiddled with by Freightyard on 2008-12-27 at 21:50
Freightyard is offline   Reply With Quote
Old 2008-12-28, 00:59   #2
starrynte
 
starrynte's Avatar
 
Oct 2008
California

22·59 Posts
Default

Quote:
Originally Posted by http://www.mersenne.org/various/math.php
GIMPS uses floating point FFTs written in highly pipelined, cache friendly assembly language
Thus it is not written in C, though it may still be possible to make it a DLL
starrynte is offline   Reply With Quote
Old 2008-12-28, 01:25   #3
Freightyard
 
Nov 2008
San Luis Obispo CA

27 Posts
Default

ASM--that's right, I remember reading that. I'm guessing just the core is written in ASM, though, and the rest in C.

Either way, it is ENTIRELY POSSIBLE to "inline" ASM into C source files, and it probably is inlined already. Both C and ASM can be linked as a DLL.

Inline Assembler Overview (MS C/C++):
http://msdn.microsoft.com/en-us/library/5f7adz6y(VS.80).aspx

Last fiddled with by Freightyard on 2008-12-28 at 01:26
Freightyard is offline   Reply With Quote
Old 2008-12-28, 01:55   #4
cheesehead
 
cheesehead's Avatar
 
"Richard B. Woods"
Aug 2002
Wisconsin USA

22·3·641 Posts
Default

Quote:
Originally Posted by Freightyard View Post
just the core
What's your definition of "just"?

Quote:
it probably is inlined already.
No, it isn't.

I think you need to go read the actual assembly source code, _then_ think about the feasibility of in-lining it within C source. (The latest version is in ftp://mersenne.org/gimps/source258.zip) I expect that you'll come to a different conclusion after you see (and understand) the actual assembly source code. :-) Some .asm source modules have thousands of lines, and there are many .asm modules.

- - -

This is to criticize not your DLL suggestion, which looks reasonable to me, but just the in-lining .asm in C bit.

Last fiddled with by cheesehead on 2008-12-28 at 02:26
cheesehead is offline   Reply With Quote
Old 2008-12-28, 02:50   #5
Freightyard
 
Nov 2008
San Luis Obispo CA

27 Posts
Default

Thanks for the pointer to the source! I didn't realize it was available--or, maybe I did and forgot.

"Inlined" or not, it is just as simple to create a DLL (simple is relative, of course). The point would be compartmentalize the functional parts of the code so that the parts--interface, math engine, data persistence, etc.--are not intertwined with each other and could be individually replaced.

>What's your definition of "just"?

"Just" the math engine. Not inferring that it is a trivial portion of the source; but that it would be surprising (to me) if the GUI was written in assembly.

How deeply intertwined the existing codebase is really is the question. I'm suggesting a move towards a more OO approach. That way, the math engine could be updated, but retain a Windows 95 GUI, for instance.

My main drive, if you haven't seen me write about it before, is to see a user interface added to the Windows Service version.
Freightyard is offline   Reply With Quote
Old 2008-12-28, 03:04   #6
cheesehead
 
cheesehead's Avatar
 
"Richard B. Woods"
Aug 2002
Wisconsin USA

22×3×641 Posts
Default

Quote:
Originally Posted by Freightyard View Post
The point would be compartmentalize the functional parts of the code so that the parts--interface, math engine, data persistence, etc.--are not intertwined with each other and could be individually replaced.
I suggest that there's already some compartmentalization, and you might find it adequate if you were actually familiar with it.

Quote:
How deeply intertwined the existing codebase is really is the question.
... and you haven't even looked at it to determine that depth since I posted the link, have you?

Quote:
I'm suggesting a move towards a more OO approach.
How is it that you know that George isn't already using an OO-enough-for-you approach?

You haven't yet looked enough at the source code, now that you have a link to it, to know whether the user interface is written in C or assembly!

- - -

This is not to say that the prime95 code couldn't be improved; it's to say that you seem to have remarkably little basis for suggesting improvements to it.

Last fiddled with by cheesehead on 2008-12-28 at 03:16
cheesehead is offline   Reply With Quote
Old 2008-12-28, 03:21   #7
Freightyard
 
Nov 2008
San Luis Obispo CA

27 Posts
Default

Well, what I am seeing is pretty good separation among several libraries that are linked together. As I suspected, the GUI is written in standard "Windows C".

It will take me a good while to figure out what I'm looking at. It's certainly not obvious which library is in charge of the "business logic."

I'm simply putting forth the idea to release the math engine with a public interface so that others can create alternate GUIs and features. A DLL allows automatic updates without re-linking.
Freightyard is offline   Reply With Quote
Old 2008-12-28, 03:28   #8
Freightyard
 
Nov 2008
San Luis Obispo CA

27 Posts
Default

Quote:
Originally Posted by cheesehead View Post
This is not to say that the prime95 code couldn't be improved; it's to say that you seem to have remarkably little basis for suggesting improvements to it.
You are, to some degree, correct. Which is why I am inquiring from people that might know. The basis, as stated, is to realize a reusable and portable module so that the interface code could be completely separated. It's not worth modifying the source to support a different implementation if one might be required to constantly "chase" changes as revisions occur. That is the point of OO, and I don't have any idea if that separation exists or not. Perhaps you do?

Adding further: The "basis" is this forum is littered with "feature requests" for Prime95. If the core engine were (or is) available as a binary DLL (or other module) then others with programming talent--myself included--might implement some of these feature requests, produce specialized utilities (i.e., a "Benchmark95.exe"), alternate GUIs, etc., etc. Maintaining just the separate versions of Prime95 would be simplified as well.

???

Last fiddled with by Freightyard on 2008-12-28 at 03:39
Freightyard is offline   Reply With Quote
Old 2008-12-28, 04:24   #9
cheesehead
 
cheesehead's Avatar
 
"Richard B. Woods"
Aug 2002
Wisconsin USA

22×3×641 Posts
Default

(Again, I have no quarrel with the DLL suggestion.)

What I took exception to was that it seemed in post #5 you were flatly stating that the existing prime95 software:

(a) was not compartmentalized enough, and

(b) was not OO enough,

even though your other statements clearly indicated that you were completely, or almost completely, unfamiliar with how that software was actually coded, and thus seemed to have no factual basis for judgments (a) and (b).

Quote:
I'm simply putting forth the idea to release the math engine with a public interface so that others can create alternate GUIs and features. A DLL allows automatic updates without re-linking.
Fine.

Quote:
Which is why I am inquiring from people that might know.
Looked more like declarative statements on those points than interrogative ones, to me.

Quote:
That is the point of OO, and I don't have any idea if that separation exists or not. Perhaps you do?
I don't know enough to make informed declarative statements about the existing OO-ness or separation. Perhaps there is enough of one or both, or perhaps there isn't, but I wouldn't presume that either must necessarily need improvement.

Quote:
If the core engine were (or is) available as a binary DLL (or other module) then others with programming talent--myself included--might implement some of these feature requests, produce specialized utilities (i.e., a "Benchmark95.exe"), alternate GUIs, etc., etc.
It is my understanding that the "core" FFT-performing routines coded by George Woltman _have_ already been used by others in software other than prime95. I suspect that this was done simply via source-sharing/copying, as had others' source code been incorporated (properly acknowledged) at some points in the prime95 source code, but I could be wrong. I agree that DLL development seems like an excellent idea.
cheesehead is offline   Reply With Quote
Old 2008-12-28, 04:59   #10
Freightyard
 
Nov 2008
San Luis Obispo CA

27 Posts
Default

Well now that my ignorance and assumption are laid out on the public Internet...

What I think would be most utilitarian would be modules like so:
  • Math module that you could call to say "please LL this" or "TF that"
  • Networking module that could be called to "Inform PrimeNet of this" or "Ask PrimeNet that".
  • Data persistence module that would store intermediate results. It could use files, as is done now, or store to a network location or ? in the future.
  • Logging module for results and prime.log
  • Business Logic module that would tie everything above together (knows what modules to call to get the work done)
  • Interface module (GUI, CLI, HTTP, or ???) - Program Entry Point. Defines whether application is a GUI, Windows Service, Command Line application or ?. Instantiates all modules and transfers control to the Business Logic module which handles the work COMPLETELY separate from the interface. Call-backs ("hooks" or "events") would report information needed by the GUI or other interface.
Each module would register "hooks" for data that it is interested in. If there is no "consumers" for a data event (say a test utility doesn't need to log anything) then the other modules would simply keep working. The logging module could be completely omitted as the math module does not depend on it existing. It would only provide the "hooks" in case a module is interested. OR--you could have two logging modules, one as it is now, and another to log to an administrative console controlling multiple Prime95 systems.

One possible specialized implementation could be a Prime95 that is controlled over a network. An Interface Module could link via network connection to a master interface application that oversees and monitors numerous Prime95 systems or an entire GIMPS team. Monitoring/control could be effected locally or over WAN via WWW. Teams could build web sites showing status of their machines. Computer labs could monitor dozens or hundreds of installs remotely.

With this type of design, one could make changes to each sub-section without affecting anything else--for example: Upgrading from PrimeNet v4 to v5, bug fixes to CPU affinity, etc.

Currently, even small changes require a complete re-compile or re-link of all versions of Prime95. With DLLs, you simply replace the affected DLL.

HENCE, new or specialized implementations don't have to tear into each revised version of the source code.

Take a look at this project: http://www.cryptofreak.org/projects/gkrellmgimps/

It hasn't been updated since 2003 and would likely be a nightmare to do so. Using modules, it would still be working with v25.8 unless the module interface was changed (likely, but not nearly as often).

Good idea or bad?

Last fiddled with by Freightyard on 2008-12-28 at 05:06
Freightyard is offline   Reply With Quote
Old 2008-12-28, 15:20   #11
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

1D4416 Posts
Default

The FFT code is well isolated (but not a DLL). It is used by LLR, SoB, and OpenPFGW.

The GUI code is isolated because it is not portable to other OSes.

The rest of the code is a big blob of C code, typical of a project that has evolved over 13 years. Could it be improved? Yes. Do I have the time? No.
Prime95 is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
@ George Gordon GMP-ECM 2 2017-09-04 04:05
requesting permission from George to release Prime95 screenshot under GPL ixfd64 Software 7 2012-09-04 06:07
George Melly RIP davieddy Lounge 14 2007-07-08 08:10
Query for George about ERROR 3 garo PrimeNet 17 2005-10-18 21:01
A Question for George Hades_au Software 8 2003-01-29 00:03

All times are UTC. The time now is 16:04.

Fri May 14 16:04:38 UTC 2021 up 36 days, 10:45, 0 users, load averages: 2.26, 2.26, 2.24

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.