<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 8:40 AM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm doing very CPU bound task: video transcoding.<div><br></div><div><br></div><div>What is better to use: dirty NIF or driver async?</div>
<div><br></div><div>Is it correct to ask "what is better" in this case?</div></div></blockquote><div><br></div><div>IMO dirty NIFs are much easier to write, but there are other factors to consider.</div><div><br>
</div><div>If you're going to have a number of concurrent Erlang processes running dirty native code, then you need to watch out for occupying all the dirty CPU scheduler threads such that your dirty jobs queue up faster than they can be processed. By default you get one dirty CPU scheduler thread per regular scheduler thread, and the number of dirty CPU scheduler threads may not exceed the number of regular scheduler threads (i.e, if you reduce the number of regular scheduler threads online at runtime, the number of dirty CPU scheduler threads online is likewise reduced). So if you plan to have a lot of video transcoding jobs running concurrently, where "a lot" is a number much larger than the number of scheduler threads, it might be better to use the async thread pool since you can easily make it as large as you want. Note that a dirty NIF can cooperatively yield a dirty scheduler thread by calling enif_schedule_dirty_nif() again, as that allows the dirty scheduler thread to reenter the emulator and dequeue a new job, but this still doesn't solve the problem of having too many jobs competing for dirty CPU scheduler thread resources.</div>
<div><br></div><div>A nice thing about dirty NIFs is they're based on the normal Erlang process model, where a regular process runs native code on a dirty scheduler thread. Drivers and the async pool do not follow this model, which is part of the reason that sometime in the future, the async thread pool and drivers could go away, all in favor of native processes. None of this will happen prior to Erlang 19 at the earliest, but still, it's perhaps something to consider.</div>
<div><br></div><div>And one other caveat: the dirty NIF API is experimental in 17.x and is subject to change.</div><div><br></div><div>--steve</div></div></div></div>