Dirty schedulers and reductions #6
Comments
|
That's pretty fair. Can we run into problems with OTPs, that were compiled without dirty NIFs support? Or nowadays it's almost impossible? |
|
OTP 20 made dirty NIFs obligatory because it uses them internally, so I think it's perfectly fine to require them. Elixir itself will most probably require OTP 20 in the 1.8 release scheduled for January next year. |
elcritch
added a commit
to elcritch/matrex
that referenced
this issue
Jan 7, 2020
# This is the 1st commit message: porting numerix stats libraries # This is the commit message versilov#2: adding power function # This is the commit message versilov#3: fixing power # This is the commit message versilov#4: porting statistics # This is the commit message versilov#5: porting over statistics # This is the commit message versilov#6: fix apply # This is the commit message versilov#7: fix algos # This is the commit message versilov#8: fixing algos # This is the commit message versilov#9: test # This is the commit message versilov#10: updating stats test # This is the commit message versilov#11: switch type to matrex # This is the commit message versilov#12: fixing more tests # This is the commit message versilov#13: matrex # This is the commit message versilov#14: updates # This is the commit message versilov#15: removing experiment # This is the commit message versilov#16: try as row matrix by def # This is the commit message versilov#17: add vector pattern match # This is the commit message versilov#18: adding pseudo-vector type # This is the commit message versilov#19: fix order for column-wise vector # This is the commit message versilov#20: fix order for column-wise vector # This is the commit message versilov#21: fix order for column-wise vector # This is the commit message versilov#22: removing extras deps
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now the library uses "regular" NIFs. In general, for playing nice with the soft-realtime guarantees of the VM regular NIFs should execute in under 1ms. When they execute longer, it might throw off the load balancing of the schedulers (OS threads actually executing Erlang code) and lead to what is known as "scheduler collapse".
Fortunately, there are tools to prevent that.
If the job can be easily chunked the best solution is to periodically call
enif_consume_timesliceto check if code should yield and callenif_schedule_nifto yield and allow the VM to execute other tasks, if necessary.If chunking is not an option, the NIFs can be marked to execute on "dirty" schedulers - separate OS threads where execution can take however long it can and does not affect how regular schedulers work. The downside is that it incurs a context switch to a different OS thread - if the computation is complex enough, that overhead should not be noticeable.
After briefly looking at the code, it seems to be it would be good for the library to mark most functions as dirty (especially the element-wise operations or dot-product). A possible approach would also be to provide two implementations - dirty and not and call one of them depending on the size of the matrix. This might bring in more complexity then desired, though. An example of a library with a more intricate scheduler handling is enacl, which depending on the complexity runs functions on regular or dirty schedulers.
The text was updated successfully, but these errors were encountered: