¿Cuál es el impacto de la semántica de movimiento C ++ 11 en el contexto de la computación científica?

C ++ 11 introduce la semántica de movimiento que puede, por ejemplo, mejorar el rendimiento del código en situaciones donde C ++ 03 necesitaría realizar una construcción de copia o asignación de copia. Este artículo informa que el siguiente código experimenta una velocidad 5 veces mayor cuando se compila con C + 11:

vector<vector<int> > V;
for(int k = 0; k < 100000; ++k) {
    vector<int> x(1000);
    V.push_back(x);
}

¿Cuál es el impacto de la semántica de movimiento C ++ 11 en el contexto de la computación científica?

Me interesa que esta pregunta sea general, pero más específicamente también me interesa la semántica de movimiento para códigos de elementos finitos escritos con bibliotecas de impulso. Probé algunos de mis propios códigos C ++ 03 usando la versión de impulso 1.47.0 (ya que las notas de lanzamiento de impulso mencionan la semántica de movimiento se presentan en 1.48.0) y la versión de impulso 1.53.0, pero no noté mucha mejora. Supongo que los ahorros por no tener que hacer la construcción de copias para boost::numeric::ublas::vector/ matrixy boost::functionno son notables ya que resolver matrices del sistema constituye la mayor parte de la carga de trabajo.

Editar: En realidad, parece que la semántica de movimiento solo se implementa boost::function(consulte las notas de la versión 1.52.0 ). No se menciona la semántica de movimiento boost::numeric, agarré las fuentes para asegurarme y parece que no hay referencias de valor.

Creo que en la práctica el impacto es limitado y será limitado.

La razón por la cual es limitado en este momento es que los grandes paquetes de elementos finitos tienen cuidado de escribir código que sea portátil, por lo que todavía no usan construcciones de lenguaje C ++ 11 en sus propios códigos.

Por supuesto, se beneficiarán de un código como el que muestra donde, incluso sin tener que cambiar el código fuente, se beneficiará de una biblioteca de soporte de compilador mejorada como libstdc ++ para GCC. Dicho esto, las personas en computación científica son bastante conscientes del costo de la copia y, por lo tanto, para los objetos donde importa, simplemente no copian, o generan in situ, o hacen copias superficiales, o usan punteros, o muchas de las otras técnicas disponibles para evitar la sobrecarga de la copia. En otras palabras, la situación para la cual se inventó la semántica de movimiento no ocurre realmente muy a menudo en códigos científicos "reales".