Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Спасибо за статью и проект!
Расскажите, пожалуйста, о дальнейших планах. Собираетесь ли вы (я правильно понимаю, что команда из двух человек) довести до production ready версий?
Используете ли Вы сами наработки в текущих проектах (вижу Диптаун, не могу понять, продолжается ли его разработка)?
Расскажите, пожалуйста, о дальнейших планах. Собираетесь ли вы (я правильно понимаю, что команда из двух человек) довести до production ready версий?
Используете ли Вы сами наработки в текущих проектах (вижу Диптаун, не могу понять, продолжается ли его разработка)?
Всегда пожалуйста :)
Да, над этим проектом мы работаем с Романом вдвоем. До продакшна еще очень далеко, но при наличии времени и желания, это возможно. Впрочем, основная цель этого проекта — исследовательская. А именно: понять, насколько далеко можно зайти в оптимизации динамического языка в его предельной инкарнации, и как много может «понять» виртуальная машина, просто наблюдая за выполнением кода. Программа максимум — добиться такого уровня специализации и инлайнинга, чтобы выполнение оптимизированного кода Smalltalk не уступало по производительности типизированным языкам. Принимая во внимание структуру Smalltalk, его гибкость и легкость «обработки напильником», мне кажется, это даже более вероятно, нежели оптимизация других динамических языков.
Можно сказать, что мы намеренно ограничили себя, выбрав Smalltalk. Ведь по сути, это окружение в котором виртуальной машине не известно ничего. Соответственно, если даже в такой враждебной среде удастся добиться заметных результатов, то это уже будет хорошо.
Нет, в диптауне этот код не используется, это совершенно отдельный проект. Впрочем, есть некоторые мысли, но боюсь, что они очень нескоро найдут свое воплощение (если вообще найдут).
Да, над этим проектом мы работаем с Романом вдвоем. До продакшна еще очень далеко, но при наличии времени и желания, это возможно. Впрочем, основная цель этого проекта — исследовательская. А именно: понять, насколько далеко можно зайти в оптимизации динамического языка в его предельной инкарнации, и как много может «понять» виртуальная машина, просто наблюдая за выполнением кода. Программа максимум — добиться такого уровня специализации и инлайнинга, чтобы выполнение оптимизированного кода Smalltalk не уступало по производительности типизированным языкам. Принимая во внимание структуру Smalltalk, его гибкость и легкость «обработки напильником», мне кажется, это даже более вероятно, нежели оптимизация других динамических языков.
Можно сказать, что мы намеренно ограничили себя, выбрав Smalltalk. Ведь по сути, это окружение в котором виртуальной машине не известно ничего. Соответственно, если даже в такой враждебной среде удастся добиться заметных результатов, то это уже будет хорошо.
Нет, в диптауне этот код не используется, это совершенно отдельный проект. Впрочем, есть некоторые мысли, но боюсь, что они очень нескоро найдут свое воплощение (если вообще найдут).
Вам уже говорили, что вы проделали невероятную работу. Я повторюсь: очень хочется, чтобы проект вышел за исследовательские рамки.
Это беда Смолтолка, что нет ни одной реализации, рассчитанной на современную индустрию. Cincom VisualWorks и IBM VisualAge не считаются — условия лицензирования/цены там для владельцев заводов, больших пароходов, да и инфраструктура расчитана именно на промышленное применение.
По поводу реализации виртуальной машины — я правильно понимаю, что трансляция в LLVM откроет доступ и к платформам Apple? У Pharo с этим так и не стало ясно.
QT (все ок с LLVM?) все еще планируется использовать для GUI? Не нашел намека в этой версии, на гитхабе лежит оригинальный образ lst, может быть есть черновая версия с GUI классами?
Вопросов много, вопросы глупые, но еще раз — продолжайте, пожалуйста!
Это беда Смолтолка, что нет ни одной реализации, рассчитанной на современную индустрию. Cincom VisualWorks и IBM VisualAge не считаются — условия лицензирования/цены там для владельцев заводов, больших пароходов, да и инфраструктура расчитана именно на промышленное применение.
По поводу реализации виртуальной машины — я правильно понимаю, что трансляция в LLVM откроет доступ и к платформам Apple? У Pharo с этим так и не стало ясно.
QT (все ок с LLVM?) все еще планируется использовать для GUI? Не нашел намека в этой версии, на гитхабе лежит оригинальный образ lst, может быть есть черновая версия с GUI классами?
Вопросов много, вопросы глупые, но еще раз — продолжайте, пожалуйста!
я правильно понимаю, что трансляция в LLVM откроет доступ и к платформам Apple?
Да, так и есть. Благодаря LLVM у нас открываются возможности для JIT компиляции под любую платформу, которую поддерживает LLVM, в том числе и под Apple.
QT все еще планируется использовать для GUI? Не нашел намека в этой версии, на гитхабе лежит оригинальный образ lst, может быть есть черновая версия с GUI классами?
Дима занимается очень интересной таской — Native API. Эта штука позволит пробрасывать C++ методы внутрь образа и вызывать их, как будто они написаны на Smalltalk. Как только у нас получится довести это до ума, мы сделаем обёртки для Qt и начнём рисовать GUI.
Задавайте вопросы, ответим с удовольствием)
Про Native API: почему бы не использовать libffi? Или я чего-то не понял?
Во-первых, как минимум libffi надо заинтерфейсить в образ. Это или делать нестандартными примитивами, огребая геморрой или пользоваться NativeAPI которая в корне исключает проблему номеров примитивов. Во-вторых, LLVM, сама будучи пользователем libffi, уже предоставляет подобные средства. Но пока на эту тему капитально еще не думали.
В NativeAPI нет ничего страшного и ужасного, она предельно проста и как раз призвана писать модули без необходимости реализации врапперов. Для подключения Qt потребуется только интерфейс метаклассов Qt, через который будет проброшено все управление.
В NativeAPI нет ничего страшного и ужасного, она предельно проста и как раз призвана писать модули без необходимости реализации врапперов. Для подключения Qt потребуется только интерфейс метаклассов Qt, через который будет проброшено все управление.
Понятно. Кстати, хотел спросить как раз про отсутствие номерных примитивов. Почему и какая в них проблема? Такие примитивы позволяют не сваливаться в интерпретатор вообще в ряде случаев.
У нас есть номерные примитивы. Смысл Native API — вызывать C++ метод по названию Smalltalk метода. Таким образом, вызовом 1 номерного примитива мы можем сделать всё то же самое, что и простынками примитивов вида:
Этим достигаются плюсы:
Что вы имели ввиду?
case 42 : obj->myCppMethod1(); break;
case 666 : obj->myCppMethod2(); break;
Этим достигаются плюсы:
- Не надо каждый раз перекомпилировать виртуальную машину
- Единая точка входа как из софтовой ВМ, так и из JIT кода
- Меньше примитивов — проще поддержка
Такие примитивы позволяют не сваливаться в интерпретатор вообще в ряде случаев.
Что вы имели ввиду?
Я имел ввиду, что скомпилированный метод содержит номер специального примитива, которым этот метод должен обрабатываться. Тогда метод, состоящий, например, только из ^self будет выполнен не прибегая к интерпретации байткода. Собственно, в скомпилированном методе и байткода-то тогда может не быть. Что-то типа ahead-of-time.
См. stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf, часть 4
См. stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf, часть 4
Это возможно лишь в том случае, если примитив написан дважды. Одна реализация для софтовой части, а еще одна — для JIT. Для критичных к производительности примитивов мы так и сделали, код примитива компилируется в LLVM IR, который компилируется прямиком в нативный код. Но вызов Qt методов нельзя назвать примитивом(сущностью виртуальной машины), и уж тем более нельзя назвать критичным к производительности.
Я еще раз повторюсь, чем меньше примитивов, тем проще поддержка. А за удобную реализацию Qt можно заплатить малейшей потерей производительности.
Я еще раз повторюсь, чем меньше примитивов, тем проще поддержка. А за удобную реализацию Qt можно заплатить малейшей потерей производительности.
Роман все правильно ответил, от себя еще добавлю пару моментов.
Во-первых, даже если наш проект не взлетит в плане продакшна, а это может случиться ибо за основу взят отнюдь не стандартный диалект Smalltalk, в котором тоже есть много своих проблем, все равно, те идеи, которые мы стараемся здесь реализовать, могут быть с успехом перенесены и на другие платформы. А это уже даст толчок к развитию. Little Smalltalk был выбран именно потому, что он небольшой. Один человек в состоянии держать в уме всю архитектуру виртуальной машины и всех модулей, что положительно сказывается на понимании взаимосвязей и возможностях оптимизации. Иначе, вместо исследовательской работы, мы зарылись бы в рутину совместимости и на этом, скорее всего, все бы и закончилось.
Во-вторых, не смотря на то, что сечйас под win32 код сразу собрать не получится, он является по большей части кросс-платформенным. Когда мы тестиировали версии, мы собирали и под FreeBSD, и под Raspberry PI, так что с переносимостью серьезных проблем пока не ожидается.
P.S.: Вот чего нам действительно не хватает сейчас, так это времени и людей. Очень много второстепенной работы, которую все равно надо делать, но желающих как всегда нет. Собственно, ради этого мы и переползли на гитхаб, в надежде найти сторонников в лице западной аудитории. Но для этого, как минимум, нужно перевести статьи на английский язык, что тоже дело небыстрое. Да и как показывает практика, этот проект интересует людей гораздо меньше, нежели «программы в 30 строк» и прочие игрушки.
Во-первых, даже если наш проект не взлетит в плане продакшна, а это может случиться ибо за основу взят отнюдь не стандартный диалект Smalltalk, в котором тоже есть много своих проблем, все равно, те идеи, которые мы стараемся здесь реализовать, могут быть с успехом перенесены и на другие платформы. А это уже даст толчок к развитию. Little Smalltalk был выбран именно потому, что он небольшой. Один человек в состоянии держать в уме всю архитектуру виртуальной машины и всех модулей, что положительно сказывается на понимании взаимосвязей и возможностях оптимизации. Иначе, вместо исследовательской работы, мы зарылись бы в рутину совместимости и на этом, скорее всего, все бы и закончилось.
Во-вторых, не смотря на то, что сечйас под win32 код сразу собрать не получится, он является по большей части кросс-платформенным. Когда мы тестиировали версии, мы собирали и под FreeBSD, и под Raspberry PI, так что с переносимостью серьезных проблем пока не ожидается.
P.S.: Вот чего нам действительно не хватает сейчас, так это времени и людей. Очень много второстепенной работы, которую все равно надо делать, но желающих как всегда нет. Собственно, ради этого мы и переползли на гитхаб, в надежде найти сторонников в лице западной аудитории. Но для этого, как минимум, нужно перевести статьи на английский язык, что тоже дело небыстрое. Да и как показывает практика, этот проект интересует людей гораздо меньше, нежели «программы в 30 строк» и прочие игрушки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Внутреннее устройство llst, часть 2 или Little Smalltalk + LLVM = ♥