¿Por qué algunos lenguajes de programación son "más rápidos" o "más lentos" que otros?

82

Me he dado cuenta de que algunas aplicaciones o algoritmos que se basan en un lenguaje de programación, por ejemplo, C ++ / Rust, se ejecutan más rápido o más rápido que los creados en Java, Node.js, que se ejecutan en la misma máquina. Tengo algunas preguntas con respecto a esto:

  1. ¿Por qué pasó esto?
  2. ¿Qué gobierna la "velocidad" de un lenguaje de programación?
  3. ¿Tiene esto algo que ver con la gestión de la memoria?

Realmente agradecería si alguien me explicara esto.

malvada patata
fuente
18
Tenga en cuenta que para JVM y CLR en particular, se ha realizado una extensa investigación para optimizar las máquinas virtuales, y pueden superar a C ++ compilado en muchas circunstancias, pero es fácil hacer una evaluación comparativa ingenua mal.
chrylis -on strike-
26
Dicho esto, agrupar Java y todo lo relacionado con Javascript es insultante.
Raphael
55
Estoy dividido entre cerrar esto como demasiado amplio (¡se pueden escribir libros de texto sobre los temas relevantes!) O duplicado . ¡Votos de la comunidad, por favor!
Raphael
44
Esta pregunta también es bastante similar, lo que determina la velocidad de un lenguaje de programación
vzn

Respuestas:

96

En el diseño y la implementación del lenguaje de programación, hay una gran cantidad de opciones que pueden afectar el rendimiento. Solo mencionaré algunos.

Finalmente, cada idioma debe ejecutarse ejecutando código de máquina. Un lenguaje "compilado" como C ++ se analiza, decodifica y traduce al código de máquina solo una vez, en tiempo de compilación. Un lenguaje "interpretado", si se implementa de forma directa, se decodifica en tiempo de ejecución, en cada paso, cada vez. Es decir, cada vez que ejecutamos una declaración, el intérprete tiene que verificar si es un if-then-else, o una asignación, etc. y actuar en consecuencia. Esto significa que si hacemos un bucle 100 veces, decodificamos el mismo código 100 veces, perdiendo el tiempo. Afortunadamente, los intérpretes a menudo optimizan esto mediante, por ejemplo, un sistema de compilación justo a tiempo. (Más correctamente, no existe un lenguaje "compilado" o "interpretado": es una propiedad de la implementación, no del lenguaje. Aún así,

Diferentes compiladores / intérpretes realizan diferentes optimizaciones.

Si el lenguaje tiene administración de memoria automática, su implementación debe realizar la recolección de basura. Esto tiene un costo de tiempo de ejecución, pero alivia al programador de una tarea propensa a errores.

Un lenguaje puede estar más cerca de la máquina, permitiendo que el programador experto micro-optimice todo y exprima más rendimiento de la CPU. Sin embargo, es discutible si esto es realmente beneficioso en la práctica, ya que la mayoría de los programadores en realidad no se optimizan micro y, a menudo, el compilador puede optimizar un buen lenguaje de nivel superior mejor que lo que haría un programador promedio. (Sin embargo, ¡a veces estar más lejos de la máquina también puede tener sus beneficios! Por ejemplo, Haskell tiene un nivel extremadamente alto, pero gracias a sus opciones de diseño puede presentar hilos verdes muy livianos).

La verificación de tipo estático también puede ayudar en la optimización. En un lenguaje interpretado de tipo dinámico, cada vez que se computa x - y, el intérprete a menudo tiene que verificar si ambos x,yson números y (por ejemplo) generar una excepción de lo contrario. Esta verificación se puede omitir si los tipos ya se verificaron en tiempo de compilación.

Algunos idiomas siempre informan errores de tiempo de ejecución de una manera sensata. Si escribe a[100]en Java donde atiene solo 20 elementos, obtendrá una excepción de tiempo de ejecución. En C, eso causaría un comportamiento indefinido, lo que significa que el programa podría fallar, sobrescribir algunos datos aleatorios en la memoria o incluso realizar absolutamente cualquier otra cosa (el estándar ISO C no plantea límites). Esto requiere una verificación de tiempo de ejecución, pero proporciona una semántica mucho mejor al programador.

Sin embargo, tenga en cuenta que, al evaluar un idioma, el rendimiento no lo es todo. No te obsesiones con eso. Es una trampa común intentar micro-optimizar todo, y aún así no detectar que se está utilizando un algoritmo / estructura de datos ineficiente. Knuth dijo una vez que "la optimización prematura es la raíz de todo mal".

No subestimes lo difícil que es escribir un programa correctamente . A menudo, puede ser mejor elegir un lenguaje "más lento" que tenga una semántica más amigable para los humanos. Además, si hay algunas partes críticas de rendimiento específicas, siempre se pueden implementar en otro idioma. Solo como referencia, en el concurso de programación ICFP 2016 , estos fueron los idiomas utilizados por los ganadores:

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

Ninguno de ellos usó un solo idioma.

chi
fuente
81
Una versión de toda la cita de Knuth : "Los programadores pierden enormes cantidades de tiempo pensando o preocupándose por la velocidad de las partes no críticas de sus programas, y estos intentos de eficiencia realmente tienen un fuerte impacto negativo cuando se consideran la depuración y el mantenimiento". Deberíamos olvidarnos de las pequeñas eficiencias, digamos alrededor del 97% del tiempo: la optimización prematura es la raíz de todo mal. Sin embargo, no debemos dejar pasar nuestras oportunidades en ese crítico 3% ".
Derek Elkins
66
Además, algunos lenguajes garantizan cosas aparentemente inocentes que pueden afectar la capacidad del compilador para optimizar, vea alias estricto en C ++ vs. FORTRAN
PlasmaHH
99
Me uní para poder votar el comentario de @DerekElkins. Demasiado a menudo falta el contexto de esa cita, a veces incluso llegando a la conclusión de que defiende que toda optimización es malvada.
tubería
99
@DerekElkins Irónicamente, te perdiste quizás la parte más importante: las dos oraciones que siguen inmediatamente. "Un buen programador no se dejará llevar por la complacencia por tal razonamiento, será prudente mirar cuidadosamente el código crítico; pero solo después de que se haya identificado ese código. A menudo es un error hacer juicios a priori sobre qué partes de un el programa es realmente crítico, ya que la experiencia universal de los programadores que han estado utilizando herramientas de medición ha sido que sus conjeturas intuitivas fallan ". PDF p268
8bittree
99
@DerekElkins Para ser claros, no quiero poner palabras en la boca que digan que estaban reclamando esto, pero con demasiada frecuencia me encuentro con personas que agregan solo un poco a la cita base y piensan que Knuth estaba abogando por la optimización prematura 3 El% de las veces, cuando el artículo completo deja en claro que siempre se opone a la optimización prematura, casi siempre se opone a las pequeñas optimizaciones, pero aboga por las pequeñas optimizaciones en secciones medidas como críticas.
8bittree
19

¿Qué gobierna la "velocidad" de un lenguaje de programación?

No existe la "velocidad" de un lenguaje de programación. Solo existe la velocidad de un programa particular escrito por un programador particular ejecutado por una versión particular de una implementación particular de un motor de ejecución particular que se ejecuta dentro de un entorno particular.

Puede haber grandes diferencias de rendimiento al ejecutar el mismo código escrito en el mismo idioma en la misma máquina usando diferentes implementaciones. O incluso usando diferentes versiones de la misma implementación. Por ejemplo, ejecutar exactamente el mismo punto de referencia ECMAScript en la misma máquina usando una versión de SpiderMonkey de hace 10 años frente a una versión de este año probablemente producirá un aumento de rendimiento en cualquier lugar entre 2 × –5 ×, tal vez incluso 10 ×. ¿Eso significa que ECMAScript es 2 veces más rápido que ECMAScript, porque ejecutar el mismo programa en la misma máquina es 2 veces más rápido con la implementación más reciente? Eso no tiene sentido.

¿Tiene esto algo que ver con la gestión de la memoria?

Realmente no.

¿Por qué pasó esto?

Recursos. Dinero. Microsoft probablemente emplea a más personas que preparan café para sus programadores compiladores que toda la comunidad PHP, Ruby y Python combinada tiene personas trabajando en sus máquinas virtuales.

Para más o menos cualquier característica de un lenguaje de programación que afecte el rendimiento de alguna manera, también hay una solución. Por ejemplo, C (estoy usando C aquí como sustituto de una clase de lenguajes similares, algunos de los cuales incluso existían antes de C) no es seguro para la memoria, por lo que múltiples programas de C que se ejecutan al mismo tiempo pueden pisotear la memoria del otro Entonces, inventamos memoria virtual y hacemos que todos los programas de C pasen por una capa de indirección para que puedan fingir que son los únicos que se ejecutan en la máquina. Sin embargo, eso es lento, por lo que inventamos la MMU e implementamos memoria virtual en hardware para acelerarla.

¡Pero! ¡Los idiomas seguros para la memoria no necesitan todo eso! Tener memoria virtual no les ayuda en nada. En realidad, es peor: la memoria virtual no solo no ayuda a los lenguajes seguros para la memoria, la memoria virtual, incluso cuando se implementa en hardware, también afecta el rendimiento. Puede ser especialmente perjudicial para el rendimiento de los recolectores de basura (que es lo que utilizan un número significativo de implementaciones de lenguajes seguros para la memoria).

Otro ejemplo: las CPU de uso general modernas y modernas emplean trucos sofisticados para reducir la frecuencia de errores de caché. Muchos de esos trucos equivalen a tratar de predecir qué código se ejecutará y qué memoria se necesitará en el futuro. Sin embargo, para los idiomas con un alto grado de polimorfismo de tiempo de ejecución (p. Ej., Lenguajes OO) es realmente muy difícil predecir esos patrones de acceso.

Pero, hay otra manera: el costo total de las fallas de caché es el número de fallas de caché multiplicado por el costo de una falla de caché individual. Las CPU convencionales intentan reducir la cantidad de fallas, pero ¿qué pasaría si pudiera reducir el costo de una falla individual?

La CPU Azul Vega-3 fue diseñada específicamente para ejecutar JVM virtualizadas, y tenía una MMU muy poderosa con algunas instrucciones especializadas para ayudar a la recolección de basura y la detección de escape (el equivalente dinámico al análisis de escape estático) y potentes controladores de memoria, y todo el sistema Todavía podría progresar con más de 20000 errores de caché pendientes en vuelo. Desafortunadamente, como la mayoría de las CPU específicas del idioma, su diseño fue simplemente gastado y forzado por los "gigantes" Intel, AMD, IBM y similares.

La arquitectura de la CPU es solo un ejemplo que tiene un impacto en lo fácil o difícil que es tener una implementación de alto rendimiento de un lenguaje. Un lenguaje como C, C ++, D, Rust que se ajuste bien al modelo de programación de CPU convencional moderno será más fácil de crear que un lenguaje que tenga que "luchar" y eludir la CPU, como Java, ECMAScript, Python, Ruby PHP.

Realmente, todo es cuestión de dinero. Si gasta la misma cantidad de dinero para desarrollar un algoritmo de alto rendimiento en ECMAScript, una implementación de alto rendimiento de ECMAScript, un sistema operativo de alto rendimiento diseñado para ECMAScript, una CPU de alto rendimiento diseñada para ECMAScript como se ha gastado durante el último décadas para hacer que los lenguajes tipo C sean rápidos, entonces es probable que vea un rendimiento igual. Es solo que, en este momento, se ha gastado mucho más dinero haciendo que los lenguajes similares a C sean rápidos que los lenguajes similares a ECMAScript rápidos, y las suposiciones de los lenguajes similares a C se incorporan a toda la pila desde MMU y CPU a sistemas operativos y sistemas de memoria virtual hasta bibliotecas y frameworks.

Personalmente, estoy más familiarizado con Ruby (que generalmente se considera un "lenguaje lento"), por lo que daré dos ejemplos: la Hashclase (una de las estructuras de datos centrales en Ruby, un diccionario de valores clave) en Rubinius La implementación de Ruby está escrita en Ruby 100% puro, y tiene aproximadamente el mismo rendimiento que elHashclase en YARV (la implementación más utilizada), que está escrita en C. Y hay una biblioteca de manipulación de imágenes escrita como una extensión C para YARV, que también tiene una "versión alternativa" pura (lenta) de Ruby para implementaciones que no no es compatible con C, que utiliza un montón de trucos de Ruby altamente dinámicos y reflexivos; una rama experimental de JRuby, que utiliza el marco de interpretación Truffle AST y el marco de compilación Graal JIT de Oracle Labs, puede ejecutar esa "versión alternativa" pura de Ruby tan rápido como el YARV puede ejecutar la versión C altamente optimizada original. Esto es simplemente (bueno, cualquier cosa menos) logrado por algunas personas realmente inteligentes que hacen cosas realmente inteligentes con optimizaciones dinámicas de tiempo de ejecución, compilación JIT y evaluación parcial.

Jörg W Mittag
fuente
44
Si bien técnicamente los lenguajes no son inherentemente rápidos, algunos lenguajes se centran más en permitir que el programador cree un código rápido. C está optimizado principalmente para CPU en lugar de al revés. Por ejemplo, C eligió el tamaño fijo ints por razones de rendimiento, a pesar del hecho de que los enteros ilimitados, como los utilizados por Python, son mucho más matemáticamente naturales. Implementar enteros ilimitados en hardware no sería tan rápido como los enteros de tamaño fijo. Los lenguajes que intentan ocultar los detalles de la implementación necesitan optimizaciones complejas para acercarse a las implementaciones ingenuas de C.
gmatht
1
C tiene un historial: fue creado para hacer que un sistema escrito en lenguaje ensamblador sea portátil a otros sistemas. Por lo tanto, el propósito original era proporcionar un "ensamblador portátil" para Unix, y estaba muy bien diseñado. Le fue tan bien desde 1980-1995 que tuvo una masa crítica cuando apareció Windows 95.
Thorbjørn Ravn Andersen
1
No estaría de acuerdo con el comentario sobre los recursos. Lo que importa no es la cantidad de personas en el equipo, es el nivel de habilidad de las mejores personas en el equipo.
Michael Kay
"Microsoft probablemente emplea a más personas que preparan café para sus programadores de compilación que toda la comunidad PHP, Ruby y Python combinada tiene personas trabajando en sus máquinas virtuales". Supongo que eso depende de hasta qué punto esté dispuesto a estirar el término "programador de compiladores" y cuánto estás incluyendo con eso (Microsoft desarrolla muchos compiladores). Por ejemplo, solo el equipo del compilador VS C ++ es AFAIK relativamente pequeño.
Cubic
7

Teóricamente, si escribe código que hace exactamente lo mismo en dos idiomas y compila ambos utilizando un compilador "perfecto", el rendimiento de ambos debería ser el mismo.

En la práctica, hay varias razones por las que el rendimiento será diferente:

  1. Algunos idiomas son más difíciles de optimizar.

    Esto incluye características especialmente que hacen que el código sea más dinámico (escritura dinámica, métodos virtuales, punteros de función), pero también, por ejemplo, recolección de basura.

    Hay varias formas de hacer que el código use tales funciones rápidamente, pero generalmente sigue siendo al menos algo más lento que sin usarlas.

  2. Algunas implementaciones de lenguaje tienen que compilarse en tiempo de ejecución.

    Esto se aplica especialmente a los lenguajes con máquinas virtuales (como Java) e idiomas que ejecutan el código fuente, sin paso intermedio para binario (como JavaScript).

    Tales implementaciones de lenguaje tienen que hacer más trabajo en tiempo de ejecución, lo que afecta el rendimiento, especialmente el tiempo de inicio / rendimiento poco después del inicio.

  3. Las implementaciones de lenguaje intencionalmente dedican menos tiempo a las optimizaciones de lo que podrían.

    Todos los compiladores se preocupan por el rendimiento del compilador en sí, no solo del código generado. Esto es especialmente importante para los compiladores de tiempo de ejecución (compiladores JIT), donde tomar demasiado tiempo para compilar ralentiza la ejecución de la aplicación. Pero se aplica a los compiladores anticipados, como los de C ++ también. Por ejemplo, la asignación de registros es un problema de NP completo, por lo que no es realista resolverlo perfectamente y en su lugar se utilizan las heurísticas que se ejecutan en un tiempo razonable.

  4. Diferencias en idiomas en diferentes idiomas.

    El código escrito en el estilo común para un determinado idioma (código idiomático) usando bibliotecas comunes puede resultar en una diferencia en el rendimiento, porque dicho código idiomático se comporta de manera sutilmente diferente en cada idioma.

    Como ejemplo, considere vector[i]en C ++, list[i]en C # y list.get(i)en Java. El código C ++ probablemente no verifica el rango y no realiza llamadas virtuales, el código C # realiza la verificación de rango, pero no las llamadas virtuales y el código Java realiza la verificación de rango y es una llamada virtual. Los tres lenguajes admiten métodos virtuales y no virtuales, y tanto C ++ como C # pueden incluir la verificación de rango o evitarlo al acceder a la matriz subyacente. Pero las bibliotecas estándar de estos lenguajes decidieron escribir estas funciones equivalentes de manera diferente y, como consecuencia, su rendimiento será diferente.

  5. Algunos compiladores pueden faltar algunas optimizaciones.

    Los escritores de compiladores tienen recursos finitos, por lo que no pueden implementar todas las optimizaciones posibles, incluso ignorando los otros problemas. Y los recursos que tienen podrían centrarse en un área de optimización más que en otras. Como consecuencia, el código escrito en diferentes idiomas puede tener un rendimiento diferente debido a las diferencias en sus compiladores, incluso si no hay una razón fundamental por la que un idioma sea más rápido o incluso más fácil de optimizar que el otro.

svick
fuente
Algunos idiomas no tienen un compilador. Para algunos idiomas, no puede haber un compilador ( referencia ).
Raphael
3
Para algunos idiomas, no puede haber un compilador estático . La compilación dinámica no se ve afectada por la indecidibilidad de las propiedades estáticas.
Jörg W Mittag el
Si los idiomas son lo suficientemente diferentes, no tienen "código que haga exactamente lo mismo". Es posible que tengan un código que produzca la misma salida o comportamiento observable por el usuario, que no es lo mismo. Así que no estoy de acuerdo con tu premisa.
einpoklum - readmitir a Monica el
@einpoklum No veo la distinción. Con algunas excepciones (como la sincronización de subprocesos), que creo que no son interesantes aquí, las especificaciones del lenguaje generalmente permiten cualquier optimización que conserve el comportamiento observable. ¿Qué tipo de comportamiento tiene en mente que no es observable por el usuario, pero que no puede optimizarse?
svick
Teóricamente, cualquier lenguaje interpretado se puede "compilar" generando un archivo EXE que consiste en un intérprete + el código fuente del programa.
dan04
1

Esta es una pregunta muy general, pero en su caso la respuesta podría ser simple. C ++ compila en código máquina, donde Java compila en código de bytes Java, que luego se ejecuta en una máquina virtual Java (aunque también hay una compilación justo a tiempo, que compila aún más el código de bytes Java en código máquina nativo). Otra diferencia podría ser la recolección de basura, que es un servicio que solo proporciona Java.

Yuval Filmus
fuente
2
Esta es una respuesta demasiado simplista. Hay configuraciones en las que Java es más rápido.
Raphael
44
También hay implementaciones de Java que compilan en código máquina e implementaciones interpretadas de C ++. Y de todos modos, ¿qué es el "código de máquina"? Si tengo una CPU picoJava que ejecuta el código de bytes JVM de forma nativa, y tengo el intérprete JPC x86 ejecutándose en el JVM, entonces, ¿qué hace que el código de objeto x86 sea "código de máquina" y el código de bytes JVM no?
Jörg W Mittag el
2
Nitpick: no solo Java proporciona recolección de basura ... e incluso si solo considera C ++ y Java, algunos programas de frameworks / bibliotecas de C ++ tienen instalaciones de recolección de basura en su lugar.
einpoklum - readmitir a Monica el
Compilar en código máquina nativo generalmente mejora el rendimiento. Sin embargo, en algunos casos limitados, un intérprete de alta calidad puede vencer a un ingenuo compilador justo a tiempo.
DepressedDaniel
@ JörgWMittag El truco consiste en compilar el código de máquina nativo (el código de máquina que entiende el procesador host) y luego saltar directamente al código llamado para que pueda ejecutarse sin interpretación. Será x86 en un chip x86 y códigos de bytes JVM en una CPU picoJava.
DepressedDaniel
-5

Su pregunta es demasiado general, así que me temo que no puedo darle una respuesta exacta que necesita.

Para mi mejor explicación, echemos un vistazo a la plataforma C ++ y .Net.

C ++, muy cerca del código de máquina y una de las programaciones favoritas en el pasado (¿hace más de 10 años?) Debido al rendimiento. No se necesitan muchos recursos para desarrollar y ejecutar el programa C ++ incluso con el IDE, se consideran muy livianos y muy rápidos. También puede escribir código C ++ en la consola y desarrollar un juego desde allí. En términos de memoria y recursos, olvidé aproximadamente cuánta capacidad se necesita en una computadora, pero la capacidad es algo que no se puede comparar con la generación actual de lenguaje de programación.

Ahora echemos un vistazo a .Net. El requisito previo para el desarrollo de .Net es un IDE gigante que consista no solo en un tipo de lenguajes de programación. Incluso si solo desea desarrollar en, digamos C #, el IDE en sí incluirá muchas plataformas de programación de forma predeterminada, como J #, VB, dispositivos móviles, etc. A menos que realice una instalación personalizada y solo instale exactamente lo que desea, siempre que tenga la experiencia suficiente para jugar con la instalación IDE.

Además de instalar el software IDE en sí, .Net también viene con una gran capacidad de bibliotecas y marcos con el fin de facilitar el acceso a cualquier tipo de plataforma que los desarrolladores necesitan Y no necesitan.

Desarrollar en .Net puede ser una experiencia divertida porque muchas funciones y componentes comunes están disponibles por defecto. Puede arrastrar y soltar y usar muchos métodos de validación, lectura de archivos, acceso a la base de datos y mucho más en el IDE.

Como resultado, es una compensación entre los recursos informáticos y la velocidad de desarrollo. Esas bibliotecas y marcos ocupan memoria y recursos. Cuando ejecuta un programa en .Net IDE, puede consumir toneladas de tiempo tratando de compilar las bibliotecas, los componentes y todos sus archivos. Y cuando realiza la depuración, su computadora requiere muchos recursos para administrar el proceso de depuración en su IDE.

Por lo general, para realizar el desarrollo .Net, necesita una buena computadora con algo de Ram y procesador. De lo contrario, es mejor que no programes nada. En este aspecto, la plataforma C ++ es mucho mejor que .Net. Aunque todavía necesita una buena computadora, la capacidad no será demasiado preocupante en comparación con .Net.

Espero que mi respuesta pueda ayudar con su pregunta. Avísame en caso de que quieras saber más.

EDITAR:

Solo una aclaración a mi punto principal, principalmente respondo a la pregunta de "¿Qué rige la velocidad de la programación".

En el punto de vista IDE, el uso de lenguaje C ++ o .Net en el IDE relativo no afecta la velocidad de escritura del código, pero afectará la velocidad de desarrollo porque el compilador de Visual Studio tarda más tiempo en ejecutar el programa, pero el IDE C ++ es mucho más ligero y consumen menos recursos informáticos. Entonces, a la larga, puede hacer la programación más rápido con el tipo C ++ de IDE en comparación con .Net IDE, que depende en gran medida de las bibliotecas y el marco. Si toma el tiempo de espera del IDE para iniciar, compilar, ejecutar el programa, etc., afectará la velocidad de la programación. A menos que "la velocidad de programación" se centre solo en la "velocidad de escritura de código".

La cantidad de bibliotecas y el marco en Visual Studio también consumen la capacidad de la computadora. No estoy seguro de si esto responde a la pregunta de "administración de memoria", pero solo quiero señalar que Visual Studio IDE puede tomar muchos recursos al ejecutarlo y, por lo tanto, ralentizar la "velocidad de programación" general. Por supuesto, esto no tiene nada que ver con la "velocidad de escritura del código".

Como habrás adivinado, no sé demasiado de C ++, ya que solo lo uso como ejemplo, mi punto principal es sobre el tipo de IDE pesado de Visual Studio que consume recursos de la computadora.

Si se me ocurrió la idea y no respondí la pregunta de inicio del hilo, pido disculpas por la larga publicación. Pero le aconsejaría al iniciador de hilos que aclare la pregunta y pregunte exactamente qué necesita saber sobre "más rápido" y "más lento"

Koo SengSeng
fuente
66
Solo para el registro, el desarrollo de .NET solo requiere el SDK de .NET (y, para la ejecución, el tiempo de ejecución de .NET en sí). Puede usar un editor de texto sin formato e invocar el compilador desde la línea de comandos. El IDE (supongo que se refiere a Visual Studio) NO es obligatorio, aunque seguramente ayuda con cualquier proyecto considerable (Intellisense, depurador, etc., etc.). También hay IDE más ligeros, como SharpDevelop, con menos campanas y silbatos.
MetalMikester
16
Ciertamente puede desarrollar en .Net sin un IDE. Pero no veo cómo el IDE es relevante para la velocidad del código escrito en un idioma.
svick
8
@MetalMikester: Y, por supuesto, Visual Studio es el IDE de referencia para el desarrollo de C ++ en Windows.
Jörg W Mittag
3
Y compilar código C ++ a .Net es solo un cambio de compilador; El supuesto abismo es puentes por un clic del mouse en Visual Studio.
MSalters
1
No estoy del todo seguro de que llamaría a C ++ moderno "muy cercano al código de máquina". C original, sí; fue concebido como un ensamblador portátil y se ha mantenido muy cerca de eso (aunque la biblioteca estándar ha crecido y varios compiladores ofrecen complementos al lenguaje propiamente dicho que lo aleja más de sus orígenes). C ++ original (C con clases), tal vez; reescribir una variante de C que incluye clases a C puro no es tan difícil, en ese punto se aplica la discusión anterior. Pero, ¿C ++ moderno, con plantillas, polimorfismo y todo lo demás bajo el sol? Eso es apenas "muy cercano al código de máquina".
un CVn