> -- QWERTYProgrammer писал(а):
> Не уверен, стоит ли создавать новую тему, но утверждение в Blackbox-Listхотелось бы уточнить, например посмотреть на пример такого FOR лупа. 50 раз это все-таки очень много. Или речь идет о тривиальной оптимизации, типа выноса вычислений из тела цикла?
Стоит вынести в отдельную тему «Сравнение компиляторов f95, ifort, xds, blackbox»

Вот код для фортрана, который использовался для небольшой рабочей проверки, про которую я говорил.
## Код:
```
program bench;

DOUBLE PRECISION, DIMENSION (1000,1000) :: x
INTEGER :: i,j,k,n,m
DOUBLE PRECISION, DIMENSION (1000) :: f
DOUBLE PRECISION :: summ

do i=1,1000
   do j=1,1000
      x(i,j) = 0
   end do
end do
do k=1,1000
   f(k) = 0
end do
n = 1
m = 1
do i=1,1000
   do j=1,1000
      x(i,j) = m*m+n*n+1
      do k=1,1000
         f(k)=f(k)+x(i,j)/(x(i,j)+2.0/m)
      end do
      m = m + 1
   end do
   n = n + 1
end do
summ = 0
do k=1,1000
   summ = summ + f(k)
end do
write(*,*) summ
end program bench
```


Код не претендует на сколько-либо внятный тест. Делалось для себя, чтобы понимать достоинства, недостатки и область применимости инструмента BlackBox.

Компилятор ifrot успешно ставил как на Ubuntu, так и на Red Hat, он доступен бесплатно для академической работы с сайта Intel. Для XDS и компонентного паскаля у меня код не сохранился, к сожалению.

Привожу свою цитату из нашего рабочего блога от 12.05.2013.
> -- Цитата:
> После семинара в эту субботу у ZIM в очередной раз возник вопрос, почему я использую Компонентный Паскаль для своих приложений. Ну и слово за слово, решили сравнить скорость с языком Фортран-95. Точнее сравниваются в данном случае не языки, а компиляторы. Написали один пример, который использует массивы, циклы, сложение, умножение, деление. При этом в тест не вошли работы с указателями, обращение к процедурам и т.п. Результаты таковы: Блэкбокс выполнил процедуру на Компонентном Паскале за 17355мс, приложение с использованием компилятора F95 потратило такое-же время в 17352. Удивительно точное совпадение времени, конечно. Затем в ход пошли оптимизаторы кода. Для оптимизации компилятора F95 использовался ключ -O3 (оптимизация доступа к памяти и циклов), для получения оптимизированного кода для языка Оберон-2 использовался компилятор XDS (кстати, Новосибирская разработка). Так Фортран улучшил свои показатели примерно в 22 раза (~773мс), а Оберон-2 примерно в 14 раз (~1250мс). Как видно отсюда, по рутиной производительности Оберон-2 вполне соревнуется с Фортраном-95. Технический результат проделанной работы в том, что действительно имеет смысл переносить часть вылизанного кода в оптимизированные библиотеки собранные в XDS, например. ZIM подготовил приложение на платном компиляторе фирмы Интел (за 60000р, хотя есть и академический вариант), что дало колоссальный прирост скорости примерно в 50 раз! Что конечно супер. Если потребуется разрабатывать суперэффективные приложения для процессоров Intel, то очевидно надо выбирать ifort для разработки наиболее поддающихся оптимизации кусков вычислений. Или с тем-же успехом переносить код на C++ и компилировать его для графических процессоров с использованием технологии CUDA. Но язык это не только заготовка для компилятора, язык программирования еще и Язык. И если Фортран-95 отягощен 60-летним мусором и только начинает поддерживать ООП. То Компонентный Паскаль (наследник Оберона-2) — очень компактный и современный язык, поддерживающий как ООП, так и КОП. Подробное сравнение с Фортраном-90 и С++ сделано Берндом Мёсли [Mösli B. A Comparison of C++, FORTRAN 90 and Oberon-2 for Scientific Programming // GISI. 1999. Vol. 95. P. 740–748]. Поэтому пока не буду спешить со сменой инструмента, ну а потом видно будет. Про известные недостатки Оберона скажут лучше его недоброжелатели. Статьи по Оберону находятся на этом сайте: . Оберон — «простой как автомат Калашникова» берет начала в Высшей Политехнической школе ETH в Цюрихе, где учились Альберт Эйнштейн и Джон фон Нейман. Автор языка Никлаус Вирт.

После того как я попробовал компилятор ifort, я просто не поверил, что можно посчитать это так быстро.http://software.intel.com/en-us/non-com ... evelopment
> -- мое письмо коллеге  писал(а):
> Не Андрей не может быть 0m0.302s  он наверное все заранее посчитал и выдает результат. Если это оптимизирующий компилятор, то такое возможно, ведь эта процедура не от чего не зависит. Надо делать тогда программу с входными параметрами, чтобы он не мог заранее посчитать.
Тогда коллега по моей просьбе подготовил код, который считывает входящие параметры и использует их для вычисления. Т.е. заранее посчитать уже не так просто все тело цикла. Результат по скорости был примерно такой-же.

Поскольку я прекрасно понимаю, что такая штука хорошо оптимизирует только циклы, то не спешу списывать BlackBox. Для науки у них немного разные задачи.