¿Por qué no se agregó el rendimiento a C++ 0x?

Question

He estado usando rendimiento en muchos de mis programas Python, y realmente borra el código en muchos casos. I blogged about it y es una de las páginas más populares de mi sitio.

C# también ofrece rendimiento - que se implementa a través del estado de mantenimiento en el lado del llamante, hecho a través de una clase generada automáticamente que mantiene el estado, las variables locales de la función, etc.

Actualmente estoy leyendo sobre C++ 0x y sus adiciones; y al leer acerca de la implementación de lambdas en C++ 0x, descubrí que también se realizó mediante clases generadas automáticamente, equipadas con operador() que almacena el código lambda. La pregunta natural se formó en mi mente: lo hicieron por lambdas, ¿por qué no lo consideraron también para apoyar el "rendimiento"?

Seguramente pueden ver el valor de las rutinas conjuntas ... así que solo puedo adivinar que piensan que las implementaciones basadas en macros (como Simon Tatham's) son un sustituto adecuado. No son, sin embargo, por muchas razones: destinatario de la llamada cuidada estado, no reentrante, con sede en macro (que por sí solo es motivo suficiente), etc.

Editar: hilosyield no depende de la recolección de basura, o fibras Puede leer el artículo de Simon al ver que yo estoy hablando del compilador de hacer una transformación sencilla, como por ejemplo:

int fibonacci() { 
    int a = 0, b = 1; 
    while (true) { 
     yield a; 
     int c = a + b; 
     a = b; 
     b = c; 
    } 
} 

En:

struct GeneratedFibonacci { 
    int state; 
    int a, b; 

    GeneratedFibonacci() : state (0), a (0), b (1) {} 

    int operator()() { 
     switch (state) { 
     case 0: 
      state = 1; 
      while (true) { 
       return a; 

     case 1: 
       int c = a + b; 
       a = b; 
       b = c; 
      } 
     } 
    } 
} 

basura recogida? No. ¿Hilos? No. ¿Fibras? No. ¿Transformación simple? Podría decirse que sí.

Answer 1

Lo hicieron por lambdas, ¿por qué no lo consideraron para apoyar el rendimiento, también?

Compruebe papers. ¿Alguien lo propuso?

... Solo puedo adivinar que consideran que las implementaciones basadas en macros son un sustituto adecuado.

No necesariamente. Estoy seguro de que saben que existen tales macro soluciones, pero reemplazarlas no es suficiente motivación, por sí solo, para que se pasen las nuevas funciones.

---

A pesar de que hay varias cuestiones en torno a una nueva palabra clave, los que podrían superarse mediante una nueva sintaxis, tal como se hizo para lambdas y el uso de automóviles como un tipo de retorno de la función.

Las funciones radicalmente nuevas necesitan controladores fuertes (es decir, personas) para analizar y enviar por completo características a través del comité, ya que siempre habrá mucha gente escéptica ante un cambio radical. De modo que, incluso sin lo que vería como una fuerte razón técnica en contra de una construcción de rendimiento, puede que aún no haya habido suficiente apoyo.

Pero, fundamentalmente, la biblioteca estándar de C++ ha adoptado un concepto diferente de iteradores de lo que vería con el rendimiento. Comparar a los iteradores de Python, que sólo requieren dos operaciones:

1. an_iter.next() devuelve el siguiente elemento o plantea StopIteration (next() BuiltIn incluido en 2.6 en lugar de utilizar un método)
2. iter (an_iter) devuelve an_iter (para que pueda tratar iterables e iteradores de forma idéntica en funciones)

iteradores C++ 's se utilizan en parejas (que debe ser del mismo tipo), se dividen en categorías, sería un cambio semántico para la transición en algo más susceptible a una construcción de rendimiento, y ese cambio no encajaría bien con los conceptos (que luego se abandonó, pero llegó tarde) Por ejemplo, vea el rationale para (justificadamente, si decepciona) rechazar mi comentario sobre el cambio de bucles basados ​​en rangos a un formulario que haría mucho más fácil escribir esta forma diferente de iterador.

Para aclarar concretamente lo que quiero decir acerca de las diferentes formas de iterador: el ejemplo de código generada necesita otro tipo ser el tipo más iterador maquinaria asociada para conseguir y mantener los iteradores. No es que no pueda ser manejado, pero no es tan simple como puedes imaginar al principio. La verdadera complejidad es la "transformación simple" que respeta excepciones para variables "locales" (incluso durante la construcción), el control de la vida útil de variables "locales" en ámbitos locales dentro del generador (la mayoría debería guardarse en llamadas), etc.

Answer 2

Agregar una palabra clave siempre es complicado, porque invalida el código previamente válido. Intenta evitar eso en un lenguaje con una base de código tan grande como C++.

La evolución de C++ es un proceso público. Si siente que yield debe estar allí, formule una solicitud apropiada al comité estándar de C++.

Recibirá su respuesta, directamente de las personas que tomaron la decisión.

Answer 3

En general, puede realizar un seguimiento de lo que está sucediendo en el committee papers, aunque es mejor para realizar un seguimiento en lugar de buscar un problema específico.

Una cosa para recordar sobre el comité de C++ es que es un comité de voluntarios y no puede lograr todo lo que quiere. Por ejemplo, no había un mapa tipo hash en el estándar original, porque no pudieron llegar a tiempo. Puede ser que no haya nadie en el comité que se haya preocupado lo suficiente por yield y lo que hace para asegurarse de que el trabajo haya terminado.

La mejor manera de averiguarlo sería consultar a un miembro activo del comité.

Answer 4

Bueno, para un ejemplo tan trivial como ese, el único problema que veo es que std::type_info::hash_code() no está especificado constexpr. Creo que una implementación conforme podría hacerlo y apoyar esto. De todos modos, el verdadero problema es obtener identificadores únicos, por lo que podría haber otra solución. (Obviamente me prestó su "interruptor maestro" construir, gracias.)

#define YIELD(X) do { \ 
    constexpr size_t local_state = typeid([](){}).hash_code(); \ 
    return (X); state = local_state; case local_state: ; } \ 
