Легче ли оптимизировать Fortran, чем C, для тяжелых вычислений?

391
задан Martin Broadhurst 28 January 2018 в 08:40
поделиться

16 ответов

Языки имеют подобные наборы функций. Различие в производительности прибывает из того, что Фортран говорит, что искажение не позволяется, если оператор EQUIVALENCE не используется. Любым кодом, который имеет искажение, не является допустимый Фортран, но это до программиста а не компилятора для обнаружения этих ошибок. Таким образом компиляторы Фортрана игнорируют возможное искажение указателей памяти и позволяют им генерировать более эффективный код. Смотрите на этот небольшой пример в 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;
    }
}

Эта функция работала бы медленнее, чем дубликат Фортрана после оптимизации.Как же так? Если Вы пишете значения в выходной массив, можно изменить значения матрицы. В конце концов, указатели могли наложиться и указать на тот же блок памяти (включая int указатель!). Компилятор C вынужден перезагрузить четыре матричных значения из памяти для всех вычислений.

В Фортране компилятор может загрузить матричные значения однажды и сохранить их в регистрах. Это может сделать так, потому что компилятор Фортрана предполагает, что указатели/массивы не накладываются в памяти.

, К счастью, restrict ключевое слово и строгое искажение были представлены стандарту C99 для рассмотрения этой проблемы. Это хорошо поддерживается в большинстве компиляторов C++ в эти дни также. Ключевое слово позволяет Вам давать компилятору подсказку, что программист обещает, что указатель не искажает ни с каким другим указателем. Строгое искажение означает, что программист обещает, что указатели другого типа никогда не будут накладываться, например, double* не наложится с int* (за определенным исключением, которое char* и void* может наложиться с чем-либо).

при использовании их, Вы получите ту же скорость от C и Фортрана. Однако способность использовать restrict ключевое слово только с производительностью, критические функции означают, что C (и C++) программы намного более безопасны и легче записать. Например, рассмотрите недопустимый код Фортрана: CALL TRANSFORM(A(1, 30), A(2, 31), A(3, 32), 30), который большинство компиляторов Фортрана счастливо скомпилирует без любого предупреждения, но представляет ошибку, которая только обнаруживается на некоторых компиляторах на некоторых аппаратных средствах и с некоторыми опциями оптимизации.

425
ответ дан Zaffy 28 January 2018 в 18:40
поделиться
  • 1
    Проблема с моим выше реализации состоит в том, что значение не сохраняется. Как только я добавляю сохранение к свойству, будет это присвоение устанавливать значение в свойство. И если некоторые другие доступы к объекту это свойство будут это значение быть там. Я также изменил свой вопрос – awsome 29 April 2010 в 22:17

Это более, чем несколько субъективно, потому что это входит в качество компиляторов и таких больше, чем что-либо еще. Однако, чтобы более непосредственно ответить на Ваш вопрос, говорящий с точки зрения языка/компилятора нет ничего о Фортране по C, который собирается сделать его по сути быстрее или лучше, чем C. При выполнении тяжелых математических операций это сведется к качеству компилятора, навыку программиста на каждом языке и внутренних математических вспомогательных библиотеках, которые поддерживают те операции для окончательного определения, который будет быстрее для данной реализации.

РЕДАКТИРОВАНИЕ: Другие люди, такие как @Nils подняли положительный вопрос о различии в использовании указателей в C и возможности для искажения, которое, возможно, делает самые наивные реализации медленнее в C. Однако существуют способы иметь дело с этим в C99 через флаги компиляторной оптимизации и/или в том, как C на самом деле записан. Это хорошо охвачено в ответе @Nils и последующих комментариях, которые следуют его ответ.

1
ответ дан Tall Jeff 28 January 2018 в 18:40
поделиться
  • 1
    Хорошо, это очень странно. Используя firstname = [n retain] просто работы для меня. Так или иначе, если Ole Begemann' s работа метода я предполагаю, что это прекрасно. – Rengers 30 April 2010 в 00:30

Обычно ФОРТРАН медленнее, чем C. C может использовать указатели аппаратного уровня, разрешающие программисту вручить - оптимизируют. ФОРТРАН (в большинстве случаев) не имеет доступа к аппаратным взломам обращения памяти. (VAX ФОРТРАН является другой историей.) я использовал ФОРТРАН на и прочь с '70-х. (Действительно).

Однако запуск в 90-х ФОРТРАН развился для включения определенных конструкций языка, которые могут быть оптимизированы в по сути параллельные алгоритмы, которые могут действительно крик на многоядерном процессоре. Например, автоматическая Векторизация позволяет нескольким процессорам обрабатывать каждый элемент в векторе данных одновременно. 16 процессоров - 16 векторов элемента - обработка берут 1/16-й время.

В C, необходимо управлять собственными потоками и разработать алгоритм тщательно для многопроцессорной обработки и затем использовать набор вызовов API, чтобы удостовериться, что параллелизм происходит правильно.

В ФОРТРАНЕ, только необходимо разработать алгоритм тщательно для многопроцессорной обработки. Компилятор и время выполнения могут обработать остальных для Вас.

можно считать немного приблизительно Высокая производительность Фортран , но Вы находите много битых ссылок. Вы - более обеспеченное чтение о Параллельном программировании (как OpenMP.org ) и как поддержки ФОРТРАНА это.

7
ответ дан S.Lott 28 January 2018 в 18:40
поделиться

Любыми различиями в скорости между Фортраном и C будет больше функция оптимизации компилятора и базовой математической библиотеки, пользовавшейся конкретным компилятором. Нет ничего внутреннего Фортрану, который сделал бы его быстрее, чем C.

Так или иначе, хороший программист может записать Фортран на любом языке.

9
ответ дан Kluge 28 January 2018 в 18:40
поделиться

Я не услышал, что Fortan значительно быстрее, чем C, но это мог бы быть мыслимый tht в определенных случаях, это будет быстрее. И ключ не находится в функциях языка, которые присутствуют, а в тех, которые (обычно) отсутствуют.

пример указатели C. C указатели используются в значительной степени везде, но проблема с указателями состоит в том, что компилятор обычно не может говорить, указывают ли они на различные части того же массива.

, Например, если Вы записали strcpy стандартную программу, которая была похожа на это:

strcpy(char *d, const char* s)
{
  while(*d++ = *s++);
}

компилятор должен работать под предположением, что d и s могли бы перекрывать массивы. Таким образом, это не может выполнить оптимизацию, которая привела бы к различным результатам, когда массивы накладываются. Как Вы ожидали бы, это значительно ограничивает вид оптимизации, которая может быть выполнена.

[я должен отметить, что C99 имеет "ограничить" ключевое слово, что explictly говорит компиляторам, что указатели не накладываются. Также обратите внимание, что Фортран также имеет указатели с семантикой, отличающейся от тех C, но указатели не повсеместны как в C.]

, Но возвращение к C по сравнению с проблемой Фортрана, возможно, что компилятор Фортрана может выполнить некоторую оптимизацию, которая не могла бы быть возможна для (прямо записанный) C программа. Таким образом, я не был бы слишком удивлен требованием. Однако я ожидаю, что различие в производительности не было бы всем так очень. [~5-10%]

10
ответ дан Pramod 28 January 2018 в 18:40
поделиться
  • 1
    Это - лучшее решение. Точно, что я искал. – Tamzin Blake 11 June 2014 в 07:58

Я сравниваю скорость Фортрана, C, и C++ со сравнительным тестом классика Levine-Callahan-Dongarra от netlib. Несколько, которые языковая версия, с OpenMP, http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors C, более ужасны, когда это началось с автоматического перевода, плюс вставка ограничивают и прагмы для определенных компиляторов. C++ просто C с шаблонами STL когда это применимо. К моему представлению STL является ассортиментом относительно того, улучшает ли это пригодность для обслуживания.

существует только минимальное осуществление автоматического встраивания функции для наблюдения, до какой степени оно улучшает оптимизацию, так как примеры основаны на традиционной практике Фортрана, где мало уверенности является местом на встраивании.

компилятор C/C++, который имеет безусловно самое широко распространенное использование, испытывает недостаток в автовекторизации, на которую эти сравнительные тесты полагаются в большой степени.

Ре сообщение, которое появилось незадолго до этого: существует несколько примеров, где круглые скобки используются в Фортране для диктовки более быстрого или более точного порядка оценки. Известные компиляторы C не имеют опций наблюдать круглые скобки, не отключая более важную оптимизацию.

14
ответ дан 28 January 2018 в 18:40
поделиться

Нет ничего об эти языки Фортран и C, который делает один быстрее, чем другой в определенных целях. Существуют вещи об определенном компиляторы для каждого из этих языков, которые делают некоторых благоприятными для определенных задач больше, чем другие.

Много лет, компиляторы Фортрана существовали, который мог сделать черную магию к Вашим числовым стандартным программам, делая много важных вычислений безумно быстро. Современные компиляторы C не могли сделать этого также. В результате много больших библиотек кода выросли в Фортране. Если Вы хотите пользоваться этими хорошо протестированными, сформировавшимися, замечательными библиотеками, Вы вспыхиваете компилятор Фортрана.

Мои неофициальные наблюдения показывают, что в эти дни люди кодируют свой тяжелый вычислительный материал на любом старом языке, и если он требует времени, они находят, что время на некоторых дешевых вычисляет кластер. Закон Гордона Мура делает дураков из нас всех.

14
ответ дан jfm3 28 January 2018 в 18:40
поделиться
  • 1
    Не совсем решение, которым я был после, потому что событие размытости все еще инициировано, но я don' t думают it' s возможный сделать точно, что я хочу. – Jake 9 November 2010 в 07:58

Существует другой объект, где Фортран отличается, чем C - и потенциально быстрее. Фортран имеет лучшие правила оптимизации, чем C. В Фортране порядке оценки не определяются выражения, который позволяет компилятору оптимизировать его - если Вы хотите вызвать определенный порядок, нужно использовать круглые скобки. В C порядок намного более строг, но с "-быстро" опции, они более ослабляются, и" (...)" также проигнорированы. Я думаю, что Фортран имеет путь, который находится приятно в середине. (Ну, IEEE делает живое более трудное, поскольку определенные изменения порядка оценки требуют, чтобы никакое переполнение не происходило, который или должен быть проигнорирован или препятствует оценке).

Другая область более умных правил комплексные числа. Не только, что это взяло до C 99, что C имел их, также правила управляют ими, лучше в Фортране; так как библиотека Fortran gfortran частично записана в C, но реализует семантику Фортрана, GCC получил опцию (который может также использоваться с "нормальными" программами C):

-fcx-fortran-rules Сложное умножение и разделение следуют правилам Фортрана. Сокращение диапазона сделано как часть сложного подразделения, но нет никакой проверки, является ли результатом сложного умножения или разделения "NaN + I*NaN", с попыткой спасти ситуацию в этом случае.

упомянутые выше правила псевдонима являются другой премией и также - по крайней мере в принципе - целые операции над массивом, которые, если взято правильно во внимание оптимизатором компилятора, может привести более быстрый код. На мятежнике сторона - то, что определенная операция занимает больше времени, например, если Вы делаете уроки к allocatable массиву, существует много необходимых проверок (перераспределите? [Функция Fortran 2003], имеет шаги массива, и т.д.), которые делают простую операцию более сложной негласно - и таким образом медленнее, но делает язык более мощным. С другой стороны, операции над массивом с гибкими границами и шагами помогают написать код - и компилятор обычно лучше оптимизирует код, чем пользователь.

Всего, я думаю, что и C и Фортран об одинаково быстро; выбор должен быть больше, как который язык делает один больше или более ли использование целых операций над массивом Фортрана и его лучшей мобильности полезно - или лучшее взаимодействие через интерфейс к системе и библиотекам графического интерфейса пользователя в C.

22
ответ дан 28 January 2018 в 18:40
поделиться
  • 1
    Необходимо использовать true и false, а не строки потому что Boolean('false') === true – Jake 6 March 2012 в 20:05

Я думаю, что ключевой пункт в пользу Фортрана - то, что это - язык, немного более подходящий для выражения вектора - и основанная на массиве математика. Аналитическая проблема указателя, на которую указывают выше, реальна на практике, так как портативный код не может действительно предположить, что можно сказать компилятору что-то. Всегда существует преимущество для выражения computaitons способом ближе к тому, как домен смотрит. C действительно не имеет массивов вообще, если Вы смотрите тесно, просто что-то такой ведет себя как он. Фортран имеет реальный arrawys. Который помогает скомпилировать для определенных типов алгоритмов специально для параллельных машин.

В глубине души в вещах как система во время выполнения и соглашения о вызовах, C и современный Фортран достаточно подобны, что трудно видеть то, что имело бы значение. Обратите внимание, что C здесь является действительно основой C: C++ является полностью другим вопросом с совсем другими рабочими характеристиками.

27
ответ дан F'x 28 January 2018 в 18:40
поделиться
  • 1
    Вместо progn можно также использовать prog1, который будет возвращаемое значение первого выражения. – jcubic 12 November 2013 в 20:28

Существует несколько причин, почему Фортран мог быть быстрее. Однако сумма, они имеют значение, так несущественна или может работаться вокруг так или иначе, что она не должна иметь значения. Главная причина использовать Фортран в наше время поддерживает или расширяет унаследованные приложения.

  • ЧИСТЫЕ и ЭЛЕМЕНТНЫЕ ключевые слова на функциях. Это функции, которые не имеют никаких побочных эффектов. Это позволяет оптимизацию в определенных случаях, где компилятор знает, что та же функция будет вызвана с теми же значениями. Примечание: реализации GCC, "чистые" как расширение языка. Другие компиляторы могут также. Межмодульный анализ может также выполнить эту оптимизацию, но это трудно.

  • стандартный набор функций, которые имеют дело с массивами, не отдельными элементами. Материал как sin(), журнал (), sqrt () берут массивы вместо скаляров. Это помогает оптимизировать стандартную программу. Автовекторизация приносит ту же пользу в большинстве случаев, если эти функции являются подставляемыми или builtins

  • Встроенный составной тип. В теории это могло позволить компилятору переупорядочивать или устранять определенные инструкции в определенных случаях, но вероятно Вы будете видеть то же преимущество со структурой {двойное ре, я;}; идиома используется в C. Это делает для более быстрой разработки, хотя, поскольку операторы работают над составными типами в Фортране.

28
ответ дан F'x 28 January 2018 в 18:40
поделиться

Да, в 1980; в 2008? зависит

, Когда я начал программировать профессионально преобладание скорости Фортрана, просто бросался вызов. Я помню чтение об этом в докторе Dobbs и сообщение программистам старшего возраста о статье - они смеялись.

, Таким образом, у меня есть два представления об этом, теоретическом и практичном. В теории Фортран сегодня не имеет никакого внутреннего преимущества для C/C++ или даже любого языка, который позволяет ассемблерный код. На практике Фортран сегодня все еще пользуется преимуществами наследия истории и культуры, созданной вокруг оптимизации цифрового кода.

Вплоть до и включая Фортран 77, конструктивные соображения языка имели оптимизацию как основной фокус. Из-за состояния теории компилятора и технологии, это часто означало ограничение функции и возможность, чтобы дать компилятору лучший выстрел в оптимизацию кода. Хорошая аналогия должна думать о Фортране 77 как профессиональный гоночный автомобиль, который жертвует функциями скорости. В эти дни компиляторы поправились через все языки, и функции производительности программиста более оценены. Однако существуют все еще места, где люди главным образом обеспокоены скоростью в научных вычислениях; эти люди, скорее всего, наследовали код, обучение и культуру от людей, которые самих были программистами Fortran.

, Когда каждый начинает говорить об оптимизации кода, существует много проблем, и лучший способ получить ощущение этого для скрываний, где люди - то, чье задание это должно иметь быстрый цифровой код . Но имейте в виду, что такой критически чувствительный код обычно является небольшой частью полных строк кода и очень специализированный: Много кода Фортрана так же "неэффективно" как много другого кода на других языках и , оптимизация даже не должна быть первоочередной задачей такого кода .

А замечательным местом для запуска в приобретении знаний об истории и культуре Фортрана является Википедия. статья в Википедии Фортрана превосходна, и я очень ценю тех, кто не торопился и усилие сделать ее из значения для сообщества Фортрана.

(Сокращенная версия этого ответа была бы комментарием в превосходном потоке, запущенном [1 114] Nils, но у меня нет кармы, чтобы сделать это. На самом деле я, вероятно, не записал бы ничего вообще, но для которого этот поток имеет фактическое информационное содержание и совместное использование в противоположность войнам пламени и фанатизму языка, который является моим основным опытом с этим предметом. Я был поражен и должен был совместно использовать любовь.)

157
ответ дан Russ 28 January 2018 в 18:40
поделиться

Нет такой вещи как один язык, являющийся быстрее, чем другой, таким образом, надлежащий ответ никакой .

то, Что действительно необходимо спросить, является "кодом, компилируется с компилятором Фортрана X быстрее, чем эквивалентный код, скомпилированный с компилятором C Y?" Ответ на тот вопрос, конечно, зависит, на котором два компилятора Вы выбираете.

Другой вопрос, который можно было задать, будет вроде, "Учитывая то же усилие, помещенное в оптимизацию в их компиляторах, какой компилятор произвел бы более быстрый код?" Ответ на это на самом деле был бы Фортран . Компиляторы Фортрана имеют преимущества certian:

  • Фортран должен был конкурировать с блоком назад в день, когда некоторые поклялись никогда не использовать компиляторы, таким образом, он был разработан для скорости. C был разработан, чтобы быть гибким.
  • ниша Фортрана была перемалыванием чисел. В этом доменном коде никогда достаточно быстро. Таким образом, всегда было большое давление для хранения языка эффективным.
  • большая часть исследования в оптимизации компилятора проведена людьми, заинтересованными ускорением кода перемалывания чисел Фортрана, так оптимизация кода Фортрана является намного более известной проблемой, чем оптимизация любого другого скомпилированного языка, и новые идеи обнаруживаются в компиляторах Фортрана сначала.
  • Важная персона : C поощряет намного больше использования указателя, чем Фортран. Это решительно увеличивает потенциальный объем любого элемента данных в программе C, которая делает их намного тяжелее для оптимизации. Обратите внимание, что Ada является также путем лучше, чем C в этой области и является намного более современным Языком OO, чем обычно находимый Fortran77. Если Вы хотите язык OO, который может сгенерировать более быстрый код, чем C, это - опция для Вас.
  • снова благодаря его нише перемалывания чисел, покупатели компиляторов Фортрана склонны заботиться больше об оптимизации, чем покупатели компиляторов C.

Однако нет ничего мешающего кому-то поместить тонну усилия в оптимизацию их компилятора C и заставить его сгенерировать лучший код, чем компилятор Фортрана их платформы. На самом деле большие продажи, сгенерированные компиляторами C, делают этот сценарий довольно выполнимым

23
ответ дан T.E.D. 28 January 2018 в 18:40
поделиться
  • 1
    " Изящный Solution" и setInterval не принадлежат той же регистрации. – aaronsnoswell 26 September 2012 в 15:45

В некоторой степени Фортран был разработан, имея в виду компиляторную оптимизацию. Язык поддерживает целые операции над массивом, где компиляторы могут использовать параллелизм (особенно на многоядерных процессорах). Например,

Плотное умножение матриц просто:

matmul(a,b)

норма L2 вектора x:

sqrt(sum(x**2))

операторы Moreover такой как FORALL, PURE & ELEMENTAL процедуры и т.д. дальнейшая справка для оптимизации кода. Даже указатели в Фортране не так гибки как C из-за этой простой причины.

предстоящий стандарт Фортрана (2008) имеет co-массивы, который позволяет Вам легко писать параллельный код. G95 (открытый исходный код) и компиляторы от CRAY уже поддерживают его.

Так да Фортран может быть быстрым просто, потому что компиляторы могут оптимизировать/параллелизировать его лучше, чем C/C++. Но снова как все остальное в жизни существуют хорошие компиляторы и плохие компиляторы.

61
ответ дан CT Zhu 28 January 2018 в 18:40
поделиться
  • 1
    спасибо за него чувак. Я чувствующий себя удобным с этим:) – Vicky 26 June 2009 в 17:41

У вас есть ArrayList.Adapter , который позволяет использовать процедуры сортировки ArrayList , но это сильно повлияет на производительность для общих списков неупакованных типов значений, плюс накладные расходы как на виртуальный вызов, так и на диспетчеризацию интерфейса.

Для ссылочных типов и типов значений диспетчеризация интерфейса может быть дорогостоящей, что означает вызов ICollection .CopyTo массива T [] , за которым следует отдельная сортировка, может быть самым быстрым вариантом общего назначения, включая настраиваемое расширение для прямой сортировки по объекту IList .

List имеет метод Sort , потому что он может очень эффективно работать с базовым массивом типа T [] .Это просто невозможно сделать для произвольного IList .

