RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Ну, можно построить доверительный интервал, например, по уровню 95 %.

Я не предлагаю отсечь чёткую границу: здесь суперкомпиляция, а здесь — нет.

Я предлагаю определить два порога: ниже которого большинство согласятся, что 
это не суперкомпиляция, выше — что это точно суперкомпиляция. И поспорить о 
том, что же между ними.

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Wednesday, February 6, 2019 11:24 PM
To: refal@botik.ru
Subject: Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

> С: — Ну а шесть орехов?
> М: — Не ку… а… ты меня совсем запутал. Я знаю только что куча это 
> когда много, а если мало — то это не куча. А больше я ничего не знаю.
Изучал бы нечеткую логику, тогда знал бы:
куча — с мерой μ, и не куча — с мерой 1-μ.
Обе вещи вместе, а не «или, или» :)

Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Boyko Bantchev boykobb_AT_gmail . com]

> С: — Ну а шесть орехов?
> М: — Не ку… а… ты меня совсем запутал. Я знаю только что куча это
> когда много, а если мало — то это не куча. А больше я ничего не знаю.
Изучал бы нечеткую логику, тогда знал бы:
куча — с мерой μ, и не куча — с мерой 1-μ.
Обе вещи вместе, а не «или, или» :)

RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

««И ещё вопрос: почему суперкомпилятор Николая Кондратьева называется 
„полусуперкомпилятором“?»»
«Наверно, потому же, почему вы свой называете „плохим“. 
Просто, чтобы не претендовать на полноценность.»

Хороший вопрос: а что есть полноценный суперкомпилятор?

И вообще, какие можно назвать черты некоторого действа с программой, чтобы это 
действо можно было назвать «суперкомпиляцией»? Понятно, что это вопрос из 
категории «с какого количества орехов начинается куча», которым задавался 
Слонёнок из мультфильма. Но в мультфильме Слонёнок с Мартышкой тем не менее 
смогли очертить границы: два ореха — ещё не куча, а девять — уже куча (хотя 
потом прибежал Попугай со своим мнением).

 

С уважением,
Александр Коновалов

 

From: Arkady Klimov arkady.klimov_AT_gmail.com  
Sent: Wednesday, February 6, 2019 2:26 PM
To: refal@botik.ru
Subject: Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

 

 

 

вт, 5 февр. 2019 г. в 18:00, Александр Коновалов a.v.konovalov87_AT_mail.ru 
<http://a.v.konovalov87_AT_mail.ru>  mailto:refal@botik.ru> >:

 

И ещё вопрос: почему суперкомпилятор Николая Кондратьева называется 
«полусуперкомпилятором»?

Наверно, потому же, почему вы свой называете "плохим". 

Просто, чтобы не претендовать на полноценность.

Аркадий 

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru 
<http://a.v.konovalov87_AT_mail.ru>  mailto:refal@botik.ru> > 
Sent: Thursday, January 31, 2019 6:22 PM
To: refal@botik.ru <mailto:refal@botik.ru> 
Subject: RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор

 

Добрый вечер, Аркадий!

«Что интересно, такой проект существовал (может вы уже слышали о нем?), его 
инициировал Николай Кондратьев на рубеже 80/90-х, и я немного лепты внёс.»

Об этом суперкомпиляторе Вы когда-то писали, но деталей (почему он 
полусуперкомпилятор, что он делает и зачем) Вы не уточняли.

«И делал он примерно то, о чём вы написали.»

Всё уже украдено придумано до нас.

«Всё работало, но довольно тяжеловесно: приходилось результат прикомпилировать 
к основному интерпретатору ri.exe „на правах“ встроенных функций (на практике 
имело смысл полусуперкомпилировать лишь основные внутренние время-ёмкие 
функции).»

Точно также работает компилятор Конышева, который преобразует граф, порождённый 
SCP4, в программу на Си.

«И давало для типовых задач ускорение в 4-5 раз. Главным образом за счёт а) 
форматов и б) компиляции в прямой код.»

Про форматы оценить не могу, но компиляция в код на Си даёт примерно 
двухкратное ускорение. У меня Рефал-5λ может компилировать в RASL и C++.

«В принципе исходники все у меня лежат, только комментариев там маловато, а 
отчёты, к сожалению, были утеряны.»

