¿Es C notablemente más rápido que C ++ [cerrado]

82

Hasta donde yo entiendo, todos los lenguajes de scripting y los programas científicos básicos generalmente se escriben en C; esto hace que la implementación sea complicada pero de una manera directa al grano.

Entiendo que a estas personas les gustaría maximizar su rendimiento, pero ¿hay una diferencia real entre usar cadenas C y estructuras C y usar clases C ++? C ++ parece funcionar de la misma manera, aparte de las funciones virtuales, almacena una función de clase una vez y cada instancia de esa clase llama a esa función.

¿Qué hace que C sea más rápido y es una diferencia notable en un proyecto como python o sqlite que tienen que ser los más rápidos?

c++ c performance

— Will03uk
fuente

8

"Solo debe hacer preguntas prácticas y de respuesta basadas en problemas reales que enfrenta". - Preguntas frecuentes de stackoverflow.

— RedGrittyBrick

4

@Will - No. "Es un idioma más rápido que otro" es incontestable. Los idiomas no son rápidos, solo sus implementaciones. "¿Es la implementación X de un lenguaje más rápida que la implementación Y de otro?" se puede responder mediante la elaboración de perfiles, pero ¿qué perfila? Las implementaciones del lenguaje pueden ser rápidas o lentas en una variedad de áreas y sin duda es imposible probarlas todas. Una mejor pregunta sería "¿Por qué los diseñadores de lenguajes eligen el lenguaje X en lugar del lenguaje Y?" Eso tiene una respuesta clara (los fundamentos dados por diferentes diseñadores de lenguajes) y es más probable que sea útil.

— Chris Lutz

3

El mismo código en C y C ++ normalmente debería ejecutarse exactamente a la misma velocidad, con la excepción del código que tiene una semántica diferente debido a diferentes reglas de alias, etc. La diferencia está entre los modismos de C y los modismos de C ++. Si escribe código con las mejores prácticas idiomáticas de C en C o C ++, generalmente será mucho más ligero y rápido (y tendrá menos casos de falla que manejar) que una funcionalidad similar escrita con las mejores prácticas idiomáticas de C ++ (independientemente de si la escribe en C o C ++), pero probablemente le llevará mucho más trabajo escribirlo.

— R .. GitHub DEJA DE AYUDAR A ICE

7

C es notablemente más rápido de aprender en su totalidad que C ++;)

— fredoverflow

2

@Gracchus Estamos hablando de dos cosas diferentes aquí. Realizar tareas comunes es mucho más fácil en C ++ gracias a los contenedores estándar y RAII y todo eso. Solo digo que el lenguaje en sí es mucho más grande que C. Si su objetivo es aprender C ++ en su totalidad hasta un punto en el que pueda tomar programas arbitrarios de C ++ escritos por otra persona y entenderlos, se necesitan varios años (aproximadamente 10 según muchos) de aprender C ++. Por otro lado, aprender todas las complejidades de C puede llevar un par de semanas o meses como máximo, porque simplemente no hay tanta complejidad de lenguaje en C.

— fredoverflow

63

C ++ se usa a menudo para programas científicos. La popularidad de C puede estar disminuyendo en ese dominio. Fortran sigue siendo popular como lenguaje de "bajo nivel".

En C ++, "solo paga por lo que usa". Así que no hay nada que lo haga más lento que C. En particular para los programas científicos, las plantillas de expresión permiten realizar algunas optimizaciones personalizadas utilizando el motor de plantillas para procesar la semántica del programa.

La razón por la que se elige C para proyectos como Python es que muchas personas lo entienden (relativamente) completamente, por lo que una gran base de código no confundirá a muchos de los muchos colaboradores.

SQLite tiene un requisito para un tamaño de código ejecutable pequeño, donde C tiene una ligera ventaja. El uso sensato de C ++ aún permite su uso en aplicaciones integradas, pero es menos popular debido al temor de que aparezcan características de lenguaje no deseadas.

— Potatoswatter
fuente

9

Tenga en cuenta que C ++ modifica los nombres, mientras que C no lo hace, esto facilita que otros lenguajes interactúen con C directamente. (Swig en realidad crea una interfaz C para el código C ++ antes de crear la envoltura de Python para la biblioteca C ++).

— Sam P

7

@Samp C ++ tiene una función para desactivar el nombre de mangling, extern "C". Swig usa C como lengua franca, pero podría implementar ese contenedor dentro del subconjunto compatible con C de C ++ y nunca invocar un compilador de C.

— Potatoswatter

26

No creo que la razón esté tanto relacionada con el rendimiento como con la interoperabilidad. El lenguaje C ++ es más complejo que el lenguaje C, pero desde el punto de vista del rendimiento no debería haber una diferencia notable de ninguna manera. Algunas construcciones de C ++ son más rápidas que el equivalente de C ( std::sortes más rápido que qsort) y probablemente haya buenos ejemplos al revés.

EDITAR: En el lado de la interoperabilidad ...

