<?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: Scala liftoff</title>
	<atom:link href="http://www.sauria.com/blog/2008/05/14/scala-liftoff/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sauria.com/blog/2008/05/14/scala-liftoff/</link>
	<description>Open Source, Modern Programming Languages, OS X, Photography, and ...</description>
	<lastBuildDate>Thu, 19 Jan 2012 07:08:30 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: David Pollak</title>
		<link>http://www.sauria.com/blog/2008/05/14/scala-liftoff/comment-page-1/#comment-15279</link>
		<dc:creator>David Pollak</dc:creator>
		<pubDate>Fri, 16 May 2008 15:42:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.sauria.com/blog/2008/05/14/scala-liftoff/#comment-15279</guid>
		<description>Ted,

Thanks for your awesome write-up of the Scala lift off.

In terms of Actor performance vs. C-style low-level performance, there are different reasons to use each.

If you&#039;ve got a lot of state in course-grains components and want to do multi-threaded work on a collection of components, then Actors are the right answer.  Each actor dispatch takes hundreds if not thousands of instructions to process.

If you&#039;ve got very simple data structures and simple synchronization semantics, coding at the &quot;metal&quot; is going to yield better performance and when you&#039;re competing against well written, well tuned C code, coding at the metal counts.

So, if I were writing a memcached clone or a spreadsheet, I&#039;d be focusing my development efforts on tuning the last few cycles.  That means writing very C-ish Scala/Java (pre-allocating buffers, minimizing byte-copying, integer offsets over arrays of bytes, etc.)

On the other hand, if I was writing a system where there are many developers (more than me and one other guy with a mind-meld), where the synchronization semantics are complex (different threads can ask questions of each other during processing), and where I might have to distribute the collection across multiple JVMs (e.g., the Skittr example), I&#039;d use Actors.

Thanks,

David</description>
		<content:encoded><![CDATA[<p>Ted,</p>
<p>Thanks for your awesome write-up of the Scala lift off.</p>
<p>In terms of Actor performance vs. C-style low-level performance, there are different reasons to use each.</p>
<p>If you&#8217;ve got a lot of state in course-grains components and want to do multi-threaded work on a collection of components, then Actors are the right answer.  Each actor dispatch takes hundreds if not thousands of instructions to process.</p>
<p>If you&#8217;ve got very simple data structures and simple synchronization semantics, coding at the &#8220;metal&#8221; is going to yield better performance and when you&#8217;re competing against well written, well tuned C code, coding at the metal counts.</p>
<p>So, if I were writing a memcached clone or a spreadsheet, I&#8217;d be focusing my development efforts on tuning the last few cycles.  That means writing very C-ish Scala/Java (pre-allocating buffers, minimizing byte-copying, integer offsets over arrays of bytes, etc.)</p>
<p>On the other hand, if I was writing a system where there are many developers (more than me and one other guy with a mind-meld), where the synchronization semantics are complex (different threads can ask questions of each other during processing), and where I might have to distribute the collection across multiple JVMs (e.g., the Skittr example), I&#8217;d use Actors.</p>
<p>Thanks,</p>
<p>David</p>
]]></content:encoded>
	</item>
</channel>
</rss>

