Привет!
Скажите, пожалуйста, могут ли быть такие задачи из области микрофизики, которые на фортране было бы эффективнее решать, чем на С++ / assembler?



Это сообщение отредактировал(а) Riddik - 3.12.2009, 17:48

О какой эффективности идёт речь? Эффективность разработчика или временная/пространственная эффективность готового продукта?

Хотя, не важно.  И в том и в другом случае - современный Fortran - лучший выбор.

Наверное потому что фортран специально создан для научных вычислений?

Как ни крути, вопрос некорректный. Область микрофизики - понятие растяжимое. 
Лучше всего решить точно на бумаге.

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

На западе есть тенденция  считать с помощью специальных пакетов, некоторые из которых написаны на миксте вышуказанных "компонент".

Ну да, можно и так сказать. Само название языка... Специально для вычислений. А уж научных, инженерных или каких ещё - не суть важно.

Из-за того что Fortran содержит средства регулярного, параллельного и распределённого программирования, его использование оказывается наиболее эффективным при обработке массивов данных. Про науку в его стандарте мало что написано. Он эффективен в очень большом числе современных задач под различные архитектуры.

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

Вы на вряд ли напишите код на ассемблере эффективнее того, что создаёт хороший компилятор. Более того, такой код будет намного сложнее писать и поддерживать. Взять ту же векторизацию (SSE). Обычно фразы типа "вставки пишем на ассемблере" говорят те люди, которые сами этим не занимаются. На ассемблере имеет смысл писать только если вам необходимо использовать инструкции, которые, возможно, компилятор сам не использует или ещё не умеет подставлять. Например, при программировании видеокарт или цифровых сигнальных процессоров.

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

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

А смысл имеет использование фортрана при подключении старого кода с новым.
но это мое имхо, конечно же.

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


Фортран широко используется для параллельных вычислений.

Впечатление неправильное. 
Во-первых, типизация должна быть статической. Для вычислительных задачах - железно.  
Во-вторых, производительность больше. Глянь тут, например.

И NumPy - действительно быстрая библиотека. Вот другой вопрос, что можно делать так же как они в бенче - Python + Fortran. То есть числодроблением занимается Fortran, а сверху интерфейсная логика на Python.

P.S. Также сразу хочу отметить, что строчка Pure C++ 2.16 говорить о том, что производительность у Fortran и ++ одного порядка. Бенч слишком маленький, чтобы делать более далеко идущее выводы... Но ++ не надо использовать по другой причине.  

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

Lazin, при тяжких параллельных вычислениях обычно много поточность не столь важна, сколько независимость на уровне процесса.
а параллелизация идет на уровне процессов - запускаются множество процессов на огромном количестве нод (GRID кластер может доходить до 10k или более процессоров).
а параллелизация на уровне потоков - только замедляет общий поток обработки данных.
(т.е. получается, что смена контекстов между потоками - невыгодное пенальти)

но меня больше тревожит процесс разработки и внедрения такой бодяги:
на фортране мне надо скомпилировать на все возможные комбинации архитектруры-оси, которые моя задача сможет встретить в кластере.
сегодня в гридах обычно архитектуры варьируют (x86, x86_64, ia64, ppc, ppc64, mips, sparc), a OS (linux, windows, irix, hpux, solaris, freebsd).
получается для фортрана придется дебажить твой код на 10-15 системах.
а со скриптовым языком и готовой библиотекой это значительно проще (Ессно если библиотека - стабильная).

я не говорю, что код на фортране бежит медленнее.

просто с вот этой т.з.:
Время разработки течет в твоих реальных человеко-часах и включает в себя написание и отладку кода до состояния - "можно запускать" на всю систему.
А Общее время до конца ВЫПОЛНЕНИЯ запущенной задачи зависит от объема ресурсов и объема работы.

и тут встает вопрос, допустим код писать займет 5 недель на фортране  или 1 неделю на питоне/руби 
а запускать 2 недели на фортране или 10 недель на питоне.

И вопрос что вы предпочтете? дебажить код 5 недель под 10 систем, или 1 неделю и немного подточить под все системы ?

Если возможно - Я - второй вариант однозначно 
Да, это потратит больше электроэнергии (но за нее я с клиента денежку возьму) и общего времени ожидания.
Зато если вдруг добавится в грид какой-то кластер с системой Х и архитектурой Y, шанс, что мой код на питоне побежит на ней без проблем выше, чем с фортраном. и менее хлопотно, ведь после 1 недели и запуска задачи я смогу уже работать над другим проектом, пока шестеренки крутятся... 




