On Thu, 2009-09-03 at 12:44 -0400, erik quanstrom wrote: > On Thu Sep 3 12:20:09 EDT 2009, [email protected] wrote: > > On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote: > > > > Plan 9 has a lot to offer and a lot for others to learn from. > > > > Concurrency > > > > framework that could scale up to 1K [virtual]cores in an SMP > > > > configuration is not one of those features though. > > > > > > forgive the ignorance, but is there any such thing as a > > > 1k-core smp machine? > > > [...] > > True. But even for those platforms good SMP frameworks are quite > > difficult to come by. And here I do mean computation, not how > > to accommodate scalable IO. > > i'll grant you this in implementation. the pool library's lock > in effect becomes plan 9's BLK. since the pool library is used > in the kernel and user space, a user space application gets hit > twice. i've been doing some full-tilt boogie testing with 2x10gbe > and even with 2 cores, the BLK^wpool lock is devastating.
I'm not surprised here. I'm also not surprised that it gets used twice -- that's precisely what Sun does with slab allocator. > where do you see the theoretical limitation in plan 9? I don't think there's anything limiting plan 9, except for people willing to invest their time and coding skills in tuning these things and coming up with programming frameworks that take us further than manually juggling processes/threads. My view is a bit skewed towards computations, and there its all about your kernel scheduler and memory usage patterns. At least at the low level it is. So I guess as long as these things are ok, you can then build abstractions a'la GCD on top of them. Thanks, Roman.
