¿Rust es más rápido que C?

 (steveklabnik.com)
13 puntos por GN⁺ 2026-01-15 | 9 comentarios | Compartir por WhatsApp
  • La comparación de rendimiento entre Rust y C es una cuestión compleja que depende de cómo se defina la premisa de que “todas las condiciones son iguales”
  • En el caso del ensamblador en línea, ambos lenguajes pueden generar el mismo código ensamblador, por lo que no hay una diferencia de velocidad propia del lenguaje
  • En la disposición de memoria de structs, Rust puede tener un tamaño menor al reordenar campos, aunque también puede usar el mismo layout que C con el atributo #[repr(C)]
  • Debido a las diferencias en las comprobaciones en tiempo de ejecución y el comportamiento de los desarrolladores, la estructura del código y el rendimiento pueden variar en proyectos reales
  • En conclusión, no hay una diferencia de rendimiento causada por limitaciones propias del lenguaje; el resultado cambia según el proyecto y los factores humanos

Planteamiento del problema y ambigüedad de la premisa

  • El punto de partida es la pregunta planteada en Reddit: “si las condiciones son las mismas, ¿puede Rust ser más rápido que C?”
  • La expresión “todas las condiciones son iguales” es, en sí misma, un concepto muy difícil de definir al comparar lenguajes
  • La comparación de rendimiento depende no solo de las diferencias del lenguaje, sino también de la forma del código, las decisiones de desarrollo y la optimización del compilador

Comparación de ensamblador en línea

  • Rust admite ensamblador en línea a nivel del lenguaje, mientras que C lo implementa mediante extensiones del compilador
    • En ambos lenguajes se puede escribir el mismo ejemplo usando la instrucción rdtsc
    • El ensamblador generado por rustc 1.87.0 y clang 20.1.0 se muestra con una forma completamente idéntica
  • Este caso no demuestra una diferencia de rendimiento entre lenguajes, pero sí prueba que Rust puede realizar control de bajo nivel al mismo nivel que C

Diferencias en el layout de structs

  • Los structs de Rust pueden optimizar el uso de memoria reordenando campos
    • En el ejemplo, el struct de Rust se calcula en 16 bytes, mientras que el mismo struct en C resulta en 24 bytes
  • En C, hay que cambiar manualmente el orden de los campos para obtener el mismo tamaño
  • Si se usa el atributo #[repr(C)] en Rust, se puede forzar el mismo layout de memoria que en C

Factores sociales y del desarrollador

  • Gracias a las comprobaciones de seguridad de Rust, hay casos en los que los desarrolladores pueden intentar optimizaciones más agresivas
    • En el proyecto Stylo de Mozilla, dos intentos de paralelización en C++ fracasaron, pero en Rust se implementó con éxito
  • Incluso en un mismo proyecto, el rendimiento y la estabilidad del código resultante pueden variar según el lenguaje y la experiencia del desarrollador
  • Como el resultado de “la misma tarea” cambia según si quien la hace es principiante o experto, y según su dominio del lenguaje, una comparación simple es difícil

Comprobaciones en compilación y en ejecución

  • Muchas de las comprobaciones de seguridad de Rust se realizan en tiempo de compilación, pero algunas permanecen como comprobaciones en tiempo de ejecución
    • Por ejemplo, al acceder a array[0], Rust realiza una verificación de límites, mientras que C no lo hace
    • Si se usa get_unchecked() en Rust, se puede obtener el mismo comportamiento que en C
  • Cuando el compilador puede demostrar la seguridad, ambos lenguajes pueden eliminar las comprobaciones mediante optimización
  • Estas diferencias influyen en la forma de escribir el código y, como resultado, pueden provocar diferencias de rendimiento

Conclusión

  • Incluso si se asumiera que C es “el lenguaje más rápido”, no hay razón para que Rust no pueda alcanzar el mismo nivel de rendimiento
  • Más que las limitaciones del lenguaje, son las características del proyecto, la capacidad del desarrollador, las restricciones de tiempo y otras variables externas las que determinan la diferencia de rendimiento
  • Por lo tanto, la pregunta “¿Rust es más rápido que C?” se interpreta mejor como un problema de contexto de ingeniería que como una simple comparación de lenguajes

Lecturas relacionadas

