[erlang-questions] Percept profiler

[Ulf Wiger (TN/EAB)]

Andreas Hillqvist skrev:
> I got in contact with Björn-Egil Dahlberg, who wrote a thesis on
> "Profiling applications in Erlang Symmetrical MultiProcessing system".
> I do not believe the thesis is public available. But you can find an
> early draft online:
> http://www.cs.umu.se/~tm99bdg/documents/thesis-v.0.3.pdf

A few statements in the early draft could use some polishing
(no surprise there, of course...)

Especially, perhaps, this, on page 15:

"However, with the new runtime technique some performance issues
has arisen. Instead of good speedup, no speedup or even slowdown
has plauged the tested systems."

While I agree that there is definitely room for improvement
in SMP Erlang, and not all programs benefit from SMP, this
statement doesn't reflect that there have also been significant
successes with SMP Erlang. For example, we (Ericsson) have
delivered commercial products to customers, where we measured
a 1.7x-1.9x speedup when going from single-core to dual-core,
depending on traffic case. For a complex, real-life application,
I would say that qualifies as good speedup, esp since the work
required to adapt and verify the app to multicore was minimal.

http://www.sics.se/files/projects/multicore/day2007/UlfW.pdf

BR,
Ulf W

> 
> I sent an e-mail to, Björn-Egil Dahlberg, he gave my some insights.
> 
> I have translated his answer from Swedish:
> -----Original Message-----
> From: Björn-Egil Dahlberg
> Sent: 2007-11-13 16:56
> 
> Profiling is activated though a special BIF, erlang:system_profile/2.
> Through it you could specify if you would like to monitor Erlang
> process, ports or schedule threads.
> 
> Through monitoring Erlang process you could measure parallelity in
> your applications and hopfully identify bottlenecks in your system. It
> dose not state how well erts utilize the CPUs. For that you could use
> the scheduler.
> 
> The monitoring is performed by identifying parallel primative (send,
> receive, spawn, suspend, etc) in the runtime system. When a event is
> triggered by a matching state transition a message together with a
> time stamp and MFA is sent to the Pid/Port you have assigned as
> listener. This is similar to erlang:trace.
> 
> I(Björn-Egil) have made a rugh simplification and divided the process
> states into two parallel states: running, runnable, exiting -> active,
> waiting, suspend -> inactive
> 
> system_profile(Pid, [scheduler]) monitors the scheduler (Those threads
> that are actually running Erlang processes on the OS).
> They are often mapped 1-1 against the number of processors/cores that
> exist on the system. (But some problems still persist)
> 
> Evan ports may be monitored, but this is not as interesting. Some
> callbacks are queued and are considered as runnables (active), when
> they run (active) and i other case non running (inactive).
> 
> There will be a new OTP-application , Percept. Percept stands for,
> Percept - Erlang Concurrency Profiling Tool.
> The thought behind it was to offer a better overview of the data.
> Amongst other through graphs parallelity over time.
> -----End Original Message-----
> 
> I have not tried Percept, yet. I think this tool will be useful to
> help you find bottle necks.
> I.e. Many "worker" process waits for a single server/process to reply.
> 
> 
> Kind regards
> Andreas Hillqvist
> 
> 2007/12/14, Joel Reymont <joelr1@REDACTED>:
>> I see documentation on the Percept profiler API but could someone
>> explain the purpose of this tool?
>>
>> What is a "Concurrency Profiler"?
>>
>> When and where should it be used?
>>
>>         Thanks, Joel
>>
>> --
>> http://wagerlabs.com
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions