Is there consumer s/w available now that uses multi-core CPUs?

John Doe wrote:
RayLopez99 wrote:

Yes wrote:

Maybe OT, but given the thread about future CPUs, is there
consumer software now that actually uses the multi-core
CPU technology? I mean, all the additional cores sounds
nice, but has any consumer s/w caught up with the
hardware?

One game that does multi-threading (multi-core) is computer
chess playing.

There are plenty of others.

But as Paul says, the applications are thin.

True or not, that would be irrelevant to the benefit of
multicore CPUs. In fact, modern PCs usually have hundreds of
processes and thousands of threads running at the same time.

What part of that is difficult understand?

I think a bigger benefit of multi-cores is that you can run
several apps simultaneously.

Yeah, or hundreds of processes and thousands of threads like
with a typical modern PC. You are supposed to be a
programmer?

At some point he's right.

Cinebench is an example of an "infinitely" scaling
application. It uses as many cores as you give it,
and attempts to benchmark performance with them. However,
this does not reflect the realities of real applications.

Cinebench would be closest to your view of how it works.

Real applications stop scaling at some point. You can
certainly program multiple cores, but that doesn't mean
you get a benefit. And the software developer has to
code to take this into account. For example, Microsoft
FSX uses "up to N cores", where N really isnlt a large
number, and that's because the processes forked on the
fly, there's only a limited number of things they can
do that way, and get parallelism. For example, there's
a lookahead process, which reads in terrain data, in
the direction you're flying. Could you split that into
two processes ? Could one process read the left-hand
terrain data, and another read the right-hand terrain
data. That sounds like a horrible idea. It could
cause thrashing on the hard drive.

Take for example, a movie renderer that runs out of
steam at 8 cores. In other words, if they use more
cores, little extra output is produced. If you have a
26 core CPU, then it's in your best interest to
render three 8-core movie jobs, to get the best
usage from the CPU.

Take Photoshop as another example. It uses divide-and-conquer
for some of the filters. For example, it splits an image
into four pieces, one core works on each piece. Then a final
step is "stitching" that happens along the borders of each
chunk before the final composition is formed. It's easy
to see at first, that dividing into four pieces makes sense.
Now, if I divided in 24 pieces and did a whole bunch of
stitching with a single core at the end, am I still winning ?
These are things the developers have to benchmark, and decide
at what point doing more dividing, isn't delivering more
performance, or perhaps is compromising the image quality.

For some of the incoming AMD processing products, it's
quite likely that multiple applications will need to run
on them, to get value. Because, as it turns out, the L3
cache is not unified over the entire processing complex,
and the CPU behaves as a "cluster", rather than as a
single CPU. The definition of whether it's one or
another architecture, is determined by the cache latency - if
you get to a point where main memory (L4) is faster than
L3, then the L3 is no longer as significant as a performance
enhancement. And this might cause you to alter the way
you run stuff on it. Rather than their largest chip
offering 64MB of L3 cache, it offers "8x8MB" of L3 cache.
And what that means is, mechanically it's still wired
as 64MB, but if you notice a particular benchmark isn't
running well on it, it can be explained by the link
latency between chunks.

And then the user modifies their usage behavior, to
get the best results from what they bought. It's an
empirical process. You test and see. If the hardware
hides the fact that certain partitions exist, you
don't have to worry. If a thing you do isn't running
well, then you have to take steps to fix it.

As an example, there was a piece of software which
was mistaking virtual cores as physical cores. And to
get the best behavior from it, the users were turning
off hyperthreading. The users noticed a problem, and
took steps to deal with it. They could also have
used affinity controls or affinity applications, to
have more granular control. And the trick in some cases,
is figuring out which tick box belongs to which physical
core. The application developer could fix it properly,
but in lieu of that, the users took action on their end.

Paul