Отчёты были бы интереснее, поскольку реконструировать идеи из исходников весьма 
трудоёмко. Жалко, что они утеряны.

Значит, идеи работы нужно извлекать путём изучения исходников и экспериментируя 
с самой программой. Индустриальная археология 
<http://hrazvedka.ru/guru/obratnyj-promyshlennyj-shpionazh-i-industrialnaya-arxeologiya.html>
 , да.

«Там в рамках отображения возникла одна очень интересная задачка — выбор 
эффективной разметки параметров и результатов по принципу actual — ghost. Для 
списка актуальный — это когда его можно перестраивать, ghost — только 
„видимость“ — когда можно только читать и если вставить надо, то надо 
скопировать. Был придуман алгоритм, но реализован не был.»

Очень ценная оптимизация для Рефала-6 с подвешенными скобками. Но я изначально 
предполагал оптимизацию для массивного представления, где все параметры 
неизменяемые.

«Если будет интересно, готов всё предоставить, что есть (с согласия Коли).»

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

«Но вам наверно, будет интересно все самим сделать заново и в рамках своей же 
системы, да? Тоже нормально.»

Может, когда-нибудь и сделаю.

 

Спасибо,
Александр Коновалов

 

From: Arkady Klimov arkady.klimov_AT_gmail.com 
<http://arkady.klimov_AT_gmail.com>  mailto:refal@botik.ru> > 
Sent: Wednesday, January 30, 2019 4:07 PM
To: refal@botik.ru <mailto:refal@botik.ru> 
Subject: Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

 

Вы правы, Александр. Что интересно, такой проект существовал (может вы уже 
слышали о нем?), его инициировал Николай Кондратьев на рубеже 80/90-х, и я 
немного лепты внес. Собственно, оттуда и пошел Рефал-6.  

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

Мне выпало поучаствовать в виде выходного отображения: из остаточного графа 
программы в язык С. Все работало, но довольно тяжеловесно: приходилось 
результат прикомпилировать к основному интерпретатору ri.exe "на правах" 
встроенных функций (на п

Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Arkady Klimov arkady . klimov_AT_gmail . com]

вт, 5 февр. 2019 г. в 18:00, Александр Коновалов a.v.konovalov87_AT_mail.ru
:

>
> И ещё вопрос: почему суперкомпилятор Николая Кондратьева называется
> «полусуперкомпилятором»?
>
> Наверно, потому же, почему вы свой называете "плохим".
Просто, чтобы не претендовать на полноценность.
Аркадий

>
>
> *From:* Александр Коновалов a.v.konovalov87_AT_mail.ru 
> *Sent:* Thursday, January 31, 2019 6:22 PM
> *To:* refal@botik.ru
> *Subject:* RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор
>
>
>
> Добрый вечер, Аркадий!
>
> *«Что интересно, такой проект существовал (может вы уже слышали о нем?),
> его инициировал Николай Кондратьев на рубеже 80/90-х, и я немного лепты
> внёс.»*
>
> Об этом суперкомпиляторе Вы когда-то писали, но деталей (почему он
> полусуперкомпилятор, что он делает и зачем) Вы не уточняли.
>
> *«И делал он примерно то, о чём вы написали.»*
>
> Всё уже украдено придумано до нас.
>
> *«Всё работало, но довольно тяжеловесно: приходилось результат
> прикомпилировать к основному интерпретатору ri.exe „на правах“ встроенных
> функций (на практике имело смысл полусуперкомпилировать лишь основные
> внутренние время-ёмкие функции).»*
>
> Точно также работает компилятор Конышева, который преобразует граф,
> порождённый SCP4, в программу на Си.
>
> *«И давало для типовых задач ускорение в 4-5 раз. Главным образом за счёт
> а) форматов и б) компиляции в прямой код.»*
>
> Про форматы оценить не могу, но компиляция в код на Си даёт примерно
> двухкратное ускорение. У меня Рефал-5λ может компилировать в RASL и C++.
>
> *«В принципе исходники все у меня лежат, только комментариев там маловато,
> а отчёты, к сожалению, были утеряны.»*
>
> Отчёты были бы интереснее, поскольку реконструировать идеи из исходников
> весьма трудоёмко. Жалко, что они утеряны.
>
> Значит, идеи работы нужно извлекать путём изучения исходников
> и экспериментируя с самой программой. Индустриальная археология
> <http://hrazvedka.ru/guru/obratnyj-promyshlennyj-shpionazh-i-industrialnaya-arxeologiya.html>,
> да.
>
> *«Там в рамках отображения возникла одна очень интересная задачка — выбор
> эффективной разметки параметров и результатов по принципу actual — ghost.
> Для списка актуальный — это когда его можно перестраивать, ghost — только
> „видимость“ — когда можно только читать и если вставить надо, то надо
> скопировать. Был придуман алгоритм, но реализован не был.»*
>
> Очень ценная оптимизация для Рефала-6 с подвешенными скобками. Но я
> изначально предполагал оптимизацию для массивного представления, где все
> параметры неизменяемые.
>
> *«Если будет интересно, готов всё предоставить, что есть (с согласия
> Коли).»*
>
> Можно с этим не торопиться. Вряд ли руки дойдут изучать, к сожалению.
> Последнее время руки ни до чего не доходят.
>
> *«Но вам наверно, будет интересно все самим сделать заново и в рамках
> своей же системы, да? Тоже нормально.»*
>
> Может, когда-нибудь и сделаю.
>
>
>
> Спасибо,
> Александр Коновалов
>
>
>
> *From:* Arkady Klimov arkady.klimov_AT_gmail.com 
> *Sent:* Wednesday, January 30, 2019 4:07 PM
> *To:* refal@botik.ru
> *Subject:* Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор
>
>
>
> Вы правы, Александр. Что интересно, такой проект существовал (может вы уже
> слышали о нем?), его инициировал Николай Кондратьев на рубеже 80/90-х, и я
> немного лепты внес. Собственно, оттуда и пошел Рефал-6.
>
> Но кроме собственно Рефала-6, который и сейчас активно используется (по
> меньшей мере мной), был еще и проект т.наз. полусуперкомпилятора. И делал
> он примерно то, о чем вы написали. Прежде всего это форматы  - местность и
> ко-местность. Ну и немного безусловной прогонки.
>
> Мне выпало поучаствовать в виде выходного отображения: из остаточного
> графа программы в язык С. Все работало, но довольно тяжеловесно:
> приходилось результат прикомпилировать к основному интерпретатору ri.exe
> "на правах" встроенных функций (на практике имело смысл
> полусуперкомпилировать лишь основные внутренние время-емкие функции). И
> давало для типовых задач ускорение в 4-5 раз. Главным образом за счет а)
> форматов и б) компиляции в прямой код.
>
> В принципе исходники все у меня лежат, только комментариев там маловато, а
> отчеты, к сожалению, были утеряны.
>
> Там в рамках отображения возникла одна очень интересная задачка - выбор
> эффективной разметки параметров и результатов по принципу actual - ghost.
> Для списка актуальный - это когда его можно перестраивать, ghost - только
> "видимость" - когда можно только читать и если вставить надо, то надо
> скопировать. Был придуман алгоритм, но реализован не был. (Пришлось
> заниматься други

RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!

Ещё одно соображение про «плохой» суперкомпилятор. Не знаю на сколько верное.

Но если задача такого суперкомпилятора состоит в повышении местности online (в 
отличие от offline-повышения, которое когда-то делал Романенко), и при этом он 
должен гарантированно завершаться и желательно быстрее, то можно принять 
стратегию. Когда возникает конфигурация, содержащая несколько вызовов функций, 
она принудительно разбивается на несколько, и те уже развиваются независимо.

 

И ещё вопрос: почему суперкомпилятор Николая Кондратьева называется 
«полусуперкомпилятором»?

 

С уважением,
Александр Коновалов

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru  
Sent: Thursday, January 31, 2019 6:22 PM
To: refal@botik.ru
Subject: RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор

 

Добрый вечер, Аркадий!

«Что интересно, такой проект существовал (может вы уже слышали о нем?), его 
инициировал Николай Кондратьев на рубеже 80/90-х, и я немного лепты внёс.»

Об этом суперкомпиляторе Вы когда-то писали, но деталей (почему он 
полусуперкомпилятор, что он делает и зачем) Вы не уточняли.

«И делал он примерно то, о чём вы написали.»

Всё уже украдено придумано до нас.

«Всё работало, но довольно тяжеловесно: приходилось результат прикомпилировать 
к основному интерпретатору ri.exe „на правах“ встроенных функций (на практике 
имело смысл полусуперкомпилировать лишь основные внутренние время-ёмкие 
функции).»

Точно также работает компилятор Конышева, который преобразует граф, порождённый 
SCP4, в программу на Си.

«И давало для типовых задач ускорение в 4-5 раз. Главным образом за счёт а) 
форматов и б) компиляции в прямой код.»

Про форматы оценить не могу, но компиляция в код на Си даёт примерно 
двухкратное ускорение. У меня Рефал-5λ может компилировать в RASL и C++.

«В принципе исходники все у меня лежат, только комментариев там маловато, а 
отчёты, к сожалению, были утеряны.»

Отчёты были бы интереснее, поскольку реконструировать идеи из исходников весьма 
трудоёмко. Жалко, что они утеряны.

Значит, идеи работы нужно извлекать путём изучения исходников и экспериментируя 
с самой программой. Индустриальная археология 
<http://hrazvedka.ru/guru/obratnyj-promyshlennyj-shpionazh-i-industrialnaya-arxeologiya.html>
 , да.

«Там в рамках отображения возникла одна очень интересная задачка — выбор 
эффективной разметки параметров и результатов по принципу actual — ghost. Для 
списка актуальный — это когда его можно перестраивать, ghost — только 
„видимость“ — когда можно только читать и если вставить надо, то надо 
скопировать. Был придуман алгоритм, но реализован не был.»

Очень ценная оптимизация для Рефала-6 с подвешенными скобками. Но я изначально 
предполагал оптимизацию для массивного представления, где все параметры 
неизменяемые.

«Если будет интересно, готов всё предоставить, что есть (с согласия Коли).»

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

«Но вам наверно, будет интересно все самим сделать заново и в рамках своей же 
системы, да? Тоже нормально.»

Может, когда-нибудь и сделаю.

 

Спасибо,
Александр Коновалов

 

From: Arkady Klimov arkady.klimov_AT_gmail.com mailto:refal@botik.ru> > 
Sent: Wednesday, January 30, 2019 4:07 PM
To: refal@botik.ru <mailto:refal@botik.ru> 
Subject: Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

 

Вы правы, Александр. Что интересно, такой проект существовал (может вы уже 
слышали о нем?), его инициировал Николай Кондратьев на рубеже 80/90-х, и я 
немного лепты внес. Собственно, оттуда и пошел Рефал-6.  

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

Мне выпало поучаствовать в виде выходного отображения: из остаточного графа 
программы в язык С. Все работало, но довольно тяжеловесно: приходилось 
результат прикомпилировать к основному интерпретатору ri.exe "на правах" 
встроенных функций (на практике имело смысл полусуперкомпилировать лишь 
основные внутренние время-емкие функции). И давало для типовых задач ускорение 
в 4-5 раз. Главным образом за счет а) форматов и б) компиляции в прямой код.

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

Там в рамках отображения возникла одна очень интересная задачка - выбор 
эффективной разметки параметров и результатов по принципу actual - ghost. Для 
списка актуальный - это когда его можно перестраивать, ghost - только 
"видимость" - когда можно только читать и если вставить надо, то надо 
скопировать. Был придуман алгоритм, но реализован не был. (Пришлось заниматься 
другим). Ручные эксперименты обещали ускорение еще раза в 2.

Если будет интересно, готов все предоставить, что есть (с согласия К

RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Аркадий!

«Что интересно, такой проект существовал (может вы уже слышали о нем?), его 
инициировал Николай Кондратьев на рубеже 80/90-х, и я немного лепты внёс.»

Об этом суперкомпиляторе Вы когда-то писали, но деталей (почему он 
полусуперкомпилятор, что он делает и зачем) Вы не уточняли.

«И делал он примерно то, о чём вы написали.»

Всё уже украдено придумано до нас.

«Всё работало, но довольно тяжеловесно: приходилось результат прикомпилировать 
к основному интерпретатору ri.exe „на правах“ встроенных функций (на практике 
имело смысл полусуперкомпилировать лишь основные внутренние время-ёмкие 
функции).»

Точно также работает компилятор Конышева, который преобразует граф, порождённый 
SCP4, в программу на Си.

«И давало для типовых задач ускорение в 4-5 раз. Главным образом за счёт а) 
форматов и б) компиляции в прямой код.»

