Comment by rdtsc | Hacker News Reader

Comment by rdtsc | Hacker News Reader

The 3-5 usec overhead, with VM optimization flag, for dirty schedulers is pretty good.

What's the overhead of just passing the data through to a regular NIF? Probably gets burried in the jitter caused by cache and memory access times...

(For others, if you don't know about the Erlang VM, and didn't understand the first couple of paragraphs, dirty schedulers is a new feature that solves the problem of running user created, long running, C extension code inside the Erlang VM, without blocking the rest of the VM).

With jitter, the call time for a constant, in a dynamically linked library, is around 1200ns:

	  enacl_nif:crypto_box_ZEROBYTES/0                  
	           value  ------------- Distribution ------------- count    
	            1000 |                                         0        
	            1100 |@@@@                                     110903   
	            1200 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@      879765   
	            1300 |                                         7131     
	            1400 |                                         689      
	            1500 |                                         218      
	            1600 |                                         45       
	            1700 |                                         29

Thanks. That is a bit higher than I would expect but not too bad.

Do Java Native Interfaces suffer the same sort of problem?

Java maps its threads to native OS threads one-to-one. So if you execute in a thread in Java then jump to C you'll block that particular thread. Erlang implementas N:M concurrency where N Erlang processes map to M schedulers (a scheduler here is a separate OS thread ). N is usually greater than M. So you might have N=100K processes mapping to M=16 threads. If one of those processes makes a call to a C module it might block large (say 10k) number of other processes from executing.

Reply on news.ycombinator.com