Производительность программ на fpc

[Replicator]

Скоро появятся сообщения, что Java обгоняет Assembler... И самое главное, что такое тоже возможно! Ведь никто не запретит на асме написать жутко тормозную программу

А вообще, во всех тестах сравнивается, видимо, время работы самого алгоритма. А что делать с временем загрузки программы? А что с GUI? Реальные проекты именно на этом и тормозят. И мне, например, не важно, что Java исполнит алгоритм на 3 мс быстрее, если программа будет грузиться на 5 секунд медленнее и жрать в 10 раз больше памяти

[alexs]

ну пожалуста, объясните мне (не понимаю я) - как может интепретатор работать быстрее самого процесора, на котором он запушен?
все разговлоры о том что жаба обгоняет КОМПИЛИРУЕМЫЕ языки - это только показатель того - ка составлен пример для компилируемого языка

по другому НЕ БЫВАЕТ
НЕ ВЕРЮ!!!!

[Юра]

Java (и некоторые другие языки) делает компиляцию в машинный код по ходу выполнения программы. Поэтому возможен вариант, что машинный код для некоего алгоритма (который обычно ограничен циклом/циклами) будет сопоставим по скорости с кодом, который генерится для компилируемого языка. Код алгоритма будет скомпилирован Java машиной 1 раз и будет выполнятся на полной скорости.

Но, как правильно заметил Replicator, для реальных приложений более важны скорость работы GUI, время загрузки, требования к памяти. Вот здесь компилируемые языки вне конкуренции...

[bw]

Python в некоторых случаях так же обгоняет Си. Например при работе со строками и циклами. Python при интерпретации использует какой-то откомпилированный и вылизанный код, например для "сложения" строк, который запросто может обгонять не самые удачные реализации кода на Си или Си++. Не самые удачные, это, например, с использованием библиотек вроде std или др.

..bw

[alexs]

ну вроде пришли к общему мнению
меня просто убивают заявления - "наш супер-пупер интрепретатор делает все компиляторя по скорости"

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

P.S.
я всёж нудный - поэтому перефразирую превыдущее высказывание, чтобы не осталось неточностей:
"Python в некоторых случаях так же обгоняет Си. Например при работе со строками и циклами"
по моему надо говорить так:
Библиотеки компилятора (кажется там C) используемые в Python для работы со строками запросто может обгонять не самые удачные реализации кода на Си или Си++. Не самые удачные, это, например, с использованием библиотек вроде std или др.

[SovNarKom]

alexs
Понимаешь, если в цикле надо сделать i действий с переменной (к примеру сложений), то любой компилируемый язык будет использовать счётчик текущего шага, короче постоянная проверка какого-то регистра.
И таких проходов 10000 штук.

Интерпретируемый же язык один раз может развернуть цикл по i, просто повторив код 10 раз перед первым проходом. И затем использовать этот развёрнутый алгоритм без проверок 10000 раз.

То, что 10000 проходов будут испонены быстрее - факт. А если и на компиляцию фрагмента потребуется ощутимо меньше времени чем на i*10000 проверок - то такой код будет работать ощутимо быстрее.
(не спорю, некоторая память при этом скушается)

Есть правда одно НО... реализовать подобное поведение и в компилируемых языках можно, просто программа должна иметь в себе сложные алгоритмы генерации run-time кода... Сложно конечно... но осуществимо.

Кстати в процессорах ARM9, насколько мне известно, существует технология Jazelle™, которая, согласно пресс релизу, в разы ускоряет скорость исполнения java кода.

А вот тут можно прочитать подробнее как это всё работает, и что существуют ещё более совершенные технологии.... (преобразование байт кода в машинные "на лету")
http://wiki.wapcity.ru/show/lang/ru/?text=Jazelle

Интересно, кстати, другое, ничего инновационного на самом деле тут нет...(кроме разве новых инструкций процессора в технологии RCT) Идеи такие уже давно имеются... Но, что самое интересное, они частично реализованы в FPC, где сначала создаётся промежуточный код, который потом компилируется под конкретную платформу...
Так вот, если такой код распостранять отдельно, то можно будет просто из существующих в настоящее время кросскомпиляторов собрать на разных платфорах "FPC Машины", которые будут генерировать и исполнять код "на лету" - очень быстро. Можно даже кусочки программы перекомпилировать во время исполнения, для вышеописанных оптимизаций .
Тут конечно много подводных камней, но все эти проблемы разрешимы.

[alexs]

Есть правда одно НО... реализовать подобное поведение и в компилируемых языках можно, просто программа должна иметь в себе сложные алгоритмы генерации run-time кода... Сложно конечно... но осуществимо.

почему этоне сложно в интерпретаторе и сложно в компиляторе - какаято неувязка

Кстати в процессорах ARM9, насколько мне известно, существует технология Jazelle™, которая, согласно пресс релизу, в разы ускоряет скорость исполнения java кода.

фактически это приводит к компиляции в машинный код (инструкции процессора) - чем отличаемся от компилятора?

Но, что самое интересное, они частично реализованы в FPC, где сначала создаётся промежуточный код, который потом компилируется под конкретную платформу...

ну это далеко не новость - такую методу ещё сам Вирт планировал в своей паскаль-машине - откуда и понятие P-код пошло. NET - это фактически идеии вирта о P-машие 30-летней давности

[trifon]

alexs
Понимаешь, если в цикле надо сделать i действий с переменной (к примеру сложений), то любой компилируемый язык будет использовать счётчик текущего шага, короче постоянная проверка какого-то регистра.
И таких проходов 10000 штук.

Интерпретируемый же язык один раз может развернуть цикл по i, просто повторив код 10 раз перед первым проходом. И затем использовать этот развёрнутый алгоритм без проверок 10000 раз.

То, что 10000 проходов будут испонены быстрее - факт. А если и на компиляцию фрагмента потребуется ощутимо меньше времени чем на i*10000 проверок - то такой код будет работать ощутимо быстрее.
(не спорю, некоторая память при этом скушается)

Есть правда одно НО... реализовать подобное поведение и в компилируемых языках можно, просто программа должна иметь в себе сложные алгоритмы генерации run-time кода... Сложно конечно... но осуществимо.

man gcc почитать не пробовал, там есть такие оптимизации: -funroll-loops, -funroll-all-loops.
-funroll-loops разворачивает циклы, количество итераций которых можно определить во время компиляции, соответственно -funroll-all-loops, все циклы.
Читал на форуме gentoo.ru, некоторые дебилы собирали весь gentoo linux с опцией -funroll-all-loops.

[alexs]

Читал на форуме gentoo.ru, некоторые дебилы собирали весь gentoo linux с опцией -funroll-all-loops

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

[trifon]

О впечатлениях не сообщали, написано было в стиле - "у меня ни фига не получается, вот мой make.conf"

[trifon]

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

В некокорых вешах -funroll-loops вставляют сами разработчики, кажется xinelib

[Юра]

alexs
Но, что самое интересное, они частично реализованы в FPC, где сначала создаётся промежуточный код, который потом компилируется под конкретную платформу...

Не нужно вводить людей в заблуждение.
Никакой промежуточный код в FPC не создается. Из pascal исходника создается дерево структурных элементов, над которым можно проводить действия (например, общую оптимизацию), независимые от целевого процессора. Потом на основе этого дерева генерится целевой процессорный код. После этого проводится оптимизация кода для целевого процессора.
Никакого Р-кода, естественно, нет.

[SovNarKom]

trifon
И как GCC разворачивает все циклы, если число итераций не известно в процессе компиляции?

alexs
А кто говорил что это "не сложно в интерпретаторе"?
А от колмпилятора это отличается тем, что компиляция частична, и происходит на целевой машине, да ещё и в процессе выполнения... и на мой взгляд, это будущее компиляторов.

Юра
Да, прошу прощения, повёлся на слухи в форуме.
Кстати, а если оптимизированное дерево сохранить в файл, то на целевой машине можно будет докомпилировать его под целевой процессор? Или потребуются дополнительные данные?
Или просто размер такого файла будет неприемлем?

[trifon]

Понятия не имею, я gcc не придумывал и документации к нему не писал

-funroll-all-loops
Unroll all loops, even if their number of iterations is uncertain when the loop is entered. This usually makes programs run more slowly. -funroll-all-loops implies the same options as -funroll-loops,

если в мануале ошибка, думаю нашлось бы множество квалифицированных специалистов способных указать авторам на неё.

[trifon]

Думаю раскручивается какое то вероятное количество, затем выполняется как обычный цикл.