Cuando se usa el mismo código, simplemente cambiando el compilador (de un compilador C a un compilador C ++) cambiará la cantidad de memoria asignada. No estoy muy seguro de por qué es así y me gustaría entenderlo más. Hasta ahora, la mejor respuesta que he recibido es "probablemente las transmisiones de E / S", que no es muy descriptiva y me hace preguntarme sobre el aspecto "no paga por lo que no usa" de C ++.
Estoy usando los compiladores Clang y GCC, versiones 7.0.1-8 y 8.3.0-6 respectivamente. Mi sistema se ejecuta en Debian 10 (Buster), la última. Los puntos de referencia se realizan a través del macizo Valgrind.
#include <stdio.h>
int main() {
printf("Hello, world!\n");
return 0;
}
El código utilizado no cambia, pero si compilo como C o como C ++, cambia los resultados del benchmark Valgrind. Sin embargo, los valores permanecen consistentes entre los compiladores. Las asignaciones de tiempo de ejecución (pico) para el programa son las siguientes:
- CCG (C): 1,032 bytes (1 KB)
- G ++ (C ++): 73,744 bytes, (~ 74 KB)
- Clang (C): 1,032 bytes (1 KB)
- Clang ++ (C ++): 73,744 bytes (~ 74 KB)
Para compilar, uso los siguientes comandos:
clang -O3 -o c-clang ./main.c
gcc -O3 -o c-gcc ./main.c
clang++ -O3 -o cpp-clang ./main.cpp
g++ -O3 -o cpp-gcc ./main.cpp
Para Valgrind, ejecuto valgrind --tool=massif --massif-out-file=m_compiler_lang ./compiler-lang
en cada compilador e idioma, luego ms_print
para mostrar los picos.
¿Estoy haciendo algo mal aquí?
try
bloque a expensas de una huella de memoria más grande, tal vez con una tabla de salto o algo así. Tal vez intente compilar sin excepciones y ver qué impacto tiene. Editar: de hecho, intente deshabilitar iterativamente varias funciones de c ++ para ver qué impacto tiene en la huella de la memoria.
clang++ -xc
lugar de clang
, la misma asignación estaba allí, lo que sugiere que se debe a las bibliotecas vinculadas
C
modo y exactamente el mismo número de bytes en C++
modo. ¿Cometiste un error de transcripción?