while (0) 

Uso:

struct GeneratedFibonacci { 
    size_t state; 
    int a, b; 

    GeneratedFibonacci() : state (0), a (0), b (1) {} 

    int operator()() { 
     switch (state) { 
     case 0: 
      while (true) { 
       YIELD(a); 
       int c = a + b; 
       a = b; 
       b = c; 
      } 
     } 
    } 
} 

Hmm, ellos también tienen que garantizar que el hash no es 0. No hay problema allí tampoco . Y una macro DONE es fácil de implementar.

---

El problema real es lo que sucede cuando regresas de un osciloscopio con objetos locales. No hay esperanza de guardar un marco de pila en un lenguaje basado en C. La solución es usar una coroutine real, y C++ 0x aborda directamente eso con hilos y futuros.

Considere este generador/corrutina:

void ReadWords() { 
    ifstream f("input.txt"); 

    while (f) { 
     string s; 
     f >> s; 
     yield s; 
    } 
} 

Si un truco similar se utiliza para yield, f es destruido en la primera yield, y es ilegal para continuar el bucle después de ella, porque no se puede goto o switch después de una definición de objeto no POD.

Answer 5

ha habido varios implementación de corrutinas como bibliotecas de espacio de usuario. Sin embargo, y este es el trato, esas implementaciones se basan en detalles no estándar. Por ejemplo, en ninguna parte del estándar C++ se especifica cómo se guardan los cuadros de pila. La mayoría de las implementaciones sólo tienes que copiar la pila porque así es como trabaja la mayoría de las implementaciones ++ c

respecto a las normas, C++ podrían haber ayudado apoyo corrutina mediante la mejora de la especificación de los marcos de pila.

