[erlang-questions] widefinder update

[Caoyuan]

For my code, the best +h Size option is 8192, and the block size of
binary for processing + reading  is 10240000 to 20480000 Bytes per my
testing. The result is now about 2.97 sec vs Ruby's 4.1 sec on 2.8Ghz
4-CPU box.

Attached is the newest code with some cleanup. To evaluate:
$ erlc -smp tbray5.erl
$ time erl +h 8192 -smp -noshell -run tbray5 start o1000k.ap -s erlang halt

real    0m2.972s
user    0m9.685s
sys     0m0.748s


On 10/25/07, Caoyuan <dcaoyuan@REDACTED> wrote:
> It seems heap size is really a key for binary processing, and there
> are other tips for binary processing too. With proper heap size set,
> the straightforward Erlang code (in 80 LOC) can achieve around 3.1 sec
> on my 4-CPU linux box (the ruby code took about 4.1 sec on the same
> machine). The code is pasted on:
>
> http://blogtrader.net/page/dcaoyuan/entry/learning_coding_binary_was_tim
>
> With default heap size, the code may take 4.8+ sec.
>
> On 10/24/07, Steve Vinoski <vinoski@REDACTED> wrote:
> >
> > On 10/24/07, Thomas Lindgren <thomasl_erlang@REDACTED> wrote:
> > >
> > > --- Steve Vinoski <vinoski@REDACTED> wrote:
> > >
> > > Anders, thanks for collecting and posting these.
> > > > I've just performed a set
> > > > of new timings for all of them, as listed below. For
> > > > each, I just ran this
> > > > command:
> > > >
> > > > time erl -smp -noshell -run <test_case> main
> > > > o1000k.ap >/dev/null
> > > >
> > > > where "<test_case>" is the name of the tbray test
> > > > case file. All were
> > > > looped ten times, and I took the best timing for
> > > > each. All tests were done
> > > > on my 8-core 2.33 GHz dual Intel Xeon with 2 GB RAM
> > > > Linux box, in a local
> > > > (non-NFS) directory.
> > >
> > > So, looking at Steve's results on his 8-core system,
> > > we have:
> > >
> > >             real    user     tbray5/real    user/real
> > > tbray5      9.8     --       1.0            --
> > > tbray14     6.63    34.53    1.48            5.21
> > > tbray15     4.12    25.14    2.38           6.10
> > > tbray16     3.16    16.15    3.10           5.11
> > > tbray_tuple 2.28     8.61    4.30           3.78
> > > tbray_ets   1.87     7.42    5.24           3.97
> > > tbray_blkr  1.55     7.34    6.32           4.74
> > >
> > > tbray5/real is the speedup versus the baseline, while
> > > user/real is the speedup for each version due to
> > > parallelization.
> > >
> > > Thus, the latest version is 6.3 times faster than the
> > > first one. The parallel speedup is about the same in
> > > tbray5 and tbray_blkr, a very decent utilization of
> > > >50%, but the amount of work (user) has shrunk from
> > > (presumably more than) 34.53 seconds to 7.34 seconds.
> > >
> > > Tim Bray's original Erlang number on "his macbook"
> > > appears to be 34.16 seconds user (probably about the
> > > same real?). How does this compare to Ruby? Tim Bray
> > > reported that it needed 3.46 seconds real, again on
> > > his macbook. (As I understand it, all results here are
> > > for the big data set.)
> > >
> >
> > Yes, all results are for o1000k.ap, Tim's original large dataset. As for
> > Ruby, I just ran Tim's original code on the 8-core, and out of ten attempts
> > the best was:
> >
> >
> > real    0m2.210s
> > user    0m2.095s
> > sys     0m0.109s
> > --steve
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
>
>
> --
> - Caoyuan
>


-- 
- Caoyuan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tbray5.erl
Type: application/octet-stream
Size: 2663 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20071026/74de589c/attachment.obj>