> > That's why good distributed apps look nothing like your
> > desktop app (which still has algorithms from the i386
> > days, when table lookups still _were_ faster than some
> > calculation).
>
> well, they still are somehow often. It's just braindead now to make
> *large* tables for *simple* calculation, you might have wanted to say... i
Of course there are still uses for table lookups. What I
really wanted to say was that the balance of CPU/mem/IO
is so different that the algorithms from the 386 days
are not optimal anymore.
Extending this metaphor to distributed systems -- which
are so totally different from uniprocessor systems that
the difference 386-686 can be ignored -- will clearly
show that the algorithms used for IPC and other stuff
on single nodes are (very) far from optimal on clusters.
Shared memory, for example, is being used as a fast and
large message buffer on single machines. But since on
networks you can only send messages, there's no real
advantage to shared memory anymore. This means that it's
faster, and probably better, to switch to messaging
entirely and just rewrite the app.
Therefore DSM is not a very good idea. The same goes for
a lot of other single node optimizations, which should be
replaced by more network-efficient algorithms (if you
want decent performance, that is).
Of course, there are those people who don't care about
performance anyway. I just haven't figured out why they
even bother with clusters :)
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu