Здравствуйте, Шахтер, Вы писали:
Ш>Вообще, оптимизация кода практически не зависит от языка.
Все-таки зависит. Конечно, на уровне комплексных чисел, никакой разницы нет, но, тем не менее, разные свойства языков допускают/упрощают разные оптимизации.
FORTRAN благодаря ограниченности языка допускает меньше возможностей для data aliasing, что позволяет большее количество оптимизаций при манипуляции данными, чем например, в C. В последнем стандарте C, C99, например, ввели специальное ключевое слово, restricted, чтобы уровнять шансы для оптимизиции с FORTRAN'ом. В C++ ситуация другая. Высокоуровневые вычислительные библиотеки такие как Blitz++ надежно энкапсулируют данные, работать с указателями нет нужды, и компилятор может сделать aliasing analysis.
FORTRAN 95 поддерживает матричные операции, которые компилятор может перевести в соответствующие multimedia инструкции современных процессоров. Для C и C++ оптимизатор должен быть достаточно нетривиальным, чтобы распознать такие ситуации, хотя это тоже возможно и делается.
В тоже время у C++ есть одно приемущество для проведения глобальных оптимизаций. Дело в том, что source code библиотек обычно доступен в следствие повсеместного использования шаблонов. В FORTRAN'е же библиотеки представляют заранее скомпилированные модули, которые к тому же должны быть вызываемы из C, поэтому возможностей таких оптимизаций меньше.
Насчет комплексных чисел скажу отдельно. Если кто читал Липпмана "C++ Object Model", то там описывается случай сравнения эффективности C++ и FORTRAN при работе с комплекными числами. Сначала версия C++ работала в два раза медленнее. И проблемма была в ... избыточном вызове конструкторов копирования. Как только это было выяснено и устранено производительность обеих программ стала идентичной.
A2>Один уважаемый программер как-то заявил следующее (давно было, текст примерный): A2>«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…». A2>Вопрос: может ли точность зависть от языка? A2>И вообще, что уважаемый ALL думает о Fortran’е (насколько этот язык востребован сейчас)? Появился ведь Visual Fortran, значит его актуальность сохранилась….
A2>Заранее СПАСИБО!!!
Ну, не на персональных, а на нормальных компьютерах фортран и сейчас рулит. Несколько книжек Бартеньева, одна из которых тому подтверждение.
По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>1. Знатоки фортрана, как правило, не знают других языков. И не стремятся узнать.
Тем более, что их основной интерес — численные методы, зачастую в конкретных приложениях, а не программирование вообще.
LVV>2. Знатоки других языков не знают фортрана. И не стремятся узнать.
Еще бы, ведь у фортрана-77 (про -90 уже не в курсе) обратная совместимость чуть ли не с фортран-II, а это, извините, вообще макроассемблер для IBM-360!
Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.
LVV>3. Знатоки языков — не знают численных методов. И не стремятся узнать. LVV>4. Объем — не под силу паре человек. Тут должна работать целая команда. Или даже контора должна на этом специализироваться.
Здравствуйте, oRover, Вы писали:
PE>>1. Перегнать весь код в один класс с сохранением процедур,имен переменных, !!!!переходов!!!! и комментариев, буде таковые найдутся.
R>надо сделать русско-белорусский словарь на РСДН
А при чем здесь белорусско-русский словарь ? В белорусском языке такого оборота нет.
Здравствуйте, achp, Вы писали:
К>>Оптимизирующий компилятор фортрана для векторных процессоров, например, крэй, вынужден догадываться, ... А ведь цикл можно записать десятком разных способов. ...
A>Я попробовал об этом написать здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=89410&only=1
A2>Один уважаемый программер как-то заявил следующее (давно было, текст примерный): A2>«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…». A2>Вопрос: может ли точность зависть от языка?
Может.
Дело в том, что вообще говоря, в компьютерных вычислениях некоторые правила арифметики выполняются не совсем точно. Например, a*(b+c) не обязательно окажется равным a*b+a*c. Это происходит из-за ошибок округления. Так вот, в стандарте Фортрана этому уделено особое внимание, прописано как должен себя вести компилятор, и как следствие, вычисления чуть точнее...
PE>Авторы того кода были чаще всего хрошими инженерами или математиками, но , к сожалению, естественная уыль населения сделала свое черное дело.
PE>1. Перегнать весь код в один класс с сохранением процедур,имен переменных, !!!!переходов!!!! и комментариев, буде таковые найдутся.
Здравствуйте, Larm, Вы писали:
L>А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...
Уже все давно написано.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Один уважаемый программер как-то заявил следующее (давно было, текст примерный):
«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…».
Вопрос: может ли точность зависть от языка?
И вообще, что уважаемый ALL думает о Fortran’е (насколько этот язык востребован сейчас)? Появился ведь Visual Fortran, значит его актуальность сохранилась….
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, не на персональных, а на нормальных компьютерах фортран и сейчас рулит. Несколько книжек Бартеньева, LVV>одна из которых тому подтверждение. LVV>По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
Хотя сам по себе язык страшненький.
Я очень жалею, что с фортраном пытался конкурировать APL, но не выжил из-за откровенно издевательского синтаксиса (алфавит языка уходил далеко за пределы ASCII).
А там была такая классная матричная арифметика! Сколько сил сэкономили бы разработчики программ и компиляторов...
Оптимизирующий компилятор фортрана для векторных процессоров, например, крэй, вынужден догадываться, что за
DO 1 I=1,100,1
F(I)=G(I)+H(I)
1 CONTINUE
скрывается векторная операция F = G+H. А ведь цикл можно записать десятком разных способов. В результате автор программы должен знать, как писать код, чтобы его можно было оптимизировать.
Здравствуйте, Кодт, Вы писали:
К>Хотя сам по себе язык страшненький. ...
К>Оптимизирующий компилятор фортрана для векторных процессоров, например, крэй, вынужден догадываться, ... А ведь цикл можно записать десятком разных способов. ...
Здравствуйте, LaptevVV, Вы писали:
LVV>По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
Интересно, а в чем сложность перевести эти библиотеки на другие языки?
Здравствуйте, Кодт, Вы писали:
К>Дело не в абстракциях и выразительной мощи.
Да нет же, именно в них.
К>И Фортран, и С++ — языки для скалярных вычислений. А математикам часто нужны векторные и матричные.
И Фортран и Си++ могут полагаться на специфичные для платформы библиотеки с объектным кодом, невыразимым на самих этих языках.
К>Фортран вообще вырос из макроассемблера для какой-то древней IBM. Вот если бы он начинался от Крея — было б по-настоящему интересно.
Не было бы. Есть ведь уйма "приспособлений" Фортрана для разных аппаратных платформ с оптимизацией специфических операций. Почему они все не прижились?
Причина в том, что хочется иметь язык а) универсальный и не замкнутый на конкретную платформу, б) способный использовать специфику отдельных платформ. Эти два требования состоят в конфликте друг с другом.
Борьба с этим конфликтом может быть либо механической, либо диалектической , то есть — либо унификация, либо выделение абстракций.
То есть, если производится сложение векторов, то его так и нужно назвать в библиотеке — сложением векторов (ввести абстракцию), а не писать цикл. Реализация, которой доступен векторизующий процессор, может использовать эту особенность платформы, а другая реализация честно выполнит цикл.
Си++ дает нам возможнось выделить и назвать абстракцию, Фортран — нет.
A2>Один уважаемый программер как-то заявил следующее (давно было, текст примерный): A2>«… для решения этой задачи использовались численные методы. Было рассмотрено несколько реализаций и выбрана реализация на Fortran’е. Т.к. она была более быстрая и давала более точное решение…». A2>Вопрос: может ли точность зависть от языка? A2>И вообще, что уважаемый ALL думает о Fortran’е (насколько этот язык востребован сейчас)? Появился ведь Visual Fortran, значит его актуальность сохранилась….
A2>Заранее СПАСИБО!!!
IMHO, востребован только для поддержки древнего наследия в виде огромных отработанных библиотек. То, что он сколько-нибудь быстрее С на ПК на современных компиляторах — миф. Про Большие Машины ничего не скажу, в них не разбираюсь...
Я когда-то проводил элементарное сравнение (вычисление интеграла), наслушавшись таких программеров, но значимой разницы не обнаружил (С был слегка быстрее ). А уж насчет точности... Это, скорее, вопрос реализации алгоритма, а не конкретного языка.
Мы используем C++ для численного моделирования и ничуть об этом не жалем
Полность согласен с achp
Пункт 3 обязательных правил запрещает излишнее цитирование и требует оставлять в ответах только критичные для понимания цитаты.
Обратите на это внимание.
Здравствуйте, Socrat, Вы писали:
S>Что-то я не понял. Неужели абзац — уже слишком много для цитирования? Или он не относится к задаваемому вопросу?
Лишние цитаты в этом сообщении были удалены модератором, по-видимому. Поэтому к этому сообщению претензия уже не относится.
Но требование соблюдать правила относится ко всем сообщениям. К сожалению, в своих ответах ты иногда этим пренебрегаешь.
Это интересно, спасибо!
Но меня настораживает следующее (цитата из статьи):
Размерность массива, предназначенного для хранения расчетных значений первого теста, выбрана равной 96 x 96. При 4-байтовой длине элементов этот массив займет в оперативной памяти 36 KB, что примерно в 1,8 раза меньше, чем размер кэш-памяти L2 процессора VIA C3 (64 KB), и в 3,6 раза меньше, чем L2-кэш у Celeron Coppermine (128 KB). Такое соотношение и особенности алгоритма обеспечивают благоприятные условия для эффективного использования кэш-памяти в данном тесте.
Хорошо, если приходится работать с такими массивами А если они имеют размерность ~1*10^8(общее число ячеек)? Тогда, пожалуй, в кэш не поместится. И какие будут результаты в этом случае? Учитывая, что скорость обмена с памятью практически одинаковая для всех компиляторов, разница в 30% Intel C++ vc Fortran превратится в нечто совсем мифическое.
Наверное есть класс задач, где все данные удается запихать в кэш, вот только мне с ними работать не приходится.
Потом, реализация алгоритмов не преведена. Вряд ли, конечно, там что-нибудь сделано некорректно, но все же...
Думай, прежде чем родиться в этой сказочной стране!
(с) Антон Духовской
Здравствуйте, Комаров Иван, Вы писали:
КИ>Хорошо, если приходится работать с такими массивами А если они имеют размерность ~1*10^8(общее число ячеек)? Тогда, пожалуй, в кэш не поместится. И какие будут результаты в этом случае? Учитывая, что скорость обмена с памятью практически одинаковая для всех компиляторов, разница в 30% Intel C++ vc Fortran превратится в нечто совсем мифическое.
Безотносительно к тесту, есть забавный факт, что к памяти можно по разному обращаться. Известно, например, что линейное чтение не является наиболее эффективным и позволяет достичь разве что 40%-50% процентов от максимального throughput'а.
Здравствуйте, Socrat, Вы писали:
LVV>>По поводу точности — от языка не зависит. Просто для фортрана еще с конца 50-х годов нарабатывались библиотеки численных методов. Сейчас это тщательно отлаженные "вылизанные" подпрограммы и их огромное количество. Ни один язык программирования не обладает таким количеством наработок высокого класса именно в численных расчетах.
S>Интересно, а в чем сложность перевести эти библиотеки на другие языки?
Сложность в том, что в то время, когда жил фортран, культуры программирования не существовало.
На фортране писали еще хуже, чем на перле сейчас. Процедуры в !сотни килобайт! не редкость. Goto был самым используемым оператором. Имена переменных сводились к двум-трем буквам.Структур данных не было, использовались массивы.Копипейст это была основная и почти единственная парадигма пррограммирования.
Авторы того кода были чаще всего хрошими инженерами или математиками, но , к сожалению, естественная уыль населения сделала свое черное дело.
Чтобы перевести программу с фортрана например на С++ нужно.
1. Перегнать весь код в один класс с сохранением процедур,имен переменных, !!!!переходов!!!! и комментариев, буде таковые найдутся.
2. Изучить теорию, а лучше описание алгоритма.
3. Переименовать все переменные по-человечески.
4. Разобраться с таким кодом
5. Написать юниттесты на все функции с учетом самых редких, вырожденных случаев.
6. Теперь можно написать несколько врапперов или произвести рефакторинг кода, на кажом этапе тестируя, тестируя и еще много раз тестируя.
Если выбираете рефакторинг, то нужно найти несколько человекомесяцев в пересчете на мегабайт кода.
Это дорого ! Но зате есть плюс — если алгоритм уникальный, то моджно быть уверенным, что он до сих пор уникальный Чаще всего используют врапперы всякие.
Но даже сейчас MS Visual Fortran рулит. Мне посчастливилось поработать с кодом, где добрый десяток мегабайт кода именно на Фортране. Насколько ме известно, тот проект еще жив !
Здравствуйте, Кодт, Вы писали:
К>Хотя сам по себе язык страшненький.
Ну, я писал на нем в свое время. Его даже пытались использовать в качестве единого языка для решения проблемы мобильности ПО. Я даже диплом писал "Фортран->Фортран" c jlyjuj rjvgm.nthf yf lheujq/ К>Я очень жалею, что с фортраном пытался конкурировать APL, но не выжил из-за откровенно издевательского синтаксиса (алфавит языка уходил далеко за пределы ASCII). К>А там была такая классная матричная арифметика! Сколько сил сэкономили бы разработчики программ и компиляторов...
В книжке ООП в действии Тимоти Бадда есть просто великолепный пример использования АПЛ на задаче, на которой фортран просто загнулся! Почитайте — классное чтиво!
Помнится еще IBM пыталась АПЛ как-то поддерживать и по этой системе даже книжка была — не помню авторов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Socrat, Вы писали:
S>Интересно, а в чем сложность перевести эти библиотеки на другие языки?
1. Знатоки фортрана, как правило, не знают других языков. И не стремятся узнать.
2. Знатоки других языков не знают фортрана. И не стремятся узнать.
3. Знатоки языков — не знают численных методов. И не стремятся узнать.
4. Объем — не под силу паре человек. Тут должна работать целая команда. Или даже контора должна на этом специализироваться.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Кодт, Вы писали:
К>>Хотя сам по себе язык страшненький. LVV>Ну, я писал на нем в свое время. Его даже пытались использовать в качестве единого языка для решения проблемы мобильности ПО. Я даже диплом писал "Фортран->Фортран" c jlyjuj rjvgm.nthf yf lheujq/
С чем-чем?
К>>Я очень жалею, что с фортраном пытался конкурировать APL, но не выжил из-за откровенно издевательского синтаксиса (алфавит языка уходил далеко за пределы ASCII). К>>А там была такая классная матричная арифметика! Сколько сил сэкономили бы разработчики программ и компиляторов... LVV>В книжке ООП в действии Тимоти Бадда есть просто великолепный пример использования АПЛ на задаче, на которой фортран просто загнулся! Почитайте — классное чтиво!
Мне шеф рассказывал, что в ЦНИИ кораблестроения им. Крылова была французская ЭВМ с АПЛ на борту.
Так вот, библиотека подпрограмм к ней была оформлена в виде перекидного календаря. Слева на развороте — подпрограмма в несколько строчек, сопроводиловка к ней, а справа — фото женщин. Для подъёма, тыскыть, энтузиазма.
LVV>Помнится еще IBM пыталась АПЛ как-то поддерживать и по этой системе даже книжка была — не помню авторов.
Я в руках держал интерпретатор АПЛ для IBMPC. Больше всего затрахивал способ ввода всех этих кружков с точками.
Плюс убойная графика чб 640*200.
Когда в институте работали с матлабом, моя душа плакала. Ну почему нельзя было ТОГДА (в 60-е годы) ввести такой удобный аскишный синтаксис?!
Здравствуйте, Кодт, Вы писали:
LVV>>Ну, я писал на нем в свое время. Его даже пытались использовать в качестве единого языка для решения проблемы мобильности ПО. Я даже диплом писал "Фортран->Фортран" c jlyjuj rjvgm.nthf yf lheujq/
одного компьютера на другой. К>С чем-чем?
К>Мне шеф рассказывал, что в ЦНИИ кораблестроения им. Крылова была французская ЭВМ с АПЛ на борту. К>Так вот, библиотека подпрограмм к ней была оформлена в виде перекидного календаря. Слева на развороте — подпрограмма в несколько строчек, сопроводиловка к ней, а справа — фото женщин. Для подъёма, тыскыть, энтузиазма. К>Я в руках держал интерпретатор АПЛ для IBMPC. Больше всего затрахивал способ ввода всех этих кружков с точками. К>Плюс убойная графика чб 640*200. К>Когда в институте работали с матлабом, моя душа плакала. Ну почему нельзя было ТОГДА (в 60-е годы) ввести такой удобный аскишный синтаксис?!
Да, по мощности конструкций — наверное ни один язык не сравнится. Но по синтаксису — это ж компьютерная стенография! Помнится, читал в какой-то книжке: один из китов признался, что расшифровывал 4 строчки на АПЛ около 4 часов!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, LaptevVV, Вы писали:
К>Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, Socrat, Вы писали:
S>>Интересно, а в чем сложность перевести эти библиотеки на другие языки? LVV>1. Знатоки фортрана, как правило, не знают других языков. И не стремятся узнать. LVV>2. Знатоки других языков не знают фортрана. И не стремятся узнать. LVV>3. Знатоки языков — не знают численных методов. И не стремятся узнать. LVV>4. Объем — не под силу паре человек. Тут должна работать целая команда. Или даже контора должна на этом специализироваться.
Как-то читал я книгу по авторегрессионному анализу. Там все примеры были написаны на фортране. Перевод на C++ не вызывал никаких трудностей.
Здравствуйте, Socrat, Вы писали:
S>Как-то читал я книгу по авторегрессионному анализу. Там все примеры были написаны на фортране. Перевод на C++ не вызывал никаких трудностей.
Если написано структурировано и культурно, хорошим почерком, с соблюдением негласных правил, то любой язык на любой переписать очень просто. Я раз видел уникальную библиотеку по сопромату — больше не хочу.
Переписать ее не смогли. Как ни крути, в то время, когда были написаны основные программы на фортране, культуры программирования по сути и не было.
К>>Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.
S>Я согласен.
И табуретками швыряться не будешь?!
К>>>Предложите-ка С++- или даже фортран-программисту посопровождать библиотеки для калькулятора БЗ-34 (а к нему, между прочим, много чего понаписано было). Главное потом увернуться от летящей табуретки.
S>>Я согласен. U>И табуретками швыряться не будешь?!
А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...
The God who walks is among us...
Re[3]: Fortran vs C
От:
Аноним
Дата:
12.02.04 16:40
Оценка:
Здравствуйте, Кодт, Вы писали:
К>Оптимизирующий компилятор фортрана для векторных процессоров, например, крэй, вынужден догадываться, что за К>
К> DO 1 I=1,100,1
К> F(I)=G(I)+H(I)
К>1 CONTINUE
К>
К>скрывается векторная операция F = G+H. А ведь цикл можно записать десятком разных способов. В результате автор программы должен знать, как писать код, чтобы его можно было оптимизировать.
В FORTRAN-90 именно так и можно записать сложение масивов, а еще можно записать b = MAX(A) и в b будет максимальное значение из массива
И для разных архетектур это будт обрабатываться по разному. И вообще в 90 сделан большой упор использование паралельности.
А еще введена перегрузка функций. Так что язык развивается, и значит это кому-то нужно
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, Larm, Вы писали:
L>>А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...
Ш>С чего бы это?
Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,... А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )
Здравствуйте, Larm, Вы писали:
L>Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,... А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )
L>Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,...
Угу. Конечно. L> А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )
Вот фомы неверующие... Неправда это все. Во-первых, в комплексных числах никаких виртуальных функций быть не может. Ок, остались только статические. Далее, передача this сама по себе ничего не стоит. "Получение доступа к полям" — тоже. Что, кто-то искренне полагает, что там кто-то что-то в стек будет складывать? Или что Fortran это сделает как-то намного быстрее? На практике все элементарный функции инлайнятся, благодаря чему всякие штуки типа вычисления корня из суммы квадратов модулей практически невозможно ускорить даже ручным ассемблерным кодом.
В общем, я бы рекомендовал перед тем как делать подобные заявления, просто натравить дизассемблер на результат работы С++ компилятора со включенной оптимизацией.
Я так думаю, что сила Фортрана исключительно в хорошо проработанных библиотеках математики. В некоторых местах там наверное можно даже встретить глобальные оптимизации. ООП здесь совершенно ни при чем.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Larm, Вы писали:
L>Здравствуйте, Шахтер, Вы писали:
Ш>>Здравствуйте, Larm, Вы писали:
L>>>А вдобавок втроенная поддержка компленксных чисел. НА С++ придется классы писать, а это медленнее...
Ш>>С чего бы это?
L>Да хотя бы потому, что будут вызываться виртуильные функции (или пусть даже обычные ), им передается this, там ты получаешь доступ к полям Re & Im, проводишь с ними какие-то операции через встроенные типы,... А когда это встроено в язык, то и работает это побыстрее . Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной . (а она будет поболее )
Не будет ничего вызыватся. Компилятор встроит код в точку вызова. Никакой разницы с Fortran ом просто не будет. Вообще, оптимизация кода практически не зависит от языка. Если оптимизатор написан качественно, то результаты будут одинаковыми.
Перекуём баги на фичи!
, то есть — либо унификация, либо выделение абстракций.
То, что он сколько-нибудь быстрее С на ПК на современных компиляторах — миф. Про Большие Машины ничего не скажу, в них не разбираюсь... 
. Когда у тебя МНОГО вычислений, разница даже в 20-30% будет ОЧЕНЬ заметной 
