Добрый день! Как я понимаю, параллелизм может быть нескольких видов: * Распараллеливание внутри одной операции, например, поиска по большому массиву. Это может быть сделано вне языковой сущности Рефала — с помощью «железа» или СУБД; * Распараллеливание на уровне ветвей при вычислении одного выражения, с учётом функций или без; * Распараллеливание на уровне алгоритма — создание параллельных потоков, решающих по-сути разные задачи. Пункт 1 работает хорошо и понятно, только не даёт глобального выигрыша, так как применим в ограниченном количестве случаев. Пункт 2 представляет наибольший интерес для автоматизации распараллеливания, только реализации реальной пока не видно, хотя серьёзные исследования были. Почему? Трудоёмко и эффективность непредсказуема. Для получения как-нибудь ясной картины я предлагаю опираться на статистику, которая должна вырабатываться на предварительно обрабатываемых наборах данных. В зависимости от решаемых задач эти наборы могут отличаться. Такого рода оптимизация уже делается в серверных решениях для СУБД. Называется «план запроса». На эту тему создано достаточное количество практических решений, позволяющих этим серверам работать в меняющихся и совсем разных условиях. Почему бы не применить эту технологию для Рефала? Требуется разработка, конечно. Пункт 3 тоже из области серверного мышления: нет необходимости всю большую задачу «забивать» в один поток. При наличии возможности межпотокового взаимодействия сложная задача обычно выигрывает от такого разбиения. Это я к чему: если принять Рефал — систему изначально параллельной, параллелизм выполнения придёт. Однако, для этого нужно начинать не с переделки популярных однопользовательских и однозадачных решений, а «с нуля». Тогда всё получится быстрее, чем за 20 лет. В связи с этим я готов выразить удивление, что мой проект по созданию как раз серверного решения не вызвал видимого интереса за прошедшие полгода с момента его обнародования. Даже не сам проект, поскольку меня в сообществе немногие и знают. Сама идея не находит ожидаемого отражения. Или я этого не вижу. А проект продвигается в меру моих возможностей. Не быстро, к сожалению. Но будущее как раз за такими решениями — серверными и обязательно тиражными, если уж оно есть. Тиражность фактически закончилась после завершения эпохи использования у нас «взрослых» компьютеров — БЭСМ-6 и серии ЕС ЭВМ. >Воскресенье, 22 марта 2020, 12:03 +03:00 от Arkady Klimov >arkady.klimov_AT_gmail.com <refal@botik.ru>: > >Немного встряну про параллелизм. >Имхо существенное ускорения получается там и тогда, когда единицы >распараллеливания достаточно крупны (при том, что их достаточно много). >Сегодня это не менее 10 мкс или 10 Кфлоп. Собственно, об этом упоминал Леонид >(проблемы функций с малыми временами, накладные расходы). >Поэтому что для чистого, что для грязного, все равно надо укрупнять шаги, 1мкс >это мало. >Но от компилятора этого ждать трудно. Придется получать эту инфу от >программиста, ему-то виднее. >Хотя какое-то рантайм-профилирование может быть полезным (но не по операторам >отождествления-замены, а по функциям). >А "умный" компилятор или рантайм пусть использует результаты. Кто-то пытался >так делать? >Аркадий >сб, 21 мар. 2020 г. в 18:32, Eisymont Leonid verger-lk_AT_yandex.ru < >refal@botik.ru >: >>Автоматическое распараллеливание с учетом побочного эффекта можно и оставить, >>но это не должно повредить основному, о чем я говорил для чистого рефала без >>побочного эффекта. Абзац в ответе по поводу автоматического распараллеливания >>в Вашем письме я не понял. Мы параллелили компиляцию (выполняемую >>компилятором на Рефале) на уровне операторов исходной программы, а исходная >>программа на фортрано-подобном языке. >>Статистику по основным затратам при выполнении разных рефал-программ делали. >>Затраты на открытые переменные - это миф. Я же пересылал Вам материалы, там >>есть расклад. Измерения были достаточно точные, поскольку выполнялись на >>микропрограммной реализации Рефала. Это была разработка ИПМ тех лет. >>Диссертации моей в электронном виде у меня нет, тогда еще этого не было. У >>меня только в оригинале. М.б. есть в сети, кто-то отсканировал. >>Дипломная работа Александра Фролова и статьи уже 2000-х годов у меня есть, но >>я ведь статьи и презентации пересылал. Надо повторить? >>Л.Эйсымонт >> >> >>21.03.2020, 18:03, "Александр Коновалов a.v.konovalov87_AT_mail.ru " < >>refal@botik.ru >: >>>Добрый вечер, Леонид! >>>Текст диссертации, препринт и дипломная работа доступны в электронном виде? >>>Я бы почитал. >>> >>>«Оставьте затею с решением побочного эффекта на автомате.» >>>Имеем программу для обычного последовательного Рефала. >>>Если компилятор поддерживает распараллеливание на автомате, то для >>>параллельного выполнения в идеале ничего делать не надо: оно само >>>распараллелится. Чтобы обеспечить бо́льшую степень параллелизма, нужно в >>>программу добавить больше независимых чистых вычислений. Например, если это >>>компилятор, то можно сначала загрузить в память несколько исходных файлов, >>>потом их всех в памяти откомпилировать в целевой код, потом (если не было >>>ошибок) записать скомпилированный код в целевые файлы. Компиляция на втором >>>этапе может быть полностью чистой, при этом отдельные исходники >>>транслируются независимо. А значит, будут параллелиться. При этом программу >>>по-прежнему можно будет откомпилировать и запустить на обычной >>>последовательной реализации Рефала. >>>А если компилятор не поддерживает автоматическое распараллеливание? Что >>>тогда делать? >>> >>>«Рекомендую решать проблему распараллеливания только для чистого Рефала, там >>>есть чем заняться для минимизации накладных расходов и по балансировке >>>параллельных вычислений.» >>>Согласен, есть чем заняться. В имеющейся реализации балансировка очень >>>примитивная с высокими накладными расходами. >>> >>>«Ещё там есть проблема функций с малыми временами выполнения, их лучше >>>последовательно выполнять, но для этого их надо уметь выявлять.» >>>Я вообще исходил из предположения, что все функции Рефала имеют малое время >>>выполнения. Исходная последовательная версия Рефала-05 компилирует себя за >>>1,9 секунд, при этом делает 2 244 201 шаг. Т . е . 1 шаг занимает в среднем >>>0,85 микросекунд. >>>Но о том, что разные шаги выполняются разное относительное время, я не >>>задумывался. Любопытно это проверить экспериментально. Можно предположить, >>>что функции, в которых нет открытых e -переменных, повторных и копируемых >>>e - и t -переменных, будут выполняться быстрее. Но это надо проверять. >>>Подопытный Рефал-05 имеет классическую списковую реализацию. >>>Т.е. экспериментально любопытно проверить следующее: есть ли значимое >>>отличие между функциями, которые выполняются «быстро», и функциями, которые >>>выполняются «медленно». Есть ли вообще такой феномен, как «функция с малым >>>временем выполнения». >>> >>>С уважением, >>>Александр Коновалов >>> >>>From : Eisymont Leonid verger - lk _ AT _ yandex . ru < refal @ botik . ru > >>>Sent : Saturday , March 21, 2020 4:05 PM >>>To : refal @ botik . ru ; Al exander Frolov < fro...@nicevt.ru > >>>Subject: Re: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ >>> >>>Александр, по поводу первого доклада. Эти проблемы с побочными эффектами мы >>>исследовали сорок лет назад. Элементы были включены в мою диссертацию, >>>которую я защищал в ИПМ в мае 1983 года. Была "спешная" защита, поскольку я >>>был включен в группу сотрудников ИПМ для работ по Бурану. И было ясно, что к >>>этой тематике мне не вернуться. Еще был препринт ИПМ по распарараллеливанию >>>одного модельного компилятора. Я с Андреем Валентиновичем эти исторические >>>моменты уже вспоминал и обсуждал. Не понимаю, почему он Вам это не передал, >>>либо передал? >>>Вы ломитесь в открытую дверь. Практический совет такой. Оставьте затею с >>>решением побочного эффекта на автомате. Рекомендую решать проблему >>>распараллеливания только для чистого Рефала, там есть чем заняться для >>>минимизации накладных расходов и по балансировке параллельных вычислений. >>>Еще там есть проблема функций с малыми временами выполнения, их лучше >>>последовательно выполнять, но для этого их надо уметь выявлять. Это уже в >>>компиляторе Рефала. При этом проблемы побочных эффектов решать через >>>машинные операции. Это типа мониторов Хоара. Собственно говоря, именно так >>>мы и решили сорок лет назад проблему распараллеливания компилятора, а там >>>много было побочных эффектов. Это и было описано в упомянутых работах. >>>Чистый рефал распараллеливал в свое время Александр Фролов, это была его >>>дипломная работа в МИФИ, лет 15 назад. Сейчас он начальник отдела в >>>НИЦЭВТ-е, другими делами занимается, но интерес, как понимаю, сохранился. В >>>то время не было таких возможностей аппаратуры и накладные расходы оказались >>>большими. Сейчас - другое дело. Советую не терять напрасно время, поступайте >>>именно так. >>>Успехов. >>>Л.Эйсымонт >>> >>>21.03.2020, 14:25, "Александр Коновалов a.v.konovalov87_AT_mail.ru " < >>>refal@botik.ru >: >>>>Добрый день всем! >>>>Я, прежде чем ответить, ждал презентацию от Станислава (мы договаривались, >>>>что он скинет её в рассылку), но он что-то не отсылал и я ответить на >>>>письмо забыл. Извините, что так долго. >>>> >>>>Прозвучало два доклада. Первым был доклад Станислава про распараллеливание >>>>Рефала, вторым был доклад Максима Кривчикова про промежуточное >>>>представление Рефала и его использование для верификации. >>>> >>>>Про первый доклад. Станислав рассказывал про свою курсовую работу по курсу >>>>«Операционные системы» на тему распараллеливания Рефала (научный >>>>руководитель — я). Про распараллеливание. >>>>Из плюсов: предложен подход к параллельному вычислению функций в «грязном» >>>>языке программирования. Когда все функции чистые, проще — есть зависимости >>>>только по данным. А Рефал — «грязный» язык, в нём есть недетерминированные >>>>функции или функции с побочным эффектом (ввод, вывод, копилка). И нужен >>>>механизм, который (а) обеспечивал бы параллельные вычисления для чистых >>>>функций и (б) обеспечивал правильный порядок выполнения «грязных» функций. >>>>Такой механизм предложен, ждём, когда Станислав скинет его в рассылку. >>>>Из минусов: не распараллеливается. Красивого прироста >>>>производительности от большего числа потоков получить не удалось. Нам во >>>>время доклада подсказали, что надо было использовать work stealing для >>>>балансировки задач между потоками. >>>> >>>>Про второй доклад. Максим разработал новый диалект Рефала и планирует его >>>>использовать для верификации типов в динамически типизированных языках при >>>>помощи прогонки (суперкомпиляции). Эту идею верификации я понял не до >>>>конца, другие идеи автора мне показались интересными. Доклад был >>>>незапланированным, поэтому прошёл без слайдов — в рассылку скидывать >>>>нечего. >>>>Андрей Валентинович, второго докладчика Вы добавляли в рассылку? >>>> >>>>С уважением, >>>>Александр Коновалов >>>> >>>>From: Eisymont Leonid verger-lk_AT_yandex.ru < refal@botik.ru > >>>>Sent: Monday, March 2, 2020 2:33 PM >>>>To: refal @botik.ru >>>>Subject: Re: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ >>>> >>>>Андрей, очень хотел попасть на семинар, но сижу дома со статьей по ЭКБ для >>>>ИИ. Очень тяжело идет, а завтра надо бы отдать коллегам на анализ. Жду >>>>презентацию, вопросов у меня уже сейчас много, ведь мы этим занимались 15 >>>>лет назад, еще в НИЦЭВТ-е, тогда не пошло, а потом не до этого было. Сейчас >>>>интерес есть, даже Рреализацию на односвязных списках Рефала-2 на сервере >>>>Модуля установили, она с машинными операциями под MPI, да и вообще >>>>испытанная и самая практически продвинутая. Вручную распараллеливать можно, >>>>даже пробовали еще в НИЦЭВТ-е. Это в НИР Вектор с Квантом - 2004 год. >>>>Успехов, завидую вашему участию в работе такого семинара. >>>>Л.Эйсымонт >>>> >>>>02.03.2020, 08:03, "Andrei Klimov andrei_AT_klimov.net" < refal@botik.ru >: >>>>>Александр, доброе утро! >>>>> >>>>>Жаль, но что ж делать... >>>>>Если параллелизм нас так не затянет, что первый доклад с обсуждением >>>>>займет намного больше времени, чем думали, то есть такие соображения для >>>>>полезных рефал-обсуждений после него: >>>>>* Новый участник семинара Максим Кривчиков может дать у доски аннотацию >>>>>его статьи, а мы обсудим: >>>>>· >>>>>* >>>>>* Vasenin, V.A., Krivchikov, M.A. Intermediate Representation of >>>>>Programs with Type Specification Based on Pattern Matching . Program >>>>>Comput Soft 46 , 57–66 (2020). https://doi.org/10.1134/S0361768820010077 >>>>>* Это журнал "Программирование", но файл статьи на русском дают только за >>>>>деньги (или у автора), а у Шпрингера можно взять бесплатно из >>>>>академических институтов и, наверно, из части университетов. (А есть >>>>>способы и не только из институтов.:-)) >>>>>* У меня есть затравочные вопросы по (отсутствующему, но потенциальному) >>>>>месту Рефала в мире и его (гипотетическому) развитию в соответствующем >>>>>направлении, которых на доклад недостаточно, но дискуссию могу разжечь. >>>>>Вот этот доклад и статья доклад Сергея Романенко в ту же сторону, но есть >>>>>что добавить: >>>>>· >>>>>* >>>>>* С.А. Романенко. Рефал и Агда как воплощения идеи “метаалгоритмического >>>>>языка” // Научный сервис в сети Интернет: труды XIX Всероссийской научной >>>>>конференции (18-23 сентября 2017 г., г. Новороссийск) . — М.: ИПМ им. >>>>>М.В.Келдыша, 2017. — С. 417-424 . — http://doi.org/10.20948/abrau-2017-63 >>>>>* Файл статьи доступен по этой ссылке. >>>>>До встречи! >>>>> >>>>>Всего наилучшего, >>>>>Андрей Климов >>>>> >>>>> >>>>>On Sun, Mar 1, 2020 at 6:13 PM 'Александр Коновалов' via Метавычисления и >>>>>специализация программ < metacomputation...@googlegroups.com > wrote: >>>>>>Добрый вечер всем! >>>>>>Я не успеваю подготовить доклад к завтрашнему семинару, поэтому снимаю >>>>>>завтрашнее выступление. >>>>>>Поэтому слушать завтра будем только доклад Станислава. >>>>>>Но я думаю, что мы найдём достаточно тем для обсуждения и без моего >>>>>>выступления. >>>>>>Простите, что так выходит. >>>>>> >>>>>>С уважением, >>>>>>Александр Коновалов >>>>>> >>>>>> >>>>>>From: Andrei Klimov [mailto: and...@klimov.net ] >>>>>>Sent: Friday, February 28, 2020 2:04 PM >>>>>>To: metacomputation-ru < metacomputation...@googlegroups.com >; >>>>>>refal@botik.ru >>>>>>Subject: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ >>>>>> >>>>>>Добрый день всем! >>>>>>В понедельник 2 марта 2020 в 15 часов соберемся в 416 комнате ИПМ им. >>>>>>М.В. Келдыша РАН на семинар, чтобы послушать два доклада, связанных с >>>>>>языком Рефал: >>>>>>* Станислав Санталов (МГТУ им. Н.Э. Баумана) >>>>>>Параллельное выполнение функций в Рефале-05 >>>>>>>Основная идея — рассмотреть возможность вычисления функций в Рефале-05 >>>>>>>независимо, в различных потоках. Предлагается способ распределения >>>>>>>нагрузки между потоками, сохранения порядка вычисления функций и доступа >>>>>>>к глобальному полю зрения. Для реализации поставленных задач вводится >>>>>>>новая сущность — а-терм, экземпляры которой организуются в дерево с >>>>>>>атомарными счетчиками и специальный глобальный потокобезопасный >>>>>>>безблокировочный список. Также создается несколько очередей а-термов: >>>>>>>общая глобальная и по одной локальной для каждого потока. В конце >>>>>>>приводятся результаты тестирования и анализ полученной схемы. >>>>>>* >>>>>>Александр Коновалов (МГТУ им. Н.Э. Баумана) >>>>>>Алгоритм вывода свёрточной формы для функций обработки строк >>>>>>>Под свёрточной формой мы будем подразумевать представление функции, >>>>>>>потребляющей некоторую структуру данных с помощью операции, знакомой >>>>>>>функциональным программистам под именем foldr для лисповских списков, >>>>>>>а в общем случае для типизированных языков типа ML и Haskell как >>>>>>>катаморфизм этой структуры данных — термин из теории категорий. Для >>>>>>>функций обработки строк (и выражений Рефала), где есть ассоциативная >>>>>>>операция конкатенации, это будет катаморфизм для свободного моноида, >>>>>>>который также можно рассматривать как гомоморфизм моноида конкатенации в >>>>>>>некоторый другой моноид. >>>>>>>Под строками в докладе будут пониматься однородные последовательности >>>>>>>произвольных значений, которые могут быть пустыми и для которых >>>>>>>определены конкатенация и итерация с обеих сторон. Для сравнения: в >>>>>>>лисповских списках определено добавление одного элемента в начало (cons) >>>>>>>и итерация только слева-направо. >>>>>>>Представление функций, потребляющих строки, в свёрточной форме даёт >>>>>>>некоторые преимущества: >>>>>>>* Появляется возможность выполнять слияние (fusion) с функциями, >>>>>>>порождающими строки — в результирующей функции промежуточная строка даже >>>>>>>не будет создаваться. Это вообще верно для любого катаморфизма и >>>>>>>является основой сокращённой дефорестации (shortcut deforestation). >>>>>>>* Появляется возможность распараллеливать вычисление функции — строку >>>>>>>можно разделить на части, свернуть независимо и результаты их свёрток >>>>>>>скомбинировать в искомое значение. Это свойство верно только для >>>>>>>свёрточной формы строковых функций. >>>>>>>* Можно менять направление обработки строк — из свёрточной формы можно >>>>>>>получить функцию, читающую строку как слева-направо, так и >>>>>>>справа-налево. Например, это позволяет преобразовать наивную функцию, >>>>>>>вычисляющую значение многочлена, в схему Горнера. >>>>>>>На семинаре 29 октября 2019 года рассматривалась сокращённая >>>>>>>дефорестация и способ её реализации для языка Рефал. На нём было введено >>>>>>>понятие свёрточной формы для строковых функций в терминах Рефала и были >>>>>>>рассмотрены некоторые примеры функций в этой форме. Способ построения >>>>>>>свёрточной формы на том семинаре не давался. >>>>>>>В докладе 2 марта 2020 года мы определим свёрточную форму уже без >>>>>>>использования терминологии Рефала, а также рассмотрим алгоритм перевода >>>>>>>функций в свёрточную форму. Входом алгоритма будет функция, >>>>>>>анализирующая строку по одному элементу слева-направо (или >>>>>>>справа-налево), выходом будет свёрточная форма либо сообщение о том, что >>>>>>>алгоритм не может её вывести. >>>>>>>Алгоритм применим для ограниченного класса функций, т.е. не для любой >>>>>>>функции, представимой в свёрточной форме, эту форму можно вывести. >>>>>>>Однако, этот класс достаточно широк, что будет продемонстрировано на >>>>>>>нескольких примерах. >>>>>>>Вывод свёрточной формы использует ограниченную суперкомпиляцию на >>>>>>>некоторых этапах своей работы. Ограниченность выражается в допустимых >>>>>>>вариантах обобщения похожих конфигураций. Если в процессе требуется >>>>>>>выполнить недопустимое обобщение, то или преобразуемая функция не >>>>>>>представима в свёрточной форме, или она слишком сложна для этого >>>>>>>алгоритма. >>>>>>>В отличие от доклада 29.10.2019 для понимания этого доклада знания >>>>>>>Рефала не требуется. >>>>>>---------------------------------------------------------------------- >>>>>>Гости ИПМ, которым нужен разовый пропуск, напишите мне по email или >>>>>>пошлите смс-ку с ФИО и НОМЕРОМ ПАСПОРТА на моб. +7 985 364 3536 до 12 >>>>>>час в день семинара. Пропуск получите либо в бюро пропусков в окошке >>>>>>слева от вахтера в главной проходной ("стеклянной", со стороны Миусской >>>>>>площади), либо непосредственно у вахтера. Я вам сообщу, какой вид >>>>>>пропуска будет оформлен. >>>>>> >>>>>>С ноутбуком, не зарегистрированным в списке на вахте на пронос в ИПМ, >>>>>>лучше не приходить, чтобы не споткнуться о ситуацию, когда не пропустят, >>>>>>а соответствующего начальства, чтобы подписать материальный пропуск на >>>>>>внос-вынос, не окажется на месте. >>>>>>---------------------------------------------------------------------- >>>>>> >>>>>>До встречи! >>>>>> >>>>>>Андрей Климов >>>>>>-- >>>>>>Вы получили это сообщение, поскольку подписаны на группу "Метавычисления >>>>>>и специализация программ". >>>>>>Чтобы отменить подписку на эту группу и больше не получать от нее >>>>>>сообщения, отправьте письмо на электронный адрес >>>>>>metacomputation-ru+unsubscr...@googlegroups.com . >>>>>>Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке >>>>>>https://groups.google.com/d/msgid/metacomputation-ru/CAM7HiMnG8AfcNM%2BUG3ufHWeKX_0qs-Mbx_nWp7Eq2DWMVP-tSw%40mail.gmail.com >>>>>> . >>>>>> >>>>>>-- >>>>>>Вы получили это сообщение, поскольку подписаны на группу "Метавычисления >>>>>>и специализация программ". >>>>>>Чтобы отменить подписку на эту группу и больше не получать от нее >>>>>>сообщения, отправьте письмо на электронный адрес >>>>>>metacomputation-ru+unsubscr...@googlegroups.com . >>>>>>Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке >>>>>>https://groups.google.com/d/msgid/metacomputation-ru/0af601d5efdc%240145e8a0%2403d1b9e0%24%40mail.ru >>>>>> . > С уважением, Александр Гусев gusev_aleksa...@mail.ru
Re[2]: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ
Александр Гусев gusev_aleksandr_AT_mail . ru Mon, 23 Mar 2020 02:33:09 -0700
- ... Andrei Klimov klimov_AT_keldysh . ru
- RE:... Александр Коновалов a . v . konovalov87_AT_mail . ru
- ... Andrei Klimov andrei_AT_klimov . net
- ... Eisymont Leonid verger-lk_AT_yandex . ru
- ... Александр Коновалов a . v . konovalov87_AT_mail . ru
- ... Eisymont Leonid verger-lk_AT_yandex . ru
- ... Eisymont Leonid verger-lk_AT_yandex . ru
- ... Arkady Klimov arkady . klimov_AT_gmail . com
- ... Eisymont Leonid verger-lk_AT_yandex . ru
- ... Andrei Klimov andrei_AT_klimov . net
- ... Александр Гусев gusev_aleksandr_AT_mail . ru
- ... Eisymont Leonid verger-lk_AT_yandex . ru
- ... Александр Гусев gusev_aleksandr_AT_mail . ru
- ... Arkady Klimov arkady . klimov_AT_gmail . com
- ... Eisymont Leonid verger-lk_AT_yandex . ru
- ... Andrei Klimov andrei_AT_klimov . net
- ... Eisymont Leonid verger-lk_AT_yandex . ru
- ... Arkady Klimov arkady . klimov_AT_gmail . com
- ... Александр Коновалов a . v . konovalov87_AT_mail . ru