Модератор: Выделено из другой популярной темы.



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


Это сообщение отредактировал(а) Cr@$h - 20.1.2009, 09:29

Не. Это не догма Это моё личное мнение. Как и то, что каждый использует тот инструмет, который ему нравится.
Да и на кой чёрт тогда Sun, IBM и иже с ними Фортран развивают?

SSE-инструкции введены не для численных методов, а для оптимизации вычислений с плавающей точкой вообще 
То есть Вы хотите сказать, что, например, Intel-фортран, генерирует неоптимальный маш. код для Intel-процессоров?! Да ещё и без поддержки SSE (Для каких процессоров, кстати. Itlanium)?

Категорически не согласен. Компилятор надо настраивать. Под конкретное железо. Я на своем опыте убедился, что лучший из C-компиляторов для Intel-платформы - это icc:) А вот ifc по многим тестам на 5-10% его производительнее. Проверял сам. Вообще говоря, сейчас затраты на компиляцию пренебрежимо малы, поэтому  грамотно настроенный компилятор icc или ifc практически не различаются по производительности. НО это если сравнивать Фортран и C, как только мы переходим на C++, ООП с высокой степенью абстракции сказывается на производительности. И весьма сильно. Поэтому в выч. математике лучше классы не использовать. А Фортран просто удобнее. Не знаю как у вас, а у меня руки устают писать вложенные циклы, когда массивы обрабатываю. Фортран просто удобнее, скорость разработки мат. приложений выше, кода (а значит и потенциальных ошибок - не тот индекс, например) меньше в разы. 

Помню был случай, писала одна студентка чис. метод для диплома (метод релаксации для решения уравнения Навье-Стокса, описывающего течение вязкой несжимаемой жидкости в гофрированной трубе с периодическим ГУ ) на C. И вечно теряла индекс фиктивного слоя, потому что приходилось в памяти держать этот сдвиг, плюс ещё 2 фиктивных слоя по середине расчетной сетки, а работы мозгам и без этого хватало. Попросила помочь, как результат: код на Фортране был раза в 4 короче, а за счёт удобной индексации массивов, использования их сечений ошибка индексации была просто исключена. Потом, получив хорошие результаты, исправили её программу, скомпилировали (icc) и запустили на моей же машине (Core Quad, в опциях обоих компиляторов автораспараллеливание включено). 

Профилировщик показал, что код на Фортране выполнился на 7% быстрее (Проверялись и вся программа, и только расчётная часть). Хотя программы семантически были буквально один в один. Это как в рекламе про Досю. Зачем писать больше, если результат тот же (в лучшем случае)? 

Да и студентам кафедры "Прикладная математика", 
после года численных методов Фортран пришелся по душе. Практически всем, хотя изучали они его уже с крепко вбитым C и C++.


Это сообщение отредактировал(а) popovda - 23.6.2008, 18:41

Нее, про Itanium-ы - не уверен, но для Intel Core Duo/Quad, AMD Athlon/Operton, короче, где есть поддержка хотя бы SSE 3.


Я имею в виду не компиляторную оптимизацию, а явное использование SSE-инструкций в коде программы. В качестве примера - любая численная схема, например, "чехарда", в которой в нормальном режиме в цикле идёт пересчёт в каждый момент времени для одной точки сетки. Ну а если использовать длинные XMM-регистры, то можно расчитывать значения одновременно в двух последовательных точках сетки, потому что в 128-битный регистр помещается два 64-битных числа двойной точности. Всё это в рамках одного ядра и, конечно, масштабируется.

Всё что умеет ifc если открыть документацию, это MM_PREFETCH - довольно древняя инструкция. Всё остальное не может быть проконтролировано. Вы скажете - всё это не нужно, поскольку ура, компилятор оптимизирующий. НУ КОНЕЧНО, компилятор в состоянии, скажем, сделать развёртку циклов в каком-нибудь скалярном произведении, но не стоит переоценивать его возможности, равно как и автопараллелизма. Они ограниченны несовершенством самой программы : если разработчик создал зависимость по данным там, где она не нужна, никакой оптимизирующий компилятор на это ему не укажет. Да и никаких графов для перекройки программы тоже не строится. Обзор того, что умеют компиляторы давно-давно делал Крис Касперски (и с тех пор стало несильно лучше) в присоединённой статье.


Это обобщение обречено быть неправильным, поскольку оно однозначно, когда как возникающие задачи весьма многообразны. Да и в целом, ну будут классы, и что? Как раз, если вычислительная часть будет достаточно тяжела, накладные расходы на объектность вряд ли будут с ней соизмеримы. То есть если не конструировать массив объектов с вызовом виртуальных функций в цикле с десятью уровнями вложенности, то эффект ООП в показаниях профилировщика придётся искать сильно правее запятой...


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

