вторник, 11 января 2011 г.

[prog.flame] Пару слов к получению командой разработчиков Scala гранта в размере 2.3M Euros

Вчера на сайте языка программирования Scala появилась новость о том, что команда разработчиков Scala в EPFL получила грант в размере 2.3M евро сроком на 5 лет. Не абы на что, а на разработку новых подходов к упрощению параллельного программирования.

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

Итак, если пересказать вкратце то, что я понял, то разработчики Scala предлагают подход, который они называют “language virtualization”. За этим красивым названием скрывается довольно простая и совсем не новая (особенно для Ruby-разработчиков) вещь: средства для решения каких-то вычислительных задач следует оформлять в виде DSL-ей на языке Scala, которые затем посредством staged compilation будут преобразовываться уже к оптимизированному низкоуровневому коду.

Что такое staged compilation я лично себе представляю не очень четко. Но термин staging самим Мартином Одерски употреблялся уже давно, еще когда я брал у него мини-интервью (русский вариант). Тогда я попытался нарыть материалов на эту тему, но их было совсем мало и понял я вот что: процесс компиляции специальным образом разделяется на стадии. Результаты работы каждой стадии представляются в стандартизированном виде. А разработчикам предоставляются стандартизированные интерфейсы для написания своих компонентов, работающих на конкретной стадии компиляции. Например, после лексического и синтаксического анализа строится AST и это является результатом первой стадии компиляции. Можно написать свой компонент, который будет получать это AST, анализировать его и вносить в него свои изменения. После чего результирующий AST будет передан следующей стадии компиляции.

Примечание: под “стандартизированным” я здесь понимал стандартизацию в рамках конкретного языка и даже конкретного компилятора для него.

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

При этом, однако, Одерски и Ко уделяют особое внимание безопасности данного процесса. Поэтому они вряд ли дадут доступ напрямую к AST, а потребуют использовать исключительно языковые возможности Scala (может быть, даже за счет расширения языка). В частности, упоминаются такие механизмы, как finally tagless и polymorphic embedding.

Так что, вполне возможно, под staging-ом в Scala будет пониматься что-то вроде специализации C++ных шаблонов.

Повторюсь, что это я так понял предложения разработчиков Scala. Вполне возможно, что я понял не правильно. Поэтому отсылаю интересующихся к первоисточникам:

Теперь мои субъективные впечатления от этой новости.

Во-первых, есть серьезное недоумение. Мне казалось, что вычислительные задачи – это вотчина нативных языков, поскольку эффективность и близость к железу здесь должны находиться на первых местах. Не случайно же в данной области Fortran до сих пор жив и здоров, и не сильно-то его теснит тот же C++. А тут в качестве решения предлагается JVM! Java со своим hotspot-ом, может быть, и хороша на серверах для задачек, где львиную долю времени запросы к БД занимают. Но в числодробилках… Другое дело, если Scala будет использоваться только как host-язык и как язык для компилятора, а трансляция из Scala+DSL-и будет вестись куда-нибудь в Fortran/C++ или в машинный код.

Кстати, такой пример и приводится в статье – DSL под названием Liszt, из которого затем генерируется чистый C++, использующий MPI.

Но что-то я сильно сомневаюсь, что это будет сильно распространено. Хотя бы за счет того, что Scala далеко не единственный язык, который удобен для разработки embedded DSL. Так что основным результатом трансляции Scala-вских DSL-ей будет все-таки Scala и Java-байткод.

Во-вторых, интересно, как на все это дело будет смотреть Oracle. По мне, так Oracle заинтересован в продвижении Java и JVM только в Enterprise. Ну, может быть, еще и на мобильных платформах за счет лицензионных отчислений со специализированных реализаций JVM. Вычислительные задачи – это, вроде как, совсем не вотчина Oracle. А если Oracle не будет затачивать JVM для вычислительных задач (скажем, будет поддерживать очень ограниченный набор платформ для JVM), то какой смысл в вычислительных DSL-ях, если они генерируют в итоге всего лишь Java-байткод?

В-третьих, я вспоминаю лекции нашего университетского преподавателя Быховцева Виктора Емельяновича, читавшего у нас спецкурс по методам конечных элементов (МКЭ). Он рассказывал, что в 80-х годах разработчики вычислительных пакетов для МКЭ ориентировались на создание универсальных инструментов – каждый пакет стремился решать как можно больше задач. Для этого в пакетах были системы метаописаний из которых затем специальные трансляторы по заданным пользователям параметрам генерировали исходники на Fortran/Pascal/C, затем транслировали их в машинный код чтобы получить максимально эффективное конкретное решение. Но затем этот подход благополучно провалился из-за своей монстроузности и, как оказалось, не очень большой эффективности.

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

