Fwd: [elixir-talk:2800] Sundown NIF library apart from ExDoc

[Dave Cottlehuber <dc...@jsonified.com>]

No doubt of interest here too.


---------- Forwarded message ----------
From: Vincent Siliakus <za...@gmail.com>
Date: 14 February 2014 14:20
Subject: Re: [elixir-talk:2800] Sundown NIF library apart from ExDoc
To: elixir-lang-talk@googlegroups.com
Cc: Devin Torres <de...@devintorr.es>, jose.valim@plataformatec.com.br


For those interested, here's a follow-up after my initial dirty
scheduler experiments with the markdown library:

After posting a question on the erlang mailing list about some of the
new dirty scheduler functionality and getting a reply from the Steve
Vinoski, who actually implemented dirty schedulers in OTP 17.0, we
continued to have some discussion off list. Steve was kind enough to
have a look at my implementation and do some profiling. His
conclusions are that my implementation is fine and that the results
matches his expectations.

I also posted some results of a slightly updated version of the ring
benchmark that I described in a previous post of this mail list thread
here:

https://gist.github.com/zambal/8974206

You can see what dirty schedulers can do in the last test where large
documents are parsed and iex is started with only one scheduler. The
reason that the ring benchmark still performs well when dirty
schedulers are enabled is because even with only one scheduler, the
erlang run-time system still uses a separate OS thread for the dirty
NIF.

The other tests show that the run-time system is actually pretty smart
in scheduling processes. Even with dirty schedulers disabled, the test
that parses large documents still performs quite good when using 2
normal schedulers, indicating that all or at least most ring benchmark
processes are scheduled on one core and the markdown parsing on
another. However, using dirty schedulers for long performing NIFs is
still advised when using multiple cores, because in a more complex
real world scenario, changes are that the normal schedulers will start
to behave badly when not used.


--
You received this message because you are subscribed to the Google
Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elixir-lang-talk+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [elixir-talk:2800] Sundown NIF library apart from ExDoc

[Paul Davis <pa...@gmail.com>]

Neat!

I did some playing as well the other day:

https://github.com/davisp/nif-examples/tree/master/apps/dirty_sched
https://github.com/davisp/dsprof

I was mostly just interested in the overhead of shunting to a dirty
scheduler vs making direct calls. I ended up seeing a 20-40
microsecond overhead between a direct call and using dirty schedulers
which means I'll probably stick with making Jiffy yield properly
rather than using dirty schedulers. For other NIFs I could definitely
see them being useful though (ie, interacting with external libraries
where you can't yield easily).

On Fri, Feb 14, 2014 at 9:37 AM, Dave Cottlehuber <dc...@jsonified.com> wrote:
> No doubt of interest here too.
>
>
> ---------- Forwarded message ----------
> From: Vincent Siliakus <za...@gmail.com>
> Date: 14 February 2014 14:20
> Subject: Re: [elixir-talk:2800] Sundown NIF library apart from ExDoc
> To: elixir-lang-talk@googlegroups.com
> Cc: Devin Torres <de...@devintorr.es>, jose.valim@plataformatec.com.br
>
>
> For those interested, here's a follow-up after my initial dirty
> scheduler experiments with the markdown library:
>
> After posting a question on the erlang mailing list about some of the
> new dirty scheduler functionality and getting a reply from the Steve
> Vinoski, who actually implemented dirty schedulers in OTP 17.0, we
> continued to have some discussion off list. Steve was kind enough to
> have a look at my implementation and do some profiling. His
> conclusions are that my implementation is fine and that the results
> matches his expectations.
>
> I also posted some results of a slightly updated version of the ring
> benchmark that I described in a previous post of this mail list thread
> here:
>
> https://gist.github.com/zambal/8974206
>
> You can see what dirty schedulers can do in the last test where large
> documents are parsed and iex is started with only one scheduler. The
> reason that the ring benchmark still performs well when dirty
> schedulers are enabled is because even with only one scheduler, the
> erlang run-time system still uses a separate OS thread for the dirty
> NIF.
>
> The other tests show that the run-time system is actually pretty smart
> in scheduling processes. Even with dirty schedulers disabled, the test
> that parses large documents still performs quite good when using 2
> normal schedulers, indicating that all or at least most ring benchmark
> processes are scheduled on one core and the markdown parsing on
> another. However, using dirty schedulers for long performing NIFs is
> still advised when using multiple cores, because in a more complex
> real world scenario, changes are that the normal schedulers will start
> to behave badly when not used.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to elixir-lang-talk+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.