I was holding off responding to see if someone else could give you a better response than I could, but I suppose I can tell you what I know at least. :P

AFAIK, FLOPS doesn't work like that. :P

Calculating the maximum FLOPS of anything is going to depend on factors that are difficult to know, including the width of the internal circuit pathways, the amount of instructions needed to push floating point data through the CPU, and then, even if you DO figure the number out, it has nothing to do with INTEGER math, or CPU ops in general, and without knowing those you wouldn't be able to paint an overall picture of the CPU's capabilities.

You say your professor wants you to explain how to calculate system speed. OK, but that's a MASSIVELY wide topic. What speed are you calculating? Relative to what? What kind of representitive number should the final result be?

This is what's confusing since FLOPS and CPU Speed are two very different things. Also, that Wikipedia equation you pulled actually has FLOPS per Cycle in the equation, so you still need to know at least THAT much to use it. :P

No, he's roughly right.

The FLOPS/cycle at the end is the key and supposes that you know that number already (you do).

The rest is basically a fancy way of saying "Multiply the FLOPS of one core by the number of cores".

And you're almost never going to get an exact real-world number for it in a real system because of things like memory latency, etc. but that's not really important. I'm pretty sure what his prof is asking for is a theoretical assessment of what peak GFLOPS would be in an ideal world. You're never going to hit this number because of things like time spent on disk IO, message passing between nodes in your cluster, network latency, etc. The actual number is meaningless in a real-world sense. It just gives you a theoretical max - an estimation, so you can start talking about and comparing performance in some useful way.

Modern CPUs using SSE do ~4 floating point ops per cycle, so you'd basically just multiply the clock speed by four, then multiply by the number of cores in the cluster.

Ex. I just built a cluster with one chassis, four nodes per chassis, two sockets per node, six cores per socket @ 2.3GHz per core, so a total of 441.6 GFLOPS. It also runs 105.6 GFLOPS on the head node (different configuration, favours more and faster memory w/ quad-core CPUs) which can do computations as well, so a total of 547.2 GFLOPS.

Again, it's an estimation of the theoretical peak, not a real-world number.

I see, i also had a similar thought on it. I know its more complex than just dumping a number.

Thanks a lot for the reply and Gecko for the clarification of link between SSE ## and cycle rates. That cleared some things to me.
I think she meant overall measurement in FLOPS, but i might get extra credit if i present what can influence it in detail.
I am also doing a short presentation for which i chose the Amiga computer.

Another way to get more a real world estimate of what your cluster is capable of is running a benchmarking program.

I think LINPACK is commonly used in compute clusters to measure this.

I see. Well, what im aiming at is a more technical approach.
Component wise. Clock cycles, frequency, bus speed, etc.

I have wrote what I've learned here and will google with this info too.