Всё-таки почему Cи --- системный? Выглядит так, что любой язык - системный, если только это - не фортран, и компилятор - не Intel?


Это сообщение отредактировал(а) marcusmae - 23.6.2008, 20:41

Присоединённый файл ( Кол-во скачиваний: 4 )
 Optimization.Techincs.zip 99,89 Kb

Полагаю, сложились партии с разными взглядами, методологиями и штампами. Например, есть старая шарманка "да как же без фортрана... а вот мы в 70-ые на БЭСМ-6... он будет всегда!" - результат как у неоконченной войны : следующее поколение уже даже не задумывается над тем, по какой причине оно так поляризует свои навыки. Коммерчески-то ясно, что спрос рождает предложение : резкое сворачивание поддержки - верный способ потерять деньги, клиентов и позиции в отрасли. Вероятно, что-то будет меняться, но не за год и даже не за десятилетие. Не нужно просто вешать всякие ярлыки, наоборот, стремиться бы к пониманию  


Это сообщение отредактировал(а) marcusmae - 23.6.2008, 21:05

Отвечу marcusmae - штампы я не использую. Изучать Фортран начал в 2004-2005 году, когда диплом писал (Хотя к тому времени прекрасно знал C/C++ и ещё несколько ЯП, правда раритетных - Ada95, например.) И полюбил его. Что до использования SSE-инструкций в явном виде в коде, то этим вопросом я не задавался. Не требовалось. И сейчас не требуется. Если надо я напишу кусочек на ассемблере.

Почему привел для сравнения компиляторы Intel? Платформа самая распространенная и компилятор для неё родной. 

Что од ООП, то в соответствии со стандартом Fortran 2003, в нем есть полноценная модель ООП. Вопрос не в этом, а в том, как этот ООП реализован. Для C++ - мощного абстрактного языка, производительность - важный критерий, но он не на первом месте. А вот для Фортана - другое дело. Поэтому и синтаксическе конструкции там очень проработаны. Ах с каким бы удовольствием на IBM Fortran XL 11 под PPC работал бы! 

C - это системный ЯП, потому что он создавался как системный ЯП. Я вам и на ассемблере могу списки сортировать, а на Лиспе графику обрабатывать. Но удобно ли это?! Нравится - пользуйте C для выч. математики, я же предпочитаю использовать тот инструмент, который мне удобнее и естественнее. Для меня смесь ЯП - это удобно.



Хочу подправить: диапазон, как вы его назвали, сечение (subsection) массива задается в круглых, а не в квадратных скобках.
И Ваши коллеги просто не переосмыслили язык, т.к. у них остался подход строгой императивности действий. А ведь сечения как раз таки прекрасно оптимизируются на многопроцессных архитектурах. Может они чистые и поэлементные подпрограммы не используют? 
Тогда действительно нет разницы - паскаль, C, Fortran...

На C реализовать такое можно - это будет макрос. Штука потенциально опасная. А на Фортране - это СИНТАКСИЧЕСКАЯ КОНСТРУКЦИЯ ЯЗЫКА, стандартизированная и проверяемая на этапе компиляции. 


Это сообщение отредактировал(а) popovda - 25.6.2008, 22:29

Это будет и труднее, и не то, потому что сами по себе intrinsics - штука более умная : там, где соответствующие инструкции реализуются железом напрямую, они и используются, а там где техника старая или другой архитектуры - эмулируются эквивалентным набором инструкций. То есть, иметь кросс-процессорную поддержку на ассемблере, конечно, не получится - быстро утомитесь, да и ассемблеры под x86 и под x64 различны. Вообще, слово intrinsics это и означает - на фортране под ними понимаются, скажем, функции приведения типов и тригонометрия, так же удовлетворяющие этому свойству.



