Записки К.Л.М.

Выпустил новую версию J+ (и, соответственно, YACTS). Для тех, кто (как и большая часть человечества пока) не в курсе -- это мой собственный MATLAB в комплекте с Simulink. Работает очень хорошо, я на нём считаю микромагнитные задачи. К последней версии, вышедшей два года назад нареканий не было -- работает (по крайней мере на моих задачах) как часы.

Основной фокус этого релиза -- портабельность. Теперь (за счёт кросс-компиляции) поддерживается платформа Win32. Есть готовые полностью статические бинарники (тот, кто не знает языка J, может запустить из них разве что tester.exe ;-).

update (9.07.2015): Для примера сделал ещё простенькую симуляцию аттрактора Лоренца, иллюстрирующую как разделять симуляцию и обработку траектории в YACTS. Этот пример войшел в jplus-0.4.6, с сайта я его убрал.

update (13.07.2015): Выпустил jplus-0.4.6, начиная с которого поддерживаются 64-битные платформы. Обновил бинарники Windows-версии в нескольких вариантах.

Мне уже давно хотелось прикрутить J к численному счету (см. например здесь или здесь). И вот, сделал следующий шаг в этом направлении... Встречайте новый проект J+ с новой программой YACTS ! Подробнее здесь (на английском). Читайте, пишите, комментируйте, присылайте патчи. ;-)

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

В общем и с явовской виртуальной машиной вышло по сценарию -- "хотели как лучше, а получилось -- как всегда." ;-) Вроде бы делали универсальный байткод, который write once, run anywhere... Сделали. Но теперь неймется компании Google, которая мало того, что написала для Явы новую виртуальную машину, да еще к тому-же и совершенно другой архитектуры.

Большинству, конечно, все равно, они свои программы перекомпилируют специальным гуглевским компилятором (который из обычных Java class files делает Dalvik-овские dex файлы). А что делать нам, несчастным писателям компиляторов ? ;-)

Но мало того, то байткод другой архитектуры. Еще и загружать динамически его приходится по-новому. И не просто по-новому, оказывается сам этот байткод Dalvik загрузить непосредственно не может, только из zip архива... В общем, грабли на граблях.

Ну вот я вроде разобрался. Пишу, чтобы зафиксировать. Вам это, скорее всего, будет не интересно. ;-)

( загрузка Dex файла в Андроид in seven "easy" steps ;-) )

Так что, наступает эра многоплатформенных компиляторов в явовские байткоды со всеми вытекающими "прелестями". Да, явовский байткод не очень оптимален в плане используемого пространства, но неужели такая оптимизация, всего-лишь в несколько раз, стоила того ? И все равно-ж, гады, в процессе загрузки этого .zip с файлом .dex (вызов конструктора DexFile), они докомпилируют его в "оптимизированный" байткод в формате .odex, который еще хранят в отдельном файле.

Вот такая вот бессмысленная политика (ибо по-другому мне это сложно объяснить). Нет, для меня это, конечно, выгодно. Я то думал проект уже закончен. А тут опа, появляется возможность переписать все заново (с сохранением старого, проверенного и удобного API). Типа раз, и снова в девках. ;-) Хорошо, но бессмысленно.

По-хорошему нужно было спрятать свой dalvik подальше (как implementation detail, раз уж они верят, что именно такой подход даст им performance edge), включить в стандартную поставку перекомпилятор dx в прозрачном режиме и пройти явовский testsuite.

Вначале я хотел похвалить автора за чувство юмора...

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

Забавен автор, осмеливающийся при этом приводить результаты тестов (он даже bonnie додумался запустить) и бахвалящийся там, что эта его поделка быстрее nfs. Только вот, незадача, "не работает пока с большими файлами"... Конечно tmpfs быстрее nfs, а с большими файлами это г. не работает и не может работать по причине переполнения буфера.

Повбывав бы ! ;-))

