Почти год назад я писал, что в Oracle делают новую GraalVM для замены HotSpotVM, а также статический AoT компилятор и минималистичный runtime Truffle для JRuby [1][2][3][4], которые должны были выйти этой весной в релизе Java 9, но сейчас выделились в отдельные самостоятельные проекты TruffleRuby и GraalVM.
Тогда же ходили слухи о "top-secret" JIT компиляторе Ruby, который будет очень хорошо совместимым с CRuby и проект которого поддержал сам benevolent dictator Юкихиро Матсумото.
И вот недавно в феврале об этом проекте было объявлено в докладе на конференции FOSDEM-2017. [1][2]
https://developer.ibm.com/open/2017/03/01/ruby-omr-jit-compiler-whats-next/
https://github.com/rubyomr-preview/ruby
https://github.com/eclipse/omr - http://www.eclipse.org/omr/
Репозиторий проекта Ruby+OMR открыт год назад, но активная контрибуция началась осенью 2016 года - проект очень молодой. [1]
При этом код проекта OMR также открыт уже почти год, но более широкую известность получил только сейчас. [1]
IBM уже давно на основе OMR технологии от Eclipse делает common language run-time для своей проприетарной виртуальной Java машины - IBM J9 Virtual Machine.
Суть проекта Eclipse OMR.
Ребята из фонда Eclipse и IBM делают компонентный (back-end JIT compiler + GC + runtime thread mapping and management) compiler toolkit для байт кода динамических языков, который назвали OMR, и уже опубликовали код JIT компилятора Ruby+OMR для эталонной реализации CRuby (MRI/YARV). Также в скором времени обещают открыть код уже существующего компилятора Python+OMR для эталонной реализации CPython.
Мне нравится такой подход, когда фронтэнд компилятором порождающим байт-код является эталонная реализация языка, что улучшает совместимость программ, а в бэкэнд работает JIT компилятор, динамически компилирующий байт-код в машиный код вместо простой его интерпретации и ускоряет таким образом исполнение байт-кода.
Но это только в теории.
При практической реализации, к сожалению я уже не верю и не питаю иллюзий к попыткам перенести динамическое определение типов и RTTI из run-time обратно в статический код и в compile-time - это возможно для динамического вывода типов (type inference) в compile-time и обобщённых типов (generics), для которых нужен минималистичный run-time и zero-cost abstractions в языке (типа реализации трейтов в Rust), но не тогда когда всё определение типов происходит в run-time, как в Ruby и Python.
Это хорошо иллюстрирует провал DropBox с компилятором Pyston [1][2][3][4], и проблемы в проекте JRuby с invoke-dynamic (которые уже решены, но к реактивному ускорению исполнения это не привело) и с поддержкой CSP многопоточности (класс Fibers, они же green threads, сопрограммы). [1][2][3][4] А многопоточность и распределённые вычисления сейчас в тренде и получают всё более широкое распространение.[1][2]
Тогда же ходили слухи о "top-secret" JIT компиляторе Ruby, который будет очень хорошо совместимым с CRuby и проект которого поддержал сам benevolent dictator Юкихиро Матсумото.
И вот недавно в феврале об этом проекте было объявлено в докладе на конференции FOSDEM-2017. [1][2]
https://developer.ibm.com/open/2017/03/01/ruby-omr-jit-compiler-whats-next/
https://github.com/rubyomr-preview/ruby
https://github.com/eclipse/omr - http://www.eclipse.org/omr/
Репозиторий проекта Ruby+OMR открыт год назад, но активная контрибуция началась осенью 2016 года - проект очень молодой. [1]
При этом код проекта OMR также открыт уже почти год, но более широкую известность получил только сейчас. [1]
IBM уже давно на основе OMR технологии от Eclipse делает common language run-time для своей проприетарной виртуальной Java машины - IBM J9 Virtual Machine.
Суть проекта Eclipse OMR.
Ребята из фонда Eclipse и IBM делают компонентный (back-end JIT compiler + GC + runtime thread mapping and management) compiler toolkit для байт кода динамических языков, который назвали OMR, и уже опубликовали код JIT компилятора Ruby+OMR для эталонной реализации CRuby (MRI/YARV). Также в скором времени обещают открыть код уже существующего компилятора Python+OMR для эталонной реализации CPython.
Мне нравится такой подход, когда фронтэнд компилятором порождающим байт-код является эталонная реализация языка, что улучшает совместимость программ, а в бэкэнд работает JIT компилятор, динамически компилирующий байт-код в машиный код вместо простой его интерпретации и ускоряет таким образом исполнение байт-кода.
Но это только в теории.
При практической реализации, к сожалению я уже не верю и не питаю иллюзий к попыткам перенести динамическое определение типов и RTTI из run-time обратно в статический код и в compile-time - это возможно для динамического вывода типов (type inference) в compile-time и обобщённых типов (generics), для которых нужен минималистичный run-time и zero-cost abstractions в языке (типа реализации трейтов в Rust), но не тогда когда всё определение типов происходит в run-time, как в Ruby и Python.
Это хорошо иллюстрирует провал DropBox с компилятором Pyston [1][2][3][4], и проблемы в проекте JRuby с invoke-dynamic (которые уже решены, но к реактивному ускорению исполнения это не привело) и с поддержкой CSP многопоточности (класс Fibers, они же green threads, сопрограммы). [1][2][3][4] А многопоточность и распределённые вычисления сейчас в тренде и получают всё более широкое распространение.[1][2]
Telegram
Technologique
В Java 9 Oracle готовится выпустить новый JIT компилятор для JVM на смену HotSpot - GraalVM
Заявлена поддержка всех возможностей Ruby (JRuby+Truffle) и JavaScript (Graal.JS, Node.js), и полная их интеграция со всей инфраструктурой JavaVM
http://openjdk.…
Заявлена поддержка всех возможностей Ruby (JRuby+Truffle) и JavaScript (Graal.JS, Node.js), и полная их интеграция со всей инфраструктурой JavaVM
http://openjdk.…
Но есть надежда, что проект OMR стандартизирует свою run-time компонентную архитектуру тулкита и создаст вокруг неё экосистему, чтобы разработчики будущих машинных архитектур её учитывали при аппаратном дизайне и изначально закладывали поддержку run-time для высокоуровневых языков в фундамент машинной аппаратной архитектуры. Возможно имеено этот проект исправит ситуацию с текущими машинными архитектурами, которые ограничивают высокоуровневые конструкции языка (как например поддержку сопрограмм, динамического определения типов, использование комплексных структур данных, типа деревьев и графов).
Вспоминаютя слова о "программно-аппаратном симбиозе и конвергенции" Джона МакКарти, автора языка Lisp в 1958 году, первый компилятор для которого был создан только спустя два года, в 1960 году, после создания самого языка, из-за ограничений концепций и конструкций языка со стороны машинных архитектур того времени. Позже в 1970-х по этим причинам были созданы даже Lisp машины с аппаратной поддержкой Lisp на уровне наборов команд процессора.
Поддержка же концепций функционального программирования со стороны аппаратных архитектур по прежнему очень слабая, что порождает избыточность на выходе компилятора и очень сильно замедляет скорость исполнения конечных программ. Сравните скомпилированные программы на Си и C++ по скорости исполнения с программами на Common LISP, Scheme, Racket, Clojure, Standard ML, OCaml, F#, Miranda, Haskell - замедление по скорости для языков функционального программирования будут от 10 до 50 раз! [1] Всё из-за избыточности и соответственно неэффективности конечного кода, генерируемого компиляторами этих языков ФП.
Также Никлаус Вирт при разработке программно-аппаратной архитектуры Lilith и языка Oberon говорил о них, что "машинная архитектура должна учитывать высокоуровненвые возможности языка, чтобы сделать их возможными и максимально быстрыми по исполнению" - ведь это и есть настоящая full-stack разработка, программно-аппаратная! =)
The long term goal for the Eclipse OMR project is to foster an open ecosystem of language runtime developers to collaborate and collectively innovate with hardware platform designers, operating system developers, as well as tool and framework developers and to provide a robust runtime technology platform so that language implementers can much more quickly and easily create more fully featured languages to enrich the options available to programmers.
Вспоминаютя слова о "программно-аппаратном симбиозе и конвергенции" Джона МакКарти, автора языка Lisp в 1958 году, первый компилятор для которого был создан только спустя два года, в 1960 году, после создания самого языка, из-за ограничений концепций и конструкций языка со стороны машинных архитектур того времени. Позже в 1970-х по этим причинам были созданы даже Lisp машины с аппаратной поддержкой Lisp на уровне наборов команд процессора.
Поддержка же концепций функционального программирования со стороны аппаратных архитектур по прежнему очень слабая, что порождает избыточность на выходе компилятора и очень сильно замедляет скорость исполнения конечных программ. Сравните скомпилированные программы на Си и C++ по скорости исполнения с программами на Common LISP, Scheme, Racket, Clojure, Standard ML, OCaml, F#, Miranda, Haskell - замедление по скорости для языков функционального программирования будут от 10 до 50 раз! [1] Всё из-за избыточности и соответственно неэффективности конечного кода, генерируемого компиляторами этих языков ФП.
Также Никлаус Вирт при разработке программно-аппаратной архитектуры Lilith и языка Oberon говорил о них, что "машинная архитектура должна учитывать высокоуровненвые возможности языка, чтобы сделать их возможными и максимально быстрыми по исполнению" - ведь это и есть настоящая full-stack разработка, программно-аппаратная! =)
Весьма интересная статья о корнях языка D, о том, как он создавался и как встретились два его автора, Уолтер Брайт и Андрей Александреску - за кружкой пива в баре в Сиэттле. =)
Уолтер Брайт к тому моменту уже имел огромный бэкграунд в создании компиляторов C и C++ в Symantec и в созданной им компании Digital Mars.
Андрей Александреску был простым студентом, разрабатывющим свой язык программирования. =)
https://www.wired.com/2014/07/d-programming-language/
Сейчас D используется в бэкэнде Facebook. Более того Андрей Александреску работал над HHVM [1], а Уолтер Брайт разработал новый препроцессор Warp для Си и C++, написанный на D, для использования его в разработках Facebook - https://code.facebook.com/posts/476987592402291/under-the-hood-warp-a-fast-c-and-c-preprocessor/
Недавнее весьма интересное интервью с Уолтером Брайтом:
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
Links:
https://github.com/WalterBright
https://twitter.com/WalterBright
http://walterbright.com
Уолтер Брайт к тому моменту уже имел огромный бэкграунд в создании компиляторов C и C++ в Symantec и в созданной им компании Digital Mars.
Андрей Александреску был простым студентом, разрабатывющим свой язык программирования. =)
https://www.wired.com/2014/07/d-programming-language/
Сейчас D используется в бэкэнде Facebook. Более того Андрей Александреску работал над HHVM [1], а Уолтер Брайт разработал новый препроцессор Warp для Си и C++, написанный на D, для использования его в разработках Facebook - https://code.facebook.com/posts/476987592402291/under-the-hood-warp-a-fast-c-and-c-preprocessor/
Недавнее весьма интересное интервью с Уолтером Брайтом:
https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
Links:
https://github.com/WalterBright
https://twitter.com/WalterBright
http://walterbright.com
WIRED
The Next Big Programming Language You've Never Heard Of
Andrei Alexandrescu didn’t stand much of a chance. And neither did Walter Bright. When the two men met for beers at a Seattle bar in 2005, each was in the midst of building a new programming language, trying to remake the way the world creates and runs its…
Молекула ДНК в качестве носителя информации известна давно. =)
Но впервые в молекулу ДНК в виде последовательности аминокислот был закодирован и записан дистрибутив KolibriOS!
https://nplus1.ru/news/2017/03/03/dnaflashdrive
Но впервые в молекулу ДНК в виде последовательности аминокислот был закодирован и записан дистрибутив KolibriOS!
В результате применения нового метода — фонтанного кода, модифицированного авторами для работы с ДНК, — ученым удалось экспериментально закодировать и прочитать 2,14 мегабайт информации в виде ДНК-олигонуклеотидов. В них уместилась подарочная карта Amazon, операционная система KolibriOS, статья Шеннона о передаче информации в зашумленном канале, видеофайл «Прибытия поезда» братьев Люмьер и даже один компьютерный вирус. Итоговая физическая плотность записи — ее измеряли в эксперименте с постепенным «гомеопатическим» разбавлением ДНК — составила 215 петабайт (215 000 000 гигабайт) на грамм нуклеиновой кислоты.
https://nplus1.ru/news/2017/03/03/dnaflashdrive
N + 1 — главное издание о науке, технике и технологиях
В ДНК записали «Прибытие поезда» и операционную систему KolibriOS
Technologique
Почти год назад я писал, что в Oracle делают новую GraalVM для замены HotSpotVM, а также статический AoT компилятор и минималистичный runtime Truffle для JRuby [1][2][3][4], которые должны были выйти этой весной в релизе Java 9, но сейчас выделились в отдельные…
Вчера я писал про проект Ruby+OMR и что не вижу особого смысла переделывать существующие Ruby и Python для ускорения исполнения выдаваемого их интерпретаторами кода - они и так сами по себе как языки достаточно хороши, а попытки как-то встроить динамические типы в comile-time и в статический код заранее обречены на провал, т.к. это фундаментальные ограничения самой концепции динамических типов и связывания.
Но в плане эффективности и скорости исполнения конечного кода я бы всё же сделал ставку на язык и комилятор Crystal - cинтаксис как у Ruby, но это native code compiler!
https://crystal-lang.org
https://github.com/crystal-lang/crystal
https://github.com/kemalcr/kemal - минималистичный веб-фреймворк, построенный поверх (wrapper, "on-top of") функций работы с протоколом http в stdlib Crystal
Для тех кому интересна многопоточность - всё о языке Crystal одной страницей документации! =)
https://crystal-lang.org/docs/guides/concurrency.html
Многопоточность на базе модели CSP - сопрограмм и каналов для синхронной передачи сообщений.
Это почти тот же Ruby c классом Fibers, но статически типизируемый и статически компилируемый, пока однопоточный, с поддержкой асинхронности (event loop), но без GIL, т.к. нет интерпретации и контроля исполнения со стороны интерпретатора байт-кода, и с наличием GC, который управляет памятью, потоками (fribers == green threads) и в ближайшем будущем сможет мапить их по M:N модели на системные треды.
Это всё же лучше чем TruffleRuby, Ruby+OMR, Rubinius или JRuby, которые всё равно ресурсоёмкие, медленные и к тому же очень прожорливые по памяти.
Бенчмарки это только подтверждают:
https://github.com/kostya/benchmarks
Это внушает оптимизм на счёт будущего языка Crystal - проект ещё очень молодой, был начат в 2011-м, на GitHub c 2013-го. Самое время поддержать проект контрибуцией или материально - https://salt.bountysource.com/teams/crystal-lang
Для тех, кому больше близок Python и Delphi я бы порекомендовал посмотреть проект уже довольно зрелого языка Nim:
https://nim-lang.org
Из преимуществ Nim - приятный синтаксис, автоматическое управление пямятью (GC), CSP и actor-based модели работы с многопоточностью, транс-компиляция в оптимизированный Си код (а также в C++, Objective-C, JavaScript, на выбор), лёгкий FFI с Си кодом, возможность использования нескольких бэкэнд-компиляторов (GCC, LLVM, CLang) для компиляции Си кода.
Оба языка, и Crystal, и Nim, пока ещё только на пути к своей первой версии, поэтому пока нет стабилизации кодовой базы и синтаксиса, но есть прекрасная возвожность внести в них свой вклад контрибуцией в эти проекты!
Links:
https://t.me/technologique/787
https://t.me/technologique/788
Но в плане эффективности и скорости исполнения конечного кода я бы всё же сделал ставку на язык и комилятор Crystal - cинтаксис как у Ruby, но это native code compiler!
https://crystal-lang.org
https://github.com/crystal-lang/crystal
https://github.com/kemalcr/kemal - минималистичный веб-фреймворк, построенный поверх (wrapper, "on-top of") функций работы с протоколом http в stdlib Crystal
Для тех кому интересна многопоточность - всё о языке Crystal одной страницей документации! =)
https://crystal-lang.org/docs/guides/concurrency.html
Многопоточность на базе модели CSP - сопрограмм и каналов для синхронной передачи сообщений.
Это почти тот же Ruby c классом Fibers, но статически типизируемый и статически компилируемый, пока однопоточный, с поддержкой асинхронности (event loop), но без GIL, т.к. нет интерпретации и контроля исполнения со стороны интерпретатора байт-кода, и с наличием GC, который управляет памятью, потоками (fribers == green threads) и в ближайшем будущем сможет мапить их по M:N модели на системные треды.
Это всё же лучше чем TruffleRuby, Ruby+OMR, Rubinius или JRuby, которые всё равно ресурсоёмкие, медленные и к тому же очень прожорливые по памяти.
Бенчмарки это только подтверждают:
https://github.com/kostya/benchmarks
Это внушает оптимизм на счёт будущего языка Crystal - проект ещё очень молодой, был начат в 2011-м, на GitHub c 2013-го. Самое время поддержать проект контрибуцией или материально - https://salt.bountysource.com/teams/crystal-lang
Для тех, кому больше близок Python и Delphi я бы порекомендовал посмотреть проект уже довольно зрелого языка Nim:
https://nim-lang.org
Из преимуществ Nim - приятный синтаксис, автоматическое управление пямятью (GC), CSP и actor-based модели работы с многопоточностью, транс-компиляция в оптимизированный Си код (а также в C++, Objective-C, JavaScript, на выбор), лёгкий FFI с Си кодом, возможность использования нескольких бэкэнд-компиляторов (GCC, LLVM, CLang) для компиляции Си кода.
Оба языка, и Crystal, и Nim, пока ещё только на пути к своей первой версии, поэтому пока нет стабилизации кодовой базы и синтаксиса, но есть прекрасная возвожность внести в них свой вклад контрибуцией в эти проекты!
Links:
https://t.me/technologique/787
https://t.me/technologique/788
The Crystal Programming Language
Crystal is a general-purpose, object-oriented programming language. With syntax inspired by Ruby, it’s a compiled language with static type-checking. Types are resolved by an advanced type inference algorithm.
Для тех кто ещё верит в святость Microsoft и не читает лицензионные соглашения EULA и соглашения о приватности клиентской информации.
https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_English.htm
https://privacy.microsoft.com/en-us/privacystatement
SwiftKey (приложение виртуальной клавитуры для сенорного ввода):
Это единственное, что позитивно, но я слабо в это верю - для ввода чувствительных данных нужно переключаться на другое приложение клавитуры предварительно органичив ему доступ в сеть в системных настройках или через системное firewall приложение с root доступом.
И добивающий пункт:
We share data we collect with third parties
Перевод на русский язык:
https://privacy.microsoft.com/ru-ru/privacystatement
И там ещё очень много подобного!
Советую внимательно прочитать и насладиться всем лицемерием Microsoft в отношении пользователей и потребителей.
https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_English.htm
By accepting this agreement and using the software you agree that Microsoft may collect, use, and disclose the information as described in the Microsoft Privacy Statement (aka.ms/privacy)
https://privacy.microsoft.com/en-us/privacystatement
- We collect your first and last name, email address, postal address, phone number, and other similar contact data.
- We collect passwords, password hints, and similar security information used for authentication and account access.
- Demographic data. We collect data about you such as your age, gender, country, and preferred language.
- We collect data about the features you use, the items you purchase, and the web pages you visit.
- We collect data about your interests and favorites,
- We collect data about your location, which can be either precise or imprecise.
- We collect data about your device and the network you use to connect to our products. It includes data about the operating systems and other software installed on your device, including product keys. It also includes IP address, device identifiers (such as the IMEI number for phones), regional and language settings.
- The BitLocker recovery key for your personal device is automatically backed up online in your personal Microsoft OneDrive account.SwiftKey (приложение виртуальной клавитуры для сенорного ввода):
Where a field has been flagged by a website or app as denoting a password field or payment data, SwiftKey does not log, store, or learn from this data.
Это единственное, что позитивно, но я слабо в это верю - для ввода чувствительных данных нужно переключаться на другое приложение клавитуры предварительно органичив ему доступ в сеть в системных настройках или через системное firewall приложение с root доступом.
И добивающий пункт:
We share data we collect with third parties
such as AOL and AppNexus so that they can select and deliver some of the ads you see on our sites and appsПеревод на русский язык:
https://privacy.microsoft.com/ru-ru/privacystatement
И там ещё очень много подобного!
Советую внимательно прочитать и насладиться всем лицемерием Microsoft в отношении пользователей и потребителей.
О дикой удалённой работе и жизни 😭😆😂
#ЗапискиУдалёнщика
#NotesOfOutsourcer
#Ремесло
#Handicraft
#Passengers
#BigLebowski
#ЗапискиУдалёнщика
#NotesOfOutsourcer
#Ремесло
#Handicraft
#Passengers
#BigLebowski
Все спят, а ты бродишь по ночи, потому что ты #удалёнщик в другой тайм-зоне =)