Если какой-либо программе необходимо передать данные эрланговсому серверу, эти данные предварительно должны быть сериализованы. То есть преобразованы в бинарный вид, так, чтобы эрланг мог потом распаковать их обратно. Обычно это делают с помощью ASN.1, google protobuf, thrift и т.д. Все это без сомнения достойные продукты.

В качестве альтернативного варианта можно рассмотреть использование эрланговского external term format. В исполняемой системе эрланга есть две функции - term_to_binary() и binary_to_term(), которые эффективно и быстро могут запаковать/распаковать любые значения в этот формат, а сам формат хорошо описан в документации — www.erlang.org/doc/apps/erts/erl_ext_dist.html

Как это все работает.

На рынок NoSQL подтягиваются большие игроки. На сайте Oracle Corp. появилось описание нового продукта — Oracle NoSQL database. Пока документации нет, самого сервера (по крайней мере community edition) нет, но должно появиться «к середине октября».

Но по тому, что уже выложено, можно составить определенное впечатление:

В некоторых случаях бывает удобно скомпилировать определенные части программы во время работы приложения. Например, в мире явы так происходит компиляция веб сервером .jsp страниц в сервлеты. Другими возможными применениями подобной техники являются разные языки шаблонов, регулярные выражения и т.д.

В эрланге транслятор встроен в библиотеку времени исполнения, и позволяет полностью управлять всеми стадиями трансляции.

Как это сделать

В экспериментальной версии (5.6.2) Oracle mysql появился плагин, позволяющий обращаться к innodb или ndb (mysql cluster) данным через memcached интерфейс. Оставляя возможность доступа к тем же данным через sql интерфейс.

Описание здесь:
Сообщение Оракла
http://blogs.innodb.com/wp/2011/04/nosql-to-innodb-with-memcached/

Код:
http://labs.mysql.com/

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

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

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

Как это делается?

В серии статей от tyomitch «Компиляция» (тут, тут, тут, тут, тут и здесь) было рассмотрено построение транслятора игрушечного языка jsk, описанного в 4 части.
В качестве back-end для этого транслятора tyomitch предложил реализацию байт-кода и интерпретатор этого байт-кода.

На мой взгляд, более разумным подходом было бы использование существующих решений для backend, например llvm, и следуя принципу «Критика без конкретных предложений — критиканство», я предлагаю вариант реализации этого маленького языка jsk с llvm.

Что это даст для jsk? Настоящую компиляцию, то есть результатом будет исполняемый файл, который не зависит ни от каких runtime, возможность серьезной оптимизации, профилирования кода и автоматически получим документацию по back-end (что облегчит сопровождение).

Эта статья является продолжением статей:
Простой тест libjit vs llvm
Простой тест llvm/libjit часть II, те же + gnu lightning .

Вступительный реверанс

В предыдущих статьях рссматривалась производительность llvm, libjit и gnu lightning на примере решета эратосфена. Все из рассмотренных вариантов — низкоуровневые библиотеки, которые имеют хорошую скорострельность, но по существу являются специализированными ассемблерами, и, например, работу со строками придется реализовывать самому.

Есть и другие виртуальные машины, которые можно включить в свою программу в качестве backend для своих DSL. Например — родившийся в результате первоапрельской шутки — parrot — основа будущего перла.

Там возможностей — намного больше, включая строки, хэш-таблицы, безразмерные массивы, garbage collection, консольный и файловый ввод-вывод и другие приятные вещи. Вопрос — какова цена (в потере производительности) за все эти приятные добавления?

Давайте попробуем.

Эта статья является продолжением Простой тест libjit vs llvm, где сравнивалось быстродействие библиотек для Just In Time компиляции llvm и libjit на примере задачи решета эратосфена.

В этой статье решается точно та же задача — решето эратосфена при помощи еще одной JIT библиотеки — GNU lightning .

«И опыт, сын ошибок трудных» (с) Сами знаете кто

С самого детства меня интересовали вопросы типа "кто победит — слон или кит". Или, например, "кто сильнее — тигр или лев". Теперь, когда я стал взрослым, вопросы немного изменились. Теперь меня интересует в частности — что круче libjit или llvm.

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

Итак. Простая задача — решето Эратосфена, или поиск простых чисел.