Ну, хоть сделал себе новый образ под старым добрым User Mode Linux, порассматривал под gdb core dump-ы (поскольку, первым, что делает pohmelfs из ядра 2.6.33 является segfault), снова почувствовал себя kernel хацкером. ;-) Так что если кому нужно срочно захачить kernel -- обращайтесь пока снова не забыл. ;-))

А тема распределенных сбоеустойчивых файловых систем вообще-то горячая и очень нетривиальная. Пока что все об нее сломали зубы. Насколько я знаю, дальше всех продвинулся M. Satyanarayanan c системой coda (которая таки работала без дураков, а не как pohmel, типа выложу в интернет tmpfs, насобираю полный буфер файлов, пропихну в ядро, раструблю на весь мир, а потом буду думать -- что с этим буфером делать)... Только coda сегодня, к сожалению, остается системой прошлого века с файлами <2GB, директориями не более 256KB (пара тысяч файлов всего, если имена средней длины), и не тянет реально более десятка миллионов файлов на сервер (что не так уж и много). Запатчить ее до современного уровня, хоть Jan Harkes и пытается, я думаю, не удастся. Нужно писать с нуля...

Самая многообещающая, на сегодня, распределенная (хоть это ее свойство является унаследованным, а не собственным) сбоеустойчивая файловая система, как мне кажется -- tsumufs, но там в коде сплошные TODO: и около года его никто не касался.

update (4.04.2010): Файловая система ceph, упоминавшаяся здесь в комментариях, официально включена в ядро Linux, начиная с версии 2.6.34, которая вот вот выходит.

Скоро будет закончена работа над 3-ей версией GNU General Public License (GNU GPL). Об изменениях в новой лицензии и причинах, сделавших эти изменения необходимыми, можно прочитать здесь.

Если Вы не очень в курсе этих дел, рекомендую статью "Freedom or Power ?" by Bradley M. Kuhn and Richard M. Stallman, где обьясняется -- зачем все это нужно вообще. Соль этой статьи можно выразить одной цитатой: "A choice of masters isn't freedom.".

update(15:59): А вот, в качестве примера альтернативы, новости из параллельного мира: История о человеке, который сделал то, что потом стало делать нельзя; ибо воля хозяина непостоянна.

целый день на работе любимым делом -- установкой Линукса. ;-) Вот сам не знаю почему мне нравится этот процесс, может быть потому что случается не часто... Программистам и системным администраторам, боюсь, моя радость будет не понятна... Но для меня Linux -- это приятное хобби, не работа...

( новая добавка к кластеру )

Обалдеть... Решил побаловаться и сравнить GCC (вернее G77, компилятор фортрана из GCC) с Intel Fortran Compiler... на своей программе... Включил максимум оптимизации и там и там...

( И вот, что получилось )

ну мрак... целый день сегодня писал формулы и программировал (отвечая только на E-mail, и то парочку серьезных оставил на завтра, пописывал слегка в ЖЖ в перерывах)... Выяснилось, что конформные преобразования многоугольников лучше считать не через гипергеометрическую функцию, а интегрируя контурный интеграл численно, что Mathematica очень неточно вычисляет эту самую функцию при больших аргументах, что можно ловко так применить теорему Римана-Грина и свести четырехкратный интеграл по двум взаимодействующим конечным элементам к двойному по их контурам. Проверил формулу в Mathematica, решив, временно, проблемы с вычислением 2F1... Просчитал все возможные случаи взаимного расположения сингулярностей на контурах двух конечных элементов и рассчитал параметры всех преобразований переменных для удобного численного интегрирования...

Вот такая-вот фигня... и мало кто, наверное, понял о чем я... Потерпите ребята ! Закончу пару этапов -- стану снова понятен...

забадяжил новый релиз. Казалось-бы можно и расслабиться... Ан нет... ;-) Сегодня у меня еще по плану на десерт вечер фортрана с численным интегрированием... Зато это снова будет физика... Хотя JEL тоже в библиотеку CERN входит, и в дисерах со статьями на нее ссылаются, че-то там для спутников ее лицензировали когда-то... ;-)