With the new Apple M1/2 ARM processors, not all cores are the same, and there's also very aggressive resource management. There is therefore much higher risk / probability that the receiving threads are pre-empted.
I've been noticing performance issues on m1 machines, using our software which uses libdatachannel, and to see if I could address these I made the change below to juice:
---------------------------
static thread_return_t THREAD_CALL conn_thread_entry(void *arg) {
#ifdef __APPLE__
if (__builtin_available(macOS 10.10, *))
{
int ret = pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0);
JLOG_DEBUG("Raised Thread Priority");
if (ret < 0)
{
JLOG_ERROR("failed to raise QOS");
}
}
#endif
conn_registry_t *registry = (conn_registry_t *)arg;
conn_poll_run(registry);
return (thread_return_t)0;
}
---------------------------
While I haven't noticed much of a difference I still thought it is worthwhile asking about the issue here - do you have experience using libdatachannel / juice on apple silicon, and if so, have you had to address the issue above?
With the new Apple M1/2 ARM processors, not all cores are the same, and there's also very aggressive resource management. There is therefore much higher risk / probability that the receiving threads are pre-empted.
https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon
I've been noticing performance issues on m1 machines, using our software which uses libdatachannel, and to see if I could address these I made the change below to juice:
While I haven't noticed much of a difference I still thought it is worthwhile asking about the issue here - do you have experience using libdatachannel / juice on apple silicon, and if so, have you had to address the issue above?
Thank you!