Básicamente, el estándar C ++ no define algunas de las cosas que podrían ser necesarias para una fácil interoperabilidad entre binarios creados con diferentes compiladores / versiones. El problema más notable aquí sería la convención de nomenclatura para los símbolos en el binario. En C, el lenguaje define una sola asignación de cada símbolo en código al nombre del símbolo binario. Una función llamada my_functioncreará un símbolo en el binario llamado my_function. Por otro lado, y debido a características como la sobrecarga de funciones, los nombres de las funciones de C ++ deben ser mutilados(traducido a diferentes símbolos de función en el binario, codificando los tipos de argumentos y tipos de retorno), y el estándar no define cómo se realiza la alteración. Eso, a su vez, significa que la misma función en C ++ se puede compilar en diferentes símbolos según el compilador (a menos que extern "C"se use para forzar la interoperabilidad de C para esas funciones en C ++).

Al final del día, la interfaz entre el lenguaje de programación y el código nativo tendría que ser una interfaz C de todos modos, incluso si los detalles de cómo se implementa internamente podrían ser C / C ++ / cualquier otro idioma nativo.

(Intencionalmente no quiero entrar en una guerra de pretensiones lingüísticas, C ++ es realmente poderoso, pero también da un poco de miedo ya que es un lenguaje mucho más complejo que C, y algunas cosas que parecen simples pueden tener un impacto en actuación)

— David Rodríguez - dribeas
fuente

1

Creo que uno puede decir con seguridad que el C ++ moderno e idiomático requiere un compilador inteligente para aprovechar al máximo el inlining, RVO, el plegado constante, etc. Con eso, es muy posible que las construcciones de C ++ de gran peso no se noten en absoluto en el nivel de máquina, pero un buen compilador es mucho más importante para C ++ que para C.

— Kerrek SB

@Kerrek SB: La mayoría de los compiladores modernos de C ++ (donde moderno significa en los últimos años) son realmente buenos para identificar construcciones idiomáticas de C ++ y optimizar. El std::sortes uno de esos ejemplos: el std::lessfunctor usado por defecto no es menos eficiente que la función C equivalente, pero todos los compiladores que conozco lo integrarán (siendo una plantilla, está disponible para la inserción) y eliminarán todas las llamadas de función al comparefunctor.

— David Rodríguez - dribeas

Curiosamente, la biblioteca EASTL de Electronic Arts está parcialmente justificada por la afirmación de que encontraron que GCC era malo en la alineación (y que MSVC era mucho mejor) y que, por lo tanto, la biblioteca estándar incurriría en demasiadas llamadas a funciones no optimizadas. En EASTL utilizan menos indirectas para combatir esto. Quién sabe qué tan bien se sostiene ese razonamiento hoy en día.

— Kerrek SB

12

Como mencionó Bjarne en [D&E], la efectividad es uno de los principales objetivos de C ++. Entonces C ++ es más lento solo cuando el programador usa sus funciones "adicionales" como las funciones virtuales que mencionaste, información rtt, etc.

Así que creo que es más por razones psicológicas: se usa C porque no permite funciones de C ++ "lentas".

— burlar
fuente

9

Los lenguajes no son intrínsecamente más rápidos o más lentos, los intérpretes y compiladores pueden ser más o menos eficientes.

Además de eso, los lenguajes de nivel superior proporcionan capas de abstracción que generalmente tienen un costo de tiempo de ejecución. Si no los está usando, el compilador podría ser lo suficientemente inteligente como para eliminarlos, pero eso podría no ser posible si la semántica del lenguaje no permite hacerlo de manera segura ... Y si los necesita, impleméntelos usted mismo en un idioma de nivel inferior probablemente será más lento que usar el idioma "lento".

— fortran
fuente

24

Los lenguajes con

— secuencias de comandos son heredadamente

2

@ Will03uk - ¿Qué le impide escribir un compilador para un lenguaje que suele estar escrito en scripts?

— Chris Lutz

5

@Chris entonces no sería un lenguaje escrito; las implicaciones de un lenguaje con script es que se interpreta o se compila con un código de bytes. Una vez que lo compila, ¿no es un lenguaje compilado

— Will03uk

1

esta no es toda la verdad: la semántica del lenguaje es importante porque determina la información disponible para el optimizador y qué suposiciones se pueden hacer de manera segura sin tener que realizar un análisis de todo el programa; caso en cuestión: la restrictpalabra clave en C o luajit: este último no elimina a todos los demás vm para lenguajes dinámicos solo porque Mike es un tipo inteligente, sino también porque la semántica de Lua es bastante limpia (en comparación con, por ejemplo, JavaScript)

— Christoph

1

@Christoph Lo que estoy tratando de decir es que no hay una fórmula mágica. Si necesita cosas como despacho dinámico, llamadas virtuales, carga en caliente de código o escritura rápida, un lenguaje que puede parecer "lento" al proporcionarlo de fábrica es probablemente más rápido que una implementación ingenua en C.

— fortran