Photoshop and PC with Dual Processors

Blue Apricot wrote:

Are there versions of Photoshop for PCs running XP that take advantage of dual processors? If yes, at what version did this start happening?

Version 6, if not earlier, I think. Look in Adobe\Adobe Photoshop CS2\Plug-Ins\Extensions (or as appropriate) and see "MultiProcessor Support.8BX" exists.

Andrew

On 3 Oct 2006 09:17:11 -0700, "Blue Apricot"
wrote:

Are there versions of Photoshop for PCs running XP that take advantage of dual processors? If yes, at what version did this start happening? (I am assuming once the code was put in place, all versions afterward had it, but maybe this is wrong?)

I just bought an AMD Athlon 64 X2 Dual-Core 3800+ with 2 gigs of RAM, and want to make sure I get the version of Photoshop that is optimized for my new setup, if such a version exists. (Maybe "Symmetrical Multi Processing" code, or whatever it is called, is for MACs only at this point?)

Thanks,
Blue Apricot

You will find that the dual-core processors don’t need the software to be "multiple processor" coded to benefit the software. A multi-core processor of AMD’s design allows the cores to communicate with one another directly. They automatically share the load. In a true multi-processor system the software’s code had to be written for that software to direct tasks to be shared between the processors. To reiterate, that is not needed with AMD’s dual-core’s.

—
FredEx

You will find that the dual-core processors don’t need the software to be "multiple processor" coded to benefit the software. A multi-core processor of AMD’s design allows the cores to communicate with one another directly. They automatically share the load. In a true multi-processor system the software’s code had to be written for that software to direct tasks to be shared between the processors. To reiterate, that is not needed with AMD’s dual-core’s.

What evidence is this argument based on?

Just because the cores of a CPU are linked via a high speed communications channel doesn’t mean they suddenly get the ability to "share the load". The load needs to be spilt by the software and defined such that the OS can distribute it to available resources. The software will need to be multithreaded and have all the usual (and complex) inter process communications, deadlock avoidance, thread joining and other such stuff.

If AMD have solved these problems such that a single threaded application can distribute itself across processing core, I’d like to read about it.

FredEx wrote:

You will find that the dual-core processors don’t need the software to be "multiple processor" coded to benefit the software.

This I know to be true, because there are many OS processes and even other applications running that can be used by one core while the other core can handle Photoshop, for instance. So yes, there is a benefit in overall computer performance two dual-cores (in an OS like XP Pro that supports it) even if a specific app isn’t designed to take advantage.

Derek Fountain wrote:

If AMD have solved these problems such that a single threaded application can distribute itself across processing core, I’d like to read about it.

I am sure this is not what he meant, I think he meant what I addressed above. There is no doubt that to really take advantage of dual-core processors in a single app, it has to be coded to do so, which is the vast minority of applications. I had read that Photoshop WAS coded in this multi-threaded manner, hence my original question.

— Blue Apricot

On Wed, 04 Oct 2006 09:52:24 +0100, Derek Fountain
wrote:

You will find that the dual-core processors don’t need the software to be "multiple processor" coded to benefit the software. A multi-core processor of AMD’s design allows the cores to communicate with one another directly. They automatically share the load. In a true multi-processor system the software’s code had to be written for that software to direct tasks to be shared between the processors. To reiterate, that is not needed with AMD’s dual-core’s.

What evidence is this argument based on?

Just because the cores of a CPU are linked via a high speed communications channel doesn’t mean they suddenly get the ability to "share the load". The load needs to be spilt by the software and defined such that the OS can distribute it to available resources. The software will need to be multithreaded and have all the usual (and complex) inter process communications, deadlock avoidance, thread joining and other such stuff.

If AMD have solved these problems such that a single threaded application can distribute itself across processing core, I’d like to read about it.

Google is your friend.

—
FredEx

On Wed, 04 Oct 2006 09:52:24 +0100, Derek Fountain
wrote:

You will find that the dual-core processors don’t need the software to be "multiple processor" coded to benefit the software. A multi-core processor of AMD’s design allows the cores to communicate with one another directly. They automatically share the load. In a true multi-processor system the software’s code had to be written for that software to direct tasks to be shared between the processors. To reiterate, that is not needed with AMD’s dual-core’s.

What evidence is this argument based on?

Just because the cores of a CPU are linked via a high speed communications channel doesn’t mean they suddenly get the ability to "share the load". The load needs to be spilt by the software and defined such that the OS can distribute it to available resources. The software will need to be multithreaded and have all the usual (and complex) inter process communications, deadlock avoidance, thread joining and other such stuff.

If AMD have solved these problems such that a single threaded application can distribute itself across processing core, I’d like to read about it.

I forgot to say, that is the big advantage of the dual-cores. AMD’s dual-core were designed to automatically share the processing load, the Intel’s with the newer Core-Duo. Intel’s first multiple core design worked little different than having two processors.

As I stated in my other message, "Google is your friend." That is not meant as a SA remark, there is much to read about the matter.

—
FredEx

I forgot to say, that is the big advantage of the dual-cores. AMD’s dual-core were designed to automatically share the processing load,

You’re wrong. That’s not what dual cores are about. They are multiple CPUs on a single die connected via a fast comms channel. They don’t "share the processing load" without application and OS scheduler support.

This I know to be true, because there are many OS processes and even other applications running that can be used by one core while the other core can handle Photoshop, for instance. So yes, there is a benefit in overall computer performance two dual-cores (in an OS like XP Pro that supports it) even if a specific app isn’t designed to take advantage.

Agreed, but that doesn’t actually make Photoshop operations run faster, it just reduces the latency Photoshop experiences in getting CPU resources.

