jplus-0.4.6

Jul. 9th, 2015 05:47 pm
dr_klm: (В человеческом обличье)
Выпустил новую версию 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-версии в нескольких вариантах.

JEL 2.0.2

May. 14th, 2015 04:26 pm
dr_klm: (В человеческом обличье)
Выпустил новый релиз JEL (локальное зеркало). Старый проект, но живёт ! ;-) В этой версии устранён довольно коварный дедлок при использовании с Oracle JRockit JVM и немного подпилен парсер (он теперь игнорирует символы табуляции + позволяет задавать целые литералы в более широком диапазоне значений).

Скачать можно либо в .tar.gz либо в .zip.

jplus

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

Ну а я сейчас, как обычно, прохлаждаюсь на косе в Бердянске. Если кто поблизости -- можно пивка попить.
dr_klm: (Default)
Еще в конце прошлого года (не знаю по какому поводу) решил глянуть современные космические стратегии. Да, есть множество интересных идей, красивая графика, но все равно, мне не попалось ничего, что я мог бы поставить однозначно выше старой доброй Galaxy. Наиболее перспективной мне показалась игра Star Ruler, но и в ней... )
dr_klm: (Default)
В общем и с явовской виртуальной машиной вышло по сценарию -- "хотели как лучше, а получилось -- как всегда." ;-) Вроде бы делали универсальный байткод, который 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.
dr_klm: (Default)
Последние две недели изучал lisp по книге Питера Норвига. Почувствовал себя мольеровским мсье Журденом, который вдруг понял, что всю жизнь говорил "прозой". ;-) Многие системы компьютерной алгебры (с которыми я работал постоянно, последние лет >15) если и не написаны непосредственно на lisp, то (как Mathematica), фактически, реализуют его неявно (не по букве, так по духу). Но речь не об этом... Глянув на настоящий lisp, я понял как "малой кровью" достичь (местами) табуированного "священного грааля" векторных языков -- компиляции.

Эта мысль оказалась не новой. Еще в 1979-м Burge, Moses и Pratt задавались вопросом "APL and LISP—should they be combined, and if so how?". Эта статья мне, к сожалению, недоступна, но и lisp и APL с тех пор здорово изменились. Каким бы ни был ответ -- возможно, сейчас стоит задать тот-же вопрос заново. Мой ответ: "Да, должны. И понятно -- как".

"Священный грааль" в виде компиляции APL в машинный код или C тоже был "взят" неоднократно. Был частичный компилятор фирмы STSC, написал свою книгу "An APL Compiler" Timothy Budd и свой компилятор APEX Robert Bernecky. Но то APL. Для J, насколько я знаю, на сегодня компилятора нет.

С другой стороны, компилятор есть в большинстве популярных реализаций Common Lisp. Причем такой, что компилирует программу как целыми модулями, так и по одной функции "на лету". Замыкания, созданные во время работы программы тоже транслируются в машинный код. Идея компиляции в замыкания тоже не нова, но для APL и J так, насколько я понял, никто не делал. Так почему бы не сделать ?

Написание компилятора в замыкания по трудозатратам сопоставимо с написанием интерпретатора. Да и структура его подобна. Если использовать опыт, накопленный при написании интерпретатора J. Добавив, развитую Бернецким, морфологию массивов -- можно, мне кажется, получить весьма высокопроизводительную вещь. Другое дело, что примитивы в J очень нетривиальны, реализация полной спецификации J с существующими на сегодня оптимизациями займет, наверное, целую человеко-жизнь. Прелесть, однако, в том, что компиляцию в замыкания несложно реализовывать поэтапно, добавляя по одному глаголу, наречию или союзу. Такая работа, по идее, должна хорошо распараллеливаться.

И так, в чем я здесь не прав ? Стоит ли этим заняться ?

Чтобы не быть голословным... )

pohmelfs

Mar. 9th, 2010 01:00 am
dr_klm: (Default)
Вначале я хотел похвалить автора за чувство юмора...

Теперь, побаловавшись почти целый день, понимаю, что название очень точное. По-началу, если читать розовые мечты автора, кажется -- "ну нифига себе человек сделал !". А если попробовать -- наступает разочарование, поскольку ничего за этим реально не стоит. Так, фактически, 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, которая вот вот выходит.
dr_klm: (Default)
Похоже выбор свободной универсальной системы компьютерной алгебры сегодня сводится к выбору между Maxima и Axiom. Выбор, как оказалось, непрост.

