неделю назад столкнулся с фундаментальным ограничением в JRuby (bottle-neck) при тюнинге производительтности - код поддержки coroutine based fibers оказывается выпилен из JRuby до лучших времён

https://github.com/jruby/jruby/wiki/PerformanceTuning#enable-coroutine-based-fibers

https://github.com/jruby/jruby/wiki/DifferencesBetweenMriAndJruby#continuations-and-fibers

https://github.com/jruby/jruby/wiki/PerformanceTuning#enabling-invokedynamic

https://github.com/jruby/jruby/wiki/JRubyCompiler
https://github.com/jruby/jruby/wiki/StaticCompiler
https://github.com/jruby/jruby/wiki/Testingjrubyinvokedynamic

причина - GC и байт-код JVM не заточены под сопрограммы
при том JRuby запускается в режиме JIT компиляции со включёной опцией invokedynamic
забавность в том что почву для реализации сопрограмм в MLVM для JVM подготовили уже давно, реализовав continuations, а уже на их основе можно кодить coroutines (сопрограммы)

http://openjdk.java.net/projects/mlvm/subprojects.html#StackContinuations

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6655643

http://openjdk.java.net/projects/mlvm/subprojects.html#InvokeDynamic

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655646

но внедряется это всё крайне медленно, а комьюнити стандарты JSR вырабатываются ещё дольше
такими темпами JVM просто добьют современные фичи, пришедшие из функционального программирования (динамическая типизация, лямбда функции, параметрический полиморфизм, сопрограммы, функции как объекты первого класса, замыкания, анонимные функции) и она загнётся за ненадобностью - разработчики просто уйдут на LLVM, уже уходят, Rust и Swift используют LLVM как оптимизирующий бэкэнд JIT-компилятор

и вот тут я крепко и глубоко задумался о причинах, почему с 2007-го года нет видимых подвижек в реализации continuations и соответственно сопрограмм в JVM
в JVM есть собственная реализация тредов, которая основана на модели акторов
а сопрограммы нужны для реализации парадигмы CSP (Communicating Sequential Processes), что и сделано в Go (goroutines) и его GC
но почему этого же нельзя сделать в стековой машине JVM и её GC, реализовать в байт-коде, для лучшей поддержки возможностей функциональных языков и компиляторов/интерпретаторов для JVM языков с динамической типизацией - это большой вопрос!
неделю, с 24 апреля по 1 мая, изучал проблему, читал литературу, смотрел видео курсы Coursera и всё таки нашёл ответ, докопался до истинной сути!
всё потому что машина стековая и её архитектура (stack-based dynamic memory allocation, управление динамической памятью основанное на использовании стековых структур данных) ограничивает высокоуровневые языки
при реализации сопрограмм проявляется архитектурная проблема функциональных аргументов (funarg, даже не знаю на сколько правильно это можно перевести на русский, информации в русскоязычной литературе об этой проблеме крайне мало) в языках, окружение (трансляторы) которых используют стек как структуру данных для управления памятью и стек вызова (call stack, call/cc) для сохранения контекста функций, вызываемых по цепочке при реализации сопрограмм на низком уровне

https://en.wikipedia.org/wiki/Funarg_problem

продолжение следует...

#funarg
#coroutines
#goroutines

В Java 9 Oracle готовится выпустить новый JIT компилятор для JVM на смену HotSpot - GraalVM
Заявлена поддержка всех возможностей Ruby (JRuby+Truffle) и JavaScript (Graal.JS, Node.js), и полная их интеграция со всей инфраструктурой JavaVM

http://openjdk.java.net/projects/graal/
http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html
https://github.com/jruby/jruby/wiki/Downloading-GraalVM
https://github.com/jruby/jruby/wiki/Building-Graal
https://wiki.openjdk.java.net/display/Graal/Instructions
https://github.com/jruby/jruby/wiki/Using-Graal-in-JDK-9-EA-Builds

https://github.com/jruby/jruby/wiki/Truffle
https://github.com/jruby/jruby/wiki/Truffle-FAQ
https://github.com/jruby/jruby/wiki/Developing-with-JRuby-Truffle
https://github.com/jruby/jruby/wiki/JRuby-and-Truffle-Interop
https://github.com/jruby/jruby/wiki/Truffle-Module

https://gist.github.com/smarr/d1f8f2101b5cc8e14e12

