On 1/18/07, Erik Wikström <[EMAIL PROTECTED]> wrote:
On 2007-01-17 16:31, Petr Janda wrote: Even more interesting would be a guess of how good it might scale when you finally get rid of BGL.
To memory-quote Matt, it should scale really well in theory, because most things are naturally lockless and so aren't co-dependent. FreeBSD scales badly (though improving) because there are complex locks everywhere, and even in the best case there's still a lot of data structures that end up making each CPU take turns. There's no way to make that scale well - the only clean solution is with replication and messaging like DragonFly is gaining. Linux has similar problems in theory, but has had so much more manpower applied to optimization that it performs very well anyway. FreeBSD is in a difficult position of not having an architecture that's easy to develop and optimize by few people (like DragonFly), and not having the manpower to fix consequences of a complex architecture (like Linux). That's not to say it's a bad system for low end SMP, but I doubt we'll ever see it utilize 1024-core servers very well. I'm interested to know how NetBSD's SMP is going to evolve, because I haven't heard much about it at all. What they have now seems to be the same giant lock that FreeBSD 4 had, which means the kernel won't scale. However, in my benchmarks on a dual core, the userland M:N threading 'scales' as well as it possibly could for two cores (at least 2x throughput, compared to the same user threads on one kernel thread). --- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia email: [EMAIL PROTECTED]