Maxima выглядит весьма неплохо. Вместе с wXmaxima интерфейс на уровне Mathematica 4-5. Внутренности тоже очень даже неплохи. Если чего не хватает -- всегда можно написать (собственно, речь и идет о том, чтобы выбрать систему и написать для нее реализацию некоторой спецфункции).

Axiom, судя по заложенной туда изначально инфраструктуре, выглядит гораздо лучше не только Maxima, но и Mathematica ! Проблема, однако, что по своим возможностям на сегодня и по степени завершенности Axiom значительно отстает. Проблема усугубляется чисто человеческими вещами. Один из ключевых разработчиков недавно умер. Maintainer, похоже, не справляется с управлением проектом. Ставит странные цели, аж на 30 лет вперед и легко приносит им в жертву вещи расширяющие возможности системы сегодня. Соответственно, в лагере разработчиков раздрай, на сегодня существует 3 форка.

Maxima работает уже сегодня. Axiom технически выглядит перспективнее, но чисто человеческий фактор там прийдется разгребать похоже еще долго. Что выбрать ? Может есть еще что-то ?

GPLv3

Jun. 6th, 2007 03:44 pm
dr_klm: (Default)
Скоро будет закончена работа над 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): А вот, в качестве примера альтернативы, новости из параллельного мира: История о человеке, который сделал то, что потом стало делать нельзя; ибо воля хозяина непостоянна.

JEL 2.0

Oct. 2nd, 2006 12:55 am
dr_klm: (Default)
Выпустил новую версию JEL под JDK 5 (с использованием generics и всякого другого синтаксического сахара ;-). Строится теперь при помощи ant, документация в docbook. К сожалению, как и другие программы под JDK 5, новая версия не совместима с ранними JDK (используйте старые, если что).

аннонс на Freshmeat, home, zip, tar.gz

update 2.10.2006: Исправил © внизу странички еще до обеда. Сейчас заскочил по ходу с работы в интернет кафе добавить ссылку на аннонс во Freshmeat, открыл страничку... смотрю, а © старый ! Нифига себе, думаю... А потом понял: страничка то была здесь еще старая в кэше на прокси. Нас читают и отсюда тоже ! ;-))

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

новая добавка к кластеру )
dr_klm: (Default)
Уже месяц мечтаю такую игрушку себе купить:

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

И вот, что получилось )
dr_klm: (Default)
Два дня искал !!! Два дня !!! Почему, блин, не считается интеграл, и результаты работы программы зависят от опций компилятора и от самого компилятора (в смысле, я двумя пробовал)...

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

Вот такая-вот фигня... и мало кто, наверное, понял о чем я... Потерпите ребята ! Закончу пару этапов -- стану снова понятен...
dr_klm: (Default)
Была у меня недописанная программа на Sun стареньком, считала пока кое-какие простые тесты. Но Sun медленный, а мне предстояло дописать часть, которая гораздо более требовательна к процессору. И решил я возобновить свой старый account на местном типа мощном компьютере (проэкт Луна).

Лунная соната )

JEL 0.9.11

Oct. 15th, 2003 04:48 pm
dr_klm: (Default)
забадяжил новый релиз. Казалось-бы можно и расслабиться... Ан нет... ;-) Сегодня у меня еще по плану на десерт вечер фортрана с численным интегрированием... Зато это снова будет физика... Хотя JEL тоже в библиотеку CERN входит, и в дисерах со статьями на нее ссылаются, че-то там для спутников ее лицензировали когда-то... ;-)
dr_klm: (Default)
Регулярно, приезжая сюда, я агитирую народ переходить под Linux в Универе, в ФизТехе... Рассказываю, что Windows -- система для секретарш, что под Linux есть (причем бесплатно и сразу) все средства для разработки, особенно рассчетных программ... Пугаю (в рассчете на инстинкт подражания), что только в странах третьего мира в исследовательских организациях пользуют Windows (и платят за это Microsoft фактически налог, если хоть что-то платят), что в первом мире (где бабла в институтах и универах несравненно больше) народ в большинстве сидит под Linux (и Unix)... Рассказываю, рассказываю, но все впустую... Нет, ну понятно, что у нас пользуют Винды тоже фактически бесплатно... но это-ж явление временное... Да и Linux обьективно лучше для исследовательской работы... Для офисной может и не лучше, а вот для исследовательской точно... Может у нас народ таки офисной работой большую часть времени занимается ? Может не бесплатность Windows тут причина, а засилие бюрократии и бумагомарательства ?
Page generated Jul. 27th, 2017 02:40 am
Powered by Dreamwidth Studios