JLua+Truffle:
https://github.com/lucasallan/LuaTruffle
http://www.luatruffle.org

ZipPy - fast and lightweight Python 3 implementation built using the Truffle framework
https://bitbucket.org/ssllab/zippy
https://bitbucket.org/ssllab/zippy/wiki/Home

Последнее время много пишут про DL/ML (deep learning, machine learning)

Для машинного обучения есть фреймворки
Torch, Leaf, Theano и MXNet весьма круты! 👍

Google DeepMind использует Torch

https://en.wikipedia.org/wiki/Comparison_of_deep_learning_software

https://github.com/autumnai/leaf (Rust)
http://autumnai.com

https://github.com/dmlc/mxnet (multilanguage - JavaScript, Go, Python, Julia, R, Scala)
http://mxnet.readthedocs.io/en/latest/

https://github.com/torch/torch7 (Lua, LuaJIT)
http://torch.ch
https://en.wikipedia.org/wiki/Torch_(machine_learning)

Про него столько писали зарубежные СМИ, выдвигали спекулятивные предположения, что он автор BitСoin и вот наконец он сам в этом признался! И не просто признался, а доказал своё авторство криптографически!
http://www.drcraigwright.net/jean-paul-sartre-signing-significance/
http://gavinandresen.ninja/satoshi

