[OT] Maximum performance on single processor ?

Marc Baaden baaden at smplinux.de
Fri Jun 20 13:43:27 EDT 2003

Hi again,

first thanks for all the helpful (though a bit discouraging) comments.

Firstly I should probably say that the factor of 1000 was what we'd ideally
need to be absolutely sure about the feasability. Maybe a factor 10-20 is
sufficient, maybe less.

Then, just out of pure curiosity, I'd still like to know what kind of
speedup by investment I could get for 20k$, let's say eg with respect to
the Athlon MB 2600 and which are currently the fastest processors in this
pricerange. I think someone "estimated" a factor of 4-5 for a Power4+, is
that right ?

landman at scalableinformatics.com said:
>>  As it does not appear that you have profiled the code (just a guess),

Half-right half-wrong guess. I have very rapidly profiled the code, just
confirming what I already guessed, that the bottleneck (> 80% of the time)
is the energy calculation subroutine, which calculates pairwise interactions
between atoms in the system.
There are indeed potential speedup factors in this code, like
- introduction of a neighbour list
- parallelization
.. or maybe the use of a specialized board (MD-GRAPE) for just these 

Unfortunately I currently do lack the competence for parallelization or other
optimizations (probably trying to use SSE2 code would be even better), and
part of the more specialized methods seems like a complicated and particularly
short-lived business.

hahn at physics.mcmaster.ca said:
>> do you mean you want uniprocessors? you also need to characterize the
>> code MUCH better in order to  choose a machine.  for instance, power*
>> and itanium chips are  both very fast for some kinds of FP code, but
>> miserable for  integer-dominated code. 

We do use floating-point code.

hahn at physics.mcmaster.ca said:
>> have you actually done paper calculations to see whether the
>> performance you observe is sensible/expected?  ie, that you're not
>> triggering some  pathological behavior, even bugs?

Yes. The code is tested (> 10 years). But we know it has not been developed
with speed in mind (my contest for the understatement of the year)

>>  have you done the
>> high-resolution measuring to know whether your user inputs are
>> actually arriving without being blocked (for instance, on 20ms
>> scheduler ticks)? 

I have measured the calculation separately for now. Not even doing the user
part. But I do have an alternative program which already does run. So I know
that the method in itself is working. It is just the calculation module which
is in Fortran that is not yet adapted.

hahn at physics.mcmaster.ca said:
>>  an athlon MP 2600+)
>> a quite poor architecture for today; it was competitive a year ago.

oops, we must have been very ill advised then, because the machine is just a 
month old, and was the "top" model from our vendor. Or is there such a gap
between the US and the European market ?

mikee at mikee.ath.cx said:
>> Can the lisp technique of memoization help with your processing? 

Sorry, I don't know about this. What is it about ?

beowulf-request at scyld.com said:
>> Also, you should consider how the code is written - if you are
>> manipulating large arrays then the order of access, and the stride
>> length can make a big difference. You may be ranging all over a huge
>> array, pulling things in from memory(*) when a different algorithm/
>> different loop arrangement could keep things in cache.

So - if I interpret your and other people's statements right - depending on
the code, memory might be as important/critical as CPU power ?
Is there a way to check on what the code depends most ?

>> And Fortran,
>> being 'closer to the machine' can expose these things (I may be
>> wrong).

I don't see how (but I am not very experienced in this), any more direct ideas  ?

>> Have you looked at books like: "High Performance Computing"
>> http://www.oreilly.com/catalog/hpc2/

No, not yet. I will definitely need some guidance into how to best optimize the

beowulf-request at scyld.com said:
>> (*) Sorry to teach my granny to suck eggs, but your machine isn't
>> going into swap I trust. 

I was about to say no it is not .. but I shall give it a serious check.

johnb at quadrics.com said:
>> If it looks like it would be a major project, you could get a summer
>> student to get on with doing it whilst the rest of the folks are doing
>> the other stuff.

It is (going to be) a major project. I would love having a summer student
doing the job, but I certainly haven't been able to get hold of someone
with the corresponding competences. (Also, in general the people I met who might
be competent, did not program in Fortran :)) )

rgb at phy.duke.edu said:
>> From this description, the ONLY thing you should be working on is
>> rewriting the code from scratch, doing a serious job of algorithm
>> analysis, optimization, vectorization, parallelization, and (IMHO) not
>> in fortran.

>> If it is graphics/visualization, consider studying things like
>> computer games, render farms, openGL, and various libraries and
>> hardware devices that can move the work required into custom
>> processors.  It could be that you are using Fortran to do various data
>> transformations in poorly written software that are now done extremely
>> rapidly in highly specialized hardware (not even on a "CPU" -- on an
>> offboard coprocessor with its own memory and instruction set).  Or
>> not.

These are all excellent remarks. But I do totally lack competence or knowledge
in these fields, and it seems extremely difficult/dangerous to me to make the
right choices in this context or to get an overview of what the best ways are
to optimize the code/algorithm.
Also I do not (yet) know the fortran code very well, as I am not developing/
maintaining it, and this does not really help in making those choices.

Well, if you are still with me, then thanks for reading through all this.

  Marc Baaden

 Dr. Marc Baaden  - Institut de Biologie Physico-Chimique, Paris
 mailto:baaden at smplinux.de      -      http://www.marc-baaden.de
 FAX: +49 697912 39550  -  Tel: +33 15841 5176 ou +33 609 843217

Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

More information about the Beowulf mailing list