Codedot ([info]codedot) wrote,
@ 2008-03-31 16:34:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:computers, ideas, lambda calculus, programming

MIPS, сильная редукция и дальнейшие планы
Системы, основанные на MIPS, имеют очень лаконичный и простой ассемблер и могли бы быть по праву названы идеальными императивными вычислительными системами. Как известно, на основе MIPS работает множество бытовой аппаратуры, сетевое оборудование, а также игровые приставки Playstation и Playstation 2, и такие системы отличаются низким энергопотреблением и отличной масштабируемостью. К сожалению, корпорации Intel и Microsoft сделали достаточно, чтобы практически полностью вытеснить MIPS с рынка персональных компьютеров.

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

К сожалению, в комбинаторной логике сильная редукция требует бесконечного набора аксиом, поэтому создание машины для сильной редукции на основе комбинаторной логики теряет смысл - гораздо легче при решении этой задачи обратиться к обычному лямбда-исчислению. С другой стороны, прямое примененение эта-конверсии в машинах для редукции графов является крайне неэффективным, так как требует прохода по дереву для проверки на свободное вхождение переменной в подвыражение. В свою очередь, попытки применить подход "Micro Lambda Calculus" (который, кстати, показал себя особенно неэффективным, по крайней мере, при выборе стратегии Gyorgy Revesz) к эта-редукции пока не увенчались успехом.

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



(Post a new comment)


[info]nivanych
2008-04-03 12:07 pm UTC (link)
> для максимальной оптимизации вычислений
> следует компилировать в машинные коды
> императивных вычислительных систем.

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

Для определения качества оптимизации
разных архитектур мы должны быть уверены,
что как для той, так и для другой архитектуры,
оптимизация произведена наилучшим образом.
Или же как-то ... одинаково плохо (хорошо) :-)
Как я могу быть уверен, что для данной архитектуры
не существует лучшей, или хотябы, существенно
лучшей техники оптимизации, чем та, с которой сравниваем ?
А то ведь так и z80 у MIPS запросто выиграет.

Из-за того, что архитектуры могут быть
совершенно разными, то сравнивать получится
только конкретные программы, то есть, сделать
эдакий "трам-парарам architecture shootout".
Но платформы могут быть очень разными, с разными
возможностями для реализации разных алгоритмов,
даже если они написаны на одном и том же языке.
Разными они могут быть настолько, что зачастую
будет очень сложно определить какое-то подобие
"одинаковых условий" для сравнения времени исполнения.

Хорошая оптимизация возможна под всё ;-)
И практически самой оптимальной платформой будет такая,
на которой наилучшее на данный момент соотношение
скорости работы конкретных техник оптимизации
и технических характеристик типа максимальной частоты,
какой-нибудь параллельности, и так далее.
Но это чисто практическое определение оптимизации.

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

P.S.
Сейчас я думаю, что самая оптимальная платформа -
это FPGA (ну или вообще ASIC), которые я лично
стесняюсь наывать "императивными".
Не спорю, "очень оптимально" компилировать туда
языки типа Haskell, должно быть, непростая задача.
Но не для всех вычислительных систем это так.

(Reply to this) (Thread)


[info]codedot
2008-04-03 12:21 pm UTC (link)
Качество оптимизации для конкретно выбранной архитектуры можно сравнить, например, по времени выполнения одной из возможных программ, то есть тестированием. Согласен, что вряд ли имеет смысл сравнивать качество оптимизации в отрыве от одной конкретной машины. Но, честно говоря, эти вопросы меня лично пока мало волнуют, так как, насколько мне известно, еще не доказано, что машины для сильной редукции, которые мне очень интересны, неэффективны в каком-либо смысле, и я все еще надеюсь, что это не так.

Edited at 2008-04-03 12:35 pm UTC

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-03 12:38 pm UTC (link)
Сформулирую по-другому.
Как установить, что код оптимизируется
под одну платформу лучше, чем под другую ?
Сравнивать можно только конкретные реализации,
а они могут быть написаны под одну платформу
хорошо, под другую плохо.

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

Ну да понятно ...
Практическая задача - сделать достаточно хорошую реализацию.

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-03 12:58 pm UTC (link)
Вопрос о качестве оптимизации вообще, который я, кстати, не поднимал в тексте и которого даже не касался, требует введения (или нахождения готового в литературе) формализма, в котором можно определить бинарные отношения "лучше" и "хуже", а потом построить их транзитивные замыкания и упорядочить тем самым элементы в множестве различных видов оптимизации. Но этот вопрос, повторюсь, меня мало пока волнует. Сам же я считаю, что рассматривать оптимизацию кода в отрыве от конкретных одной программы и одной машины не следует.

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

Edited at 2008-04-03 01:13 pm UTC

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-03 01:56 pm UTC (link)
Практическая пользая от этого есть -
строить по программе FPGA-конфигурацию,
то есть, компилировать в Verilog & VHDL.

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-03 01:59 pm UTC (link)
Боюсь, не совсем понял, извините. Практическая польза есть от чего именно?

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-06 02:07 pm UTC (link)
Практическая польза от изучения
"эффективности в каком-либо смысле"
машин редукции.

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-06 04:34 pm UTC (link)
Конечно, польза, в том числе и практическая, от этой задачи может быть, но сама задача не практического, а скорее теоретического характера.

(Reply to this) (Parent)


[info]nivanych
2008-04-06 02:05 pm UTC (link)
> рассматривать оптимизацию кода
> в отрыве от конкретных одной программы
> и одной машины не следует.

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

Хотя, к конкретному случаю это отношение не имеет.
Тут это никак не доказать.

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-06 04:36 pm UTC (link)
Еще раз хочу обратить внимание, что в тексте не говорится об оптимальности компиляции. Там сказано об оптимизации вычислений путем компиляции. Это разные вещи.

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-07 06:44 am UTC (link)
> Это разные вещи.
Соглашусь, эти вещи стоит рассматривать отдельно.


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

Вот это меня и спровоцировало на разъяснения.

Оптимальнее точно будет не в императивные выч. системы.
Почти в любом смысле слова "оптимально".
Даже если выбирать из практически применимого.

Всё же, каком смысле рассматривать
оптимальность вычислений на машине редукции ?
Кроме как по количеству "атомарных" редукций,
ничего в голову не приходит.

P.S.
Из-за этого поста я засомневался,
что же мне читать, когда освобожусь ...
Скорее, это хорошо :-)

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-07 07:08 am UTC (link)
Во-первых, Levi ввел определение оптимальности редукции на графах, для которого позднее Lamping построил "An algorithm for optimal lambda calculus reduction" и рассмотрел его свойства:

http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=96711

Позже, Levi опубликовал статью "The Geometry of Optimal Lambda Reduction", где подвел некоторые итоги этого исследования и пересмотрел многие конструкции, введенные Lamping:

http://citeseer.ist.psu.edu/gonthier92geometry.html

Сейчас же меня интересует, как реализовать машину для сильной редукции оптимальным образом. Недавно, кстати, я нашел статью, которая с большой вероятностью могла бы мне помочь разобраться с этим вопросом. Это "Eta-conversion for the languages of explicit substitutions":

http://www.springerlink.com/content/p778664h6lwk4653/

К сожалению, мне не удалось ее купить из-за каких-то проблем на сервере "SpringerLink", а на мою просьбу помочь заполучить текст этой статьи в сообществе "pdf" пока не откликнулись:

http://community.livejournal.com/pdf/956445.html

Edited at 2008-04-07 07:12 am UTC

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-07 07:38 am UTC (link)
Только что мне прислали PDF-файл со статьей "Eta-conversion for the languages of explicit substitutions", которую я просил в сообществе "pdf". Согласно правилам, удалил сообщение в этом сообществе.

Если Вам тоже интересна эта статья, дайте мне знать. Я могу переслать ее Вам.

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-09 01:12 pm UTC (link)
Интересна !
Только читать пока серьёзно нет времени.
По чуть-чуть и так много читаю,
а нормально освободиться получится,
боюсь, только к маю ...
Ну да ничего, торопиться некуда :-)

NIvanych сабака gmail.com
Спасибо !

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-09 01:25 pm UTC (link)
Переслал.

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-09 01:54 pm UTC (link)
Скачал, всё открылось.
Спасибо !

Совершенно правильно он
вспоминает про DeBruijn notation :-)
Многое с ним проще, особенно,
при создании чего-нибудь "лямбдового".

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-09 02:44 pm UTC (link)
Для редукции графов нотация де Брейна оказывается бесполезной. В "Graph Reduction Machine" вместо имен и индексов де Брейна легче использовать адреса нод, представляющих лямбда-абстракции, или наоборот, - это удобно при ленивых вычислениях - использовать ссылки из лямбда-нод на ноды-переменные.

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

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-10 06:15 am UTC (link)
Да, соглашусь.

Мои практические познания по редукции графов
ограничиваются несколькими главами Барендрегта
и пониманием того, как работает GRIN :-)

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-10 06:18 am UTC (link)
И ещё мне кажется, что многим людям
было бы проще понять лямбду, используя
DeBruijn-notation, т.к. альфа-преобразование
не надо затрагивать, и чуть проще с подстановками.

Сразу в виде деревьев надо объяснять.
Но это я ещё попробую ... потом ...

(Reply to this) (Parent)


[info]nivanych
2008-04-09 01:56 pm UTC (link)
> http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=96711
> http://www.springerlink.com/content/p778664h6lwk4653/

Регистрации требуют ... ещё поди за деньги ...
Ну ладно, это потом.

> http://citeseer.ist.psu.edu/gonthier92geometry.html

CiteSeer is currently unavailable.
Чего ж так не везёт-то ? ;-)

Всё равно спасибо. Когда-нибудь да скачаю.

(Reply to this) (Parent)(Thread)


[info]codedot
2008-04-09 02:49 pm UTC (link)
PDF-файлы, ссылки на которые я перечислил, платные для частных лиц, но я бы мог переслать Вам копии, если статьи оказались Вам интересными по их кратким обзорам.

(Reply to this) (Parent)(Thread)


[info]nivanych
2008-04-10 06:13 am UTC (link)
Интересно !
Эх ... пока читать некогда ...

(Reply to this) (Parent)


Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…