что-то долгое?

хеш считает от 8кб строки

теоретически миллисекунды или микросекунды там какие-то

Просто почему все вызовы на одном ядре?

Я вот вообще задумался - как эрланг решает какое ядро запускать нифку будет?

вот я тоже задумался. В своем основном проекте от nifок избавился давно, еще 18 или 19 OTP был

А оно у тебя параллельно вызывается или последовательно?

последовательно

из одного процесса?

может поэтому он в один шедулер попадает?

я вспомниаю как у меня NIFки работали, и ЕМНИП они выполнялись на разных ядрах, но они вызывались параллельно с большой конкурентностью из тысяч erlang процессов

72 потока, 142гб
Неплохой такой монстр. Наверное каждый час дорого обходится

По идее, если всё в нифке написано верно, то никаких проблем быть не должно. Вполне вероятно, что где-то произошло зацикливание и нифка не отдаёт управление (виртуалка должна такое отрубать, но мало ли что)

А не проще ерлангом хеш считать ? Если формула тривиальная , типа по модулю произвольного числа, то это одна две строки на ерлагюнге. Нифки блокируют всю параллельность исполнения в ерланг и очень часто сводят на нет все преимущества многопоточности ерланга.

Ну, я думаю что формула не тривиальная, раз её имплементируют в NIF

А стандартные криптографические хеши не устраивают ? Может их можно использовать ?

http://erlang.org/doc/man/erl_nif.html

Threads and concurrency

    A NIF is thread-safe without any explicit synchronization as long as it acts as a pure function and only reads the supplied arguments. When you write to a shared state either through static variables or enif_priv_data, you need to supply your own explicit synchronization. This includes terms in process independent environments that are shared between threads. Resource objects also require synchronization if you treat them as mutable.

Может я неправильно понял, но это вроде значит что их можно параллелить

По-моему это утверждение не верно

ЕМНИП у меня параллельно все выполнялось

Удваиваю