Just finished pulling my code from the repository. Edited my Makefile (for C Activation, not Topographica) to use cc (Cray's C compiler) instead of gcc. Compiling failed at first complaining about some mpi stuff but suddenly started working (I didn't get how I fixed it, but whatever). Time to make a first run!
Side note: it actually feels pretty cool to have 3 terminal windows all ssh'ed into different supercomputers, one of which being UK national service :P
Submitted my job. 1 core on one processor with a small density size, just to check if it works. Wasn't sure which budget to use, so decided to go with the one we used for our msc practicals (it's the only one I know anyway). Job submitted ok and just finished running. Error. Why does everything that has to do with programming never seems to work the first time you run it? "I don't know, said Hector, but you're..."
Attempting to use an MPI routine before initializing MPICH
I'm just grateful it attempted to run my script and there were no problems with the budget. Ok, how the hell do I initialise MPICH?
Tried loading xt-mpich2/5.1.4 module, it conflicted with xt-mpi, so I had to unload it. What is mpt anyway? What's really bothering me (after googling up the problem) is that probably the error is due to the fact that I compiled the code with a set of libraries different from the ones used for running my code. I wonder why. I used cc (default compiler on Cray) and now using default MPI libraries and that just doesn't seem to work.
I looked up my PD and AT notes: we did use Hector for exercises, but it was for co-arrays and UPC. Couldn't find anything on MPI. Voodoo-ing again...
[update] I got it! So ridiculous... Basically, I was calling MPI_Wtime() before MPI_Init() and after MPI_Finalize. While openmpi allows doing it, mpich seems not to. Glad I've solved it.
And here's the result of tonight's effort (using 1 to 24 cores of one node, i.e. full SMP):
The speed-ups and parallel efficiency values for dot-product are (I'll improve my plotting script to display speed-ups soon):
2 cores: x1.99 (E=0.99)
4 cores: x3.91 (E=0.9775)
8 cores: x6.40 (E=0.8)
16 cores: x11.87 (E=0.74)
24 cores: x20.94 (E=0.87) <- seems to be hitting the cache, or at least close to
Well done for getting things running on hector. (I wonder why you get such huge delays starting even 30 second jobs on eddie? I admit I haven't used eddie for a while, but I never experienced anything that bad unless I ran a lot of simulations.)
ReplyDeleteI don't know what the important differences between hector and jupiter are, and you don't have a title on the graph above (I can't tell what densities you were using), and the colours seem to have changed again :), but I tried to compare the graph above to the last graph on the post "Graphs (Jupiter)" (http://hyper-graphica.blogspot.com/2011/07/graphs-jupiter.html).
For the jupiter graph, sizes 2 and 3 (not shared memory) look like about x2.0 and x2.9, respectively (by eye!). Sizes 4 and 8 (mixed shared and not shared memory) look like about x3.3 and x5.2, respectively. So I guess this means hector has some better memory sharing system?
I guess non shared memory results from hector are next? Do you still plan to try to get results from eddie, or are you giving up on it? From a selfish and practical point of view, I'm more interested in eddie (which I can use, and which sounds like the kind of system more people would have access to) than hector.
Chris