<div><span class="gmail_quote">On 9/23/07, <b class="gmail_sendername">Bob Ippolito</b> <<a href="mailto:bob@redivi.com">bob@redivi.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 9/24/07, Patrick Logan <<a href="mailto:patrickdlogan@gmail.com">patrickdlogan@gmail.com</a>> wrote:<br>> > > >  <a href="http://www.tbray.org/ongoing">http://www.tbray.org/ongoing</a>/When/200x/2007/09/22/Erlang
<br>> > > ><br>> > > > Tim Bray might raise some valid points here, even if he's slightly<br>> > > > biased by his background.<br>><br>> The good news is speeding up the i/o in erlang should be easier than
<br>> introducing better concurrency to another language.<br>><br><br>I've never had a problem with Erlang's general I/O performance, it's<br>probably just some implementation detail of direct file I/O that is
<br>the loser here. The obvious Erlang fast path to read lines is to spawn<br>cat and let the port machinery do all of the work for you. Here's an<br>example (including a copy of Tim's dataset):<br><br><a href="http://undefined.org/erlang">
http://undefined.org/erlang</a>/o10k.zip<br></blockquote></div><br><div>I posted a link in a comment to Tim's blog to an example that uses multiple processes to break down the expensive parts of processing Tim's dataset in parallel, and was able to achieve a pure Erlang approach that on my MacBook Pro equals your "cat" approach, and is much faster than "cat" on an 8-core machine. It's shown on my blog:
</div><div><br class="webkit-block-placeholder"></div><div><<a href="http://steve.vinoski.net/blog/2007/09/23/tim-bray-and-erlang/">http://steve.vinoski.net/blog/2007/09/23/tim-bray-and-erlang/</a>></div><div><br class="webkit-block-placeholder">
</div><div>It definitely speeds up as the number of cores goes up.</div><div><br class="webkit-block-placeholder"></div><div>I don't consider myself an Erlang expert and so welcome any suggestions for improving this. I'm guessing someone will see the two instances of "++" list handling and jump on that, but I tried it with the typical reverse approach and with flattening and neither was faster. However I am quite open to being enlightened. :-)
</div><div><br class="webkit-block-placeholder"></div><div>--steve</div>