On Friday, March 2, 2012 5:11:04 PM UTC+1, Jorge wrote:
>
>
> Please note that time passes in parallel (N threads doing usleep()s in 
> parallel are always going to be faster than M<<N threads running N 
> usleep()s), but real disk I/O jobs even when ran in parallel in separate 
> threads tend to be executed sequentially (unless you happen to hit the disk 
> caches, a disk usually can do no more than an i/o operation at a time).
>
> So unless I'm misunderstanding (quite likely), istm that that test is 
> flawed.
>
> Also note that on a Mac (on darwin), there's a mutex in libeio 
> (https://github.com/joyent/node/blob/master/deps/uv/src/unix/eio/eio.c#L402 
> and 
> https://github.com/joyent/node/blob/master/deps/uv/src/unix/eio/eio.c#L2171) 
> that prevents parallel execution of write()s, even to different file 
> descriptors, so they won't ever run in parallel, due to a bug in OSX's 
> read() 2 and write() 2, both of which happen to be not fully thread-safe, 
> unlike in Linux. So on a Mac, you'd gain ~ nothing using more (libeio) 
> threads for io.
> -- 
> Jorge.
>


You are correct. Like I said, it's very hard to do any meaningful 
benchmarks since it all depends on the modules you use.

I guess that for some people using certain modules and running linux it 
might be beneficial to have an api to increase the thread count. But I can 
also see people shooting themselves in the foot with it by setting it way 
to high. I guess I'll just write a small module to expose the eio functions 
for people who want to use it.

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to