Создатель идеи BitCoin - австралиец Craig Wright (http://www.drcraigwright.net/about/).
Сам протокол BitCoin и технология базы транзакций Blockchain была создана им в соавторстве с криптографом Hal Finney и другими инженерами.

Нужно полагать, что во многом такой шаг Крэйга направлен на популяризацию BitCoin, вывод его из тени финансового мира и повышение доверия к нему.

http://www.bbc.com/news/technology-36168863

Забавно, что это событие совпало с началом приёма Bitcoin в качестве электронной криптовалюты для оплаты игр в Steam.

Интересен факт, каким количеством биткойнов владеет сам Крэйг Райт, ведь он был вовлечён в процесс формирования блокчейна и майнинга с самого начала его существования и сгенерировал первую транзакцию из 10-ти биткойнов, которая сформировала начальный генезис-блок в базе блокчейн.

https://telegram.me/g33ks/161

Однозначно же в этой истории можно сделать только один вывод: анонимности нет, и Сатоши Накамото тому - последнее прямое цифровое подтверждение.

длительная анонимность возможна
анонимность можно сохранять до тех пор и так долго пока сам не решишь раскрыться или сам не совершишь ошибку с утечкой данных, через контрагентов, посредников например

однако, даже TOR уже не последняя фантазия для сокрытия - кто контролирует выходные шлюзы, тот контролирует содержимое трафика, а кто контролирует входные шлюзы, тот контролирует адреса источников трафика
end-to-end шифрование (ассиметричные шифры) также не всегда решают проблему сокрытия данных
для сокрытия адреса источника трафика со времён трассировки Шимомуры-Митника было придумано много весьма изощрённых методик, обфускации, стеганографии и т.п.

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

http://www.infowatch.ru
http://infowatch.livejournal.com
http://forensics.ru
http://forensics.ru/InFuWo.htm
http://geektimes.ru/post/136816/
http://bezopasnik.org/article/book/95_0.pdf

чем меньше вы следов оставляете и информации испускаете в сети - тем сложнее её связать для установления фактов

поэтому, если бы Крэйг Райт сам не раскрылся и не предоставил доказательства авторства, то это оставило бы пространство для догадок и тайна Сатоши осталась бы тайной

почему в Java и в реализациях окружений (трансляторов) языков под JVM (Scala, Kotlin, Groovy, JRuby, Jython), в C и в C++, нет нативной поддержки сопрограмм (coroutines) до сих пор?

я был в поиске ответа на этот вопрос из-за ограничений производительности coroutine based fibers и в целом сопрограмм в JRuby под JVM, т.к. в JRuby код поддержки сопрограмм был выпилен, потому что на уровне байт-кода JVM нет их нативной реализации и поддержки, а текущая реализация fibers в JRuby основана на green и native тредах JVM

до сих пор реализация тредов (от Java до Rust) была единственным мэйнстрим решением параллелизма основанного на модели акторов, но не на её более развитой модели CSP (Communicating Sequential Processes), на которой основан Go и которая сама является развитием идеи акторов, и базируется на парадигме сопрограмм

после долгих поисков в литературе и лекций Coursera я наконец таки нашёл ответ

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

https://en.wikipedia.org/wiki/Funarg_problem

если более подробно:
во всём виноват аппаратный (процессорный) и программный стэк (в кэше и динамической памяти), т.к. в отличии от деревьев (структур данных), стэк это одна из самых неэффективных структур данных для хранения аргументов (call stack) при множественном объединённом (chained) вызове функций по цепочке, что на самом деле и происходит на низком уровне при реализации сопрограмм

в свою очередь большинство виртуальных машин и их JIT компиляторов реализованы именно как стековые машины и основаны на использовании стэка и стэковых структур данных (cactus stack) для компиляции программы в байт-код, а самого байт-кода в машинный код и трансляции специальных инструкций байт-кода в вызовы виртуальной машины (invokedynamic, invokestatic, invokevirtual, etc.), потому что стэк, особенно аппаратный, это самая быстрая структура данных по производительности операций с ней
JVM и MLVM (Da Vinci Machine) это стековые виртуальные машины, не регистровые, как например LLVM, Parrot, Dalvik, ART, LuaJIT, V8, которые активно используют быстрые регистровые операции, хранение структур данных в кэше процессора и в динамической памяти, динамическое управление памятью на основе кучи, деревья (кучи, heap) для хранения контекста, окружения (scopes, closures, cactus stack) и аргументов вызова функций

https://en.wikipedia.org/wiki/Comparison_of_application_virtualization_software

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

продолжение следует...

#funarg
#coroutines
#goroutines

Быстрое руководство в виде code-snippets по языку Solidity для создания смарт-контрактов под EthereumVM в сети криптовалюты Ethereum

https://github.com/adambard/learnxinyminutes-docs/blob/master/solidity.html.markdown

Друзья, внимательней с мессенджером Телеграм, используйте номер и сим-карты операторов стран с независимой юрисдикцией для привязки к аккаунту, обязательно используйте двухфакторную авторизацию (cloud password в клиентах) и секретные чат-комнаты с end-to-end шифрованием, проверяйте сессии других устройств в клиентах - безопасность должна быть безопасной! Think securely - keep safety!

Уведомления о новых авторизациях и новых сессиях на других устройствах приходят массовой рассылкой во все активные сессии клиентов от сервиса нотификаций Telegram: +42777

https://geektimes.ru/post/275204/

https://telegram.org/blog/sessions-and-2-step-verification

А был ли Сатоши?

https://www.nikcub.com/posts/craig-wright-is-not-satoshi-nakamoto/

Зачем вообще Крэйгу Райту нужно было что-то доказывать, своё авторство биткойн и блокчейн, если сеть Интернет и люди в ней так полны скептицизма и всё равно большинство не поверит!?

К этому он не был готов, для борьбы нужно много моральных сил, легче сдаться ничего не доказывая.

Вряд ли конечно объявится другой Сатоши и сможет доказать своё авторство.

Спектакль окончен!

http://drcraigwright.net/homepage.jpg

протюнинговали с ребятами различные стэки технологий и потестили фреймворки...
поюзали munin для мониторинга - не понравилось, nagios и ganglia лучше и сохранили свой приоритет в выборе
выбираем подходящий стек для реализации очередного микросервисного high-load проекта, расчётные нагрузки от 250K RPS по обработке json (сериализация/десериализация данных) запросов к api
результаты на лицо
производительность серверов приложений uwsgi и tornado оставляет желать лучшего, фреймворки flask, web2py и даже twisted - также низкопроизводительны
сервер приложений gunicorn и фреймворк meinheld идут с сильным отрывом
связка nginx-gunicorn-meinheld по прежнему самая производительная для Python
vert.x ещё более производителен, но это уже Java NIO2 фреймворк с binding'ом для Python
falcon и после него чуть ниже по производительности bottle - самые нормальные wsgi фреймворки по соотношению производительность+overhead/удобство+скорость разработки
pypy и jit не всегда дают ожидаемый прирост производительности, чаще обычный cpython3 оказывается производительнее, что удивительно
про django вообще молчу, это тихий ужас, по архитектуре и производительности - генерирует слишком много малопонятных объектных boilerplate'ов, как Java фреймворки, и как JVM имеет значительный overhead по памяти, масштабируется плохо, при росте нагрузок нужно больше железа, процесс обработки (обработчиков-воркеров) просто тупо встаёт намертво и зависает, потому что django фреймворк синхронный (и это огромный минус в современных условиях, сравнимо как apache vs nginx), реализующий архитектурный паттерн MVP, работа с БД медленна, ORM имеет не очень удачную и продуманную реализацию и лучше его вообще не использовать

так что тесты фреймворков от techempower (http://www.techempower.com/benchmarks/) весьма правдивы! 👍 проверено собственными руками на собственной шкуре и в проектах

пока это будет лишь прототип проекта, имеющего микросервисную архитектуру и возможно позже этот прототип будет переписываться на Go при росте нагрузок
потом посмотрим
в зависимости от того какие нагрузки пойдут и как сервис будет держать нагрузку
но, есть несколько очень тонких и важных моментов...
для реализации данного проекта Python больше подходит, динамическая типизация всё таки рулит в некоторых задачах и алгоритмах, и многое упрощает, например рефакторинг, последующую модификацию, развитие, наращивание или наоборот сокращение функционала, его композицию в монолитную архитектуру или декомпозицию, разбивку на микросервисы

Python и Ruby замечательные языки, как две ипостаси, они мне оба очень нравятся, даже не знаю какой из них больше, в них есть много полезных, интересных и удобных фич для программирования, которые пока реализованы только в их интерпретаторах
это и сопрограммы, и динамическая типизация, и параметрический полиморфизм, и метаклассы, и т.д.
https://en.wikipedia.org/wiki/First-class_citizen#Examples
очень жаль что эти реализации интерпретаторов так неэффективны и до сих пор нет толковой реализации окружения этих языков, языковой среды, транслятора (именно компилятора), использующего возможности регистровой машины LLVM
из этого вытекает огромная неэффективность, неэкономичность, энергонеэффективность, необходимость масштабирования бОльшими экономическими затратами на хостинг, бОльшими ресурсами железа, бОльшими расходами энергии, электричества для поддержания работы серверов, сервисов
для перехода на Go очень вдохновила статья Трэвиса Ридера в блоге Iron.io:
https://www.iron.io/how-we-went-from-30-servers-to-2-go/
применяя Go это замечаешь всё больше, более остро, что всё остальное это костыли программирования, неэффективные и слишком энергозатратные
особенно это заметно в сфере криптовалют, где proof-of-work это главный принцип вычислительной сети
ещё очень жаль что производительность реализаций Ruby, MRI/YARV, JRuby, стала проседать сильно с введением в них поддержки версии 2.0 языка Ruby и его возможностей, как относительно реализаций версий 1.9 языка, так и относительно даже реализаций Python 3
Python минималистичен и этим привлекателен, Go ещё более минималистичен
хотя Ruby имеет более широкие языковые возможности (языка и стандартной библиотеки) при этом сохраняя минимализм языка, лаконичность архитектуры и реализации, как самого языка так и его окружения, языковой среды, трансляторов
огромное преимущество это объектная природа всех элементов, классов и типов языка и возможность их модификации, перегрузки, ad-hoc полиморфизма - это и есть реализация парадигмы First-class citizen, которую Ruby подчерпнул из Smalltalk
в программировании это называется интроспекцией типов и более обобщённо рефлексией и метапрограммированием, first-class object
в Python и Go такие возможности тоже есть, но они позволяют модифицировать не абсолютно все возможности языка, как в Ruby, в котором любой элемент, класс, объект и тип можно переопределить или вообще создать с помощью наследования свои типы, операторы, синтаксис, DSL для определённых задач

кстати, в Go есть динамическая идентификация (RTTI) и вывод типов (type inference) в runtime через reflect.TypeOf
https://golang.org/pkg/reflect/#TypeOf
это и есть один из аспектов реализации рефлексии (first-class object) и интроспекции типов в Go для динамического вывода, идентификации и определения типов данных

Уважаемые подписчики,
поздравляем Вас с Днём Победы!
Мирного неба всем над головой!
Помним, гордимся и чтим!

Сегодня символу Linux исполнилось 20 лет.

9 мая 1996 года официальным талисманом Linux стал пингвин Tux.

https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/Tux_Enhanced.svg/1000px-Tux_Enhanced.svg.png

https://en.wikipedia.org/wiki/Tux