В-четвертых, примеры, которые приведены в упомянутых статье и презентации, что-то сильно мне напоминают шаблонное метапрогаммирование в C++. Которое сложно назвать простым и удобным. Поэтому есть у меня подозрение, что и в Scala появится своя область, в которой себя будут чувствовать нормально очень небольшой процент Ъ-гуру.

В-пятых, мне не верится в то, что разработчики Scala способны создать что-то промышленное. Ну ученные они, исследователи. Посему не могут создать практичный инструмент. Прототип – запросто, инструмент – нет. И в качестве иллюстрации своей мысли приведу сам язык Scala. Он ведь далеко не молод. Его первая версия появилась в 2003-м году. Т.е. этому языку уже семь лет, а его популярность… Разве что на форумах и в блогах. Тогда как достаточно посмотреть на широту использования тех же Perl, Python, PHP и даже Ruby через семь лет после их появления.

Так что добавление финансирования Scala лишь расширит диапазон для экспериментов его создателей. Но вряд ли поспособствуют появлению очередной “рабочей лошадки”, тем более успешной и востребованной. Имхо, одним из необходимых условий создания успешного практического инструмента является серьезное ограничение в средствах и ресурсах его разработчиков – тогда на свет рождаются действительно удачные творения, а все неприспособленные к реальным условиям просто отмирают на самых ранних стадиях.

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

Ну и еще одну неполиткорректную вещь скажу. Учась в аспирантуре наблюдал за тем, как какой-нибудь научно-исследовательский институт совместно с университетом организовывали различные “новые” исследовательские проекты, получали деньги от Академии Наук и успешно отчитывались за выполненные работы. Поскольку везде сидели свои люди. А всякие предложения и презентации, которые требовались по условиям “конкурсов” писались аспирантами. Так вот упомянутая выше презентация сильно мне напомнило то, что когда-то выдавали “на гора” наши аспиранты, “творчески” перерабатывая старые труды своих научных руководителей.

10 комментариев:

Alex комментирует...

Немного напомнило - про мега-мета-язык.

http://code.google.com/p/nemerle-2/wiki/Nemerle2

Miroslav комментирует...

staged достаточно прочно ассоциируется с Oleg Kiselyov и метапрограммированием. Это просто хинт если есть желание гуглить исследования и освоения :)

Qrilka комментирует...

По поводу JVM и выч. задач стоит вспомнить Fortress, правда какое отношение он теперь к Oracle имеет - непонятно...

eao197 комментирует...

@Alex: да, языки вроде Lisp, Nemerle, имхо, изначально более подходят для разработки DSL-лей, чем Scala.

Да и другие языки (вроде OCaml, Haskell и даже динамически типизированный Ruby) могут оказаться не хуже Scala.

eao197 комментирует...

@Myroslav Rubanets:

спасибо за наводку.

eao197 комментирует...

@Qrilka:

AFAIK, Fortress так и остался на уровне прототипа.

И в данной теме Fortress (равно как и Chapel, и X10) стоит упомянуть еще по одной причине. Очень серьезные силы были положены на специализированные языки для вычислений. Поэтому я сильно сомневаюсь, что DSL-и в Scala смогут с ними соревноваться по удобству решения конкретных задач. Да и по эффективности.

Arseni Buinitsky комментирует...

А кто-нибудь Jetbrains MPS трогал?

eao197 комментирует...

@jazzcat:

Этот MPS, похоже, никто, кроме некоторых JetBrain-овцев толком и не трогал.

имя комментирует...

небольшой buffer flush:

1. скаловский Type Constructor Polymorphism емнип полная аналогия template template parameters

2. насчет всех 4-х статей “Почему я не хочу быть начальником?” -- очень интересно и размышлительно, но там я не чувствую у себя достаточно опыта и грамотности что-либо сказать, хотя некоторые соображения и возражения есть

3. теперь по теме staged compilation: я давно бегло смотрел одну из пдф-ок одерского на эту тему, напомнило плюсовые expression templates -- разница только в том, что покороче из-за скаловского pattern match-инга

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

нучжно что-то типа управляемой partial evaluation или даже supercompilation

имя комментирует...

про MPS -- год назад я пытался

там документация несъедобная

ну и из подхода:

1. расширяемость синтаксиса в каждой точке -- это излишне

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

3. после несъедобной документации по основам даже нет надежды осилить то, что у них по системе типов

хотя если кто напишет вменяемую доку -- прочту