[OT] Maximum performance on single processor ?

[Marc Baaden]

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 
calculations.

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
code.


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.
Cheers,

  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