Basta ya de indagar por todo internet ya que estás al sitio exacto, contamos con la respuesta que buscas sin problema.
Solución:
Los idiomas tienen conjuntos de características similares. La diferencia de rendimiento proviene del hecho de que Fortran dice que no se permite el uso de alias, a menos que se use una declaración de EQUIVALENCIA. Cualquier código que tenga alias no es válido para Fortran, pero depende del programador y no del compilador detectar estos errores. Por lo tanto, los compiladores de Fortran ignoran los posibles alias de los punteros de memoria y les permiten generar un código más eficiente. Echa un vistazo a este pequeño ejemplo en C:
void transform (float *output, float const * input, float const * matrix, int *n)
int i;
for (i=0; i<*n; i++)
float x = input[i*2+0];
float y = input[i*2+1];
output[i*2+0] = matrix[0] * x + matrix[1] * y;
output[i*2+1] = matrix[2] * x + matrix[3] * y;
Esta función se ejecutaría más lentamente que la contraparte de Fortran después de la optimización. ¿Porque? Si escribe valores en la salida array, puede cambiar los valores de matriz. Después de todo, los punteros podrían superponerse y apuntar al mismo fragmento de memoria (incluido el int ¡puntero!). El compilador de C se ve obligado a recargar los cuatro valores de matriz de la memoria para todos los cálculos.
En Fortran, el compilador puede cargar los valores de la matriz una vez y almacenarlos en registros. Puede hacerlo porque el compilador de Fortran asume que los punteros/matrices no se superponen en la memoria.
Afortunadamente, el restrict La palabra clave y el alias estricto se han introducido en el estándar C99 para abordar este problema. También es compatible con la mayoría de los compiladores de C ++ en estos días. La palabra clave le permite dar al compilador una pista de que el programador promete que un puntero no se alias con ningún otro puntero. El alias estricto significa que el programador promete que los punteros de diferente tipo nunca se superpondrán, por ejemplo, un double* no se superpondrá con un int* (con la excepción específica de que char* y void* puede superponerse con cualquier cosa).
Si los usa, obtendrá la misma velocidad de C y Fortran. Sin embargo, la capacidad de utilizar el restrict La palabra clave solo con funciones críticas de rendimiento significa que los programas C (y C++) son mucho más seguros y fáciles de escribir. Por ejemplo, considere el código Fortran inválido: CALL TRANSFORM(A(1, 30), A(2, 31), A(3, 32), 30)que la mayoría de los compiladores de Fortran compilarán felizmente sin previo aviso, pero presenta un error que solo aparece en algunos compiladores, en algún hardware y con algunas opciones de optimización.
Sí, en 1980; ¿en 2008? depende
Cuando comencé a programar profesionalmente, el dominio de la velocidad de Fortran estaba siendo desafiado. Recuerdo haber leído sobre esto en Dr. Dobbs y haberle contado a los programadores mayores sobre el artículo, se rieron.
Así que tengo dos puntos de vista sobre esto, teórico y práctico. En teoria Fortran hoy en día no tiene ninguna ventaja intrínseca sobre C/C++ o incluso cualquier lenguaje que permita el código ensamblador. En la práctica Fortran hoy todavía disfruta de los beneficios del legado de una historia y una cultura construidas en torno a la optimización del código numérico.
Hasta e incluyendo Fortran 77, las consideraciones de diseño de lenguaje tenían la optimización como enfoque principal. Debido al estado de la teoría y la tecnología del compilador, esto a menudo significaba restringiendo características y capacidades para darle al compilador la mejor oportunidad de optimizar el código. Una buena analogía es pensar en Fortran 77 como un auto de carrera profesional que sacrifica funciones por velocidad. En estos días, los compiladores han mejorado en todos los lenguajes y las funciones para la productividad del programador son más valoradas. Sin embargo, todavía hay lugares donde la gente se preocupa principalmente por la velocidad en la computación científica; lo más probable es que estas personas hayan heredado el código, la formación y la cultura de personas que eran programadores de Fortran.
Cuando uno comienza a hablar sobre la optimización del código, hay muchos problemas y la mejor manera de tener una idea de esto es acechar dónde están las personas cuyo trabajo es tener un código numérico rápido. Pero tenga en cuenta que dicho código críticamente sensible suele ser una pequeña fracción de las líneas generales de código y muy especializado: una gran cantidad de código Fortran es tan "ineficiente" como muchos otros códigos en otros idiomas y la optimización ni siquiera debería ser una preocupación principal de tal código.
Un lugar maravilloso para comenzar a aprender sobre la historia y la cultura de Fortran es wikipedia. La entrada de Fortran Wikipedia es excelente y agradezco mucho a quienes se han tomado el tiempo y el esfuerzo para que sea de valor para la comunidad de Fortran.
(Una versión abreviada de esta respuesta habría sido un comentario en el excelente hilo iniciado por ceros pero no tengo el karma para hacer eso. En realidad, probablemente no habría escrito nada en absoluto, pero este hilo tiene contenido de información real y se comparte en lugar de guerras de llamas y fanatismo lingüístico, que es mi principal experiencia con este tema. Me sentí abrumado y tuve que compartir el amor.)
Hasta cierto punto, Fortran se ha diseñado teniendo en cuenta la optimización del compilador. El lenguaje soporta todo array operaciones donde los compiladores pueden explotar el paralelismo (especialmente en procesadores multinúcleo). Por ejemplo,
La multiplicación de matrices densas es simplemente:
matmul(a,b)
La norma L2 de un vector x es:
sqrt(sum(x**2))
Además declaraciones como FORALL, PURE & ELEMENTAL procedimientos, etc. ayuda adicional para optimizar el código. Incluso los punteros en Fortran no son tan flexibles como C por esta sencilla razón.
El próximo estándar de Fortran (2008) tiene matrices conjuntas que le permiten escribir fácilmente código paralelo. G95 (código abierto) y los compiladores de CRAY ya lo admiten.
Entonces sí, Fortran puede ser rápido simplemente porque los compiladores pueden optimizarlo/paralelizarlo mejor que C/C++. Pero nuevamente, como todo lo demás en la vida, hay buenos compiladores y malos compiladores.
Si posees alguna indecisión y forma de aclarar nuestro crónica eres capaz de ejecutar una crónica y con deseo lo estudiaremos.