<?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"
	>
<channel>
	<title>Comments on: Scalability != concurrency</title>
	<atom:link href="http://www.sauria.com/blog/2007/08/25/scalability-concurrency/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/</link>
	<description>Open Source, Modern Programming Languages, OS X, Photography, and ...</description>
	<pubDate>Sun, 27 Jul 2008 01:03:05 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Jasen Halmes</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6414</link>
		<dc:creator>Jasen Halmes</dc:creator>
		<pubDate>Wed, 29 Aug 2007 21:12:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6414</guid>
		<description>I think that your core argument is that you can't achieve effective concurrency with today's JVM architecture?  That may be true, but there are alternate ways to achieve concurrency without depending on the JVM design.  When you use a multiple commodity box solution you get the scale and the potential for concurrency.  With an application fabric, like the &lt;a href="www.appistry.com" rel="nofollow"&gt;Appistry EAF&lt;/a&gt; you can abstract the hardware from the Java application.  You therefore have the ability to take advantage of massive concurrency (and for a much cheaper price tag than buying bigger boxes).

For example, Google uses the map/reduce pattern to scale out their problems concurrently and recombine the answers.  Appistry provides a productized platform to get that kind of massive scale for Java (and C/C++/.NET).

-jasen</description>
		<content:encoded><![CDATA[<p>I think that your core argument is that you can&#8217;t achieve effective concurrency with today&#8217;s JVM architecture?  That may be true, but there are alternate ways to achieve concurrency without depending on the JVM design.  When you use a multiple commodity box solution you get the scale and the potential for concurrency.  With an application fabric, like the <a href="www.appistry.com" rel="nofollow">Appistry EAF</a> you can abstract the hardware from the Java application.  You therefore have the ability to take advantage of massive concurrency (and for a much cheaper price tag than buying bigger boxes).</p>
<p>For example, Google uses the map/reduce pattern to scale out their problems concurrently and recombine the answers.  Appistry provides a productized platform to get that kind of massive scale for Java (and C/C++/.NET).</p>
<p>-jasen</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Isaac Gouy</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6409</link>
		<dc:creator>Isaac Gouy</dc:creator>
		<pubDate>Wed, 29 Aug 2007 03:30:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6409</guid>
		<description>&lt;b&gt;IF&lt;/b&gt;

I'll just say that I think you've overstated your position.</description>
		<content:encoded><![CDATA[<p><b>IF</b></p>
<p>I&#8217;ll just say that I think you&#8217;ve overstated your position.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ted Leung</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6407</link>
		<dc:creator>Ted Leung</dc:creator>
		<pubDate>Wed, 29 Aug 2007 02:18:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6407</guid>
		<description>If the machinery for that gets in the way of making the VM efficient for actors, then I consider that a fatal flaw.   We know that any computational model can emulate any other.  But efficiency matters.</description>
		<content:encoded><![CDATA[<p>If the machinery for that gets in the way of making the VM efficient for actors, then I consider that a fatal flaw.   We know that any computational model can emulate any other.  But efficiency matters.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Isaac Gouy</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6404</link>
		<dc:creator>Isaac Gouy</dc:creator>
		<pubDate>Tue, 28 Aug 2007 22:40:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6404</guid>
		<description>Does needing the machinery for volatile or for enforcing the memory model make the VM fatally flawed for actor style concurrency - or just a pain?

It surprises me that someone managed to implement Occam style concurrency for JVM - but they have &lt;a href="http://www.booksonline.iospress.com/Content/View.aspx?piid=5982" rel="nofollow"&gt;Integrating and Extending JCSP&lt;/a&gt;.

"Fatally flawed" sounds so very definite, so very conclusive.</description>
		<content:encoded><![CDATA[<p>Does needing the machinery for volatile or for enforcing the memory model make the VM fatally flawed for actor style concurrency - or just a pain?</p>
<p>It surprises me that someone managed to implement Occam style concurrency for JVM - but they have <a href="http://www.booksonline.iospress.com/Content/View.aspx?piid=5982" rel="nofollow">Integrating and Extending JCSP</a>.</p>
<p>&#8220;Fatally flawed&#8221; sounds so very definite, so very conclusive.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ted Leung</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6398</link>
		<dc:creator>Ted Leung</dc:creator>
		<pubDate>Tue, 28 Aug 2007 06:45:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6398</guid>
		<description>Isaac,

Well you could start with the fact that  you don't need any of the machinery for volatile, or for enforcing the Java Memory Model.  Immutability and shared nothing get you a lot.</description>
		<content:encoded><![CDATA[<p>Isaac,</p>
<p>Well you could start with the fact that  you don&#8217;t need any of the machinery for volatile, or for enforcing the Java Memory Model.  Immutability and shared nothing get you a lot.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Reid</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6387</link>
		<dc:creator>Reid</dc:creator>
		<pubDate>Mon, 27 Aug 2007 03:48:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6387</guid>
		<description>&lt;em&gt;(commenting here since you didn't supply a URL for the original article)&lt;/em&gt;

Just a nit. Azureus is the most popular BitTorrent client, and it's a Java app. I couldn't find a lot of stats to back this up; these two pages are the best I can find: &lt;a href="http://torrentfreak.com/limewire-most-installed-p2p-application-bittorrent-clients-runner-up" rel="nofollow"&gt;torrentfreak.com "Most installed P2P apps"&lt;/a&gt;, and &lt;a href="http://www.associatedcontent.com/article/256053/azureus_the_best_bittorrent_client.html" rel="nofollow"&gt;an assertion&lt;/a&gt; by Associated Content.</description>
		<content:encoded><![CDATA[<p><em>(commenting here since you didn&#8217;t supply a URL for the original article)</em></p>
<p>Just a nit. Azureus is the most popular BitTorrent client, and it&#8217;s a Java app. I couldn&#8217;t find a lot of stats to back this up; these two pages are the best I can find: <a href="http://torrentfreak.com/limewire-most-installed-p2p-application-bittorrent-clients-runner-up" rel="nofollow">torrentfreak.com &#8220;Most installed P2P apps&#8221;</a>, and <a href="http://www.associatedcontent.com/article/256053/azureus_the_best_bittorrent_client.html" rel="nofollow">an assertion</a> by Associated Content.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Isaac Gouy</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6384</link>
		<dc:creator>Isaac Gouy</dc:creator>
		<pubDate>Sun, 26 Aug 2007 16:11:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6384</guid>
		<description>&lt;em&gt;"...the VM is fatally flawed when it comes to actor style concurrency"&lt;/em&gt;

It would be nice to see some explanation of that assertion.</description>
		<content:encoded><![CDATA[<p><em>&#8220;&#8230;the VM is fatally flawed when it comes to actor style concurrency&#8221;</em></p>
<p>It would be nice to see some explanation of that assertion.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J Aaron Frr</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6383</link>
		<dc:creator>J Aaron Frr</dc:creator>
		<pubDate>Sun, 26 Aug 2007 13:47:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6383</guid>
		<description>"Hmm, Erlang lab, anyone?"

You propose it, I'll +1 it!  :-)</description>
		<content:encoded><![CDATA[<p>&#8220;Hmm, Erlang lab, anyone?&#8221;</p>
<p>You propose it, I&#8217;ll +1 it!  <img src='http://www.sauria.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Croydon</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6382</link>
		<dc:creator>Matt Croydon</dc:creator>
		<pubDate>Sun, 26 Aug 2007 13:04:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6382</guid>
		<description>I've posted &lt;a href="http://www.postneo.com/2007/08/26/there-is-an-erlang-community-its-just-smaller-than-youre-used-to" title="There is an Erlang community, it’s just smaller than you’re used to" rel="nofollow"&gt;my thoughts on the Erlang community&lt;/a&gt; that you might want to check out.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve posted <a href="http://www.postneo.com/2007/08/26/there-is-an-erlang-community-its-just-smaller-than-youre-used-to" title="There is an Erlang community, it’s just smaller than you’re used to" rel="nofollow">my thoughts on the Erlang community</a> that you might want to check out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sam Ruby</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6381</link>
		<dc:creator>Sam Ruby</dc:creator>
		<pubDate>Sun, 26 Aug 2007 11:22:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6381</guid>
		<description>&lt;blockquote&gt;This is actually 2 problems. There’s the issue with the libraries, and there’s the issue with the community that did/didn’t produce the libraries.&lt;/blockquote&gt;

Either that or Sam's an idiot.

&lt;code&gt;apt-get install &lt;a href="http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&#38;word=erlang-examples&#38;version=feisty&#38;arch=all" rel="nofollow"&gt;erlang-examples&lt;/a&gt; &lt;a href="http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&#38;word=erlang-doc-html&#38;version=feisty&#38;arch=all" rel="nofollow"&gt;erlang-doc-html&lt;/a&gt; &lt;a href="http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&#38;word=erlang-manpages&#38;version=feisty&#38;arch=all" rel="nofollow"&gt;erlang-manpages&lt;/a&gt;&lt;/code&gt;</description>
		<content:encoded><![CDATA[<blockquote><p>This is actually 2 problems. There’s the issue with the libraries, and there’s the issue with the community that did/didn’t produce the libraries.</p></blockquote>
<p>Either that or Sam&#8217;s an idiot.</p>
<p><code>apt-get install <a href="http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&amp;word=erlang-examples&amp;version=feisty&amp;arch=all" rel="nofollow">erlang-examples</a> <a href="http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&amp;word=erlang-doc-html&amp;version=feisty&amp;arch=all" rel="nofollow">erlang-doc-html</a> <a href="http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&amp;word=erlang-manpages&amp;version=feisty&amp;arch=all" rel="nofollow">erlang-manpages</a></code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ingo</title>
		<link>http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6380</link>
		<dc:creator>ingo</dc:creator>
		<pubDate>Sun, 26 Aug 2007 11:06:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2007/08/25/scalability-concurrency/#comment-6380</guid>
		<description>What does "designed from the ground-up assuming that objects typically are immutable and serializable" mean for the VM?</description>
		<content:encoded><![CDATA[<p>What does &#8220;designed from the ground-up assuming that objects typically are immutable and serializable&#8221; mean for the VM?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
