<?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: ISC 07</title>
	<atom:link href="http://scalability.org/?feed=rss2&#038;p=306" rel="self" type="application/rss+xml" />
	<link>http://scalability.org/?p=306</link>
	<description>not so random musings and mutterings about high performance computing</description>
	<lastBuildDate>Fri, 10 Sep 2010 13:49:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Patrick O'Rourke</title>
		<link>http://scalability.org/?p=306&#038;cpage=1#comment-13646</link>
		<dc:creator>Patrick O'Rourke</dc:creator>
		<pubDate>Thu, 19 Jul 2007 19:11:16 +0000</pubDate>
		<guid isPermaLink="false">http://scalability.org/?p=306#comment-13646</guid>
		<description>Joe - ISVs have been slower than expected to reply. I had asked folks from IBM, Cd-adapco, CMG and Univ of Tennessee to comment. No word yet, though IBM and UofT said they&#039;d provide me something. I&#039;ll follow-up with them when I return to the office from paternity leave in August.</description>
		<content:encoded><![CDATA[<p>Joe &#8211; ISVs have been slower than expected to reply. I had asked folks from IBM, Cd-adapco, CMG and Univ of Tennessee to comment. No word yet, though IBM and UofT said they&#8217;d provide me something. I&#8217;ll follow-up with them when I return to the office from paternity leave in August.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: scalability.org &#187; Blog Archive &#187; More about adoption</title>
		<link>http://scalability.org/?p=306&#038;cpage=1#comment-13374</link>
		<dc:creator>scalability.org &#187; Blog Archive &#187; More about adoption</dc:creator>
		<pubDate>Wed, 04 Jul 2007 00:55:13 +0000</pubDate>
		<guid isPermaLink="false">http://scalability.org/?p=306#comment-13374</guid>
		<description>[...] coming back to this, adoption rates are critical. I appreciate Patrick&#8217;s point from post 306 that Microsoft doesn&#8217;t release this [...]</description>
		<content:encoded><![CDATA[<p>[...] coming back to this, adoption rates are critical. I appreciate Patrick&#8217;s point from post 306 that Microsoft doesn&#8217;t release this [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe</title>
		<link>http://scalability.org/?p=306&#038;cpage=1#comment-13371</link>
		<dc:creator>Joe</dc:creator>
		<pubDate>Tue, 03 Jul 2007 23:29:57 +0000</pubDate>
		<guid isPermaLink="false">http://scalability.org/?p=306#comment-13371</guid>
		<description>Hi Patrick

  Thanks for the comment.  With Cygwin, we have done some ports, but have observed significant performance drops in doing so.  I am not sure that SFU would give us much better/worse.  

  Most of the vendors you indicate are already existing vendors on Windows.  It is no surprise to see them on CCS.  

  The code porting issue is a significant one.  Native ports will almost always (rare exceptions) give you better performance with good compilers.  More importantly native ports are better coupled to the platform, less baggage in the way.  

  Also important is the 32 vs 64 bit issue.  Several windows folks I have spoken to don&#039;t believe their is a performance difference between 32 bit and 64 bit code.  This is incorrect.  There is a difference, and it can be quite significant.  We were measuring and reporting on this in 2003/2004 time frames.   

  All this said, the PGI compiler is the most interesting aspect.  As long as we can get a POSIX wrapper around it, porting &lt;i&gt;should&lt;/i&gt; be a little easier.  Its that POSIX wrapper that doesn&#039;t seem to be of interest to Microsoft.  You would prefer native, yet the barriers to porting POSIX code/environments is large.  

  All of the above vendors you have cited (well most of them) have initiatives for Itanium2 systems as well.  This is not a non-sequitur, I am pointing out that they have (most of them anyway) backed other platforms that have not lead to a success on that platform.  After years of trying to gain traction, all but a few have given up on that platform.  The rationale for giving up on the platform had to do with a mixture of disappointed sales volume, coupled with a better, cheaper, faster product available in the market.  You may be able to buy Itanium2 systems well into the future.  They just are not part of most of the successful vendors major platforms in HPC (save a few who made critical errors in judgement nearly a decade ago). 

  I am also aware that Microsoft provides some sort of marketing $$$ to these folks for signing up.  I am sure they will all push the platform hard.

  I looked over the scripting site.  Ouch.  You really have to know windows internals to be able to write these things.  Painful.  Also, some ... uh ... advocacy in there with jabs at telnet and ssh being &quot;inconsistent&quot;.  As they are designed for different purposes, decades apart, yeah, it is possible that they are &quot;inconsistent&quot;.  Since most cluster admins would use rsh or ssh, and they are effectively interchangable, well ...

  Anyway, I do look forward to the rest of the reply.</description>
		<content:encoded><![CDATA[<p>Hi Patrick</p>
<p>  Thanks for the comment.  With Cygwin, we have done some ports, but have observed significant performance drops in doing so.  I am not sure that SFU would give us much better/worse.  </p>
<p>  Most of the vendors you indicate are already existing vendors on Windows.  It is no surprise to see them on CCS.  </p>
<p>  The code porting issue is a significant one.  Native ports will almost always (rare exceptions) give you better performance with good compilers.  More importantly native ports are better coupled to the platform, less baggage in the way.  </p>
<p>  Also important is the 32 vs 64 bit issue.  Several windows folks I have spoken to don&#8217;t believe their is a performance difference between 32 bit and 64 bit code.  This is incorrect.  There is a difference, and it can be quite significant.  We were measuring and reporting on this in 2003/2004 time frames.   </p>
<p>  All this said, the PGI compiler is the most interesting aspect.  As long as we can get a POSIX wrapper around it, porting <i>should</i> be a little easier.  Its that POSIX wrapper that doesn&#8217;t seem to be of interest to Microsoft.  You would prefer native, yet the barriers to porting POSIX code/environments is large.  </p>
<p>  All of the above vendors you have cited (well most of them) have initiatives for Itanium2 systems as well.  This is not a non-sequitur, I am pointing out that they have (most of them anyway) backed other platforms that have not lead to a success on that platform.  After years of trying to gain traction, all but a few have given up on that platform.  The rationale for giving up on the platform had to do with a mixture of disappointed sales volume, coupled with a better, cheaper, faster product available in the market.  You may be able to buy Itanium2 systems well into the future.  They just are not part of most of the successful vendors major platforms in HPC (save a few who made critical errors in judgement nearly a decade ago). </p>
<p>  I am also aware that Microsoft provides some sort of marketing $$$ to these folks for signing up.  I am sure they will all push the platform hard.</p>
<p>  I looked over the scripting site.  Ouch.  You really have to know windows internals to be able to write these things.  Painful.  Also, some &#8230; uh &#8230; advocacy in there with jabs at telnet and ssh being &#8220;inconsistent&#8221;.  As they are designed for different purposes, decades apart, yeah, it is possible that they are &#8220;inconsistent&#8221;.  Since most cluster admins would use rsh or ssh, and they are effectively interchangable, well &#8230;</p>
<p>  Anyway, I do look forward to the rest of the reply.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick O'Rourke</title>
		<link>http://scalability.org/?p=306&#038;cpage=1#comment-13370</link>
		<dc:creator>Patrick O'Rourke</dc:creator>
		<pubDate>Tue, 03 Jul 2007 22:56:10 +0000</pubDate>
		<guid isPermaLink="false">http://scalability.org/?p=306#comment-13370</guid>
		<description>Joe - thanks for freeing up the comments section. I couldn&#039;t find my user name/password last week, then was out of the office for a bit. So this is much more convenient.

This is going to be a two-part response. The second part will include comments (directly from them, or cut/paste by me) from vendors who have done the port to Windows. I have emails out to commercial and academic partners seeking comments/input to your post. Hopefully it will drive a good discussion.

The first part here is a bit of a state of the union. Windows CCS has been in the market for 11 months. There are no YoY comparisons available to see adoption rates. But since we&#039;re starting from a low installed base for HPC, suffice it to say our growth rate will be large. There are those folks who used Windows Server 2003 (prior to CCS) and Windows 2000 Server for HPC applications. Cornell Theory Center, Perlegen Sciences, HSBC are a few that come to mind.

Of course MSFT doesn&#039;t publicly report absolute sales/shipment figures for individual server products. So how do I prove customer adoption? I can point you to the 15 case studies: http://www.microsoft.com/casestudies/search.aspx?ProTaxID=3070 . Note that two of those case studies are with ISVs: LSTC and ANSYS. I also can point to customers cited in prior PR, marketing collateral. Suffice to say, in 11 months we&#039;ve had enough customers buy Windows CCS that there will be a version 2 and broaded engineering, sales, marketing efforts.

In terms of supply, let&#039;s look at the OEMs. All of the main server vendors (absent Hitachi) have adopted and sell Windows CCS. I&#039;m not saying they sell more of Windows CCS than Linux ... that&#039;s not the case. But Dell, IBM, HP, SGI, Bull, Fujitsu, NEC have sales/marketing initiatives for Windows CCS ... some stronger than others.

Next is the networking vendors ... Windows CCS is agnostic and supports them all. I believe Mellanox and Cisco were involved with our Top500 benchmarks.

In terms of applications, the Year 1 goal was to get the top commercial ISVs in each target industry (e.g., ANSYS/Fluent, Schlumberger, Parallel Geo, LSTC, Dassault, Wolfram, MSC, CD-adapco) and the core horizontal ISVs (e.g., MathWorks, Platform). There are new ISVs and universities porting codes to Windows; these include CMG, University of Tennessee, PipeLine, SPT, Roxar, AutoDesk. New scripts and codes are posted to the community site on Technet: http://www.microsoft.com/technet/scriptcenter/hubs/ccs.mspx , and on Ken&#039;s site: www.winhpc.org . Admittedly, we don&#039;t yet have the volume of Linux, but we&#039;re committed to get there.

In terms of application porting, I know that some ISVs are opting to use Subsystem for UNIX-based applications (SUA), which comes with Windows Server 2003. I believe NCAR used SUA when it ported WRF to Windows. SUA is a posix tool similar to CYGWIN, which also has been used to do ports. Also, more and more vendors are pushing their Fortran compiler to Windows with integration in Visual Studio 2005 (Intel, PGI), which helps port the libraries and get away from the command line build that Windows users do not much appreciate. And I believe Persistence Software is doing a port to Windows.

OK, that&#039;s it for part 1. It&#039;s a sunny day in Redmond and time to take advantage of it. I&#039;ll be back in touch with comments/input from software vendors/universities.

&lt;strong&gt;Update&lt;/strong&gt; [ed]: cleaned up links so you don&#039;t get spurious commas and periods</description>
		<content:encoded><![CDATA[<p>Joe &#8211; thanks for freeing up the comments section. I couldn&#8217;t find my user name/password last week, then was out of the office for a bit. So this is much more convenient.</p>
<p>This is going to be a two-part response. The second part will include comments (directly from them, or cut/paste by me) from vendors who have done the port to Windows. I have emails out to commercial and academic partners seeking comments/input to your post. Hopefully it will drive a good discussion.</p>
<p>The first part here is a bit of a state of the union. Windows CCS has been in the market for 11 months. There are no YoY comparisons available to see adoption rates. But since we&#8217;re starting from a low installed base for HPC, suffice it to say our growth rate will be large. There are those folks who used Windows Server 2003 (prior to CCS) and Windows 2000 Server for HPC applications. Cornell Theory Center, Perlegen Sciences, HSBC are a few that come to mind.</p>
<p>Of course MSFT doesn&#8217;t publicly report absolute sales/shipment figures for individual server products. So how do I prove customer adoption? I can point you to the 15 case studies: <a href="http://www.microsoft.com/casestudies/search.aspx?ProTaxID=3070" rel="nofollow">http://www.microsoft.com/casestudies/search.aspx?ProTaxID=3070</a> . Note that two of those case studies are with ISVs: LSTC and ANSYS. I also can point to customers cited in prior PR, marketing collateral. Suffice to say, in 11 months we&#8217;ve had enough customers buy Windows CCS that there will be a version 2 and broaded engineering, sales, marketing efforts.</p>
<p>In terms of supply, let&#8217;s look at the OEMs. All of the main server vendors (absent Hitachi) have adopted and sell Windows CCS. I&#8217;m not saying they sell more of Windows CCS than Linux &#8230; that&#8217;s not the case. But Dell, IBM, HP, SGI, Bull, Fujitsu, NEC have sales/marketing initiatives for Windows CCS &#8230; some stronger than others.</p>
<p>Next is the networking vendors &#8230; Windows CCS is agnostic and supports them all. I believe Mellanox and Cisco were involved with our Top500 benchmarks.</p>
<p>In terms of applications, the Year 1 goal was to get the top commercial ISVs in each target industry (e.g., ANSYS/Fluent, Schlumberger, Parallel Geo, LSTC, Dassault, Wolfram, MSC, CD-adapco) and the core horizontal ISVs (e.g., MathWorks, Platform). There are new ISVs and universities porting codes to Windows; these include CMG, University of Tennessee, PipeLine, SPT, Roxar, AutoDesk. New scripts and codes are posted to the community site on Technet: <a href="http://www.microsoft.com/technet/scriptcenter/hubs/ccs.mspx" rel="nofollow">http://www.microsoft.com/technet/scriptcenter/hubs/ccs.mspx</a> , and on Ken&#8217;s site: <a href="http://www.winhpc.org" rel="nofollow">http://www.winhpc.org</a> . Admittedly, we don&#8217;t yet have the volume of Linux, but we&#8217;re committed to get there.</p>
<p>In terms of application porting, I know that some ISVs are opting to use Subsystem for UNIX-based applications (SUA), which comes with Windows Server 2003. I believe NCAR used SUA when it ported WRF to Windows. SUA is a posix tool similar to CYGWIN, which also has been used to do ports. Also, more and more vendors are pushing their Fortran compiler to Windows with integration in Visual Studio 2005 (Intel, PGI), which helps port the libraries and get away from the command line build that Windows users do not much appreciate. And I believe Persistence Software is doing a port to Windows.</p>
<p>OK, that&#8217;s it for part 1. It&#8217;s a sunny day in Redmond and time to take advantage of it. I&#8217;ll be back in touch with comments/input from software vendors/universities.</p>
<p><strong>Update</strong> [ed]: cleaned up links so you don&#8217;t get spurious commas and periods</p>
]]></content:encoded>
	</item>
</channel>
</rss>