Это сообщение отредактировал(а) bilbobagginz - 7.12.2009, 04:35

Что подразумевется под готовой библиотекой? 
Готовые библиотеки работают для некоторого усредненного класса задач. Попадется уникальная задача (со сложной геометрией например) и готовые библиотеки не помогут (кроме, разве что проверить предельные случаи).


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

Добавлено через 6 минут и 14 секунд


А чем С++ в плане параллельности  отличается от С?
Многопоточное программирование (всякие CreateProcess, CreateThread и т.п.) доступно в Visual Fortran.

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

Lazin, причём тут потоки? Речь о т.н. распределённых вычислениях. Различные части одной вычислительной задачи решаются несколькими вычислительными узлами, которые обмениваются данными по необходимости.

В Fortran имеется много возможностей для параллельного программирования. Например, возможность объявлять "чистые" функции для использования, например, в принципиально распараллелтваемых конструкциях типа FORALL. Есть Co-arrays... Да много там чего есть...


Ой, ну я Вас умоляю. Вы знаете, что Python 3 принципиалmyj не работает на Mac OS X сразу после установки из-за (по мнение интерпретатора) неправильных настроек локали?  А динамическая типизация? А то что чуть ниже написано про рантайм?


Вот к Python это никакого отношения не имеет. У них на каждый минор релиз приходилось несколько сотен багов. Ну нельзя написать такой мощный рантайм на С без багов. Это миф.
 

Можно запускать? Я надеюсь, это была шутка.  


Не уникальная задача, а просто задача. Всё это обобщённое программирование - чушь. Переобощённое.

Это сообщение отредактировал(а) kemiisto - 7.12.2009, 10:55

постараюсь объяснить, есть такое понятие, как parallelism, если в двух словах, то это свойство системы выполнять какую либо работу параллельно, если алгоритм легко разделить на независимые части и посчитать, то это легко сделать на любом языке используя потоки ОС, помимо этого есть еще параллелизм на уровне данных, это всякие MMX и SSE наборы инструкций, которые позволяют обрабатывать сразу несколько элементов массива, вот с этим, насколько я знаю, у фортрана очень неплохо, АФАИК, он умеет автоматически векторизовать обработку массивов
но в реальности, далеко не все алгоритмы легко распараллеливаются на независимые ветви, и зачастую, потоки разделяют какую-то память, либо обмениваются сообщениями, вот здесь, фортран не может ничего предложить нового, только явную синхронизацию, с использованием мьютексов/крит. секций/семафоров, а это очень трудоемкая задача, на С++ это делать несколько проще, так как есть соответствующие библиотеки, помимо этого еще существует ввод вывод, а для того, что-бы организовать действительно быстрый IO, нужно читать и записывать данные асинхронно, если это делать синхронно, процессор будет по сути простаивать, во время выполнения операций ввода вывода, тут у фортрана нет никаких преимуществ по сравнению с С++ или Си
вот для примера код из книги "Programming F#" Криса Смитта:

этот код на F# выглядит так, как будто он последовательный, хотя на самом деле разные его фрагменты будут выполнятся асинхронно, только после окончания очередной операции ввода вывода, причем, вполне возможно в разных потоках, во время чтения/записи на диск, процессор может выполнять другие операции; и кстати, все это не специальная фича языка, а реализовано средствами языка, как библиотека.
что-бы написать что-то подобное на Си или на Фортране, нужно организовать пулл потоков, и написать две функции обратного вызова, первая из которых, должна вызываться после чтения из файла, вторая - после записи в файл, ну и естественно, придется использовать нативный API операционной системы, для организации неблокирующего IO
Для С++ есть библиотека asio, которая позволяет это дело несклько упростить, а в Visual Fortran - придется все делать ручками, так как стандартная библиотека умеет только обычный, блокирующий IO.
Поэтому вердикт: если приложение IO bouded - то фортран отправляется в форточку, если приложение CPU boudned - и алгоритм достаточно линейный и хорошо поддается распараллеливанию и векторизации, то почему-бы и нет?

Добавлено через 1 минуту и 24 секунды

multicore revolution же!!!