On 27/04/13 12:06, David Bruant wrote:
Le 26/04/2013 23:23, Brian Anderson a écrit :
I do think 50,000 I/O-performing tasks in a 32-bit process is within
our reach. Last year I demonstrated 500,000 simultaneous Rust tasks
(that did nothing but wait) in a 32-bit process, but there have been
severe regressions since. On Linux I think we can get the initial
allocation overhead for a single task into the ~2k range for sure.
Still, one stack per I/O operation has a bad smell to it. Being forced
to create a new task (even if "only" 2k) because the 49000 previous
ones are sitting idle doesn't sound right. Not contacting the remote
resource (disk, network) would be worse. To do efficient IO, there got
to be a cheap way to start an IO and wait for it. Creating a task,
doesn't sound cheap enough to work at scale.
But we're not talking about creating a new task for every io operation
as the io module's usual under-the-hood strategy, surely?
It seems to me that, by default, what we'd want is a sync api which
under the hood, creates one task per drive accessed, or maybe
max(drives_in_use, number_of_cores). I think the OS will make them
async with the drive hardware anyway, though, so number_of_cores doesn't
matter.
We wouldn't want to request 1000 different files (or seeks) at the same
time, from one drive, though, right? I know there is command queuing on
drives and all, but still...
--
Lee
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
