imagine how much faster F@H would be in FORTRAN...

[7im]

I'd like some real evidence with relevance to Gromacs, not some random generic comparison of languages without any ties to FAH or to the computations used in FAH.

What further evidence do you need to stop proselytizing about FORTRAN when the Gromacs FAQ says their assembly loops are even faster than FORTRAN in the link I provided?

[alpha754293]

What further evidence do you need to stop proselytizing about FORTRAN when the Gromacs FAQ says their assembly loops are even faster than FORTRAN in the link I provided?

That's fine and dandy. What about everything else? Surely the assembly loops are the only thing that computationally intensive with the GROMACS core, considering the list of open projects they still have via their wiki.

[7im]

If FORTRAN did offer greater performance, but it would be too large of a job to port for a resource limited open source group, then I'm sure the Gromacs people would be aware of that option, and would have some idea of the potential increase in performance (if there was any at all). Why don't you contact then and ask if any potential does exist? If yes, we can start a crusade to drum up programmers to aid with the project. If no, we can finally drop this discussion.

[alpha754293]

If FORTRAN did offer greater performance, but it would be too large of a job to port for a resource limited open source group, then I'm sure the Gromacs people would be aware of that option, and would have some idea of the potential increase in performance (if there was any at all). Why don't you contact then and ask if any potential does exist? If yes, we can start a crusade to drum up programmers to aid with the project. If no, we can finally drop this discussion.

geez...lighten up will ya? must you always piss on my threads?

quote:
"ANSI C compiler, and possibly Fortran. GROMACS can be compiled entirely in C, which means you should be able to get it running on essentially any UNIX-style computer in the world. However, we also provide the innermost loops in Fortran to improve performance, so we strongly recommend you to use a Fortran compiler if you can - it makes a huge difference! For modern Intel and AMD processors we provide even faster assembly loops though, so for those you can skip Fortran."

x86/x64, assembly.
Everything else, Fortran.

Source: http://www.gromacs.org/content/view/23/33/

quote:
"On any system apart from Linux/x86 (where we use assembly innerloops) you should also try to use a fortran compiler for better performance, and if you run Linux/alpha you should use the Compaq compilers instead of gcc."

Source: https://nf.nci.org.au/facilities/softwa ... mxfaq.html

quote:
"C and Fortran. The only Fortran code is the inner loops (innerf.f). The inner loops typically account for more than 95% of the runtime, so all the computationally intensive parts use Fortran."

Source: http://www.spec.org/cpu2006/Docs/435.gromacs.html

*edit*
quote:
"Yet the fortran version is always faster, except when using g77 on Linux/x86 (and other platforms probably)."

Source: http://www.ccl.net/chemistry/resources/ ... index.html

[7im]

I think the last quote has our answer... Fortran is always faster, with an exception (the hand optimized non-fortran loops in Linux/x86, which is what fah uses).

