George: Prime95 DLL possible?

[Freightyard]

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?

[starrynte]

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

[Freightyard]

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

[cheesehead]

Originally Posted by Freightyard

just the core

What's your definition of "just"?

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.

[Freightyard]

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.

[cheesehead]

Originally Posted by Freightyard

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.

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?

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.

[Freightyard]

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]

Originally Posted by cheesehead

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.

???

[cheesehead]

(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).

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.

Which is why I am inquiring from people that might know.

Looked more like declarative statements on those points than interrogative ones, to me.

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.

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.

[Freightyard]

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?

[Prime95]

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.