above. There is no doubt that to really take advantage of dual-core processors in a single app, it has to be coded to do so, which is the vast minority of applications. I had read that Photoshop WAS coded in this multi-threaded manner, hence my original question.

To some extent I believe Photoshop has been converted to a multithreaded application, but there doesn’t seem to be much hard information on the subject out there.

It’s harder to split a lot of image processing tasks than many other types of tasks. Take a blur for example – one CPU does the top half of the image, the other does the bottom half. The work gets done in half the time – woohoo! Only then you’d get a line across the middle of the resultant image where each CPU has been unable to see neighbouring image data. I think that’s the problem – a lot of image processing operations are linear, often top to bottom, and very often require processed neighbouring pixels as part of their input. It’s hard to break those operations up into multiple threads.

"Derek Fountain" wrote in message

[re multi-threaded imaging]

It’s harder to split a lot of image processing tasks than many other types of tasks. Take a blur for example – one CPU does the top half of the image, the other does the bottom half. The work gets done in half the time – woohoo! Only then you’d get a line across the middle of the resultant image where each CPU has been unable to see neighbouring image data. I think that’s the problem – a lot of image processing operations are linear, often top to bottom, and very often require processed neighbouring pixels as part of their input. It’s hard to break those operations up into multiple threads.

Photoshop uses a tile based architecture that lends itself well to multi-processing. Each cpu accesses and modifies a rectangular section of image data, with input and output maintained separately. This allows multiple processors to split up the work without running into an exponential communication overhead as the number of processors is increased. —
Mike Russell
www.curvemeister.com/forum/

Photoshop uses a tile based architecture that lends itself well to multi-processing. Each cpu accesses and modifies a rectangular section of image data, with input and output maintained separately. This allows multiple processors to split up the work without running into an exponential communication overhead as the number of processors is increased.

That’s how the GIMP works too. But how does it handle the requirement for data, or worse, intermediate processing results, that are in a different tile? I was thinking of, say, motion blur, where the results in one tile are heavily dependent on what’s in another potentially distant tile.

There must be some seriously optimised pixel shifting between CPUs, and carefully implemented algorithms that appreciate that what they’re doing on each tile is part of the whole, not a discrete piece of work. Or, just possibly, they copped out and made the hard stuff single threaded.

I’ve never yet found a document that describes exactly what has been written as multi threaded. Know you of any such sources?

"Derek Fountain" wrote in message
[re tiles, Photoshop, and multiple processors]

That’s how the GIMP works too. But how does it handle the requirement for data, or worse, intermediate processing results, that are in a different tile? I was thinking of, say, motion blur, where the results in one tile are heavily dependent on what’s in another potentially distant tile.

Each processor gathers the necessary tile data adjacent to the tile it is processing. This is the advantage of tile basedover scan line based processing .

There must be some seriously optimised pixel shifting between CPUs, and carefully implemented algorithms that appreciate that what they’re doing on each tile is part of the whole, not a discrete piece of work.

In general, input tiles are kept distinct from output tiles, as well as tiles in each step of a pipelined operation, for example a blur that is followed by another operation. Photoshop may do all or part of this.

Or, just possibly, they copped out and made the hard stuff single threaded.

Yes, and there are a lot of single threaded corners in Photoshop. For example, all plugins are single threaded, because Adobe’s API does not support multi-threaded plugins, and tiles cannot be accessed in a multi-threaded fashion.

I’ve never yet found a document that describes exactly what has been written as multi threaded. Know you of any such sources?

No – Adobe is very quiet about the internals of Photoshop, however I am familiar with libpixar, on which version 1 of Photoshop was based. I bet a nickel that Adobe, and others, have borrowed heavily as well from the Pixar Image Computer, which used tiles in a SIMD architecture that is well documented in SIGGRAPH and other publications.

BTW – your earlier point about hardware not automatically bestowing multi processor capability on a program is correct. Although separate processes in the OS can run concurrently, tasks within a single program require special handling at the application level to get maximum benefit from multiple processors.
—
Mike Russell
www.curvemeister.com/forum/

On Fri, 06 Oct 2006 09:19:09 +0100, Derek Fountain
wrote:

I forgot to say, that is the big advantage of the dual-cores. AMD’s dual-core were designed to automatically share the processing load,

You’re wrong. That’s not what dual cores are about. They are multiple CPUs on a single die connected via a fast comms channel. They don’t "share the processing load" without application and OS scheduler support.

Okay, I found where SMP does help. Where there was confusion on my part and with some things written I’d read is that the AMD’s in testing were doing better at sharing system tasks, not single program tasks, which is where SMP comes in. In other words, they were seemingly getting things done faster when one was multi-tasking than when compared to a dual processor system. Perhaps due to the separate bus issue and slower communication between the processors compared to AMD’s dual cores. Other things I just read say it makes no difference, but they had no test results to back that statement.

—
Boo Boo

On Fri, 06 Oct 2006 11:07:38 -0400, Boo Boo

wrote:

On Fri, 06 Oct 2006 09:19:09 +0100, Derek Fountain
wrote:

I forgot to say, that is the big advantage of the dual-cores. AMD’s dual-core were designed to automatically share the processing load,

You’re wrong. That’s not what dual cores are about. They are multiple CPUs on a single die connected via a fast comms channel. They don’t "share the processing load" without application and OS scheduler support.

Okay, I found where SMP does help. Where there was confusion on my part and with some things written I’d read is that the AMD’s in testing were doing better at sharing system tasks, not single program tasks, which is where SMP comes in. In other words, they were seemingly getting things done faster when one was multi-tasking than when compared to a dual processor system. Perhaps due to the separate bus issue and slower communication between the processors compared to AMD’s dual cores. Other things I just read say it makes no difference, but they had no test results to back that statement.

Forgot to change my ID.

—
FredEx