> If you have computer time left over, maybe you didn't need to optimize
> so much. :-)
>
> I would be happy to see several DIPC implementations benchmarked
> against each other, but it is rather pointless to benchmark DIPC
> against something else. Everybody agrees what the result will be.
>
> I was truly surprised by the DIPC ease-of-use today. The worst part
> by far is setting up the new kernel and rebooting. Changes to the
> application code are trivial. You could use a perl one-liner for it.
> Conversion to MPI is far more complicated.
I didn't include the rest of your post in the interest of keeping the
thread manageable but I do appreciate your concerns Albert. You are
correct in that it may be difficult to assess exactly what
'excellence' in the kernel is.
I was going to mention this in my previous note but I was worried
about length. One of the reasons that we probably have spare cycles
available is the somewhat steep learning and development curve
associated with parallelizing applications. I certainly understand
how seductive an arguement increased developer/programmer efficiency
is.
Greg
}-- End of excerpt from "Albert D. Cahalan"
As always,
Dr. G.W. Wettstein Enjellic Systems Development - Specialists in
4206 N. 19th Ave. intranet based enterprise information solutions.
Fargo, ND 58102
Phone: 701-281-1686 EMAIL: greg@wind.enjellic.com
------------------------------------------------------------------------------
"The entire physical universe, including this product, may one day
collapse back into an infinitesimally small space. Should another
universe subsequently and spontaneously re-emerge, the existence of this
message in that universe cannot be guaranteed.
-- Unknown
-
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/