Estoy confundido y agradecería si me aclaras. F # usa el mismo CLR que C# y el código subyacente es idéntico, entonces ¿cómo se puede sugerir que una función se ejecute más rápido cuando se escribe en F # que en C#? Si utilizo solo variables inmutables en C# y el rendimiento debe ser lo más alto posible, entonces ¿por qué usar F #?CLR de F # y C# es lo mismo que por qué F # es más rápido que C#
Hubo this pregunta sobre stackoverflow hace algún tiempo, puede ayudarle a descubrir algunas razones por las que F # podría ser más rápido. Sin embargo, la ganancia de rendimiento depende en gran medida de la aplicación y las funciones de codificación que esté utilizando.
¿hay alguna razón para el voto a favor? La respuesta vinculada es mucho más específica que cualquiera de las respuestas escritas aquí. Entonces no veo una razón para escribir todo de nuevo. Gracias. –
Quizás se debió al hecho de que su respuesta comenzó siendo solo un enlace a la pregunta (y aún lo es). Las respuestas como esa son más adecuadas como un comentario. Si hubiera agregado un resumen completo, entonces las personas probablemente no tendrían problemas con él. –
+1 ¡Todavía te amo! (pero vea otros comentarios) –
Puede haber varias razones para que el código escrito en un idioma sea más rápido que el código escrito en el otro, incluso si utilizan la misma biblioteca de tiempo de ejecución. Sin embargo, la biblioteca de tiempo de ejecución de .NET no es la única biblioteca en tiempo de ejecución involucrada. Según lo entiendo, hay una biblioteca de tiempo de ejecución F # bastante grande que hace cosas que son específicas de F #. El compilador F # sabe sobre esa biblioteca. El compilador C# no. Por lo tanto, el compilador de F # puede realizar llamadas a un código de biblioteca de tiempo de ejecución altamente optimizado al que el compilador de C# no tiene acceso.
Si ambos utilizan el mismo conjunto de bibliotecas de tiempo de ejecución, entonces esperaría que los programas estén cerca del mismo pero no sean exactos. Los compiladores individuales podrían generar código más o menos óptimo para construcciones particulares.
El compilador F # no solo conoce las propias bibliotecas de F #, sino también los detalles de bajo nivel de la implementación de genéricos y partes de CIL de .NET que C# no genera (específicamente, ILX) porque eso fue escrito por el mismo chico (Don Syme). –
1) Si escribe el código C# y el código F # que se compilan exactamente en la misma IL (el idioma intermedio del CLR), entonces el código exhibirá las mismas características de rendimiento. Sin embargo, implementar el mismo algoritmo en C# y F # no garantiza que se genere exactamente la misma IL, por lo que el rendimiento en el mundo real puede variar. Creo que, en la práctica, a veces el código F # será más rápido, pero otras veces C# será más rápido.
2) Hay muchas razones para elegir un lenguaje de implementación además del rendimiento. Por ejemplo, algunas personas encuentran que F # es más breve, legible y más fácil de razonar que C# para ciertos dominios problemáticos, lo que sería una de las razones para preferirlo. Para la gran mayoría de los programas, una diferencia del 5% o del 10% en el rendimiento será imperceptible para los usuarios, por lo que si un lenguaje ofrece un rendimiento más o menos comparable pero una productividad superior, entonces tendría sentido usar ese lenguaje.
Puede que le interese el artículo Performance-Related Features in F# and C#. En cuanto a "por qué usar F #" no puedo hablar por ti, pero para mí uso F # porque me gusta más.
+1 al "Me gusta mejor". – Robert
El código subyacente es idéntico? Dudoso. En general, F # será más rápido en algunas cosas y más lento en otras. Lo mismo es cierto de C#. O incluso VB. Cada idioma tiene sus ventajas. Si hay un rendimiento general más en la mayoría de las áreas, está en el compilador.
Si uso solo variables inmutables en C# y el rendimiento debe ser tan alto como sea posible, entonces ¿por qué usar F #? No hay razón para cambiar el rendimiento solo, si de hecho hay una diferencia real, a menos que el rendimiento sea su problema. En cuanto a por qué cambiar si solo está usando características que están bien en C#, yo diría "no cambiar".
Me gusta F #. Hay algunos "problemas" que resuelve mucho mejor que C#. Pero, incluso si tengo un problema, se resuelve mejor, no estoy necesariamente cambiando, ya que tengo que considerar a los desarrolladores en la mezcla. Actualmente, conozco a unos pocos en esta organización que saben algo sobre F #, así que tendría que hacer un buen negocio para cambiar.
En última instancia, tiene que ver el "problema de negocios" y determinar un camino. Debe considerar el lenguaje "mejor" como parte de la combinación, pero también debe examinar la competencia central, etc.
+1: Ciertamente, se puede lograr un rendimiento comparable sin importar qué idioma esté usando. Otros factores son los que debes considerar. –
La respuesta no es el rendimiento en velocidad o recursos BC son casi los mismos. Algunas mejoras y contras debatidas ... La razón de F # es el desarrollo y el tiempo de implementación. F # es más optimizado y está ansioso por construir con un código más seguro. Menos propenso a errores y más exacto sin preocuparse por cosas simples como contadores de bucles y verificación de tipos, cross-threading, etc. Por lo tanto, no solo es más fácil y rápido de escribir, sino mucho menos problemático. Obtienes más de lo que realmente querías sin preocuparte por las pequeñas cosas. Esto significa menos pruebas y más implementación en vivo, más código de confianza y funciones más precisas que no tienen gastos generales innecesarios. Por lo tanto, el resultado final es un código escrito más rápido, un rendimiento optimizado por naturaleza e igualmente una mayor confianza con menos errores.
No hay razón para cambiar, pero sugiero componentes diseñados para cumplir con los mejores estándares. F # impone una gran cantidad de estándares, hace que las pruebas en tiempo real durante el desarrollo sean simples, y cura los problemas de mutabilidad, dependencia circular, así como la mayoría de las referencias de verificación de tipos/nulos. C# por otro lado tiene la mayoría de los desarrolladores y herramientas y puede desarrollarse con un patrón funcional en mente pero no siempre correcto. Soy un fanático de C# y casi siempre elijo C#, pero veo muchas veces cuando F # es lo que más necesito para construir un código robusto y limpio. Supongo que personalmente prefiero combinar los dos idiomas cuando puedo, pero como mencioné, es más importante trabajar con lo que tu equipo de desarrollo también puede mantener y revisar. En muchas situaciones, el equipo de desarrollo estará en contra, pero en algunos lo harán porque también quieren no solo hacer que la base del código sea lo más fuerte posible, sino que aprendan cosas nuevas. Simplemente no pierda demasiado tiempo para decidir el idioma correcto, si está seguro de que F # es mejor, preséntelo y vea si tiene un consenso para completarlo de esa manera. Mantenga su proyecto separado, incluso si están en la misma solución, y use F # cuando funcione mejor y C# cuando funcione mejor. F # no es tan difícil de aprender, pero para un desarrollador puramente imperativo puede parecer feo y confuso al principio. Explícalo un poco y creo que pone la pelota en marcha. Los tiempos para considerar F # estarían en algoritmos donde no solo desea rendimiento sino pruebas inmediatas de los resultados. Esto acelera el tiempo de desarrollo y el tiempo de ejecución, gana y gana. Otros podrían ser modelos si los modelos consisten en muchos valores inmutables. F # funciona en todas las áreas, pero para mí el lado de la interfaz de usuario se hace más fácilmente en C#, así como cosas como ViewModels, donde la lógica es ligeramente diferente, pero eso es una opinión. Te sorprenderás de las ganancias que obtienes de una dulce combinación de los dos. Además, la programación funcional se está volviendo más fácil con linq, lambda y la sintaxis C# más nueva donde C# básicamente parece funcional, por lo que su tono para usar F # puede no ser tan difícil como lo sería hace años.
No cubrí nada al máximo pero entiendes ... F # es potente, úsalo cuando funcione mejor y lo mismo para C#. Empecé con VB.NET pero no lo recomendaría más simplemente porque la tecnología más nueva como .NET Core no lo admite. Sin embargo, también hay un beneficio de usarlo a veces ... Aunque sea mucho menos que un beneficio de F #. En ese sentido, me limito a las dos primarias C#, F #. Otra cosa, no dejes que una curva de aprendizaje te impida ser el mejor ... Hace poco entrevisté a Wells Fargo por un salario decente, que estaba actualizando los sistemas heredados a 4.6.2 .NET avanzado y se negaron para aceptar la sintaxis async/await bc era demasiado para aprender y dijeron que era solo azúcar sintáctico ... (oh querido) Eso para mí fue una buena afirmación diciendo: preferimos usar lo nuevo y hacerlo a la vieja que es un gran error, especialmente para proyectos grandes. No permita que un gran proyecto sea medio ingenioso debido a una pequeña curva de aprendizaje. Los ingenieros están diseñados para aprender y actualizar no solo para mantener el legado en los tiempos modernos.
Se podría sugerir que una función particular se ejecuta más rápido en uno u otro si le presentaban un punto de referencia adecuado que mostraba los tiempos respectivos. Hasta ese momento, no tome demasiado en serio las afirmaciones sobre el rendimiento. – CurtainDog
¿Hay alguna prueba de que "F # es más rápido que C#" (o viceversa)? Es una afirmación muy * específica del contexto - ver el comentario de CurtainDog. Además, como algunos podrían señalar pedancientemente: los idiomas no tienen una "velocidad". –
Una respuesta breve a la pregunta general podría ser "optimizaciones del compilador". (por ejemplo, el compilador de F # puede y enuncia algunas cosas de forma más agresiva que el compilador de C#). Pero vea todas las respuestas a continuación, ya que hay mucha profundidad. – Brian