| Author |
Message |
|
| Thomas Lindgren |
 Posted: Mon Oct 22, 2007 3:39 pm |
 |
|
|
User
Joined: 09 Mar 2005
Posts: 284
|
--- Kostis Sagonas <kostis@cs.ntua.gr> wrote:
> Thomas Lindgren wrote:
> >
> > That's a 35% speedup just from sizing the heap
> right.
> > So it seems the internal VM heuristics for this
> could
> > be tuned or improved.
>
> Yes, of course. The question is exactly how to
> satisfy
> all needs, especially since they are often
> contradictory. /.../
I think an online approach could be interesting here.
For example, record memory usage and GC
characteristics of processes spawned at one site (or
otherwise categorized somehow) and use that, along
with current memory use, to make educated (but
non-binding) guesses.
> Having such a
> repository of real applications that can be used as
> benchmarks
> is something that is currently lacking in the Erlang
> community.
> Contributions welcome.
The drawback of 'real code' is that it is often
proprietary and relies on environments that are
tedious to set up. It can be difficult to analyze and
optimize too, as readers looking in the Hipe archives
can see for themselves 
A few years ago, I collected and used a benchmark
suite of medium-size programs, based on OTP. These
exercised the compiler, mnesia, ASN1 (encode/decode
LDAPv2) and gen_tcp.
The advantage was that the code was free and
optimizing these apps would help everyone. A potential
disadvantage was that new versions appear regularly,
so the benchmark suite would have to evolve
appropriately and comparison between versions would be
iffy.
Alas, it didn't catch on at the time. But maybe the
right time has come. Today, I'd suggest adding yaws
and maybe YXA, the wide finder (of course!), and
suchlike to the mix.
> (*) The HiPE group can help in this -- this is a
> good MS Thesis.
I think so too.
Best,
Thomas
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
 