Люблю, когда каждый неочевидный вывод подкреплён соотв доводами. Это почему макросы ещё потенциально опасны? Препроцессинг суть этап построения программы, не менее значимый, чем компиляция и линкование. Препроцессинг активно используется, например, в кроссплатформенных приложениях, реализуя "вариантность" исходного кода на различных ОС и компиляторах. Например, вот NetCDF - наверно знаком - исходники библиотеки все в макросах   Помимо этого в фортране нет функциональных макросов и токенайзера (##) - например функции max и min - это макросы.

Продолжая разговор о особенностях фортрана (не из области "системных"), вот ещё несколько.

В фортране нет понятия scope-локальных переменных : все переменные должны быть описаны в разделе описаний или вообще в теле модуля. То есть, если мне понадобился индексатор цикла в 200-ой строчке, то я должен чёрте-куда мотать, чтобы его завести. А значит, уважение к читателю этого кода может быть достигнуто только если программа разбита на достаточно маленькие функции, чтобы используемые переменные было видно глазом, что и в общем случае верно, однако мне кажется, что удобнее, если необходимая переменная могла бы быть заведена и уничтожена прямо в тексте, там где используется.

Ещё одно : ссылки. Я извиняюсь, но это просто кошмар, что сделали с ссылками. Есть pointer (это типа void что ли...), есть типизированные указатели - чтобы понадобилось что-то к чему-то привести - ооо... врагу не пожелаешь, как минимум нужно проштудировать мануал  Если нужно возвратить из функции ссылку на массив или allocatable-массив, то это тоже потребует нехилых логических способностей, последнее, с allocatable, как мне теперь кажется, вообще не может корректно работать и не должно использоваться. Общее впечатление - кто-то очень сильно хотел, чтобы фортранщик по возможности не знал о существовании указателей и не сталкивался с ними, что может быть и хорошо, но только до определённого уровня. Указатели - имхо вовсе не черта системного языка, наоборот, гибчайшее средство ориентированное именно на вычислительные операции с массивами. Какой бы ни была размерность массива, в одном из направлений действовать очень удобно и просто, например, чтобы взять сечение трёхмерного массива, достаточно просто переставить указатель на целое число слоёв.

Фортран использует довольно специфические соглашения о вызовах. Это обязательно будет видно, если взамозависимы библиотеки на разных языках. Скажем, параметр-переменная всегда передаётся по ссылке, а параметр-константа - всегда по значению - чтобы это переопределить, нужно использовать диковатые %LOC и %REF - что-то вроде сишных амперсанда и звёздочки...

Синтаксичность языка, о которой Вы упоминаете, на мой взгляд является чрезмерной : не так уж обязательно сваливать всё вместе, делать функции ключевыми словами. Если язык действительно мощный, то его синтаксис "фасад" определяет лишь "сущность", необходимый минимум возможностей, позволяющий при необходимости воспользоваться какими-то специальными расширениями - для ввода-вывода и списков - STL, для системы - Boost, для графики - OpenGL, для аудио - OpenAL, для вычислений - полным-полно больших популярных библиотек на C-C++, и когда Вы говорите, что



просто как-то не получается представить, что все эти люди идиоты, и им не нужна высокая производительность, они лишь наслаждаются магической абстрактностью  У меня был в прошлом году опыт со смесью яп : часть функциональности была выполнена на C#, другая часть с BLAS для разреженных матриц - на фортране. Так вот, этот дует имел весьма приличную производительность, уж поверьте, если нормально всё организовать, то прелести ООП достанутся Вам почти даром  



Ею мало-кто пользуется, и я слышал отзывы о трудностях восприятия. ООП в фортране неудобен, поскольку фортран 40 с лишним лет назад задумывался, как процедурный язык с весьма жёсткой структурой (имя-определения-COMMON-CONTAINS), которая затем чуть ослабилась, появились модули и интерфейсы - уже на них можно много хорошего сделать, но получается обычно хуже, чем могло бы быть. Вид больших атмосферных моделей типа WRF или MM5 несмотря на то, что разработчики тщательно заботятся о документации, описаниях и комментариях, наводит на мысли, что на фортране очень тяжело что-либо хорошо спроектировать : какие соглашения не введёш, с точки зрения организации всё-равно выглядит, как "много всего свалено в кучу".

Другое дело, если пишется что-то небольшое - элементы BLAS, LAPACK или скромная программка для диплома, и в общем - фортран очень удобен для линейной алгебры, но удобство очень "локально" из-за перечисленных выше особенностей.

Приятно об этом беседовать, но пора заканчивать  Думаю, основную мысль я донёс : системность не бывает на пустом месте, она венчает массу возможностей. Да, Фортран - не "язык системного программирования", но в то же время С-С++ имеет все его сильные стороны, как подмножество своих, а во многих отношениях даже более гибкий. 

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

В смысле, через индексаторы?


Ошибки препроцессинга не менее неочевидны, чем любые другие, и то, что было сказано, что его использование потенциально опасно, непонятно. Я бы понял, если бы речь шла об опасности void*, а тут-то вроде ничего особенного...


А я ничего против не имею, хотел лишь показать, что C-C++ по кр мере не уступает фортрану по части программирования математики.  В самом деле, посмотрите в поиск.

препроцессинг не позволяет напрямую читать текст программы

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

Ну это как захотеть, вообще-то из препроцессора можно получить результат в виде кода, прошедшего препроцессинг и делать с ним что-угодно...


Это по поводу чего? Всегда есть, что доделать, но и это вопрос способности к самокритике 


Ну зачем же так обобщать? Какую решать задачу - говорят всюду, детали навязывают в зависимости от обстоятельств, но давать место для манёвра, возможность заинтересоваться - это скорее умно со стороны руководителя, хотя зависит и от качеств подчинённого.


Вы ошибаетесь, если имеете в виду, что указанные свойства сколько-нибудь связаны с конкретным языком. Всё зависит от того, как организовано взаимодействие разработчиков. Если это - трекер Subversion, то нет никакой проблемы вести проект на фортране. У нас один есть.

Это сообщение отредактировал(а) marcusmae - 26.6.2008, 13:47

"О Боже",-  воскликнула королева: " Я опять беременна, и опять не знаю от кого". Самое короткое сочинение на тему Бог, секс, королева и немножко тайны. ПО ПОРЯДКУ.

1. О потенциальной опасности макросов писали ещё Керниган и Ритчи. То есть авторы языка С. Даже в стандартной библиотеке C есть макросы, которые сами авторы языка использовать не рекомендуют. Весело, да? Но это не значит, что C плох. Просто на нем надо думать над каждым моментом в реализации решения задачи, а Фортран 90 и выше позволяет во многом её опыисывать.

2. Многие конструкции C/C++ потенциально опасны. И ксати говоря, стандартом НАТО и Пентагона при программировании бортового оборудования является не C, а Ада. Потому что как раз надежный язык и не позволяет программисту фортелей,например, с приведением типов. Всё должно делаться ЯВНО. Опять же к книжке уже Кернигана и Пайка отошлю. Там было расаписано как новейший крейсер 4 часа бороздил мировой океан в качестве сардельки из-за ошибки программиста. (Там не было проверки на положительность значения. Ада 95 при указании диапазона типа просто так не пропустила бы это место.) Каждому свое. И если совсем неглупые люди из WG5 предложили именно такой подход, то он явно обоснован. Математики не всегда виртуозные программисты и могут с приведением типов такого понаделать. Потом, зачем в фортране целочисленные указатели (ЭТО НЕ СТАНДАРТНОЕ СРЕДСТВО)?! Инструмент ссылок весьма силен и мобилен. И если им уметь пользоваться, то указатели не нужны. А уж если они так нужны - ISO_C_BINDING. Стандартное средство.

3. 

См. стандарт 2008. И не забывайте об implicit. Опять же, если им аккуратно пользоваться (в пределах структурной единицы, где он необходим) - удобно и весьма надежно. 

4. 

Уж размещаемый массив вернуть не можем. Дошли до ручки. В чем тут проблемы? Вот объявление функции:

Неужели так сложно? Или так нелогично. У Вас мышление зашорено языком С и иже с ними. Вот в чём беда. Из-за моды на C люди разучились смотреть на непохожие на него ЯП под другими ракурсами.


5. 

И опять вы используете нестандартные средства конкретной реализации. См. стандарт 2003, iso_c_binding. Там всё есть. 
По ссылке, значит переменная так и объявляется, как это принято в Фортране, а по значению - атрибут value.

6. 
Тут много исторических аспектов, почему это так. Про производительность Вы меня не внимательно читали. Изначально синтаксис Фортрана строился так, чтобы обеспечить максимальную оптимизацию кода. НО сейчас все хорошие компиляторы готовят весьма неплохой код. Сопостовимый по производительности. А производительность сейчас во многом упирается в вызовы API ОС и саму ОС. Тут много аспектов. Но сам по себе код C++ оптимизировать сложнее, чем аналогичный код фортрана. 

7. 

ООП в Фортране. Любопытно, сколько Вы знаете компиляторов, где используется практически полная поддержка ООП на уровне стандарта 2003? И пробовали ли Вы их И я бы не сказал, что он сложен для понимания. Нет такой иерархической структуры как в C++, нет множественного наследования. Так оно совсем не всегда нужно. Вы говорите о частичной реализации ООП на Фортране 95. Это инкапсуляция на уровне модуля, статический полиморфизм, наследование, притянутое за уши простым включением типа-предка в тип-наследник...  Да и у меня есть несколько хорошо спроектированных и прозрачных программ по 7-8 тысяч строк (для Фортрана, если писать на нем правильно - это много). 

Это сообщение отредактировал(а) popovda - 27.6.2008, 12:17

производительность не упирается в АПИ, АПИ это диалоги и ввод-вывод. Для игрушек вывод критичен, но есть и другие задачи. расчетные например   
некоторые особенности фортрана усложняют жизнь программиста, пришедшего из другого языка.
пару раз попал на целочисленное деление. выражения оказались целыми и деление стало целочисленным. передачу параметров лучше делать с явным описанием intent. ко всему можно привыкнуть.
главное фортран дает быстрый код. и его можно дальше опритимизировать под процессор, систему команд и многоядерность. имеется ввиду конечно интел фортран.

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

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

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

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


Я уже писал, что в особенности на фоне ёмких вычислений накладные расходы на ООП часто являются очень скромными. Ну просто, в абсолютных долях несоизмеримы! Так что это не аргумент вообще.

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