The GROMACS MD code (http://md.chem.rug.nl/~gmx) which was developed by me and others in the Berendsen group, contains code in fortran and C that is identical. Yet the fortran version is always faster, except when using F77 on Linux/x86 (and other platforms probably).

geez...lighten up will ya? must you always piss on my threads?

Don't worry, this is the last time I'll offer you any assistance.

[alpha754293]

I think the last quote has our answer... Fortran is always faster, with an exception (the hand optimized non-fortran loops in Linux/x86, which is what fah uses).

The GROMACS MD code (http://md.chem.rug.nl/~gmx) which was developed by me and others in the Berendsen group, contains code in fortran and C that is identical. Yet the fortran version is always faster, except when using F77 on Linux/x86 (and other platforms probably).

geez...lighten up will ya? must you always piss on my threads?

Don't worry, this is the last time I'll offer you any assistance.

When have you EVER offered assistance? I don't see how any of your replies in this thread is assisting at all.

Ask yourself this - why would all other platforms be using Fortran, and not assembly?

If the hand-optimized assembly method works for x86 and is faster than using Fortran, why wouldn't they do that for all of the other platforms?

[kasson]

They do for a wide variety of platforms. Intel and AMD platforms currently form the primary base that Gromacs targets (though it runs on a large number of platforms), in part because the majority of high-performance systems currently employ those architectures (c.f. current top500). Other optimized code, for example the POWER architecture code, is often contributed by additional developers (frequently ones working with IBM). Fortran is substantially slower than the hand-tuned code. As nice as it would be to believe there is a simple solution to improving speed, such is not the case. It's good that you are reading on this subject, but a number of the documents available understate the complexity of the issues and are often out-of-date (and people have their own reporting biases). Information does not equal knowledge, unfortunately.

[bruce]

I think you missed my point about O(N) vs O(N^N). With CFD, you can create a mesh so that the forces on any node depend on only on the nearby nodes associated with the mesh elements. With MD that's not true. Every atom is a unique body and the forces on it depend on the distance/charge/bound-type/etc. from every other atom in the protein. You have to add up N forces on each atom. There is no "mesh" in the CFD sense.

In macroscopic terms, what are the forces on the earth from the moon, the sun, mars, venus, jupiter, etc. and how do they influence the motion of earth in free space? Maybe you need to include the solar wind, too, since we're not in a pure vacuum, but only then would you consider a CFD type mesh or some other method of describing the solvent.

[alpha754293]

I think you missed my point about O(N) vs O(N^N). With CFD, you can create a mesh so that the forces on any node depend on only on the nearby nodes associated with the mesh elements. With MD that's not true. Every atom is a unique body and the forces on it depend on the distance/charge/bound-type/etc. from every other atom in the protein. You have to add up N forces on each atom. There is no "mesh" in the CFD sense.

In macroscopic terms, what are the forces on the earth from the moon, the sun, mars, venus, jupiter, etc. and how do they influence the motion of earth in free space? Maybe you need to include the solar wind, too, since we're not in a pure vacuum, but only then would you consider a CFD type mesh or some other method of describing the solvent.

I haven't gotten that far or that deep in regards to how GROMACS actually treats the grid, whether it is an actual grid in the traditional sense or whether it's just some kind of discretized space (structured or not).

I would presume that there would be some kind of discretization because otherwise, I don't think that parallelization would have been possible. My guess (and this is really a guess here) is that they're able to decompose/deconstruct the protein that they're working on into multiple subsections and then the data is passed between partitions, otherwise the calculations performed within the partitions more or less stay with in.

I don't know.

I also think that hand-tuned ANYTHING (regardless of language) will always be faster than non-hand-tune code. WIth that being said, whether the tests were done with hand-tuned FORTRAN or not, I don't know, but consider that all other GROMACS platforms uses FORTRAN; in some regards it strikes me as odd that they would do that.

While I would agree with anybody who comes along and says that x86/x64 (Linux or otherwise, but mostly Linux) constitutes the greater majority of the user, I wouldn't argue about that. But considering that there's documentation about running GROMACS on BlueGene and GROMACS on Alpha, and both of those uses FORTRAN for the innermost loops; I am in some ways surprised that they would use Assembly for x86/x64.

I just don't see why they would want to keep two versions of the program. For speed and catering to the bulk majority of commodity hardware users, sure, ok. But I wouldn't be surprised if they're going to be phasing out some of the others because of limited resources to maintain a FORTRAN core version and an assembly core version. *shrug* I don't know.

I think that if it were up to, I'd keep it either as all Fortran or all assembly, rather than a mix. Especially knowing that Fortran is available for all platforms, that would probably win my vote. But again, I've never looked deeply into the GROMACS code and core, and I'm certainly not a molecular biologist or programmer by any stretch of the imagination.

Very interesting...

Here's something that I just found:

"Instead, GROMACS computes forces upon each atom from other atoms within a certain cut-off radius. Long-range forces are calculated using particle-mesh methods."

Source: http://www.cs.unc.edu/~olivier/pdsec07.pdf

So looks like that there is some sort of spatial discretization.