9 comentarios

 
GN⁺ 2026-01-15
Opiniones en Hacker News

  • En resumen, la velocidad máxima es casi la misma, pero en código real hay una gran diferencia.
    En especial, el multithreading es una variable muy importante. En Rust, todas las variables globales deben ser seguras para hilos, se usen o no, y el borrow checker limita el acceso a memoria a compartir o modificar, pero no ambas cosas a la vez.
    Por eso, escribir código multihilo en Rust es casi lo normal. En cambio, en C crear hilos ya implica una carga por temas de compatibilidad entre plataformas y riesgos al depurar.

    • Si soy sincero, creo que esta diferencia se debe sobre todo a la comodidad de la librería estándar.
      En C no es tan difícil crear hilos, pero sí es más engorroso que en Rust con std::thread::spawn(move || { ... });
      Más que la seguridad de memoria, influye más el modelo de concurrencia del lenguaje. Go permite paralelizar fácilmente con go f() aunque no sea memory-safe.
      Personalmente, he visto más heisenbugs en Go.
    • Además del multithreading, me pregunto si el sistema de tipos de Rust ofrece más información y por eso deja más margen para optimizar.
    • En realidad, con una sola línea como #pragma omp for también se puede paralelizar fácilmente en C.
    • Todavía me confunde por qué hace falta enlazar TBB para hacer multithreading en Linux. Siento que debería venir incluido por defecto.
    • Si se agregan hilos sin control, también hay que pensar en el consumo de energía y las condiciones de carrera.

  • Gracias a los traits de Rust, se pueden crear abstracciones más rápidas y flexibles.
    En C se puede imitar con macros o punteros a función, pero en Rust quien llama puede elegir entre despacho dinámico o despacho estático.
    En entornos embebidos, los punteros a función perjudican la caché y reducen el rendimiento, mientras que los traits de Rust permiten optimización por inline y resultan mucho más eficientes.

    • También me gusta hacer hacking con ELF, pero para rendimiento hay que conocer bien el linker, el ABI y el formato binario.
      Tanto en Rust como en C, al final hay que trabajar a nivel de bytes, y hoy en día las herramientas de parcheo binario también han mejorado mucho y son fáciles de aprovechar.
    • Claro, en Rust también, si usas Box<dyn Trait> en la firma de una función, obligas a quien llama a usar despacho dinámico.
      Si usas impl Trait, la elección queda del lado del llamador.
    • Eso sí, usar muchos traits hace que el tiempo de compilación aumente de forma notable. Cuanto más complejo el trait, más lenta la compilación.
    • El enfoque al estilo C directamente consiste en evitar la abstracción.

  • Personalmente, veo a Rust, C y C++ casi como parte de la misma familia de lenguajes de bajo nivel, así que la diferencia de rendimiento me parece mínima.
    Las reglas estrictas de aliasing de Rust favorecen la optimización, y el UB (comportamiento indefinido) de C/C++ existe en parte por rendimiento.
    Además, los genéricos de Rust y C++ son mucho más potentes que en C, así que, por ejemplo, es más fácil optimizar por inline un ordenamiento basado en plantillas que qsort().

    • Las plantillas de C++ siguen teniendo más expresividad que Rust, aunque la brecha se va reduciendo.
    • En realidad, esto es más un tema de diseño de la librería estándar que del lenguaje. También en C se puede hacer a mano una función de ordenamiento que permita inline.
    • El manejo de overflow de enteros en Rust sigue el comportamiento predeterminado de la plataforma, así que el resultado puede variar según la optimización.
    • El lenguaje es solo un medio para describir comportamiento; la velocidad real depende del compilador y del entorno de ejecución.
    • La diferencia de rendimiento entre los tres lenguajes al final es una cuestión de eficiencia frente al esfuerzo. C es rápido, pero el costo de desarrollo es alto, y Rust queda más o menos en medio.

  • Creo que este tipo de debates de velocidad entre lenguajes casi siempre carecen de sentido.
    Más que el lenguaje en sí, lo que determina el rendimiento es la implementación del compilador.

    • Aun así, el diseño del lenguaje influye mucho en las posibilidades de optimización. Un “compilador suficientemente inteligente” sigue siendo poco más que un mito.

  • Rust, C y C++ son todos lenguajes de bajo nivel, pero importa cómo se define eso de “rápido”.
    No es lo mismo hablar de la velocidad máxima de código optimizado por un experto que de la probabilidad de que un desarrollador promedio escriba código rápido dentro del presupuesto.

    • En la práctica, la clave está en la capacidad de optimización del compilador. La semántica de memoria de Rust es más rica, así que el compilador puede obtener más información para optimizar.
      Pero si se optimiza manualmente, las diferencias entre lenguajes casi desaparecen.
      Aun así, Rust tiene una ligera ventaja porque es un lenguaje en el que es más fácil escribir código rápido.
    • La mayoría usa la definición de “el lenguaje en el que un desarrollador promedio puede escribir código rápido”.
    • Quienes diseñan lenguajes sí piensan en “qué tan rápido será el código típico en este lenguaje”, así que me parece una pregunta válida.

  • Yo pensaba que la ventaja de Rust estaba en el multithreading y la asignación en stack.
    Gracias al modelo de ownership, se pueden poner más cosas en el stack que en C/C++, reduciendo la sobrecarga de malloc/free.

    • Sí, pero esta discusión se enfocó más en una comparación conceptual desde la perspectiva del diseño del lenguaje que en diferencias concretas de ese tipo.
      Como estos temas suelen provocar debates emocionales, quise hablar más de diferencias de enfoque que de cifras específicas.

  • Al hablar de la “velocidad” de un lenguaje, hay que mirar dos cosas:

    1. qué costos inyecta el lenguaje en el programa
    2. qué optimizaciones hace posibles el lenguaje
      Rust y C casi no tienen checks en runtime, así que son más rápidos que Python o JS.
      Aun así, Rust transmite mejor la información de aliasing, lo que deja más margen para optimizar.
      En modo debug puede ser tan lento como Ruby, pero en modo release alcanza velocidades del nivel de C.
    • Me gusta esta perspectiva. También se conecta con la idea de zero-cost abstraction de C++.
    • JS también está muy optimizado, pero sigue siendo algo más lento que Rust/C.
    • Otra pregunta es “qué tan rápido es cuando lo usa un desarrollador común”. Importa si el lenguaje guía de forma natural hacia código rápido.

  • C++ y Rust tienen más funcionalidades en tiempo de compilación que C, por lo que es más fácil escribir código rápido.
    Por ejemplo, este código en C es casi imposible.

  • Como ensamblador no forma parte del estándar de C, es difícil compararlo directamente con Rust, y Rust en realidad se parece más al proyecto GCC en su naturaleza.

  • Que un lenguaje sea “rápido” al final depende de la implementación y el contexto.
    Más que la velocidad del lenguaje en sí, influye mucho más la combinación de compilador y hardware.
 
