<div>I've tried your code with the 1000k file on my MacBook Pro (2.33 GHz 2 core) with 2 GB RAM and a Linux box with 2 quad-core 2.33 GHz Intel Xeons with 8 GB RAM. On the laptop, the best time I got was 17 secs. On the Linux system, the best time I got was 

9.7 sec. Changing the number of processes doesn't seem to affect the result that much. Perhaps there's a better way to run it than just going into the erl shell, compiling it, and then running it?</div><div><br>

</div><div>So even with an elaborate program like this, Ruby still outperforms Erlang by at least 2x, closer to 3x, and yet Ruby is generally slow compared to Perl and Python. (Mind you, I use multiple programming languages every day, so I'm not approaching this from a "my language is better than yours" perspective. I don't have time for such nonsense.) I'm just really trying to understand why file I/O has to be so slow compared to these other languages. Ulf and Klacke have mentioned putting flow control on ports -- is that the right answer to this issue, and if so, can anyone who works on the code say whether there's anything in the works for that?

</div><div><br> </div><div>BTW, Tim told me via email that he's working up a new solution, but I haven't seen it yet.</div><div><br> </div><div>thanks,</div><div>--steve</div>

<div><br> </div><div><span class="gmail_quote">On 9/27/07, <b class="gmail_sendername">Caoyuan</b> <<a href="mailto:dcaoyuan@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dcaoyuan@gmail.com

</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

I wrote a solution in Erlang, with a parallel file data reading, plus a simple express matching, for a 1 million lines file (200M size), took 8.311 seconds when -smp enable, and 10.206 seconds when smp disabled. The code is at:

<br><a href="http://blogtrader.net/page" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://blogtrader.net/page</a>/dcaoyuan?entry=tim_bray_s_erlang_exercise<br><br>My computer is a 2.0G 2-core MacBook, I'd like a see a result on

<br>more-core machine :-)<br><br>

The solution spwans a lot of processes to parallel read the file to<br>binary. Then send them to a collect_loop, collect_loop will<br>buffered_read each chunk (when chunks order is correct), buffer_read<br>will convert binary to small (4096 bytes here) lists, then scan_line

<br>will merge them to lines, and process_match on line.<br><br><br>On 9/27/07, Ulf Wiger (TN/EAB) <<a href="mailto:ulf.wiger@ericsson.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ulf.wiger@ericsson.com

</a>> wrote:<br>><br>> The Haskell code uses functions more similar to

<br>> file:read_file/1 and file:read/2, which are not<br>> nearly as slow as io:get_line/2.<br>><br>> I agree with Klacke, that if we could just get flow<br>> control on ports, then there is a perfectly fine

> line-oriented mode built into the port. It's so fast, > that using it without flow control on a large file > will swamp your erlang code (I tried that in the shootout, > with disastrous results).

<br>><br>> <a href="http://www.erlang.org/pipermai" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.erlang.org/pipermai</a>l/erlang-questions/2007-June/027557.html<br>><br>> BR,

<br>> Ulf W<br>><br>> Steve Vinoski wrote:<br>> > The whole discussion surrounding the Erlang issues that Tim Bray

<br>> > presented in his blog has got me wondering about file I/O. I'm<br>> > definitely no Erlang expert, but my own experiments seem to show that<br>> > Erlang file I/O is an insurmountable obstacle for the kind of problem

<br>> > Tim's trying to solve. Unfortunately, clear details about file I/O<br>> > didn't seem to come out in the "Not an Erlang fan" thread.<br>> ><br>> > So, I'm wondering:<br>

> ><br>> > 1. Is file I/O for large files really as slow as it seems, and if so, why?<br>> > 2. Are there existing alternatives to the regular file module functions<br>> > for file I/O that might skirt this problem, and if so, what are they?

> > 3. Is the whole premise of this problem just not "how it's done" in > > Erlang? If so, how would this problem be rearranged to better allow for > > an efficient Erlang solution on the large dataset?

<br>> > 4. Someone posted a link to a Haskell solution in a comment in my blog<br>> > that seems too good to be true:<br>> > <<a href="http://www.serpentine.com/blog" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://www.serpentine.com/blog</a>

/2007/09/25/what-the-heck-is-a-wide-finder-anyway/<br>> > <<a href="http://www.serpentine.com/blog" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.serpentine.com/blog</a>/2007/09/25/what-the-heck-is-a

-wide-finder-anyway/>>.<br>> > Assuming it's accurate, why does Haskell beat Erlang so handily in this

<br>> > situation?<br>> > 5. If file I/O speed is really the issue that it seems to be, are there<br>> > any plans to officially fix it?<br>> ><br>> ><br>> > thanks,<br>> > --steve

<br>> ><br>> ><br>> > ------------------------------------------------------------------------<br>> ><br>> > _______________________________________________<br>> > erlang-questions mailing list

<br>> > <a href="mailto:erlang-questions@erlang.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">erlang-questions@erlang.org</a><br>> > <a href="http://www.erlang.org/mailman" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://www.erlang.org/mailman</a>/listinfo/erlang-questions<br>><br>> ______________________________

_________________<br>> erlang-questions mailing list<br>> <a href="mailto:erlang-questions@erlang.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">erlang-questions@erlang.org</a><br>> 

<a href="http://www.erlang.org/mailman" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.erlang.org/mailman</a>

/listinfo/erlang-questions<br>><br><br><br><br>--<br>- Caoyuan<br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

erlang-questions@erlang.org

</a><br><a href="http://www.erlang.org/mailman" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.erlang.org/mailman</a>/listinfo/erlang-questions<br></blockquote></div><br>