<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Intel Inside: what does it mean for Photoshop?</title>
	<atom:link href="http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/feed/" rel="self" type="application/rss+xml" />
	<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/</link>
	<description>The latest news about the top pixel wrangling application on the planet.</description>
	<lastBuildDate>Sat, 28 Jan 2012 03:53:20 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jim Goshorn</title>
		<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/comment-page-1/#comment-572</link>
		<dc:creator>Jim Goshorn</dc:creator>
		<pubDate>Thu, 09 Jun 2005 14:58:50 +0000</pubDate>
		<guid isPermaLink="false">http://photoshopnews.com/?p=439#comment-572</guid>
		<description>Thanks to Jeff and Neil for the great posts.

Is the conscensus that we are not likely to see any production PowerBooks or PowerMacs until some time in 2007?</description>
		<content:encoded><![CDATA[<p>Thanks to Jeff and Neil for the great posts.</p>
<p>Is the conscensus that we are not likely to see any production PowerBooks or PowerMacs until some time in 2007?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daveed Vandevoorde</title>
		<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/comment-page-1/#comment-571</link>
		<dc:creator>Daveed Vandevoorde</dc:creator>
		<pubDate>Wed, 08 Jun 2005 15:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://photoshopnews.com/?p=439#comment-571</guid>
		<description>Note that shrink-wrapped software (like Photoshop) typically dynamically tests for the presence of AltiVec (using the Gestalt manager, for example). I&#039;m guessing that Rosetta does not decide a priori whether an executable (or shared library) uses AltiVec instructions.  Instead, much like executing on a G3, I&#039;m guessing it will raise an &quot;illegal instruction&quot; signal when attempting to execute such an instruction.

That would reduce the AltiVec issue to &quot;just&quot; a performance issue in most cases.</description>
		<content:encoded><![CDATA[<p>Note that shrink-wrapped software (like Photoshop) typically dynamically tests for the presence of AltiVec (using the Gestalt manager, for example). I&#8217;m guessing that Rosetta does not decide a priori whether an executable (or shared library) uses AltiVec instructions.  Instead, much like executing on a G3, I&#8217;m guessing it will raise an &#8220;illegal instruction&#8221; signal when attempting to execute such an instruction.</p>
<p>That would reduce the AltiVec issue to &#8220;just&#8221; a performance issue in most cases.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Schewe</title>
		<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/comment-page-1/#comment-569</link>
		<dc:creator>Jeff Schewe</dc:creator>
		<pubDate>Wed, 08 Jun 2005 08:35:48 +0000</pubDate>
		<guid isPermaLink="false">http://photoshopnews.com/?p=439#comment-569</guid>
		<description>What Neil says. . .

:-)

Nice technical summary. . .it pretty much mirrors what the other engineering types have told me (but with technical explainations that go further than my &quot;simple&quot; explainations).

The only caution is that some highly optimized processing for digital imaging does indeed have dependancies on things like G4 AltiVec or 64 bit routines in the G5. Those vector based optimizations will not run in Rosetta and must be re-written or at the very least re-compiled to Intel instruction set architecture (ISA) such as the MMX, SSE, SSE2, and SSE3 extensions. Not a major thing, but still a thing ya gotta do.

Your point about Intel chips being &quot;faster&quot; is also pretty much in line with people&#039;s opinions who write cross-platform and yes, the OS DOES get in the way a lot.

:-(

But, in general, the Intel Inside of Apple is neutral to positive for Photoshop (once the work that is required gets done).</description>
		<content:encoded><![CDATA[<p>What Neil says. . .</p>
<p> <img src='http://photoshopnews.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>Nice technical summary. . .it pretty much mirrors what the other engineering types have told me (but with technical explainations that go further than my &#8220;simple&#8221; explainations).</p>
<p>The only caution is that some highly optimized processing for digital imaging does indeed have dependancies on things like G4 AltiVec or 64 bit routines in the G5. Those vector based optimizations will not run in Rosetta and must be re-written or at the very least re-compiled to Intel instruction set architecture (ISA) such as the MMX, SSE, SSE2, and SSE3 extensions. Not a major thing, but still a thing ya gotta do.</p>
<p>Your point about Intel chips being &#8220;faster&#8221; is also pretty much in line with people&#8217;s opinions who write cross-platform and yes, the OS DOES get in the way a lot.</p>
<p> <img src='http://photoshopnews.com/wp-includes/images/smilies/icon_sad.gif' alt=':-(' class='wp-smiley' /> </p>
<p>But, in general, the Intel Inside of Apple is neutral to positive for Photoshop (once the work that is required gets done).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Neil Duffin</title>
		<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/comment-page-1/#comment-568</link>
		<dc:creator>Neil Duffin</dc:creator>
		<pubDate>Wed, 08 Jun 2005 08:03:00 +0000</pubDate>
		<guid isPermaLink="false">http://photoshopnews.com/?p=439#comment-568</guid>
		<description>I suspect that most 3rd party developers have written the vast majority of their code in C or C++ (objective C?). Metrowerk&#039;s Codewarrior compiler uses the same standards as any other compiler, such as XCode. There are some specialist actions (pragmas) that are specific to certain compilers, but they usally have equivalents in other compilers (and tend not to be used at all or very sparingly). So, the transition from CodeWarrior to XCode should not be a major issue - rebuild the projects and change a few compiler specific sections. The vast majority of the code is likely to compile exactly the same under XCode as it does under Codewarrior or any other compiler.

Since the source code (C, C++ or object C) is not generally processor specific (they are general languages) there should not be issue with the move to Intel either. The only place that issue will occur is if the developer has written any assembly language sections (machine code) as this IS processor specific or directly accesses hardware, these will need to be rewritten. Hardware access is very unlikely, this normally only occurs in device drivers in today’s operating systems (OS).

However, the writing of such machine code is much more difficult and intricate than writing C, etc, and as such I doubt that a major number of 3rd party developers (or any developers for that matter) have huge sections of it. The old adage is that a program spends 90% of it&#039;s time in 10% of its code. It will be that 10% that benefits from being &#039;hand coded&#039; in machine code. I suspect that worst case, that 10% would need to be rewritten - however, as I say, I would suspect most developers have between 0% and 1% in machine code - the compilers these days are very, very good and trying to bet them with hand written code is not normally that easy.

Another area where there may be an issue is applications which have been Carbonized. I understand that these will need to be converted to Cocoa to work with the new Intel based Macs. Any applications which fall into this category may well require a total rewrite. I have no idea how many applications fall into this area, but anything that is written specifically for OS X is likely not to be. Only more legacy applications will have taken this path?

Obviously calls to OS X are going to be the same and as with the transition from 68x00 to PowerPC, most of the time will be spent in calls to the OS. In the last transition I think they said that 90% of the time was spent there. The OS code will be rewritten to work natively on the Intel chip - you can&#039;t run the OS through Rosetta and Apple wouldn’t be daft enough to try. Therefore, only the remaining 10% of time will be emulated. There are exceptions though, anything which does heavy maths processing or image processing may well do it in its own code - so it will need to be emulated until it’s recompiled.

It&#039;s not all bad though. Java apps are not machine specific (which I why Rosetta doesn&#039;t emulate them?) and so will run &#039;natively&#039; on the Intel anyway. Also (and I know I&#039;m going to get flamed for this but stay with me) Intel chips are faster. No, I&#039;m not saying Windows PCs are faster - they 2.7GHz dual Power PC seems to be faster than the high-end PC running Windows. However, Windows is not a very efficient OS. I&#039;ve run BeOS and Linux on a PC box and it&#039;s *MUCH* faster then Windows on the same machine. OS X is a much more efficient OS. I suspect that translating it to an Intel chip will give a significant performance increase, perhaps enough to overcome most if not all of the performance lost from emulation. Particularly if only 10% of the time for most applications will be under emulation (note I say *time* not *code*, 100% of non-Intel applications code will have to be emulated, but if it only spends 10% of it&#039;s time in them and 90% in the OS&#039;s optimised routines, there should be much less of a hit).

So, what I&#039;m saying is that *most* applications are likely to run and perhaps at pretty much the same speed as now or not hugely slower. Also recompiling most is likely to be reasonably straight forward. There will be exceptions. Some very fast applications using machine code, will require much more work. And these are the ones more likely to use AltiVec code, and therefore not work under the emulator. Plus the OS 8 &amp; 9 ones of course.

As for specifically G4/G5 code not working - I would have thought that most applications would at least run on G3, otherwise their coders are reducing there market substantially.

BTW, I am a programmer. :) I&#039;ve also spent the last 3 years writing code (in C and C++) that works across 4 different hardware platforms.</description>
		<content:encoded><![CDATA[<p>I suspect that most 3rd party developers have written the vast majority of their code in C or C++ (objective C?). Metrowerk&#8217;s Codewarrior compiler uses the same standards as any other compiler, such as XCode. There are some specialist actions (pragmas) that are specific to certain compilers, but they usally have equivalents in other compilers (and tend not to be used at all or very sparingly). So, the transition from CodeWarrior to XCode should not be a major issue &#8211; rebuild the projects and change a few compiler specific sections. The vast majority of the code is likely to compile exactly the same under XCode as it does under Codewarrior or any other compiler.</p>
<p>Since the source code (C, C++ or object C) is not generally processor specific (they are general languages) there should not be issue with the move to Intel either. The only place that issue will occur is if the developer has written any assembly language sections (machine code) as this IS processor specific or directly accesses hardware, these will need to be rewritten. Hardware access is very unlikely, this normally only occurs in device drivers in today’s operating systems (OS).</p>
<p>However, the writing of such machine code is much more difficult and intricate than writing C, etc, and as such I doubt that a major number of 3rd party developers (or any developers for that matter) have huge sections of it. The old adage is that a program spends 90% of it&#8217;s time in 10% of its code. It will be that 10% that benefits from being &#8216;hand coded&#8217; in machine code. I suspect that worst case, that 10% would need to be rewritten &#8211; however, as I say, I would suspect most developers have between 0% and 1% in machine code &#8211; the compilers these days are very, very good and trying to bet them with hand written code is not normally that easy.</p>
<p>Another area where there may be an issue is applications which have been Carbonized. I understand that these will need to be converted to Cocoa to work with the new Intel based Macs. Any applications which fall into this category may well require a total rewrite. I have no idea how many applications fall into this area, but anything that is written specifically for OS X is likely not to be. Only more legacy applications will have taken this path?</p>
<p>Obviously calls to OS X are going to be the same and as with the transition from 68&#215;00 to PowerPC, most of the time will be spent in calls to the OS. In the last transition I think they said that 90% of the time was spent there. The OS code will be rewritten to work natively on the Intel chip &#8211; you can&#8217;t run the OS through Rosetta and Apple wouldn’t be daft enough to try. Therefore, only the remaining 10% of time will be emulated. There are exceptions though, anything which does heavy maths processing or image processing may well do it in its own code &#8211; so it will need to be emulated until it’s recompiled.</p>
<p>It&#8217;s not all bad though. Java apps are not machine specific (which I why Rosetta doesn&#8217;t emulate them?) and so will run &#8216;natively&#8217; on the Intel anyway. Also (and I know I&#8217;m going to get flamed for this but stay with me) Intel chips are faster. No, I&#8217;m not saying Windows PCs are faster &#8211; they 2.7GHz dual Power PC seems to be faster than the high-end PC running Windows. However, Windows is not a very efficient OS. I&#8217;ve run BeOS and Linux on a PC box and it&#8217;s *MUCH* faster then Windows on the same machine. OS X is a much more efficient OS. I suspect that translating it to an Intel chip will give a significant performance increase, perhaps enough to overcome most if not all of the performance lost from emulation. Particularly if only 10% of the time for most applications will be under emulation (note I say *time* not *code*, 100% of non-Intel applications code will have to be emulated, but if it only spends 10% of it&#8217;s time in them and 90% in the OS&#8217;s optimised routines, there should be much less of a hit).</p>
<p>So, what I&#8217;m saying is that *most* applications are likely to run and perhaps at pretty much the same speed as now or not hugely slower. Also recompiling most is likely to be reasonably straight forward. There will be exceptions. Some very fast applications using machine code, will require much more work. And these are the ones more likely to use AltiVec code, and therefore not work under the emulator. Plus the OS 8 &amp; 9 ones of course.</p>
<p>As for specifically G4/G5 code not working &#8211; I would have thought that most applications would at least run on G3, otherwise their coders are reducing there market substantially.</p>
<p>BTW, I am a programmer. <img src='http://photoshopnews.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  I&#8217;ve also spent the last 3 years writing code (in C and C++) that works across 4 different hardware platforms.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Schewe</title>
		<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/comment-page-1/#comment-567</link>
		<dc:creator>Jeff Schewe</dc:creator>
		<pubDate>Wed, 08 Jun 2005 07:15:50 +0000</pubDate>
		<guid isPermaLink="false">http://photoshopnews.com/?p=439#comment-567</guid>
		<description>As far as Adobe and Photoshop goes, yes, the Photoshop engineers will be well able to handle the tasks and have done so repeatedly through a long list of changes and &quot;transitions&quot; over the years.

The primary concern really are the smaller 3rd party developers who may not have the experience or the resources that an Adobe would have.

Many 3rd party Mac developers use CodeWarrior for Mac code for example. Well, Metrowerks sold the Intel dev rights to CodeWarrior and the odds of Metrowerks building new Intel compilers are, well extremely remote. Metrowerks is an independently operating subsidiary of Freescale Semiconductor, the Motorola spin off that WAS making G4 chips. Don&#039;t think Freescale is gonna be too jazzed about building dev tools for a company that is dropping their chips. . .

So, 3rd party developers will be forced to move to Xcode to do Universal Binaries-do build both PowerPC &amp; Mac Intel compatible applications.

I will say that PixelGenius has already ordered our &quot;Developer Transition Kit&quot; and our engineer is already reading up on Universal Binaries and has already downloaded Xcode 2.1. With 1 year in advance to prepare, PixelGenius will be in fine shape. We already do cross-platform engineering so in a way, we&#039;ll be better off than some developers without any Intel/Windows experience.

About all I can say is, remember the old Chinese curse, may you live in interesting times? Well, on Monday, June 6th, 2005, things just got a lot more &quot;interesting&quot; (if you like that sort of thing).</description>
		<content:encoded><![CDATA[<p>As far as Adobe and Photoshop goes, yes, the Photoshop engineers will be well able to handle the tasks and have done so repeatedly through a long list of changes and &#8220;transitions&#8221; over the years.</p>
<p>The primary concern really are the smaller 3rd party developers who may not have the experience or the resources that an Adobe would have.</p>
<p>Many 3rd party Mac developers use CodeWarrior for Mac code for example. Well, Metrowerks sold the Intel dev rights to CodeWarrior and the odds of Metrowerks building new Intel compilers are, well extremely remote. Metrowerks is an independently operating subsidiary of Freescale Semiconductor, the Motorola spin off that WAS making G4 chips. Don&#8217;t think Freescale is gonna be too jazzed about building dev tools for a company that is dropping their chips. . .</p>
<p>So, 3rd party developers will be forced to move to Xcode to do Universal Binaries-do build both PowerPC &amp; Mac Intel compatible applications.</p>
<p>I will say that PixelGenius has already ordered our &#8220;Developer Transition Kit&#8221; and our engineer is already reading up on Universal Binaries and has already downloaded Xcode 2.1. With 1 year in advance to prepare, PixelGenius will be in fine shape. We already do cross-platform engineering so in a way, we&#8217;ll be better off than some developers without any Intel/Windows experience.</p>
<p>About all I can say is, remember the old Chinese curse, may you live in interesting times? Well, on Monday, June 6th, 2005, things just got a lot more &#8220;interesting&#8221; (if you like that sort of thing).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pierre Courtejoie</title>
		<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/comment-page-1/#comment-566</link>
		<dc:creator>Pierre Courtejoie</dc:creator>
		<pubDate>Wed, 08 Jun 2005 05:08:02 +0000</pubDate>
		<guid isPermaLink="false">http://photoshopnews.com/?p=439#comment-566</guid>
		<description>D&#039;oh, Of course, It should read: &quot;isn&#039;t is already done by Adobe...&quot;. I&#039;m making the same mistake Bruce Chizen&#039;s mom does (as he referred during the WWDC Keynote)</description>
		<content:encoded><![CDATA[<p>D&#8217;oh, Of course, It should read: &#8220;isn&#8217;t is already done by Adobe&#8230;&#8221;. I&#8217;m making the same mistake Bruce Chizen&#8217;s mom does (as he referred during the WWDC Keynote)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pierre Courtejoie</title>
		<link>http://photoshopnews.com/2005/06/07/intel-inside-what-does-it-mean-for-photoshop/comment-page-1/#comment-565</link>
		<dc:creator>Pierre Courtejoie</dc:creator>
		<pubDate>Wed, 08 Jun 2005 05:06:13 +0000</pubDate>
		<guid isPermaLink="false">http://photoshopnews.com/?p=439#comment-565</guid>
		<description>Interesting read, Jeff, As always.

About the porting of altivec optimizations to its MMX/SSE counterparts, Isn&#039;t it already done by apple, thanks to the fact that Photoshop runs already on x86 processors on its Windows version?

Of course, I&#039;m not a software engineer, but seems to me that the routines already exist. Maybe the CTRL+C, Command+V keys will be worn out in the 10th Floor of the Adobe Building...</description>
		<content:encoded><![CDATA[<p>Interesting read, Jeff, As always.</p>
<p>About the porting of altivec optimizations to its MMX/SSE counterparts, Isn&#8217;t it already done by apple, thanks to the fact that Photoshop runs already on x86 processors on its Windows version?</p>
<p>Of course, I&#8217;m not a software engineer, but seems to me that the routines already exist. Maybe the CTRL+C, Command+V keys will be worn out in the 10th Floor of the Adobe Building&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