En realidad, 'agregarlo' al lenguaje no me parece una buena idea, porque eso lo dejaría con una implementación 'lo suficientemente buena' para la mayoría de los casos que es completamente dependiente del compilador. Para los casos en que el uso de una corutina importa, esto no es aceptable de todos modos

Answer 6

No puedo decir por qué no agregaron algo como esto, pero en el caso de lambdas, no fueron solo agregado a la idioma tampoco.

Se comenzó su vida como una implementación de la biblioteca en Boost, que demostraron que

• lambdas son ampliamente útil: mucha gente va a usar cuando están disponibles, y que
• una implementación de la biblioteca de C++ 03 adolece de varias deficiencias.

Basado en esto, el Comité decidió adoptar algún tipo de lambdas en C++ 0x, y creo que inicialmente experimentado con la adición de más características del lenguaje general como para permitir una implementación mejor biblioteca que tiene Boost .

Y, finalmente, lo hicieron una característica del lenguaje central, porque no tenían otra opción: porque no era posible hacer una implementación de la biblioteca suficientemente buena.

Las nuevas funciones del lenguaje central no se agregan simplemente al idioma porque parecen una buena idea. El comité es muy reacio a agregarlos, y la característica en la pregunta realmente necesita probarse. Se debe demostrar que la función es:

• posible implementar en el compilador,
• va a resolver una necesidad real, y
• que una implementación de la biblioteca no sería lo suficientemente bueno.

En el caso de una palabra clave yield, sabemos que el primer punto se puede resolver. Como ha demostrado, es una transformación bastante simple que se puede hacer mecánicamente.

El segundo punto es complicado.¿Cuánto de necesita para esto está allí? ¿Cuán ampliamente utilizados están las implementaciones de la biblioteca que existen? ¿Cuántas personas han pedido esto o han enviado propuestas para ello?

El último punto parece pasar también. Al menos en C++ 03, la implementación de una biblioteca adolece de fallas, como usted señaló, que podría justificar una implementación de lenguaje central. Sin embargo, ¿se podría hacer una mejor implementación de la biblioteca en C++ 0x?

Así que sospecho que el problema principal es realmente una falta de interés. C++ ya es un lenguaje enorme, y nadie quiere que crezca a menos que las características que se agregan sean realmente vale la pena. Sospecho que esto no es lo suficientemente útil.

Answer 7

primero con @Potatoswatter.

Para apoyar coroutine no es lo mismo que soporte para lambdas y no es que simple transformación como jugado con el dispositivo de Duff.

Necesita full asymmetric coroutines (stackful) para funcionar como generadores en Python. La implementación de Simon Tatham's y Chris' no son apilables, mientras que Boost.Coroutine es muy compacta, aunque es pesada.

Desafortunadamente, C++ 11 todavía no tienen yield para corrutinas aún, tal C++ 1a;)

PD: Si realmente te gusta generadores de estilo de Python, echar un vistazo a this.

Answer 8

Parece que no se convirtió en C++ 11 o C++ 14, pero podría estar en camino a C++ 17. Eche un vistazo a la conferencia C++ Coroutines, a negative overhead abstraction de CppCon2015 y el documento here.

En resumen, están trabajando para extender las funciones de C++ para tener rendimiento y esperar como características de las funciones. Parece que tienen una implementación inicial en Visual Studio 2015, no estoy seguro de si clang todavía tiene una implementación. También parece que puede haber algunos problemas con el uso del rendimiento y esperar como palabras clave.

La presentación es interesante porque habla sobre cuánto simplificó el código de red, donde está esperando que ingresen los datos para continuar la secuencia de procesamiento. Sorprendentemente, parece que usar estos nuevos resultados de corutinas en un código más rápido/menos de lo que se haría hoy. Es una gran presentación.

La propuesta de funciones reanudables para C++ se puede encontrar en here.