lkml.org 
[lkml]   [1999]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: MOSIX and kernel mods.
Kamran Karimi writes:
>
> Richard Gooch wrote:
>
> >Using DIPC or MOSIX is like using the "-parallel" switch on a
> >compiler. Sure, you'll usually get a performance boost (but sometimes
> >performance will drop through 13 floors), but it's not going to be
> >anywhere near the performance if you make the parallelism explicit.
>
> I agree completely. There will be some overhead when using systems
> like DIPC. That is because they are taking over some of the work
> that should be done by the programmer if he uses systems like PVM or
> MPI. Actually, this is true even in the case of PVM and MPI, as they
> rely on TCP sockets. I wonder if the best solution in your opinion
> is to program the networking adaptor directly?

Yep, bugger the network stack, I write to the NIC registers directly
and grab the interrupts too. I use a dedicated NIC and network for all
my distributed applications. Nothing beats fondling the bare metal!!!
I use RT-Linux too to squeeze out the last drop of performance: I'm
aiming for sub-microsecond interrupt latency!

I'm looking at designing my own NICs and network technology to
increase bandwidth and decrease latency. I'm on a mission!

> We build abstraction layers, and deciding where to "stop" building more
> is somewhat arbitrary, and subject to discussion.
>
> The point is, not all distributed applications need to get all the
> performance increase possible. Use the method you think is appropriate
> for you, and let others do the same.

Look, I have an API for message passing between remote nodes and I use
that in my distributed applications. I also have an API for threading
and I use that in my threaded applications. And when I have a threaded
and distributed application, I use both APIs. So I don't have anything
against APIs which make life easier for the programmer. I've spent
years developing these APIs and others and I use them all the time.

My fundamental point, though, is that an API should provide a sensible
abstraction of the underlying hardware. A threading/SHM API for a
distributed machine is the wrong abstraction, because performance will
suck.

A message passing API for an SMP machine is the wrong abstraction,
because it also prevents you making best use of the machine (although
it's not as foolish as threading/SHM for a distributed machine).

APIs are fine, just use the right one for the job. And in the world of
parallel processing, there are two very different kinds of hardware:
SMP and message passing. So use two APIs: threads and message passing.

What I object to is this idea that you can produce a single, unified
abstraction solve all problems. It just doesn't work this way.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.064 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site