You know, its rude to say something is obsolete in this field, so we just say...there are other choices and hope the hint is taken. Nothing ever dies quickly, it just fades away off into the sunset.
There is a lot of legacy code running with MPI for sure, but the big data and almost big data trends are clear, and CUDA has been absolutely disruptive in the scientific computing field (though some people are beginning to use MapReduce here also).
yeah, I always map CUDA blocks to racks and CUDA threads to blades ;)
GPUs, Xeon Phi, FPGAs and other accelerators still need somebody managing them. Nobody said it should be MPI, but there are still many hybrid architectures with MPI handling distribution and actual compute done using OpenMP or accelerators.
In my system I use Erlang/OTP to handle distribution and concurrency and OpenCL for data-parallel compute.
> yeah, I always map CUDA blocks to racks and CUDA threads to blades ;)
Sounds like Jeff Dean.
> Nobody said it should be MPI, but there are still many hybrid architectures with MPI handling distribution and actual compute done using OpenMP or accelerators.
MPI or even RPC works fine as a control mechanism, just not as a critical performance-sensitive abstraction, where we care about the width and speed of the pipe, and MPI is nothing like a pipe!
> In my system I use Erlang/OTP to handle distribution and concurrency and OpenCL for data-parallel compute.
This is quite reasonable. Once one understands the difference between concurrency and parallelism, they can pick appropriate tools to deal with each. As long as they confuse the issues, they'll make bad choices.
There is a lot of legacy code running with MPI for sure, but the big data and almost big data trends are clear, and CUDA has been absolutely disruptive in the scientific computing field (though some people are beginning to use MapReduce here also).