Repository navigation
Rewriting the code in C instead of using fortran #38
Description
I suggest re-writing the code solely in C instead of fortran.
Newer C standards have enabled exactly the same optimizations as Fortran has as long the coders enable them.
The point is that when you give the C function a pointer parameter,the compiler cannot know if they can point to the same object so that changing one changes another. So if the code changes an object pointed to by one pointer, the compiler can no longer assume that the value pointed to by another pointer which is loaded into the register would no longer be valid, and it needs to be re-read from RAM.
That problem particularly affects matrix computation and the like. When matrices in C are passed as pointers and without the restrict keywords, the compiler has to write virtually every intermediate result in the frame and read back when the function has more than one matrix parameter.
There are no pointers in Fortran, but reference parameters that can't be overlapped.
As said, the newer C standards allow coding so that they don't overlap each other (mainly by placing a restriction keyword in front of the pointer parameter). In other words, today's C is just as fast as Fortran.
Addition and multiplication and other mathematical functions are fast. Ram reading and writing is slow.
Activity
godotalgorithm commentedon May 11, 2022
What would be the benefit of rewriting MOPAC in C? As you say, there are no longer any fundamental differences between the performance of C and Fortran, so performance considerations are not a good rationale for moving from one language to another, in either direction. Fortran 90 has pointers and the C99 standard has Fortran-array-like restricted pointers, so the basic operational capabilities of the two languages have been steadily converging. It would be a lot of work without an obvious benefit.
For reference, there is a much older f2c'ed version of MOPAC available if you really want to tinker with MOPAC as C code. Also, there is a bare-bones modern C++ implementation of many of the semiempirical models (AM1, RM1, PM3, PM6) from MOPAC in Sparrow, so they too are independently C-accessible to some degree.
More generally, MOPAC is a very old codebase that has largely been developed by accretion with some limited refactoring such as the addition of dynamic memory allocation and a switch from Fortran 77 to Fortran 90 coding style in the early 2000s. It was always driven by constant short-term considerations of feature deployment and usability and never really had an overarching design plan. So far, the main goal of open-source MOPAC development is to make the code easier to maintain and adapt to new hardware and to make it more accessible to people through new interfaces, over new distribution channels, and with better documentation of features and use cases. Major new features or broad redesigns/rewrites are not part of the core development plan right now. However, MOPAC is now an open-source project, so developers are welcome to contribute major new features or overhaul the code as they see fit. As long as existing functionality is maintained and contributions add some kind of value, such developments will be welcome into the main branch of the code.