Леонид, OR-параллелизм имеет большую практическую ценность. О нем было много речи в прошлую волну ИИ на основе Пролога и машин 5-го поколения. И в мире параллельных алгоритмов OR-параллелизм достаточно распространен.
Например, параллельный метод ветвей и границ – это OR-параллелизм: параллельные ветви, на которых искомый результат будет заведомо хуже, чем уже достигнутый рекорд, отмирают (в литературе по ВиГ говорят "отсеиваются", "pruned"). Мы с Алексеем Адамовичем используем метод ВиГ как тестовую задачу на распараллеливание по разрабатываемой нами методике. Недавно мы опубликовали статью: - А.И. Адамович, Анд.В. Климов. *О детерминированной параллельной реализации метода ветвей и границ на монотонных объектах* // *Научный сервис в сети Интернет: труды XXI Всероссийской научной конференции (23-28 сентября 2019 г., г. Новороссийск)*. — М.: ИПМ им. М.В.Келдыша, 2019. — С. 3-18. — DOI: http://doi.org/10.20948/abrau-2019-61 - Презентация: https://keldysh.ru/abrau/2019/p/61.pdf в которой привели реализацию ВиГ, у которой в коде верхнего уровня OR-параллелизм не виден, он записан как AND-параллелизм – как параллельные вызовы функций – естественно для функционального программирования. А "отсеивание" ненужных вызовов запрятано в объект, который хранит текущий найденный рекорд. Получилось изящно. А в Т-системе, насколько я представляю, OR-параллелизма не было. Или был где-то на периферии, что я о нем и не слышал. В своей основе она эксплуатировала функциональный AND-параллелизм. Андрей Климов On Mon, Mar 23, 2020 at 7:43 PM Eisymont Leonid verger-lk_AT_yandex.ru < refal@botik.ru> wrote: > Аркадий, это сложновато и непонятна практическая ценность. Вот, в > Т-системе накрутили, чем закончилось. > Но надо иметь ввиду. Сейчас хорошо бы на чистом Рефале сосредоточиться, но > довести до практического результата. > Л.Эйсымонт > > 23.03.2020, 17:38, "Arkady Klimov arkady.klimov_AT_gmail.com" < > refal@botik.ru>: > > Я бы упомянул еще один вид параллелизма - ИЛИ-параллелизм. В строгом > смысле в рефале места для него сейчас нет. > Было бы, если бы кроме отождествления "слева" и "справа" добавить "любое" > - подходит любой вариант > длины открытой е-переменной. Или если ввести "машинную операцию" типа > <Map-Select tF eX> = > применять tF к термам eX в любом порядке или параллельно, и если есть хотя > бы один, > где результат не неуспех, то его и выбрать (любой), иначе неуспех. > Этот вид встречается в задачах типа поиска доказательств. Также в > суперкомпиляции. > Он не сводится к обычному И-параллелизму, поскольку в нем нужно убивать > запущенные подпроцессы, > чего в И-параллелизме не бывает. > Аркадий > > пн, 23 мар. 2020 г. в 14:23, Александр Гусев gusev_aleksandr_AT_mail.ru < > refal@botik.ru>: > > Ответил в личку > > > > Понедельник, 23 марта 2020, 12:58 +03:00 от Eisymont Leonid > verger-lk_AT_yandex.ru <refal@botik.ru>: > > Александр, про уровни распараллеливания в Рефале известно с конца 70-х > годов. > Вы правильно это разложили в своих пунктах. Мы сейчас говорим о втором > пункте. Первый пункт - это, наверное, будет решение на одномерном клеточном > автомате. Оно также лежит с конца 70-х. > Пункт 3 - в начале 2000-х ввели в Рефал через машинные операции работу с > MPI. Эта реализация у нас есть. в середине прошлого десятилетия был > небольшой опыт использования этого. Мы в Модуле эту реализацию даже > поставили на один из серверов, но далее пока это направление не развиваем - > много более неотложных дел, да еще этот короновирус добавился... > Ваши рассуждения правильны, надо общаться. Как узнать подробнее о том, чем > Вы занимались? > Л.Эйсымонт > > 23.03.2020, 12:29, "Александр Гусев gusev_aleksandr_AT_mail.ru" < > refal@botik.ru <http://compose?To=refal@botik.ru>>: > > Добрый день! > > Как я понимаю, параллелизм может быть нескольких видов: > > 1. Распараллеливание внутри одной операции, например, поиска по > большому массиву. Это может быть сделано вне языковой сущности Рефала — с > помощью «железа» или СУБД; > 2. Распараллеливание на уровне ветвей при вычислении одного выражения, > с учётом функций или без; > 3. Распараллеливание на уровне алгоритма — создание параллельных > потоков, решающих по-сути разные задачи. > > Пункт 1 работает хорошо и понятно, только не даёт глобального выигрыша, > так как применим в ограниченном количестве случаев. > Пункт 2 представляет наибольший интерес для автоматизации > распараллеливания, только реализации реальной пока не видно, хотя серьёзные > исследования были. Почему? Трудоёмко и эффективность непредсказуема. Для > получения как-нибудь ясной картины я предлагаю опираться на статистику, > которая должна вырабатываться на предварительно обрабатываемых наборах > данных. В зависимости от решаемых задач эти наборы могут отличаться. Такого > рода оптимизация уже делается в серверных решениях для СУБД. Называется > «план запроса». На эту тему создано достаточное количество практических > решений, позволяющих этим серверам работать в меняющихся и совсем разных > условиях. Почему бы не применить эту технологию для Рефала? Требуется > разработка, конечно. > Пункт 3 тоже из области серверного мышления: нет необходимости всю большую > задачу «забивать» в один поток. При наличии возможности межпотокового > взаимодействия сложная задача обычно выигрывает от такого разбиения. > > Это я к чему: если принять Рефал — систему изначально параллельной, > параллелизм выполнения придёт. Однако, для этого нужно начинать не с > переделки популярных однопользовательских и однозадачных решений, а «с > нуля». Тогда всё получится быстрее, чем за 20 лет. > > В связи с этим я готов выразить удивление, что мой проект по созданию как > раз серверного решения не вызвал видимого интереса за прошедшие полгода с > момента его обнародования. Даже не сам проект, поскольку меня в сообществе > немногие и знают. Сама идея не находит ожидаемого отражения. Или я этого не > вижу. А проект продвигается в меру моих возможностей. Не быстро, к > сожалению. Но будущее как раз за такими решениями — серверными и > обязательно тиражными, если уж оно есть. Тиражность фактически закончилась > после завершения эпохи использования у нас «взрослых» компьютеров — БЭСМ-6 > и серии ЕС ЭВМ. > > Воскресенье, 22 марта 2020, 12:03 +03:00 от Arkady Klimov > arkady.klimov_AT_gmail.com <http://arkady.klimov_at_gmail.com/> < > refal@botik.ru <https://e.mail.ru/compose/?mailto=mailto%3are...@botik.ru> > >: > > Немного встряну про параллелизм. > Имхо существенное ускорения получается там и тогда, когда единицы > распараллеливания достаточно крупны (при том, что их достаточно много). > Сегодня это не менее 10 мкс или 10 Кфлоп. Собственно, об этом упоминал > Леонид (проблемы функций с малыми временами, накладные расходы). > Поэтому что для чистого, что для грязного, все равно надо укрупнять шаги, > 1мкс это мало. > Но от компилятора этого ждать трудно. Придется получать эту инфу от > программиста, ему-то виднее. > Хотя какое-то рантайм-профилирование может быть полезным (но не по > операторам отождествления-замены, а по функциям). > А "умный" компилятор или рантайм пусть использует результаты. Кто-то > пытался так делать? > Аркадий > > сб, 21 мар. 2020 г. в 18:32, Eisymont Leonid verger-lk_AT_yandex.ru < > refal@botik.ru <https://e.mail.ru/compose/?mailto=mailto%3are...@botik.ru> > >: > > Автоматическое распараллеливание с учетом побочного эффекта можно и > оставить, но это не должно повредить основному, о чем я говорил для чистого > рефала без побочного эффекта. Абзац в ответе по поводу автоматического > распараллеливания в Вашем письме я не понял. Мы параллелили компиляцию > (выполняемую компилятором на Рефале) на уровне операторов исходной > программы, а исходная программа на фортрано-подобном языке. > Статистику по основным затратам при выполнении разных рефал-программ > делали. Затраты на открытые переменные - это миф. Я же пересылал Вам > материалы, там есть расклад. Измерения были достаточно точные, поскольку > выполнялись на микропрограммной реализации Рефала. Это была разработка ИПМ > тех лет. > Диссертации моей в электронном виде у меня нет, тогда еще этого не было. У > меня только в оригинале. М.б. есть в сети, кто-то отсканировал. > Дипломная работа Александра Фролова и статьи уже 2000-х годов у меня есть, > но я ведь статьи и презентации пересылал. Надо повторить? > Л.Эйсымонт > > > 21.03.2020, 18:03, "Александр Коновалов a.v.konovalov87_AT_mail.ru > <http://a.v.konovalov87_at_mail.ru/>" <refal@botik.ru > <https://e.mail.ru/compose/?mailto=mailto%3are...@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; Alexander Frolov <fro...@nicevt.ru > <https://e.mail.ru/compose/?mailto=mailto%3afro...@nicevt.ru>> > *Subject:* Re: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ > > > > Александр, по поводу первого доклада. Эти проблемы с побочными эффектами > мы исследовали сорок лет назад. Элементы были включены в мою диссертацию, > которую я защищал в ИПМ в мае 1983 года. Была "спешная" защита, поскольку я > был включен в группу сотрудников ИПМ для работ по Бурану. И было ясно, что > к этой тематике мне не вернуться. Еще был препринт ИПМ по > распарараллеливанию одного модельного компилятора. Я с Андреем > Валентиновичем эти исторические моменты уже вспоминал и обсуждал. Не > понимаю, почему он Вам это не передал, либо передал? > > Вы ломитесь в открытую дверь. Практический совет такой. Оставьте затею с > решением побочного эффекта на автомате. Рекомендую решать проблему > распараллеливания только для чистого Рефала, там есть чем заняться для > минимизации накладных расходов и по балансировке параллельных вычислений. > Еще там есть проблема функций с малыми временами выполнения, их лучше > последовательно выполнять, но для этого их надо уметь выявлять. Это уже в > компиляторе Рефала. При этом проблемы побочных эффектов решать через > машинные операции. Это типа мониторов Хоара. Собственно говоря, именно так > мы и решили сорок лет назад проблему распараллеливания компилятора, а там > много было побочных эффектов. Это и было описано в упомянутых работах. > > Чистый рефал распараллеливал в свое время Александр Фролов, это была его > дипломная работа в МИФИ, лет 15 назад. Сейчас он начальник отдела в > НИЦЭВТ-е, другими делами занимается, но интерес, как понимаю, сохранился. В > то время не было таких возможностей аппаратуры и накладные расходы > оказались большими. Сейчас - другое дело. Советую не терять напрасно время, > поступайте именно так. > > Успехов. > > Л.Эйсымонт > > > > 21.03.2020, 14:25, "Александр Коновалов a.v.konovalov87_AT_mail.ru > <http://a.v.konovalov87_at_mail.ru/>" <refal@botik.ru > <https://e.mail.ru/compose/?mailto=mailto%3are...@botik.ru>>: > > Добрый день всем! > > Я, прежде чем ответить, ждал презентацию от Станислава (мы договаривались, > что он скинет её в рассылку), но он что-то не отсылал и я ответить > на письмо забыл. Извините, что так долго. > > > > Прозвучало два доклада. Первым был доклад Станислава про распараллеливание > Рефала, вторым был доклад Максима Кривчикова про промежуточное > представление Рефала и его использование для верификации. > > > > Про первый доклад. Станислав рассказывал про свою курсовую работу по курсу > «Операционные системы» на тему распараллеливания Рефала (научный > руководитель — я). Про распараллеливание. > > Из плюсов: предложен подход к параллельному вычислению функций в «грязном» > языке программирования. Когда все функции чистые, проще — есть зависимости > только по данным. А Рефал — «грязный» язык, в нём есть недетерминированные > функции или функции с побочным эффектом (ввод, вывод, копилка). И нужен > механизм, который (а) обеспечивал бы параллельные вычисления для чистых > функций и (б) обеспечивал правильный порядок выполнения «грязных» функций. > > Такой механизм предложен, ждём, когда Станислав скинет его в рассылку. > > Из минусов: не распараллеливается. Красивого прироста производительности > от большего числа потоков получить не удалось. Нам во время доклада > подсказали, что надо было использовать work stealing для балансировки > задач между потоками. > > > > Про второй доклад. Максим разработал новый диалект Рефала и планирует его > использовать для верификации типов в динамически типизированных языках при > помощи прогонки (суперкомпиляции). Эту идею верификации я понял > не до конца, другие идеи автора мне показались интересными. Доклад был > незапланированным, поэтому прошёл без слайдов — в рассылку скидывать > нечего. > > Андрей Валентинович, второго докладчика Вы добавляли в рассылку? > > > > С уважением, > Александр Коновалов > > > > *From:* Eisymont Leonid verger-lk_AT_yandex.ru <refal@botik.ru > <https://e.mail.ru/compose/?mailto=mailto%3are...@botik.ru>> > *Sent:* Monday, March 2, 2020 2:33 PM > *To:* refal@botik.ru > <https://e.mail.ru/compose/?mailto=mailto%3are...@botik.ru> > *Subject:* Re: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ > > > > Андрей, очень хотел попасть на семинар, но сижу дома со статьей по ЭКБ для > ИИ. Очень тяжело идет, а завтра надо бы отдать коллегам на анализ. Жду > презентацию, вопросов у меня уже сейчас много, ведь мы этим занимались 15 > лет назад, еще в НИЦЭВТ-е, тогда не пошло, а потом не до этого было. Сейчас > интерес есть, даже Рреализацию на односвязных списках Рефала-2 на сервере > Модуля установили, она с машинными операциями под MPI, да и вообще > испытанная и самая практически продвинутая. Вручную распараллеливать можно, > даже пробовали еще в НИЦЭВТ-е. Это в НИР Вектор с Квантом - 2004 год. > > Успехов, завидую вашему участию в работе такого семинара. > > Л.Эйсымонт > > > > 02.03.2020, 08:03, "Andrei Klimov andrei_AT_klimov.net" <refal@botik.ru > <https://e.mail.ru/compose/?mailto=mailto%3are...@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 > <https://e.mail.ru/compose/?mailto=mailto%3ametacomputation%2...@googlegroups.com>> > wrote: > > Добрый вечер всем! > > Я не успеваю подготовить доклад к завтрашнему семинару, поэтому снимаю > завтрашнее выступление. > > Поэтому слушать завтра будем только доклад Станислава. > > Но я думаю, что мы найдём достаточно тем для обсуждения и без моего > выступления. > > Простите, что так выходит. > > > > С уважением, > Александр Коновалов > > > > > > *From:* Andrei Klimov [mailto:and...@klimov.net > <https://e.mail.ru/compose/?mailto=mailto%3aand...@klimov.net>] > *Sent:* Friday, February 28, 2020 2:04 PM > *To:* metacomputation-ru <metacomputation...@googlegroups.com > <https://e.mail.ru/compose/?mailto=mailto%3ametacomputation%2...@googlegroups.com>>; > refal@botik.ru <https://e.mail.ru/compose/?mailto=mailto%3are...@botik.ru> > *Subject:* Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ > > > > Добрый день всем! > > В *понедельник 2 марта 2020 в 15 часов* соберемся в 416 комнате ИПМ им. > М.В. Келдыша РАН на семинар, чтобы послушать два доклада, связанных с > языком Рефал: > > - *Станислав Санталов *(МГТУ им. Н.Э. Баумана) > *Параллельное выполнение функций в Рефале-05* > > Основная идея — рассмотреть возможность вычисления функций в Рефале-05 > независимо, в различных потоках. Предлагается способ распределения нагрузки > между потоками, сохранения порядка вычисления функций и доступа к > глобальному полю зрения. Для реализации поставленных задач вводится новая > сущность — а-терм, экземпляры которой организуются в дерево с атомарными > счетчиками и специальный глобальный потокобезопасный безблокировочный > список. Также создается несколько очередей а-термов: общая глобальная и по > одной локальной для каждого потока. В конце приводятся результаты > тестирования и анализ полученной схемы. > > > - *Александр Коновалов* (МГТУ им. Н.Э. Баумана) > *Алгоритм вывода свёрточной формы для функций обработки строк* > > Под *свёрточной формой* мы будем подразумевать представление функции, > потребляющей некоторую структуру данных с помощью операции, знакомой > функциональным программистам под именем foldr для лисповских списков, а в > общем случае для типизированных языков типа ML и Haskell как *катаморфизм > <https://traditio.wiki/%D0%9A%D0%B0%D1%82%D0%B0%D0%BC%D0%BE%D1%80%D1%84%D0%B8%D0%B7%D0%BC>* > этой структуры данных — термин из теории категорий. Для функций обработки > строк (и выражений Рефала), где есть ассоциативная операция конкатенации, > это будет катаморфизм для свободного моноида, который также можно > рассматривать как гомоморфизм моноида конкатенации в некоторый другой > моноид. > > Под строками в докладе будут пониматься однородные последовательности > произвольных значений, которые могут быть пустыми и для которых определены > конкатенация и итерация с обеих сторон. Для сравнения: в лисповских списках > определено добавление одного элемента в начало (cons) и итерация только > слева-направо. > > Представление функций, потребляющих строки, в свёрточной форме даёт > некоторые преимущества: > > - Появляется возможность выполнять слияние (fusion) с функциями, > порождающими строки — в результирующей функции промежуточная строка даже не > будет создаваться. Это вообще верно для любого катаморфизма и является > основой сокращённой дефорестации (shortcut deforestation). > - Появляется возможность распараллеливать вычисление функции — строку > можно разделить на части, свернуть независимо и результаты их свёрток > скомбинировать в искомое значение. Это свойство верно только для свёрточной > формы строковых функций. > - Можно менять направление обработки строк — из свёрточной формы можно > получить функцию, читающую строку как слева-направо, так и справа-налево. > Например, это позволяет преобразовать наивную функцию, вычисляющую значение > многочлена, в схему Горнера. > > На семинаре 29 октября 2019 года рассматривалась сокращённая дефорестация > и способ её реализации для языка Рефал. На нём было введено понятие > свёрточной формы для строковых функций в терминах Рефала и были рассмотрены > некоторые примеры функций в этой форме. Способ построения свёрточной формы > на том семинаре не давался. > > В докладе 2 марта 2020 года мы определим свёрточную форму уже без > использования терминологии Рефала, а также рассмотрим алгоритм перевода > функций в свёрточную форму. Входом алгоритма будет функция, анализирующая > строку по одному элементу слева-направо (или справа-налево), выходом будет > свёрточная форма либо сообщение о том, что алгоритм не может её вывести. > > Алгоритм применим для ограниченного класса функций, т.е. не для любой > функции, представимой в свёрточной форме, эту форму можно вывести. Однако, > этот класс достаточно широк, что будет продемонстрировано на нескольких > примерах. > > Вывод свёрточной формы использует ограниченную суперкомпиляцию на > некоторых этапах своей работы. Ограниченность выражается в допустимых > вариантах обобщения похожих конфигураций. Если в процессе требуется > выполнить недопустимое обобщение, то или преобразуемая функция не > представима в свёрточной форме, или она слишком сложна для этого алгоритма. > > В отличие от доклада 29.10.2019 для понимания этого доклада знания Рефала > не требуется. > > ------------------------------ > > Гости ИПМ, которым нужен разовый пропуск, напишите мне по email или > пошлите смс-ку с ФИО и НОМЕРОМ ПАСПОРТА на моб. +7 985 364 3536 до 12 час > в день семинара. Пропуск получите либо в бюро пропусков в окошке слева от > вахтера в главной проходной ("стеклянной", со стороны Миусской площади), > либо непосредственно у вахтера. Я вам сообщу, какой вид пропуска будет > оформлен. > > С ноутбуком, не зарегистрированным в списке на вахте на пронос в ИПМ, > лучше не приходить, чтобы не споткнуться о ситуацию, когда не пропустят, а > соответствующего начальства, чтобы подписать материальный пропуск на > внос-вынос, не окажется на месте. > ------------------------------ > > > До встречи! > > Андрей Климов > > -- > Вы получили это сообщение, поскольку подписаны на группу "Метавычисления и > специализация программ". > Чтобы отменить подписку на эту группу и больше не получать от нее > сообщения, отправьте письмо на электронный адрес > metacomputation-ru+unsubscr...@googlegroups.com > <https://e.mail.ru/compose/?mailto=mailto%3ametacomputation%2dru%2bunsubscr...@googlegroups.com> > . > Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке > https://groups.google.com/d/msgid/metacomputation-ru/CAM7HiMnG8AfcNM%2BUG3ufHWeKX_0qs-Mbx_nWp7Eq2DWMVP-tSw%40mail.gmail.com > <https://groups.google.com/d/msgid/metacomputation-ru/CAM7HiMnG8AfcNM%2BUG3ufHWeKX_0qs-Mbx_nWp7Eq2DWMVP-tSw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > > -- > Вы получили это сообщение, поскольку подписаны на группу "Метавычисления и > специализация программ". > Чтобы отменить подписку на эту группу и больше не получать от нее > сообщения, отправьте письмо на электронный адрес > metacomputation-ru+unsubscr...@googlegroups.com > <https://e.mail.ru/compose/?mailto=mailto%3ametacomputation%2dru%2bunsubscr...@googlegroups.com> > . > Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке > https://groups.google.com/d/msgid/metacomputation-ru/0af601d5efdc%240145e8a0%2403d1b9e0%24%40mail.ru > <https://groups.google.com/d/msgid/metacomputation-ru/0af601d5efdc%240145e8a0%2403d1b9e0%24%40mail.ru?utm_medium=email&utm_source=footer> > . > > > > > > С уважением, > Александр Гусев > gusev_aleksa...@mail.ru > <https://e.mail.ru/compose/?mailto=mailto%3agusev_aleksa...@mail.ru> > > > > > С уважением, > Александр Гусев > gusev_aleksa...@mail.ru > > > > >
