Was Moore's law, now something else, parallelism

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (Mark Woodward)]

On 07/13/2010 10:28 AM, Edward Ned Harvey wrote:
>> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On
>> Behalf Of Mark Woodward
>>
>> Maybe its an OS issue? Like the RAID process described above, operating
>> systems have to become far more modular and parallel to benefit.
>>      
> You mean more modular and parallel than what?  They already support SMP (for
> years since) and virtualization and hyperthreading...  How do you mean more
> modular?
>    
This is a complex discussion, to keep it simple I will use several vague 
generalities, so understand that I know there are threads used by the 
Linux kernel and there are no true absolutes here. That said, the 
problem with monolithic kernel design is that they are designed 
primarily and conceptually as an API library for applications. An 
application execs a kernel call, the function jumps into kernel code, 
executes the API code, and returns a value.

In the multiple processor paradigm, a task will place its request in a 
message queue which will be read by a user space process, that process 
will execute the code, and place the result in the message. On a highly 
parallel system multiple CPUs/threads will be executing.

While there is more work in the second example, the overall throughput 
of the second example will be higher in a highly parallel system.
>
>    
>> That
>> whole user-space micro-kernel process stuff doesn't sound so useless
>> now.  Monolithic/Modular kernels ruled as CPU cores were scarce.
>>      
> They still rule now.  Is there some alternative that doesn't use a
> monolithic or modular kernel?  I don't know of any other option...
>    

The point I'm making is that monolithic kernels will not perform as well 
as micro-kernel designs when there are many many CPUs.
>> With
>> many multiple CPUs, there is actually REAL benefit that can be taken
>> from it. Also, old truisms may now becoming wrong. A user space process
>> for handling services should now be effectively more efficient (in
>> operation) than kernel based ones as long as resource access and
>> contention are managed well.
>>      
> Now this one, I am completely missing.  How on earth can anything in user
> space be *more* efficient than in kernel space?
>
> I could see it, if you were saying "just as efficient" ... but "more"
> efficient?
>    

The phrase you missed is "effectively more efficient." Meaning, yes you 
are right it won't be as purely efficient, however, in practice, by 
parallelizing the work, we may lose, lets say something bad, 50% 
efficiency over a single kernel API, but by spreading the work across 
multiple abundant CPUs and decoupling the work from the client thread, 
we could substantially increase the throughput of the system.