tcmalloc have good idea. What about memory cache per scheduler?<br><br><div class="gmail_quote">2009/3/21 Tony Arcieri <span dir="ltr"><<a href="mailto:tony@medioh.com">tony@medioh.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I noticed in Ulf Wiger's presentation Erlang Programming for Multicore:<br><br><a href="http://ulf.wiger.net/weblog/2009/01/23/erlang-programming-for-multicore/" target="_blank">http://ulf.wiger.net/weblog/2009/01/23/erlang-programming-for-multicore/</a><br>

<br>...that the main contention point in R13A is now the memory allocator.<br><br>Are there any plans for addressing this, such as moving to a different memory allocator, maybe:<br><br>tcmalloc: <a href="http://goog-perftools.sourceforge.net/doc/tcmalloc.html" target="_blank">http://goog-perftools.sourceforge.net/doc/tcmalloc.html</a><br>

hoard: <a href="http://www.hoard.org" target="_blank">http://www.hoard.org</a><br clear="all"><br>I'm curious how much something like this would improve Erlang's performance.  Perhaps I'll try benchmarking Erlang with these allocators versus plain vanilla libc.<br>
<font color="#888888">
<br>-- <br>Tony Arcieri<br><a href="http://medioh.com" target="_blank">medioh.com</a><br>
</font><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil<br>
<br>Analyze your data in minutes. Share your insights instantly. Thrill your boss.  Be a data hero!<br>Try Good Data now for free: <a href="http://www.gooddata.com">www.gooddata.com</a><br>