Messages in this thread | | | Date | Fri, 5 Mar 1999 08:52:06 +1100 | From | Richard Gooch <> | Subject | Re: 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/
| |