In article , Mayayana
wrote:

| second of all, you haven't any clue about multithreading. zero.

Multi-threading is not the issue.

yes it is.

https://en.wikipedia.org/wiki/Multit...%28software%29

A single core CPU has multithreading via
time slices. The advantage of multi-core is
that a single, intensive operation can have
a dedicated core, without locking up the
machine and without needing to share time
slices.

or a single intensive operation can be parallelized across multiple
cores.

The issue is whether PS can actually
use multiple cores in any significant way.

it can, and does.

For
that it needs to be running two or more processor
-intensive operations concurrently. Do you often
run a sharpening routine on a 40 MB image while
at the same time running another filter? If not
then the sharpening will run faster with less cores
because the core being used will have a higher
MHz speed.

you still don't get it.

one filter can be multithreaded, running in parallel on multiple cores.

you don't need to run two filters in parallel, nor do cores speed up or
slow down if one or more is idle.

No one needs to go by what I'm saying.

nobody should, since you have *no* clue.

In
Windows one can run Task Manager to see usage
in real time. There may be something similar on
Macs. So rather than carpet-bombing the thread
with empty, un-qualified pronouncements and
insults, why not do some experimenting for
yourself? You can then decide what's best for
you. Maybe you'll find that PS is somehow running
your sharpening routine on 2 cores, but that's *very*
unlikely.

wrong.

not only is it likely, but photoshop is designed to do exactly that:
http://media.bestofmicro.com/F/L/251985/original/res_app_photoshop.png

and it's not just photoshop that benefits. many things are faster on
multicore, including handbrake video conversion:
http://media.bestofmicro.com/F/G/251980/original/res_app_handbrake.png

The routine is a single operation that needs
to go through the image bytes with a math operation.
There just aren't two things to do at once.

wrong.

if the operation can be parallelized, then it will usually benefit from
multiple cores unless it's bottlenecked with i/o, such as a slow hard
drive.


Much of the time there's very little CPU
usage on a typical machine. If I do something like
run a CPU-demanding script then I'll see 48-50%
usage by that process, because I'm using a 2-core
machine. Meanwhile, nothing much else is registering.
If I had four cores the script would run at about
half the speed, because it can't be run across 2
threads.

nonsense.

For that the script would have to be
running multiple, separate operations. Likewise
with PS. A sharpening routine is a single operation.
You can't spread it across 2 threads or processes.

wrong.

If you print and go online and have AV scanning
while you're doing the sharpening routine then the
4 cores might be better than 2. But what I'm getting
at is that much of the time, for most people, only
one CPU-demanding operation at a time is happening.

wrong.

An analogy.... Not a great one, but the best I
can think of right now:

Imagine having a set of measuring cups. If you
have 3 people adding 6 ingredients to a bowl, in
small amounts, they can do it fastest with 6 cups.
If they need to each add, say, 1/4 cup sugar and
1 cup flour to bowls on an assembly line, having
6 8-oz measuring cups will be optimal. But if there's
one person, adding 4 cups flour and 2 cups water,
then 2 32-oz measuring cups will be optimal. (A 32
and a 16 would be best, but I'm trying to keep
this analogous to CPU cores.)

If that one person has 6 8-0z cups then 4 will just
go unused while 2 do the job more slowly. An 8-oz
cup has to be refilled 4 times with each operation.

that's a horrible and convoluted analogy.

a simple and far better analogy is if you have a stack of pages and you
need to stamp each one with the date it's received.

you can either stamp all pages yourself (single-core) or you can spread
the work among a bunch of people, each having to stamp a portion of the
pages, all working alongside each other (multi-core).

there's a small overhead in splitting the stack into several smaller
stacks, distributing those stacks to each person and then reassembling
them at the end, which needs to be balanced with how much faster the
overall process would take.

for a small stack of 10 pages, it is not worth the trouble to split it
among 10 people, but splitting it among 2 people might work well.

for a large stack of 1000 pages, splitting it among 10 people will
definitely help, as the overhead is minimal compared to the actual
task.

Since CPU speeds seem to have plateaued in the
3-4 GHz range, there's a limit to the possible speed
of one core. So the question becomes: Do you have
3 people to use your 6 cups? (Do you actually have
frequent, concurrent operations to justify more cores?)
If not then you'll fill your bowls fastest with less cores.

certain tasks may not benefit from additional cores, but having more
cores on a chip does not make things go slower.