aer0700 2026-01-16

No sé qué lenguaje será el más rápido en promedio, pero me parece que la dispersión más grande la tendría C++.
 
jokerized 2026-01-16

En sistemas embebidos se programa incluso considerando el tamaño de la línea de caché del hardware. Al final, esto depende de hasta dónde puede llegar el programador con optimizaciones extremas por encima del lenguaje, además del rendimiento de la biblioteca estándar y del compilador; de todos modos, como ambos soportan bajo nivel, parece que la diferencia de overhead sería mínima. Por eso no parece una discusión muy significativa... Si se necesita una optimización al límite, al final hace falta intervención humana. Los compiladores no son tan perfectos como uno imagina.
 
iolothebard 2026-01-15

Creo que Rust terminará siendo más un reemplazo de C++ que de C. C es prácticamente el único (quizá el último) lenguaje en el que se puede anticipar el código que generará el compilador…
 
secret3056 2026-01-16

Zig tampoco está mal... :'(
 
iolothebard 2026-01-15

Al escribirlo, terminé usando un estilo de resumen de IA :(
 
galadbran 2026-01-16

¿No lo hizo a propósito? Jeje
 
winmain 2026-01-15

Eso depende de la capacidad del compilador.

Si ensamblas el mismo código, se verá.
 
jjw9512151 2026-01-15

Parece que la gente de ffmpeg no cree que rust sea más rápido que c jajaja https://www.memorysafety.org/blog/rav1d-perf-bounty/