ps4 - rust traduccion

¿Por qué los programas Rust usan mucha más memoria que las versiones C, Haskell y OCaml?

Question

Miré la cantidad de RAM utilizada por los programas de Rust (columna RES del comando top ) y me pregunto por qué usan tanta memoria.

Aquí hay un ejemplo:

use std::io;
fn main() {
println!("What''s your name?");
let mut input = String::new();
io::stdin().read_line(&mut input).unwrap();
println!("Hello {}!", input);
}

Vi que se usaron 6 MB de memoria antes de ingresar algo.

Aquí es cómo compilé y ejecuté el programa:

cargo build --release
./target/release/main

El programa C equivalente:

#include <stdio.h>
int main(void) {
printf("What''s your name?/n");
char input[100] = {0};
scanf("%s", input);
printf("Hello %s!/n", input);
return 0;
}

solo usa 0.6 MB. En este caso, el programa Rust usa 10 veces más memoria. En otros casos, vi que el programa Rust usa 5 veces más memoria.

También probé con otros idiomas para comparar.

La versión OCaml:

let () =
print_endline "What''s your name?";
let line = read_line () in
print_string "Hello ";
print_endline line

usa 1 MB.

La versión Haskell:

main = do
putStrLn "What''s your name?"
name <- getLine
putStrLn ("Hello " ++ name ++ "!")

usa 3 MB.

La versión de Python:

print("What''s your name?")
name = input()
print("Hello", name, "!")

usa 7 MB, casi lo mismo que la versión Rust!

Actualizar

Estoy ejecutando Linux (ArchLinux) con Rust 1.3 (también probé la noche con resultados similares).

Actualización 2

Aquí hay más datos del comando htop :

VIRT RES SHR MEM% Command
15572 2936 804 0.1 ocaml
21728 2732 2528 0.1 haskell
22540 7480 4308 0.2 python
4056 668 600 0.0 c
24180 6164 1928 0.2 rust

Actualización 3

Hice más pruebas con massif para ver el uso de la memoria.

Para cada programa, ejecuté massif dos veces, de la siguiente manera:

valgrind --tool=massif --time-unit=B ./program
valgrind --tool=massif --pages-as-heap=yes --time-unit=B ./program

Aquí están los resultados con todos los programas (como se muestra en ms_print ):

Versiones C:

https://framabin.org/?dd243f8ec99155bc#Af5cPrcHnz3DsWiOStfwgW8Qq6BTVhogz/46L+sMuSs=

https://framabin.org/?261b9366c3749469#1ztDBkgVly9CanrrWWrJdh3yBFL5PEIW3OI5OLnze/Q=

Versiones de óxido:

https://framabin.org/?0f1bac1c750e97bf#AXwlFYYPHeazq9LfsTOpRBaUTTkb1NfN9ExPorDJud0=

https://framabin.org/?c24b21b01af36782#OLFWdwLjVG2t7eoLqLFhe0Pp8Q8pA2S/oq4jdRRWPzI=

Versiones OCaml:

https://framabin.org/?060f05bea318109c#/OJQ8reHCU3CzzJ5NCOCLOYJQFnA1VgxqAIVjgQWX9I=

https://framabin.org/?8ff1ffb6d03cb37a#GN8bq3Wrm6tNWaINIhMAr4ieltLtOPjuZ4Ynof9bV4w=

Versiones Haskell:

https://framabin.org/?b204bd978b8c1fd8#DyQH862AM8NEPTKlzEcZgoapPaZLdlF9W3dRn47K5yU=

https://framabin.org/?ac1aa89fcaeb782c#TQ+uAiqerjHuuEEIhehVitjm63nc3wu5wfivAeBH5uI=

Versiones de Python:

https://framabin.org/?197e8b90df5373ec#aOi0+tEj32Na5jW66Kl97q2lsjSZ2x7Cwl/pOt0lYIM=

https://framabin.org/?397efa22484e3992#1ylOrmjKaA9Hg7gw7H7rKGM0MyxuvKwPNN1J/jLEMrk=

Resumen (uso de ram):

|------------|----------|----------|----------|----------|----------|
| | C | Haskell | OCaml | Rust | Python |
|------------|----------|----------|----------|----------|----------|
| First run | 1 B | 63.12 KB | 5.993 MB | 816 B | 1.321 MB |
|------------|----------|----------|----------|----------|----------|
| Second run | 6.031 MB | 24.20 MB | 17.14 MB | 25.60 MB | 27.43 MB |
|------------|----------|----------|----------|----------|----------|

La primera ejecución es sin el --pages-as-heap=yes .

También ejecuté massif con la opción --stacks=yes para C y Rust.

Versión C:

https://framabin.org/?b3009d198ccfdee1#HxR6LPPAzt15K+wIFdaqlfSJjBrJvhV2ZHWdElg3ezc=

(3.141 KB)

Versión de óxido:

https://framabin.org/?b446d8d76c279007#tHnGiOnRstTA2krhz6cgfvTjI+FclcZS3rqyZvquWdQ=

(8.602 KB)

¿Qué explica una diferencia tan grande entre la asignación de bloques de bloques y la asignación de páginas en Rust?

Answer 1

Porque la biblioteca estándar está vinculada estáticamente.

Puede superar esto compilando con la opción -C prefer-dynamic .

En cuanto al motivo detrás de la vinculación estática de la biblioteca estándar: aumenta la portabilidad del ejecutable (es decir, no es necesario instalar la biblioteca estándar en el sistema de destino).

Answer 2

Este artículo tiene una muy buena discusión del tema. Algunos de los culpables más grandes y más comunes son los valores predeterminados de la carga para depurar compilaciones (no son relevantes en su caso) y están incluidas de forma estática de manera predeterminada.