<?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: 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>
	<pubDate>Sun, 07 Sep 2008 04:17:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: David Pollak</title>
		<link>http://www.sauria.com/blog/2008/05/14/scala-liftoff/#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'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've got very simple data structures and simple synchronization semantics, coding at the "metal" is going to yield better performance and when you'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'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'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>