файлы с произвольным доступом существуют, но вы когда-нибудь видели, чтобы они использовались?)
  • это не способствует хорошей практике разработки, модульности.
  • Фактическое отсутствие полностью стандартного, полностью совместимого компилятора с открытым исходным кодом (и gfortran, и g95 не поддерживают все)
  • очень плохая совместимость с C (искажение: одно подчеркивание, два подчеркивания, отсутствие подчеркивания, в целом одно подчеркивание, но два, если есть другое подчеркивание. И просто не позволяйте углубляться в ОБЩИЕ блоки ...)
  • Тогда проблема в не имеет значения. Если что-то работает медленно, в большинстве случаев вы не можете улучшить это сверх заданного предела. Если хотите быстрее, измените алгоритм. В конце концов, компьютерное время стоит недорого. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно рентабельно.

  • эффективное отсутствие полностью стандартного, полностью совместимого компилятора с открытым исходным кодом (и gfortran, и g95 не поддерживают все)
  • очень плохая совместимость с C (искажение: одно подчеркивание, два подчеркивания, без подчеркивания, в целом одно подчеркивание, но два если есть еще один знак подчеркивания. и только не надо вникать в ОБЩИЕ блоки ...)
  • Тогда проблема не имеет значения. Если что-то работает медленно, в большинстве случаев вы не можете улучшить это сверх заданного предела. Если хотите что-то побыстрее, измените алгоритм. В конце концов, компьютерное время стоит недорого. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно рентабельно.

  • эффективное отсутствие полностью стандартного, полностью совместимого компилятора с открытым исходным кодом (и gfortran, и g95 не поддерживают все)
  • очень плохая совместимость с C (искажение: одно подчеркивание, два подчеркивания, без подчеркивания, в целом одно подчеркивание, но два если есть еще один знак подчеркивания. и только не надо вникать в ОБЩИЕ блоки ...)
  • Тогда проблема не имеет значения. Если что-то работает медленно, в большинстве случаев вы не можете улучшить это сверх заданного предела. Если хотите быстрее, измените алгоритм. В конце концов, компьютерное время стоит недорого. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно рентабельно.

    одно подчеркивание, два подчеркивания, без подчеркивания, как правило, одно подчеркивание, но два, если есть другое подчеркивание. и только давай не вникать в ОБЩИЕ блоки ...)

    Тогда вопрос неактуален. Если что-то работает медленно, в большинстве случаев вы не можете улучшить это сверх заданного предела. Если хотите что-то побыстрее, измените алгоритм. В конце концов, компьютерное время стоит недорого. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно рентабельно.

    одно подчеркивание, два подчеркивания, без подчеркивания, обычно одно подчеркивание, но два, если есть другое подчеркивание. и только давай не вникать в ОБЩИЕ блоки ...)

    Тогда вопрос неактуален. Если что-то работает медленно, в большинстве случаев вы не можете улучшить это сверх заданного предела. Если хотите быстрее, измените алгоритм. В конце концов, компьютерное время стоит недорого. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно рентабельно.

    компьютерное время дешево. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно рентабельно.

    компьютерное время дешево. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно рентабельно.

    0
    ответ дан 22 November 2019 в 23:38
    поделиться

    Более быстрый код на самом деле не зависит от языка, это компилятор, поэтому вы можете увидеть «компилятор» ms-vb, который генерирует раздутый, более медленный и избыточный объектный код, связанный вместе внутри ".exe", но powerBasic генерирует слишком лучший код. Объектный код, созданный компиляторами C и C ++, генерируется на некоторых этапах (по крайней мере, 2), но по замыслу большинство компиляторов Fortran имеют как минимум 5 этапов, включая высокоуровневую оптимизацию, поэтому по замыслу Fortran всегда будет иметь возможность генерировать высокооптимизированный код. Итак, в конце концов, это компилятор, а не тот язык, о котором вы должны просить, лучший компилятор, который я знаю, - это Intel Fortran Compiler, потому что вы можете получить его в LINUX и Windows, и вы можете использовать VS в качестве IDE, если вы ищете дешевый жесткий компилятор, который вы всегда можете передать на OpenWatcom.

    Подробнее об этом: http://ed-thelen.org/1401Project/1401-IBM-Systems-Journal-FORTRAN.html

    5
    ответ дан 22 November 2019 в 23:38
    поделиться

    Пару лет я занимался математикой на FORTRAN и C. Из моего собственного опыта я могу сказать, что FORTRAN иногда действительно лучше C, но не из-за скорости (можно заставить C работать так же быстро, как FORTRAN, используя соответствующий стиль кодирования), а скорее из-за очень хорошо оптимизированных библиотек, таких как LAPACK, и из-за отличной параллелизации. На мой взгляд, FORTRAN действительно неудобен в работе, и его преимущества недостаточно хороши, чтобы компенсировать этот недостаток, поэтому сейчас я использую C+GSL для вычислений.

    11
    ответ дан 22 November 2019 в 23:38
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы: