[fortran vs. C] что легче компилятору оптимизировать?
У Фортрана многомерные массивы по-другому в памяти расположены.
Да, поменяй индексы местами в фортране. Скажи какие результаты.
Ну и еще, вроде как, основная фишка Фортрана не в скорости, а в том, что операции с числами четко определены стандартом.
2 ,
действительно, смена индексов решила проблему, внутренний цикл векторизуется и время почти одинаковое
спасибо : )
и все-таки повторю вопрос
сталкивались ли вы на практике с ситуацией, когда использование фортрана было предпочтительно? Восновном интересует конечно производительность.
действительно, смена индексов решила проблему, внутренний цикл векторизуется и время почти одинаковое
спасибо : )
и все-таки повторю вопрос
сталкивались ли вы на практике с ситуацией, когда использование фортрана было предпочтительно? Восновном интересует конечно производительность.
Мой опыт работы в НИИ подсказывает, что Фортраном пользуются потому, что ему учили раньше.
Ну вот просто выросло поколение ученых, которые пользовали перфокарты и боролись за каждый байт. И про другие языки и не слышали. Вот и пишут на Фортране.
Оптимизировать нужно только хорошо написанную программу, а российские ученые, афаик, таких не пишут.
Ну вот просто выросло поколение ученых, которые пользовали перфокарты и боролись за каждый байт. И про другие языки и не слышали. Вот и пишут на Фортране.
Оптимизировать нужно только хорошо написанную программу, а российские ученые, афаик, таких не пишут.
фортран удобен встроенной поддержкой массивов.
одни сечения чего стоят.
очень удобно и приятно писать.
работал как то один раз в одной паре с физиком (физфак привет
) в одном проекте. он придумывал мат. модели из первых принципов. Гидродинамику на си писал. реализовывал свои классы векторов, матриц и т.п.
у меня на фотране его алгоритм переписался в 4 (четыре) раза короче как по коду, так и по бинарнику (знаю знаю, не кричите про бинарник, это не очем не говорит, но всё же...
а вот утверждения что проги на фортране быстрее чем на си - есессно блажь.
ибо всё зависит от того кто пишет, как пишет, какой компилятор, какие опции компилятора, какая платформа и т.п.
>отимизировать нужно только хорошо написанную программу, а российские ученые, афаик, таких не пишут.
прискорбно, но факт...
как то в одном проекте, лет 6 наза попытались использовать матлибу от нашего НИВЦа МГУшного - волосы дыбом на жопе встали.
а всё от того, что пишут такие вещи студни неразумные, каждый год новый. вот и получается как письмо из Простоквашино.
вощем никакой культуры
одни сечения чего стоят.
очень удобно и приятно писать.
работал как то один раз в одной паре с физиком (физфак привет
) в одном проекте. он придумывал мат. модели из первых принципов. Гидродинамику на си писал. реализовывал свои классы векторов, матриц и т.п.у меня на фотране его алгоритм переписался в 4 (четыре) раза короче как по коду, так и по бинарнику (знаю знаю, не кричите про бинарник, это не очем не говорит, но всё же...
а вот утверждения что проги на фортране быстрее чем на си - есессно блажь.
ибо всё зависит от того кто пишет, как пишет, какой компилятор, какие опции компилятора, какая платформа и т.п.
>отимизировать нужно только хорошо написанную программу, а российские ученые, афаик, таких не пишут.
прискорбно, но факт...
как то в одном проекте, лет 6 наза попытались использовать матлибу от нашего НИВЦа МГУшного - волосы дыбом на жопе встали.
а всё от того, что пишут такие вещи студни неразумные, каждый год новый. вот и получается как письмо из Простоквашино.
вощем никакой культуры
как то в одном проекте, лет 6 наза попытались использовать матлибу от нашего НИВЦа МГУшного - волосы дыбом на жопе встали.это пиздец. Не понимаю, откуда там взялось такое - такая либа бы зачёт Богачёву точно не прошла.
MinGW gcc (с++) под Windows, например, пихает в бинарник кучу всякого ненужного, и у них даже в FAQ есть как ему харакири делать.
На фортране ещё очень много всего запрогано, дешевле при сопровождении новый транслятор сделать, чем на другой язык переводить.
На фортране ещё очень много всего запрогано, дешевле при сопровождении новый транслятор сделать, чем на другой язык переводить.
а российские ученые, афаик, таких не пишутПишут, но единицы.
И во всем мире хорошие вычислительные программы пишут единицы.
Дело не в России.
Фортран очень хорош в плане простоты написания небольших по объему программ. Однако из-за сильно урезанной поддержки ООП в больших программах возникают проблемы. Народ даже пишет статьи в спец. журналах по эмуляции элементов ООП в научных расчетах на фортране.
> Оптимизировать нужно только хорошо написанную программу
Почему? Имхо как раз чем оптимальнее я сам написал программу, тем меньше остается оптимизировать компилятору. И плохо написанные проги могут оптимизироваться по скорости гораздо сильнее, чем хорошие (хотя все равно будут уступать последним, конечно).
Почему? Имхо как раз чем оптимальнее я сам написал программу, тем меньше остается оптимизировать компилятору. И плохо написанные проги могут оптимизироваться по скорости гораздо сильнее, чем хорошие (хотя все равно будут уступать последним, конечно).
Потому что плохие программы надо сначала нормально переписать, а потом уже оптимизировать.
тоже когда то жалели об этом (о поддержки ООП в Ф но быстро переболели.
назначение у фортрана изначально другое. формула транслэшн как никак.
наибольшее наслаждение получил, когда выдрал метод сопряженых градиентов из какого то учебника по чмам, посимволльно скопировал
выкладки в код и расставил точки с запятыми. и оно даже скомпилировалось. вот это и есть основная прелесть. никаких лишних _for_ и _do_ для
обхода массивов. если я хочу сложить два вектора и положить их удвоенную суму в третий то я просто пишу c = 2*(a+b)
его удел - быть используемым при написании красивого прозрачного кода, который реализует эффективную молотилку чисел. и всё.
эффективные структуры данных - непрерывные блоки\массивы памяти.
всю остальную - более высокую логику - надо выносить выше и не на фортран. и неча огород городить. иначе велосипед с костылями.
назначение у фортрана изначально другое. формула транслэшн как никак.
наибольшее наслаждение получил, когда выдрал метод сопряженых градиентов из какого то учебника по чмам, посимволльно скопировал
выкладки в код и расставил точки с запятыми. и оно даже скомпилировалось
. вот это и есть основная прелесть. никаких лишних _for_ и _do_ для обхода массивов. если я хочу сложить два вектора и положить их удвоенную суму в третий то я просто пишу c = 2*(a+b)
его удел - быть используемым при написании красивого прозрачного кода, который реализует эффективную молотилку чисел. и всё.
эффективные структуры данных - непрерывные блоки\массивы памяти.
всю остальную - более высокую логику - надо выносить выше и не на фортран. и неча огород городить. иначе велосипед с костылями.
Почему?
Потому что оптимизация ухудшает читабельность программы, и выпрямить оптимизированную программу уже не получится никогда.
если я хочу сложить два вектора и положить их удвоенную суму в третий то я просто пишу c = 2*(a+b)В c++ то же самое, перегрузив * + и т.д.
кхм.
никто не спорит, можно сделать всё что угодно. и шаблоны на фортране тоже
перегрузка дорогая. это факт. напиши тест и посмотри дизассм если чо.
любое языковое удобство в виде какой-либо абстракции в большинстве своем дополнительные затраты.
что перегрузка, что виртуальные функции. за всё надо платить и точка.
и речь тут шла вроде о Си и Ф, причем здесь перегрузка?
никто не спорит, можно сделать всё что угодно. и шаблоны на фортране тоже
перегрузка дорогая. это факт. напиши тест и посмотри дизассм если чо.
любое языковое удобство в виде какой-либо абстракции в большинстве своем дополнительные затраты.
что перегрузка, что виртуальные функции. за всё надо платить и точка.
и речь тут шла вроде о Си и Ф, причем здесь перегрузка?
> В c++ то же самое, перегрузив * + и т.д.
Щаззз, три раза то же самое и четвёртое одно и то же сверху.
На плюсах у тебя будут промежуточные результаты, тысячи их, и что-то я дичайше сомневаюсь, что компилятор, не имеющий ни малейшего представления о твоей семантике, сумеет их отоптимизировать нафиг.
Щаззз, три раза то же самое и четвёртое одно и то же сверху.
На плюсах у тебя будут промежуточные результаты, тысячи их, и что-то я дичайше сомневаюсь, что компилятор, не имеющий ни малейшего представления о твоей семантике, сумеет их отоптимизировать нафиг.
На плюсах у тебя будут промежуточные результаты, тысячи их, и что-то я дичайше сомневаюсь, что компилятор, не имеющий ни малейшего представления о твоей семантике, сумеет их отоптимизировать нафиг.они работают над этим, лол. =)
в новом стандарте будет фича rvalue references.
при создании объекта можно будет использовать swap вместо копирования строки.
class string
{
string(string&& rvref)
{
swap(rvref);
}
};
Щаззз, три раза то же самое и четвёртое одно и то же сверху.т.е. ты хочешь сказать, что на C++ действительно нельзя написать либу: чтобы синтаксис и скорость работы были сравнимы с фортраном?
> В c++ то же самое, перегрузив * + и т.д.Ну дык не надо так тупо перегружать.
Щаззз, три раза то же самое и четвёртое одно и то же сверху.
Уже лет 10 как научились на C++ такие вещи делать не медленнее чем на фортране
http://ubiety.uwaterloo.ca/~tveldhui/papers/iscope97/index.h...
http://www.oonumerics.org/blitz/papers/
На плюсах у тебя будут промежуточные результаты, тысячи их, и что-то я дичайше сомневаюсь, что компилятор, не имеющий ни малейшего представления о твоей семантике, сумеет их отоптимизировать нафиг.Expression templates спасают в таких случаях.
Прочитал первую ссылку. Увидел, что фортран по прежнему быстрее плюсов во всех тестах, но теперь уже всего на десятки процентов, а не в разы.
Да, я, кстати, наивную реализацию подразумевал и, наверное, это было наивно с моей стороны! Спасибо за ссылки.
Вообще я не очень понимаю, нафига этим заниматься. Template metaprogramming в плюсах отнимает в миллион раз больше сил, чем улучшение компилятора фортрана. Зачем писать свой компилятор фортрана на плюсовых говнотемплейтах, если можно писать его на нормальном языке? (любой язык нормальный по сравнению с тьюринг-полными эскейпами темплейтов, даже брейнфак)
Так-то понятно, что компилятор, заточенный под работу с массивами, генерит более быстрый код для работы с массивами. При этом я предлагаю считать все эти чудовищные темплейты compiler augmentations'ами.
Да, я, кстати, наивную реализацию подразумевал и, наверное, это было наивно с моей стороны! Спасибо за ссылки.
Вообще я не очень понимаю, нафига этим заниматься. Template metaprogramming в плюсах отнимает в миллион раз больше сил, чем улучшение компилятора фортрана. Зачем писать свой компилятор фортрана на плюсовых говнотемплейтах, если можно писать его на нормальном языке? (любой язык нормальный по сравнению с тьюринг-полными эскейпами темплейтов, даже брейнфак)
Так-то понятно, что компилятор, заточенный под работу с массивами, генерит более быстрый код для работы с массивами. При этом я предлагаю считать все эти чудовищные темплейты compiler augmentations'ами.
Нет, это все понятно. Но вот есть, например, написанный на фортране готовый код, к которому нужно то дописать, это дописать. Что в этом случае делать? Переписать сразу на более подходящем языке?
смторя что имеется ввиду под "то дописать, это дописать".
большая часть кодов на Ф, с которыми нам приходится иметь дело - математические алгоритмы.
если вам надо улучшить мат алгоритм, писанный на Ф, тогда оставайтесь в рамках Ф.
если вам надо высокую логику прикручивать, то конечно С++.
но мы же в 21 веке уже живем и можно сделать например вот так:
менеджер сырой памяти - С++ || Java.
численная молотилка - Ф90
остальные слои типа Контроллера (модель MVC Представление - это уж как вам угодно - можно
и на жабе, и пласах, и даже прости Господи шарпе. Но и саму Модель можно поделить на бэк-энд и
фронт-энд. Расчетную часть бэкэнда пишем на фортране, манагер памяти на пласах || жабе.
имеейте ввиду, что фортран - это скорость, качество, прозрачность в _обчетных_ алгоритмах,
т.е. вполне конкретная заточка. (хотя мне как выпуснику вычмета о празрачности чмов говорить легко конечно )
а всю абстрактную красоту хайлевелную - пишите на кошерных высокоуровневых языках...
я бы всё таки на джаве остановился. Получаете плюсы переносимости: все расчетные узкие
места идут как отшлифованные, отоптимизированный по самый небалуй либы под конкретную архитектуру, а весь айсберг хайлевельный менять не надо.
PS кстати ещё такой момент, ко всем специализированным вычислительным комплексам (Регата на ВМиК, кластер НИВЦ и т.п. с которыми приходилось иметь дело, поддержка математических библиотек шла на _Си_шных и фортрановских кодах.
большая часть кодов на Ф, с которыми нам приходится иметь дело - математические алгоритмы.
если вам надо улучшить мат алгоритм, писанный на Ф, тогда оставайтесь в рамках Ф.
если вам надо высокую логику прикручивать, то конечно С++.
но мы же в 21 веке уже живем и можно сделать например вот так:
менеджер сырой памяти - С++ || Java.
численная молотилка - Ф90
остальные слои типа Контроллера (модель MVC Представление - это уж как вам угодно - можно
и на жабе, и пласах, и даже прости Господи шарпе. Но и саму Модель можно поделить на бэк-энд и
фронт-энд. Расчетную часть бэкэнда пишем на фортране, манагер памяти на пласах || жабе.
имеейте ввиду, что фортран - это скорость, качество, прозрачность в _обчетных_ алгоритмах,
т.е. вполне конкретная заточка. (хотя мне как выпуснику вычмета о празрачности чмов говорить легко конечно
)а всю абстрактную красоту хайлевелную - пишите на кошерных высокоуровневых языках...
я бы всё таки на джаве остановился. Получаете плюсы переносимости: все расчетные узкие
места идут как отшлифованные, отоптимизированный по самый небалуй либы под конкретную архитектуру, а весь айсберг хайлевельный менять не надо.
PS кстати ещё такой момент, ко всем специализированным вычислительным комплексам (Регата на ВМиК, кластер НИВЦ и т.п. с которыми приходилось иметь дело, поддержка математических библиотек шла на _Си_шных и фортрановских кодах.
Фортран хорош, пока алгоритм прост. Стоит в алгоритме появиться условной логике или динамическим структурам данных и на нем становится невозможно программировать. В моей практике доля простых алгоритмов 0%. Поэтому фортран является большой головной болью.
несогласен
могу сказать всё тоже самое, но с точностью до наоборот
спорить тоже смысла нет - надо код смотреть
как всегда всё сводится к конкретному коду и примерам.
могу сказать всё тоже самое, но с точностью до наоборот
спорить тоже смысла нет - надо код смотреть
как всегда всё сводится к конкретному коду и примерам.
А теперь попробуй сказать тоже самое, но с точностью наоборот
согласен
имелось ввиду несправедливость тезиса сложные мат. алгоритмы => большая головная боль.
и тут даже не то, что впротивном случае боль маленькая, но всё же боль есть
, а имеено что боли нет Ну в идеале конечно же так и надо делать: интерфейс на одном, расчет на другом, обработка на третьем языке и т.д. Однако речь не идет о готовом решении. Код живет и дышит. Периодически нужно лезть в расчетную часть, добавить новую модель, учитывающую до кучи еще какой-нибудь физический эффект. Новая модель требует новых входных данных, нужно менять вызовы функций.
В такой ситуации, при многоязыковом коде, как мне кажется, нужно будет внести гораздо больше изменений по сравнению с кодом на одном языке. Хотя вероятно, я просто пишу не очень хорошие програмки .
В такой ситуации, при многоязыковом коде, как мне кажется, нужно будет внести гораздо больше изменений по сравнению с кодом на одном языке. Хотя вероятно, я просто пишу не очень хорошие програмки
.конечно это вопрос архитектуры.
как раз всё и делается в расчете на то, что система будет легко масштабируемой\наращиваемой.
если постоянно расширяется класс моделей, то надо опять выдять по воможности общую часть и и т.д. и т.п.
а луше конечно общепринятая концепция: базавое ядро\фреймфорк и наращиваемые плагины.
но это коненчо уже совершенно другой разговор, к фортрану не имеющий отношения.
PS а для опсания произвольного формата данных есть замечательное средство - XML. и даже на фортране для него парсеры есть.
как раз всё и делается в расчете на то, что система будет легко масштабируемой\наращиваемой.
если постоянно расширяется класс моделей, то надо опять выдять по воможности общую часть и и т.д. и т.п.
а луше конечно общепринятая концепция: базавое ядро\фреймфорк и наращиваемые плагины.
но это коненчо уже совершенно другой разговор, к фортрану не имеющий отношения.
PS а для опсания произвольного формата данных есть замечательное средство - XML
. и даже на фортране для него парсеры есть.Фортран очень хорош в плане простоты написания небольших по объему программ. Однако из-за сильно урезанной поддержки ООП в больших программах возникают проблемы
+1
Народ даже пишет статьи в спец. журналах по эмуляции элементов ООП в научных расчетах на фортране.
Ссылки не завалялись случайно?
тоже когда то жалели об этом (о поддержки ООП в Ф но быстро переболели.
назначение у фортрана изначально другое. формула транслэшн как никак.
наибольшее наслаждение получил, когда выдрал метод сопряженых градиентов из какого то учебника по чмам, посимволльно скопировал
выкладки в код и расставил точки с запятыми. и оно даже скомпилировалось
обхода массивов. если я хочу сложить два вектора и положить их удвоенную суму в третий то я просто пишу c = 2*(a+b)
его удел - быть используемым при написании красивого прозрачного кода, который реализует эффективную молотилку чисел. и всё.
эффективные структуры данных - непрерывные блоки\массивы памяти.
Это все конечно хорошо.
Только вот отсутствие шаблонов/ооп не позволяет эффективно повторно использовать существующие реализации (копипейст - это неэффективно)
Можно конечно написать шаблонизатор...
всю остальную - более высокую логику - надо выносить выше и не на фортран. и неча огород городить. иначе велосипед с костылями.
Так это все потом еще и стыковать надо
Издержки стыковки не сожрут преимущества?
Так это все потом еще и стыковать надо
Издержки стыковки не сожрут преимущества?
повторюсь: эффективные структуры данных - непрерывные блоки\массивы памяти.
какие могут быть проблемы, когды ты передаешь указатель на кусок памяти и размер этой памяти?
индианити? да и то редко...
Только вот отсутствие шаблонов/ооп не позволяет эффективно повторно использовать существующие реализации (копипейст - это неэффективно)
Можно конечно написать шаблонизатор...
да не надо ничо писать. Читай проще: фортран - низкоуровневый язык со втроенной поддержкой примитивов линейно алгебры и всё. ну чуть тензоров если хотите
.Ещё раз обращу ваше внимание на название темы: fortran vs. C . вы там хоть один плюсик видите?
Ссылки не завалялись случайно?
Ну вот, например:
Comparison of C++ and Fortran 90 for Object-Oriented Scientific Programming
Introduction to Object-Oriented Concepts using Fortran90
How to Support Inheritance and Run-Time Polymorphism in Fortran 90
Ещё раз обращу ваше внимание на название темы: fortran vs. C . вы там хоть один плюсик видите?
Не, ну тогда fortran77 vs C
насчет хронологии согласен, фортран развивается медленно и геморрно.
но ставить в сравнение процедурный и ОО-языки - это извинименя...
но ставить в сравнение процедурный и ОО-языки - это извинименя...
повторюсь: эффективные структуры данных - непрерывные блоки\массивы памяти.
какие могут быть проблемы, когды ты передаешь указатель на кусок памяти и размер этой памяти?
Простой пример - обычные и ленточные матрицы - и то, и другое реализуется массивами, но вот сделать либу на фортране, которая работала бы с ними единообразно без существенного дублирования кода нельзя
Если даже в таком простом случае возникают проблемы
индианити
Это что?
Читай проще: фортран - низкоуровневый язык со втроенной поддержкой примитивов линейно алгебры и всё. ну чуть тензоров если хотите
Ну тогда получается, что ни на что, кроме калькулятора, он не тянет
Ещё раз обращу ваше внимание на название темы: fortran vs. C . вы там хоть один плюсик видите?
Это понятно, но от С до С++ гораздо ближе, чем от фортрана до подобного языка.
То есть получается, что фортран скорее мертв и лишь инерция не дает ему остаться в прошлом.
Спасибо, посмотрю
Оставить комментарий
rolex1993
Столкнулся с утверждением, что для научных расчетов люди используют фортран еще и потому, что фортрановский код компилятору легче оптимизировать. Что вы об этом думаете?Решив проверить это утверждение написал код диагонализующий матрицу.
вот ключевой фрагмент на С
а вот на фортране 77
Удивительно следующее: при компиляции С кода при помощи icc внутренний цикл векторизуется, в то же время при компиляции фортрановской проги ifort-ом внутренний цикл он не векторизует и говорит:
Самое удивительное, что программа на С диагонализует матрицу double 1024x1024 за 2.4 c (-O3 максимум за 4.9 с (с выключенной оптимизацией -O0 т.е. ничего не векторизуется как я понимаю фортрановский же код тратит на исполнение 79с! Опции компиляторов одинаковые. Компиляторы icc ifc 9.1. C gfortran (gcc 4.2.0) та же беда. В чем может быть дело?