|
| anders_n |
| Posted: Mon Oct 22, 2007 4:12 pm |
|
|
|
User
Joined: 28 Feb 2005
Posts: 155
Location: Saltillo, Mexico
|
On 10/22/07, Thomas Lindgren <thomasl_erlang@yahoo.com> wrote:
>
> --- Anders Nygren <anders.nygren@gmail.com> wrote:
>
> > I did the change to ets:update_counter last night,
> > on my dual
> > core laptop that made an improvement from my
> > previously
> > reported
> > real 0m6.305s
> > user 0m10.149s
> > sys 0m0.380s
> >
> > to
> > real 0m5.094s
> > user 0m8.781s
> > sys 0m0.352s
> >
> > To avoid the update_counter race condition I have
> > only one process
> > that all workers report their matches to.
> >
> > I had some problems with native compilation but
> > finally made it work
> > and
> > real 0m2.192s
> > user 0m3.260s
> > sys 0m0.336s
>
> Nice -- so native compilation yields a 2.3x speedup
> versus the ets-based version (and 2.87x versus the
> original). Have you tried setting that process to
> priority high? (Can be dangerous in general, but in
> the interest of science ...
I just tried it but it actually made things worse.
>
> Parallelization yields 1.78x speedup on the first
> version and 1.49x on the native code version. That's
> pretty good too on two cores.
>
> (I think the ultimate limit in most any language would
> be a time of about 0.33 seconds, the sys time. But at
> this point, we are actually within a factor 10 of
> that.)
Huh??
I thought that sys was the time spent in the kernel.
>
> Okay, I just thought of something marginally more
> clever when using ets. Maybe you did it this way,
> even.
>
> All the matching processes do this when they find a
> match 'M':
>
> case catch ets:update_counter(Tab, M, 1) of
> {'EXIT', Rsn} -> match_table_owner ! {init_key, M};
> _ -> ok
> end
>
> and the match_table_owner (which will be the sole
> process inserting new matches into the table) does
> something like
>
> receive
> {init_key, M} ->
> case catch ets:update_counter(Tab, M, 1) of
> {'EXIT', _} -> ets:insert(Tab, {M, 1});
> _ -> ok
> end, ...;
> ...
> end
>
> This detects and handles the race condition by
> funneling all initializations through the
> match_table_owner and making the init there
> idempotent. Furthermore, post-init updates will be
> done by each matching process without sending
> anything. Sounds potentially promising.
I have tested it but on two cores it makes no noticeable
difference, even though it sounds like a good idea.
/Anders
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Thomas Lindgren |
| Posted: Mon Oct 22, 2007 4:28 pm |
|
|
|
User
Joined: 09 Mar 2005
Posts: 284
|
--- Anders Nygren <anders.nygren@gmail.com> wrote:
> On 10/22/07, Thomas Lindgren
> <thomasl_erlang@yahoo.com> wrote:
> >
> > (I think the ultimate limit in most any language
> would
> > be a time of about 0.33 seconds, the sys time. But
> at
> > this point, we are actually within a factor 10 of
> > that.)
>
> Huh??
> I thought that sys was the time spent in the kernel.
I was thinking of a variation on Amdahl's Law: even
with infinite speedup of the application, you'd still
be stuck with running stuff in the kernel, which
limits potential speedup. For example, even if all
matching work could be done while waiting for more
data to arrive, the task would still need at least
0.33 seconds. But this is basically just a theoretical
rule of thumb.
> I have tested it but on two cores [using local
ets:update_counter/3] makes no
> noticeable
> difference, even though it sounds like a good idea.
Too bad. Well, good luck with it all.
Best,
Thomas
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Oct 22, 2007 9:22 pm |
|
|
|
Guest
|
Actually it is a surprise to me that the dict version compares so favourably to both the tuple version and the ets version considering that it is implemented wholly in Erlang while the others are implemented in C in the emulator. It must have got something right.
It might help a lot if there was support for it in the emulator. Not completely implement it there but have some support functions. There are some parts which would be difficult to do in the emulator. Future EEP?
Robert
On 22/10/2007, Caoyuan <dcaoyuan@gmail.com (dcaoyuan@gmail.com)> wrote:Quote: It seems GC is also a key for performance now per my tbray4.erl
code, which uses plain Dict
After I added [{min_heap_size, 3000}] to spawn_opt, the elapsed time
dropped from 7.7 sec to 5.7s immediately.
The code is at:
http://blogtrader.net/page/dcaoyuan/entry/learning_coding_parallelization_was_tim
On 10/22/07, Thomas Lindgren < thomasl_erlang@yahoo.com (thomasl_erlang@yahoo.com)> wrote:
>
> --- Steve Vinoski <vinoski@ieee.org (vinoski@ieee.org)> wrote:
>
> > Anders sent me his code and I ran it on my 8-core
> > Linux box, with the
> > following performance results. VICTORY is right!
> >
> > real |
|
|
| Back to top |
|
| wuji |
| Posted: Thu Aug 16, 2012 7:41 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
way into the restaurant. The alarm call was coded as as cheap designer *beep* as false," the department said in a statement.Nashville police Chief
Anderson has ordered a review of police response to the the imitation designer *beep* the incident.Luther was remembered as an "awesome guy" and was
well loved," Jay Allis, the kitchen manager at the restaurant, restaurant, cheap polo shirts restaurant, told ABC News' Nashville affiliate WKRN.A recording at the
East Cafe said it would remain closed for "an indeterminate indeterminate jordan 6s indeterminate amount of time due to a tragedy in out
Cafe family."Police Pursuits in California Have Injured More Than 10,000Nearly 10,000Nearly jordan 6 10,000Nearly 90 Percent of Pursuits are for Non-Violent OffensesBy DAVID
19, 2012 More bystanders are injured or killed during high-speed high-speed [h3]cheap polo ralph lauren[/h3] high-speed police chases than by stray bullets. In California, more |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
