impulso vs comparación de rendimiento de plataforma cruzada ACE C++?
performance boost (11)
Cuando se trata de facilidad de uso, el impulso es mucho mejor que ACE. boost-asio tiene una API más transparente, sus abstracciones son más simples y pueden proporcionar bloques de construcción a su aplicación. El polimorfismo en tiempo de compilación se usa juiciosamente para potenciar / prevenir el código ilegal. Los usos de las plantillas de ACE, por otro lado, se limitan a la generalización y casi nunca están lo suficientemente centrados en el usuario como para no permitir operaciones ilegales. Es más probable que descubras problemas en el tiempo de ejecución con ACE.
Un ejemplo simple en el que puedo pensar es ACE_Reactor, una interfaz bastante escalable y desacoplada, pero debe recordar llamar a su función "propia" si está ejecutando su bucle de evento en un hilo diferente de donde fue creado. Pasé horas para resolver esto por primera vez y podría haber pasado días fácilmente. Irónicamente, su modelo de objetos muestra más detalles de los que esconde: buenos para el aprendizaje pero malos para la abstracción.
https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
Estoy involucrado en una empresa que transferirá algunas comunicaciones, análisis y funcionalidad de manejo de datos de Win32 a Linux, y ambos serán compatibles. El dominio del problema es muy sensible al rendimiento y rendimiento.
Tengo muy poca experiencia con las características de rendimiento de boost y ACE. Específicamente, queremos entender qué biblioteca ofrece el mejor rendimiento para el enhebrado.
¿Puede alguien proporcionar algunos datos, documentados o de boca en boca o tal vez algunos enlaces, sobre el rendimiento relativo entre los dos?
EDITAR
Gracias a todos. Confirmamos nuestras ideas iniciales: lo más probable es que elijamos impulsar las cosas multiplataforma a nivel del sistema.
Empezamos a usar ACE creyendo que ocultaría las diferencias de plataforma presentes entre Windows y Unix en sockets TCP y la llamada de selección. Resulta que no. El enfoque de Ace sobre select, el patrón del reactor, no puede mezclar sockets y stdin en windows, y las diferencias semánticas entre las plataformas con respecto a las notificaciones de escritura de socket aún están presentes en el nivel de ACE.
Cuando nos dimos cuenta de esto, ya estábamos usando las funciones de subprocesos y procesos de ACE (este último no oculta las diferencias de la plataforma en la medida en que nos hubiera gustado), de modo que nuestro código ahora está vinculado a una gran biblioteca que en realidad ¡previene la transferencia de nuestro código a 64 Bit MinGW!
No puedo esperar al día en que el último uso de ACE en nuestro código finalmente sea reemplazado por algo diferente.
Enhebrar es realmente solo una pequeña parte de lo que potencian y ACE, y los dos no son realmente comparables en general. Estoy de acuerdo en que impulsar es más fácil de usar, ya que ACE es un marco bastante pesado.
Hazte un favor y mantente alejado de ACE. Es una biblioteca horrible, horrible que nunca debería haber sido escrita, si me preguntas. Trabajé (o más bien TENÍA que trabajar con él) durante 3 años y te digo que es una pieza de basura mal diseñada, mal documentada y mal implementada que usa C ++ arcaico y que se basa en decisiones de diseño totalmente con muerte cerebral ... llamando a ACE "C con clases" en realidad lo está haciendo un favor. Si observa las implementaciones internas de algunos de sus constructos, a menudo le costará suprimir el reflejo nauseoso. Además, no puedo enfatizar lo suficiente el aspecto de "documentación deficiente". Usualmente, la noción de ACE de documentar una función consiste simplemente en imprimir la firma de la función. En cuanto al significado de sus argumentos, su valor de retorno y su comportamiento general, bueno, por lo general, se queda solo para resolverlo por su cuenta. Estoy harto y cansado de tener que adivinar qué excepciones puede arrojar una función, cuyo valor de retorno denota éxito, qué argumentos tengo que aprobar para que la función haga lo que necesito o si una función / clase es segura para subprocesos o no.
Boost por otro lado, es simple de usar, C ++ moderno, extremadamente bien documentado, ¡Y FUNCIONA! Boost es el camino a seguir, ¡abajo con ACE!
He estado usando ACE durante muchos años (8) pero acabo de comenzar a investigar el uso de boost nuevamente para mi próximo proyecto. Estoy considerando aumentar porque tiene una bolsa de herramientas más grande (regex, etc.) y partes de ella están siendo absorbidas en el estándar de C ++ por lo que el mantenimiento a largo plazo debería ser más fácil. Dicho esto, el impulso va a requerir algún ajuste. Aunque Greg menciona que el soporte de subprocesos es menos invasivo ya que puede ejecutar cualquier función (C o estática), si está acostumbrado a usar clases de subprocesos más parecidas a las clases de subprocesos Java y C # que es lo que proporciona ACE_Task, tiene usar un poco de delicadeza para obtener lo mismo con el impulso.
He usado ACE para numerosos servidores de producción de servicio pesado. Nunca me falló. Es sólido como una roca y hace el trabajo por muchos años. Traté de aprender el marco de red ASIO de BOOST. No pude entenderlo. Mientras que BOOST es más "moderno" C ++, también es más difícil de usar para tareas no triviales, y sin una experiencia "moderna" de C ++ y un profundo conocimiento de STL, es difícil usarlo correctamente.
Incluso si ACE es una especie de C ++ de la vieja escuela, todavía tiene muchas características orientadas a subprocesos que el impulso aún no proporciona.
Por el momento no veo ninguna razón para no usar ambos (pero para diferentes propósitos). Una vez que el impulso proporcione un medio simple para implementar colas de mensajes entre las tareas, puedo considerar abandonar ACE.
Ninguna de las bibliotecas debería tener gastos generales en comparación con el uso de las instalaciones nativas de enhebrado del sistema operativo. Deberías mirar qué API es más limpia. En mi opinión, la API de subprocesos API es significativamente más fácil de usar.
ACE tiende a ser más "OO clásico", mientras que el impulso tiende a extraerse del diseño de la biblioteca estándar de C ++. Por ejemplo, iniciar un hilo en ACE requiere crear una nueva clase derivada de ACE_Task y anular la función svc () virtual a la que se llama cuando se ejecuta el hilo. En el impulso, creas un hilo y ejecutas la función que quieras, que es significativamente menos invasiva.
No llamaría a ACE "C con clases". ACE no es intuitivo, pero si te tomas tu tiempo y usas el marco como es debido, no te arrepentirás.
Por lo que puedo decir, después de leer los documentos de Boost, me gustaría usar el marco de ACE y las clases de contenedor de Boost.
No se preocupe por la sobrecarga de una capa de abstracción de SO en objetos de subprocesamiento y sincronización. Threading literalmente no importa en absoluto (ya que solo se aplica a la creación de subprocesos, que ya es enormemente lenta en comparación con la sobrecarga de un indirecto puntero pimpl -ized). Si encuentra que las operaciones mutex le están ralentizando, es mejor que observe las operaciones atómicas o reorganice sus patrones de acceso a los datos para evitar la contención.
Con respecto a la mejora con respecto a ACE, se trata de una programación de "estilo nuevo" frente a "estilo antiguo". Boost tiene muchas trampas basadas en plantillas basadas en plantillas (que son hermosas para trabajar, si puedes apreciarlas). Si, por otro lado, estás acostumbrado al estilo "C con clases" de C ++, ACE se sentirá mucho más natural. Creo que es principalmente una cuestión de gusto personal para su equipo.
Use ACE y aumente cooperativamente. ACE tiene una mejor API de comunicación, basada en patrones de diseño de OO, mientras que boost tiene un diseño similar al "C ++ moderno" y funciona bien con contenedores, por ejemplo.