Про форматы оценить не могу, но компиляция в код на Си даёт примерно 
двухкратное ускорение. У меня Рефал-5λ может компилировать в RASL и C++.

«В принципе исходники все у меня лежат, только комментариев там маловато, а 
отчёты, к сожалению, были утеряны.»

Отчёты были бы интереснее, поскольку реконструировать идеи из исходников весьма 
трудоёмко. Жалко, что они утеряны.

Значит, идеи работы нужно извлекать путём изучения исходников и экспериментируя 
с самой программой. Индустриальная археология 
<http://hrazvedka.ru/guru/obratnyj-promyshlennyj-shpionazh-i-industrialnaya-arxeologiya.html>
 , да.

«Там в рамках отображения возникла одна очень интересная задачка — выбор 
эффективной разметки параметров и результатов по принципу actual — ghost. Для 
списка актуальный — это когда его можно перестраивать, ghost — только 
„видимость“ — когда можно только читать и если вставить надо, то надо 
скопировать. Был придуман алгоритм, но реализован не был.»

Очень ценная оптимизация для Рефала-6 с подвешенными скобками. Но я изначально 
предполагал оптимизацию для массивного представления, где все параметры 
неизменяемые.

«Если будет интересно, готов всё предоставить, что есть (с согласия Коли).»

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

«Но вам наверно, будет интересно все самим сделать заново и в рамках своей же 
системы, да? Тоже нормально.»

Может, когда-нибудь и сделаю.

 

Спасибо,
Александр Коновалов

 

From: Arkady Klimov arkady.klimov_AT_gmail.com  
Sent: Wednesday, January 30, 2019 4:07 PM
To: refal@botik.ru
Subject: Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

 

Вы правы, Александр. Что интересно, такой проект существовал (может вы уже 
слышали о нем?), его инициировал Николай Кондратьев на рубеже 80/90-х, и я 
немного лепты внес. Собственно, оттуда и пошел Рефал-6.  

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

Мне выпало поучаствовать в виде выходного отображения: из остаточного графа 
программы в язык С. Все работало, но довольно тяжеловесно: приходилось 
результат прикомпилировать к основному интерпретатору ri.exe "на правах" 
встроенных функций (на практике имело смысл полусуперкомпилировать лишь 
основные внутренние время-емкие функции). И давало для типовых задач ускорение 
в 4-5 раз. Главным образом за счет а) форматов и б) компиляции в прямой код.

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

Там в рамках отображения возникла одна очень интересная задачка - выбор 
эффективной разметки параметров и результатов по принципу actual - ghost. Для 
списка актуальный - это когда его можно перестраивать, ghost - только 
"видимость" - когда можно только читать и если вставить надо, то надо 
скопировать. Был придуман алгоритм, но реализован не был. (Пришлось заниматься 
другим). Ручные эксперименты обещали ускорение еще раза в 2.

Если будет интересно, готов все предоставить, что есть (с согласия Коли). Но 
вам наверно, будет интересно все самим сделать заново и в рамках своей же 
системы, да? Тоже нормально.

С уважением, 

Аркадий Климов

 

ср, 30 янв. 2019 г. в 00:12, Alexander Konovalov aka Маздайщик 
mazdaywik_AT_yandex.ru mailto:refal@botik.ru> >:

(Похоже, что моё письмо опять дошло не всем. Дублирую с другого почтового ящика)

Добрый вечер всем!

Пишу, чтобы проверить рассылку, а также, чтобы поделиться некоторым 
соображением.

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

Разворачиваю мысль. Для Рефала придумано (и реализовано) несколько способов 
представления в памяти объектных выражений: двусвязные списки, двусвязные 
списки с подвешенными скобками, односвязные кольцевые списки, массивы. Можно 
спекулятивно придумать ещё несколько вариан

Re: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Arkady Klimov arkady . klimov_AT_gmail . com]

Вы правы, Александр. Что интересно, такой проект существовал (может вы уже
слышали о нем?), его инициировал Николай Кондратьев на рубеже 80/90-х, и я
немного лепты внес. Собственно, оттуда и пошел Рефал-6.
Но кроме собственно Рефала-6, который и сейчас активно используется (по
меньшей мере мной), был еще и проект т.наз. полусуперкомпилятора. И делал
он примерно то, о чем вы написали. Прежде всего это форматы  - местность и
ко-местность. Ну и немного безусловной прогонки.
Мне выпало поучаствовать в виде выходного отображения: из остаточного графа
программы в язык С. Все работало, но довольно тяжеловесно: приходилось
результат прикомпилировать к основному интерпретатору ri.exe "на правах"
встроенных функций (на практике имело смысл полусуперкомпилировать лишь
основные внутренние время-емкие функции). И давало для типовых задач
ускорение в 4-5 раз. Главным образом за счет а) форматов и б) компиляции в
прямой код.
В принципе исходники все у меня лежат, только комментариев там маловато, а
отчеты, к сожалению, были утеряны.
Там в рамках отображения возникла одна очень интересная задачка - выбор
эффективной разметки параметров и результатов по принципу actual - ghost.
Для списка актуальный - это когда его можно перестраивать, ghost - только
"видимость" - когда можно только читать и если вставить надо, то надо
скопировать. Был придуман алгоритм, но реализован не был. (Пришлось
заниматься другим). Ручные эксперименты обещали ускорение еще раза в 2.
Если будет интересно, готов все предоставить, что есть (с согласия Коли).
Но вам наверно, будет интересно все самим сделать заново и в рамках своей
же системы, да? Тоже нормально.
С уважением,
Аркадий Климов

ср, 30 янв. 2019 г. в 00:12, Alexander Konovalov aka Маздайщик
mazdaywik_AT_yandex.ru :

> *(Похоже, что моё письмо опять дошло не всем. Дублирую с другого почтового
> ящика)*
>
> Добрый вечер всем!
>
> Пишу, чтобы проверить рассылку, а также, чтобы поделиться некоторым
> соображением.
>
> Соображение такое: «плохой» суперкомпилятор Рефала может использоваться
> для оптимизации программ, в частности, для повышения местности функций.
>
> Разворачиваю мысль. Для Рефала придумано (и реализовано) несколько
> способов представления в памяти объектных выражений: двусвязные списки,
> двусвязные списки с подвешенными скобками, односвязные кольцевые списки,
> массивы. Можно спекулятивно придумать ещё несколько вариантов, но мы этого
> делать не будем.
>
> Каждое представление имеет свои преимущества и недостатки. Общий
> недостаток у всех — пагубное влияние на стиль программирования. Если
> не учитывать свойства реализации (стоимость копирования или конкатенации),
> то программа будет медленнее работать (иногда существенно медленнее). Если
> учитывать — программа отходит от ясного декларативного стиля.
>
> Наиболее эффективное представление — массивное с дешёвым копированием,
> но дорогой конкатенацией. И из-за дорогой конкатенации приходится либо все
> e-переменные в аргументах функции заворачивать в скобки, или явным
> образом описывать формат функций, как в Рефале Плюс.
>
>
>
> Собственно, к чему я веду. При суперкомпиляции местность функций
> повышается — местность функции в остаточной программе равна числу
> параметров в соответствующей компоненте факторизации. Можно написать
> «плохой» суперкомпилятор, который даёт остаточную программу, близкую
> к исходной, работает быстро (рано свистит) и использовать его как
> дополнительный оптимизирующий проход. В результате мы автоматически получим
> остаточную программу повышенной местности, даже если при написании
> программы о её местности мы не заботились (т.е. не заворачивали
> искусственно e-переменные в скобки и не описывали форматы функций в явном
> виде).
>
> Если этот «плохой» суперкомпилятор будет делать анализ выходного формата
> функции, как это делает SCP4, то ещё лучше — будет повышать ещё
> и коместность.
>
> Кроме того, такой «плохой» суперкомпилятор сможет делать несложные
> оптимизации вроде встраивания функций, распространения констант, обрезки
> некоторых недостижимых ветвей и т.д.
>
>
>
> Т.е. нужно писать компилятор Рефала со встроенным «плохим»
> суперкомпилятором как оптимизирующим проходом. Приемлемую степень
> «плохизны» (или «худобы», от слова «хуже»), мне кажется, нужно определять
> экспериментально. Чтобы работал быстро, не сильно раздувал остаточную
> программу и при этом хорошо повышал местность (и коместность, если
> дополнить его анализом выходного формата).
>
>
>
> С уважением,
> Александр Коновалов
>
> P.S. Не пишу в metacomputation...@googlegroups.com, потому что (а)
> подписчики пересекаются и не хочу лишний раз спамить, (б) письмо больше про
> Рефал, чем про метавычисления.
>

