[Tfug] CPU Query

[Jeremy D Rogers]

> I wrote all the code, so I know exactly what it's doing (OK, so I didn't
> write the SVD package, but that's from one of the optimized libraries).
> I/O has all been optimized such that so you read it all in (binary
> unformatted), crunch numbers, and then write it all out.  The "bind" is in
> floating-point operations (mostly matrix manipulations - this is a largish
> inverse problem).  My interest is in whether the OS can take advantage of
> the 2X CPUs without my having to get a compiler (Fortran) that will do
> this.  Either that, or get into the manual "loop unrolling" business,
> which loses me more (in my time) than I would gain.  I want to know if
> paying a little more for a 2X CPU will gain me in throughput without my
> having to do anything other than copy codes over from my current FC3
> system and go.  As a related side issue, I could care less about video
> performance - I work at the command line and could live with this on a TTY
> user interface.

Ah, *real* computing! :-)  I have some very limited experience with
this.. trying to get the most out of a processor with a program
(Matlab) that was single threaded. Fortunately, the next release of
matlab will be multithreaded finally.

My understanding is that processor-wise, AMD is actually better at
floating point in general than intel, although intel xeon's  are very
good and carry the corresponding price tag. If the $50-100 is really
that important, then you should probably look for a single core athlon
XP with big on-die cache. On the other hand, since the upgrade to a
dual core might not actually be that much more in price, it seems a
good way to go since, as mentioned earlier, the worst case is you get
a processor dedicated to the calculation while the other core/cpu
handles OS overhead stuff.

> I have heard that some OS's (distros) will do a sort of load-leveling, but
> I don't know what sort of gain this would provide for a single process.  I
> have doubts about that, and that's why I'm asking.  I certainly don't want
> to find that I pay more for a 2X only to find that my processing runs
> slower than a comparable speed (and cheaper) 1X because I gain nothing
> from the second processor and lose from extra things the OS is doing
> because it knows it has more than one processing path through the CPU.  I
> have seen this sort of thing happen to people trying to parallelize or
> vectorize their codes.  Definitely a YMMV situation (and possible also a
> TANSTAAFL situation RE gain without pain).

If you use an SMP kernel (avail in most distros), you get to use both
processors, and the processor that code is executed on will switch
frequently. It doesn't really take much in the way of resources to do
this, so I wouldn't fret too much over this being a bad thing.

Also, regarding P4's.. I vaguely remember that there was a major issue
with the p4 pipeline (I think it was a problem with the prediction
branching) that made them really really bad for computationally
intensive work. I'm too lazy to look up references right now, so I may
simply be spreading viscous rumors, but I remember hearing that most
athlon, Pentium M, and even pentium III cpus get better floating point
performance. You should look into that before you buy a p4 for math
stuff.

In the end, I think a higher end athlon 64 or athlon XP would work
well for you, but if the difference in cost isn't much, I would
recommend looking at a dual core system.
JDR