Есть идея! Оптимизатор скорости работы программы!

← →
Igorek © (2003-12-14 11:15) [0]

//соседняя ветка натолкнула на мысль
Предлагаю на рассмотрение такое:
Пусть у нас есть код программы, который мы хотим оптимизировать по скорости.
Оптимизатор - это программа, которая содержит в виде плагинов разные приемы оптимизации. Кроме того программа имеет или встроенный профайлер или пользуется внешним и потом читает его логи.
Напр. простейший прием оптимизации - inline подстановка функции, где мы экономим на расходах по вызову функции. Скажем выдал профайлер, что некая функция вызывается кучу раз. Тогда он берет и вставляет код функции везде в местах вызова.
Другой пример. В каком-то месте использована пузырьковая сортировка. Меняем на быструю.
И т.д.

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

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

Как вы думаете, не слишком ли фантастично? ;-)

Возможен также оптимизатор по обьему кода - ищет повторяющиеся фрагменты и выносит их в процедуры.

← →
JibSkeart © (2003-12-14 11:25) [1]

фантастично :))

вопервых компилятор сам оптимизирует (как сможет , если не путаю ничего)

а во вторых лутьше чем сам программер программа тебе не оптимизирует :)

← →
Fenik © (2003-12-14 11:27) [2]

Да. Давайте объединимся и напишем полезную для всех вещь!

← →
Fenik © (2003-12-14 11:29) [3]

> JibSkeart © (14.12.03 11:25) [1]
> а во вторых лучше чем сам программер программа тебе не оптимизирует :)

Так это для тупых программеров :-)

← →
JibSkeart © (2003-12-14 11:30) [4]

ну что же дерзайте ,
а я посмотрю на сие творение :)

← →
REA © (2003-12-14 12:46) [5]

Так вроде есть оптимизаторы на уровне асма. Только не всегда оптимизация под один процессор приводит к тому же результату на другом.

← →
VEG © (2003-12-14 22:53) [6]

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

← →
Sergey_Masloff (2003-12-14 23:05) [7]

Igorek © (14.12.03 11:15)
>Напр. простейший прием оптимизации - inline подстановка >функции, где мы экономим на расходах по вызову функции.
Оптимизировать на уровне алгоритма надо. А не на уровне реализации - это тупиковый путь.

← →
MOA © (2003-12-14 23:26) [8]

2 Sergey_Masloff
>на уровне реализации - это тупиковый путь- безусловно См. Майерс "Надёжность программного обеспечения". так он (Майерс т.е.) вообще требует не предоставлять ассемблер к процессорам, дабы программист не занимался "микрооптимизацией".
Кстати, как я понял, в Intel Itanium часть битов инструкции отвечает за "микрооптимизацию" - например, вместо блока предсказания перехода бит в инструкции отвечает за предпочтительное направление ветвления. Выигрыш понятен, однако, любопытно, как это выразить на языке высокого уровня? М.б. кто-нибудь из уважаемых коллег знает какую-нибудь реализацию языка от Intel, поддерживающую такую фичу - как это они делают?

← →
MBo © (2003-12-15 06:46) [9]

>MOA
Intel C++ и Фортран - генерируют процессорозависимый код.
Есть мат. библиотеки от Интел - Signal Processing, Math Kernel и т.п., использующие MMX-SSE2.

← →
PVOzerski © (2003-12-15 10:28) [10]

Оптимизатор - вообще не всегда полезная и даже безобидная вещь. Не случайно есть возможность написать {$O-}. Всё-таки суть решаемой задачи пишущий программу представляет лучше, чем тот, кто писал оптимизатор для средства разработки, на котором эта программа делается (по крайней мере, в нормальной ситуации). Потому время от времени возникают казусы. Тот же случай с inline-подстановками. IMHO, это программист, а не компилятор должен решать, что ему важнее в программе, скорость или размер. А потому это сам программер должен иметь возможность написать ключевое слово inline после заголовка функции (что и есть во FreePascal, например). А уж если за меня будут решать, какой алгоритм расчета какой-нибудь математической функции мне нужнее... Например, можно приращивать синус на константу, пользуясь тригонометрическими закономерностями sin(a+b)=sin(a)*cos(b)+cos(a)*sin(b) и sqr(sin(a))+sqr(cos(a))=1, не вызывая каждый раз функции sin и cos (хватит 2 раза вызвать sin). При этом проигрываем в точности, но существенно выигрываем в скорости. И что за меня выберет оптимизатор?

← →
Igorek © (2003-12-15 11:43) [11]

> VEG © (14.12.03 22:53) [6]
> Интересная идея, но я считаю, что программист должен сам
> заботиться об скорости своего кода.
Несомненно. Но есть же оптимизаторы на уровне комманд процессора. А это будет высокоуровневый оптимизатор.

> Sergey_Masloff (14.12.03 23:05) [7]
> Оптимизировать на уровне алгоритма надо. А не на уровне
> реализации - это тупиковый путь.
Так было сказано что оптимизировать можно и сами алгоритмы (напр. сортировка). Другое дело, что это намного сложнее.

> PVOzerski © (15.12.03 10:28) [10]
При этом проигрываем в точности, но существенно выигрываем
> в скорости. И что за меня выберет оптимизатор?
Такая оптимизация или некорректна или должна выполнятся человеком - он знает какая точность приемлемая.

Вообще речь идет о "макрооптимизации". Мне кажется такого оптимизатора еще нету в природе.

← →
MOA © (2003-12-15 12:18) [12]

Всё же по поводу Itanium. Понятно, что есть библиотеки и компиляторы от Интел.
Но, насколько я понял, одно из важных свойств IA-64 - "перенос" оптимизации и распараллеливания на компилятор. Как это выразить, например, на Оккаме - представить можно. А как на императивных языках (на Паскале, например) выразить "предпочтительное направление перехода" в IF? Или тот факт, что данные группы инструкций могут исполняться параллельно? (впрочем, это-то как раз компилятор может сообразить). Intel ввела спец. расширения в языки?

По поводу "макрооптимизации". IMHO, для императивных языков подобная оптимизация бессмысленна, поскольку суть таких языков "машина, я приказываю тебе сделать то-то", а не "машина, посчитай-ка мне вот это" - т.е. компилятор не может догадаться о намерениях программиста, кроме того, что программист не намеревается вручную распределать регистры, выделять память и заботиться об организации циклов и подпрограмм. Для "крупноблочных" же операций (сортировки, операций с матрицами и т.д.) могут, действительно, помочь библиотеки. Хотя и тут, например, "универсальную программу сортировки" представить сложно. Тем более что не факт, что в данном конкретном случае сортировка пузырьком будет быстрее "быстрой" (см. Кнут т.3).

← →
KSergey © (2003-12-15 15:32) [13]

> [12] MOA © (15.12.03 12:18)
> А как на императивных
> языках (на Паскале, например) выразить "предпочтительное
> направление перехода" в IF?

Ну, например, классическое требование "красивости" кода: в then помещаем наиболее вероятную ситуацию, в else - наименее вероятную
Вот только что тогда делать с конструкцией вида

if then
else if then
else if then
else

к которым иногда приходится прибегать и где, очевидно, вариант else будет более вероятным? Не заню...

> Или тот факт, что данные группы
> инструкций могут исполняться параллельно?

Если верно понимаю полит. ситуацию - для этого существуют спец. языки программизма. Правда, скажу честно, какие - не знаю. Но должны же быть ;)

← →
Gero © (2003-12-15 15:45) [14]

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

← →
KSergey © (2003-12-15 15:58) [15]

> [14] Gero © (15.12.03 15:45)

Вот те здрасьте...
А я может хочу, чтобы код повторялся? Например, экономлю на вызовах. И циклы не использую ;)
Надо хотя бы определиться для начала: по объему или по скорости оптимизируем? А то что-то сразу по всем направлениям пытаемся. А так не бывае, однако ;)

> KSergey © (15.12.03 15:58) [15]

У проги должны быть настройки, где это всё можно будет указать. То бишь настроить под себя.

2KSergey ©
Для распараллеливания, например, Оккам, или параллельный Пролог - на Прологе, действительно, компилятор может здорово соптимизировать программу, и именно на "макроуровне". Но это не императивные языки (хотя Оккам-то похож немного).

>По крайней мере, реально организовать помещение часто повторяющихся кусков кода в процедуры. Когда в программе тысячи строк, вручную это сделать очень сложно.
Тревожное мнение. Это как раз то, что упомянутый Майерс называл "прочность блока по совпадению". Если это делается на уровне исходного текста - это есть самая плохая из всех возможных практик программирования. Именно для исключения подобной практики и родилось "структурное программирование", а затем и "объектно-ориентированное". На уровне машинного кода - IMHO, в толково написанной программе таких участков будет немного.

А давайт е пойдем еще дальше. И напишем прогу которая сама будет
писать код по Т.З !

И такую, которая это Т.З. придумывает.... Вот тогда точно нам ничего больше надо не будет.... И будем лопать бананы лежа под пальмой... Мечта !!! .... идиота.....

P.S. Голубая мечта босоного (ногого) детства. Т.е. чтобы вообще ничего не надо было...

> чтобы вообще ничего не надо было...

Вобщем-то это есть оптимизация в идеале :)

> Dmitriy O. © (15.12.03 16:44) [19]
> А давайт е пойдем еще дальше. И напишем прогу которая сама
> будет
> писать код по Т.З !

Так есть уже такая. Пару месяцев назад анонсировали где-то из Северной Европы. Правда слышал что потом разобраться в коде - ужас.

А вообще для решения такой задачи надо целый ИИ громоздить. Что-бы система имела много common знаний. Тогда и имена функций будут осмысленные и логику она сможет обьяснить.

Есть идея! Оптимизатор скорости работы программы! Найти похожие ветки