RE: Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Alexander Konovalov aka Маздайщик mazdaywik_AT_yandex . ru]

(Похоже, что моё письмо опять дошло не всем. Дублирую с другого почтового ящика)

Добрый вечер всем!

Пишу, чтобы проверить рассылку, а также, чтобы поделиться некоторым 
соображением.

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

Разворачиваю мысль. Для Рефала придумано (и реализовано) несколько способов 
представления в памяти объектных выражений: двусвязные списки, двусвязные 
списки с подвешенными скобками, односвязные кольцевые списки, массивы. Можно 
спекулятивно придумать ещё несколько вариантов, но мы этого делать не будем.

Каждое представление имеет свои преимущества и недостатки. Общий недостаток у 
всех — пагубное влияние на стиль программирования. Если не учитывать свойства 
реализации (стоимость копирования или конкатенации), то программа будет 
медленнее работать (иногда существенно медленнее). Если учитывать — программа 
отходит от ясного декларативного стиля.

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

 

Собственно, к чему я веду. При суперкомпиляции местность функций повышается — 
местность функции в остаточной программе равна числу параметров в 
соответствующей компоненте факторизации. Можно написать «плохой» 
суперкомпилятор, который даёт остаточную программу, близкую к исходной, 
работает быстро (рано свистит) и использовать его как дополнительный 
оптимизирующий проход. В результате мы автоматически получим остаточную 
программу повышенной местности, даже если при написании программы о её 
местности мы не заботились (т.е. не заворачивали искусственно e-переменные в 
скобки и не описывали форматы функций в явном виде).

Если этот «плохой» суперкомпилятор будет делать анализ выходного формата 
функции, как это делает SCP4, то ещё лучше — будет повышать ещё и коместность.

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

 

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

 

С уважением,
Александр Коновалов

P.S. Не пишу в metacomputation...@googlegroups.com 
 , потому что (а) подписчики 
пересекаются и не хочу лишний раз спамить, (б) письмо больше про Рефал, чем про 
метавычисления.

Плохой суперкомпилятор Рефала как неплохой оптимизатор

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!

Пишу, чтобы проверить рассылку, а также, чтобы поделиться некоторым 
соображением.

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

Разворачиваю мысль. Для Рефала придумано (и реализовано) несколько способов 
представления в памяти объектных выражений: двусвязные списки, двусвязные 
списки с подвешенными скобками, односвязные кольцевые списки, массивы. Можно 
спекулятивно придумать ещё несколько вариантов, но мы этого делать не будем.

Каждое представление имеет свои преимущества и недостатки. Общий недостаток у 
всех — пагубное влияние на стиль программирования. Если не учитывать свойства 
реализации (стоимость копирования или конкатенации), то программа будет 
медленнее работать (иногда существенно медленнее). Если учитывать — программа 
отходит от ясного декларативного стиля.

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

 

Собственно, к чему я веду. При суперкомпиляции местность функций повышается — 
местность функции в остаточной программе равна числу параметров в 
соответствующей компоненте факторизации. Можно написать «плохой» 
суперкомпилятор, который даёт остаточную программу, близкую к исходной, 
работает быстро (рано свистит) и использовать его как дополнительный 
оптимизирующий проход. В результате мы автоматически получим остаточную 
программу повышенной местности, даже если при написании программы о её 
местности мы не заботились (т.е. не заворачивали искусственно e-переменные в 
скобки и не описывали форматы функций в явном виде).

Если этот «плохой» суперкомпилятор будет делать анализ выходного формата 
функции, как это делает SCP4, то ещё лучше — будет повышать ещё и коместность.

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

 

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

 

С уважением,
Александр Коновалов

P.S. Не пишу в metacomputation...@googlegroups.com 
 , потому что (а) подписчики 
пересекаются и не хочу лишний раз спамить, (б) письмо больше про Рефал, чем про 
метавычисления.