Microsoft Dynamic Language Runtime

Сегодня наш любимый большой брат microsoft сделал еще шаг навстречу динамическим языкам на платформе .net: на конференции mix'07 объявил о релизе DLR -- Dynamic Language Runtime, по аналогии с известным всем Common Language Runtime.

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

А библиотека эта выросла из проекта IronPython -- реализации Python под .net созданной CLR Team. Основной в этой команде инжынер Jim Hugunin, до того как его взяли в майкрософт, написал на досуге компилятор Python под JVM. Дядька, в общем, в высшей степени интересный, блог его тут.

Теперь кстати парни собираются еще и компилятор Руби забацать на основе имеющегося фреймворка, в том, что у них это получится, сомневаться не приходится.

Да, все это происходит в контексте усиленного продвигания майкрософтом своего веб2десктоп фреймворка Silverlight, так что по ссылкам он упоминается очень интенсивно -- не удивляйтесь :)

Еще пара ссылок:

• A Dynamic Language Runtime (DLR) -- пост Jim'а Hugunin'а
• Подкаст с другим разрабочиком IronPython -- Джоном Лэмом
• Интервью с обоими

Читать дальше..

DirectX 10 на Windows XP

Повеселила новость с этим заголовком на theinquirer'е сегодня -- суть в том что некий товарищ обещает скоро выдать некий мега-интерпретатор для запуска виндовых программ на MacOS и linux (меньше, быстрее и удобнее чем wine в стотыщраз).

Решил он начать с малого -- сначала сделать мега-интерпретатор не для всех программ, а только для игрушек с поддержкой DX10 ;)

А на днях вот с пафосом зарелизил альфа-версию интерпретатора, якобы позволяющую пускать DX10 приложения под XP. Лучше б он этого не делал, а продолжал себе собирать по полтиннику уе за доступ к альфа-превью-версии мегаинтерпретатора. Потому как эти 50 баксов служили, видимо, фильтром, допускающих к телу мегапроджекта только идиотов, а теперь любой здравомыслящий человек может взять дизассемблер и увидеть что мега-интерпретатор является лишь хреновой попыткой реализовать интерфейсы DX через OpenGL, и реализовано там только полторы несложных функции типа CreateTexture().

У товарища явно большое большое будущее в PR. И зря он себя в профиле блога скромно называет software reverse engineer'ом :)

Читать дальше..

VB for DOS

Сейчас вот наткнулся на ностальгический пост Нейла Митчелла (рекомендую, кстати, блог) про версии Visual Basic'а которые он юзал, и вспомнил про намного более гламурный чем все эти VB 3,4,5,6 настоящий Visual Basic 1.0 for DOS

Мега-вещь была, дельфи отдыхает -- настоящая RAD среда под DOS, рисование мышкой контролов, назначение всяких событий им, и все в стандартном 80x25 текстовом режиме! Если вдруг кому-то тоже хочется поностальгировать, тут валяется дистрибутив :)

Читать дальше..

Компилятор CAML в 2000 строк

Часть курса по процессорам и компиляторам из японского Tohoku University -- написание маленького оптимизирующего компилятора CAML.

Курс вообще отличный, сижу и завидую черной завистью -- сначала студенты разрабатывают процессор на ПЛИС с системой команд от SPARC (вплоть до реализации в железке), потом пишут для него компилятор, и соревнуются у кого быстрее работает тестовое приложение -- рейтрейсер.

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

• Лекции
• Страница проекта на sf.net, исходники с подробными комментариями всех стадий компиляции

Читать дальше..

Очень параллельные языки

В продолжение к предыдущему посту, как пример параллельного языка который мог бы неплохо лечь на GPU (с серьезными изменениями конечно) -- ZPL.

Намного более дружественный синтаксис чем у APL (не нужна специальная клавиатура :), и даже чем у его диалектов J и K.

Выглядит вот так:

region R = [1..n, 1..n ];
RowVect = [ * , 1..n ];
ColVect = [ 1..m, * ];
var M: [ R ] double;
    V: [ RowVect ] double;
    S : [ ColVect ] double;
  [ ColVect ] S := +<<[R ] (M * V);

Замечательное введение в ZPL в комиксах можно смотреть тут.

В общем-то влияние APL на него чувствуется весьма, жалко в отличие от J он функциональным таки не является.

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

 sum({v * x[i] : (i,v) in row});

Что неудивительно, поскольку любой функциональный язык, все эти filter'ы и map'ы просто так и просят чтоб их распараллелили.

Ну и естественно Data Parallel Haskell наше все:

smvm sm vec = 
[: sumP [:x * (vec!:col)|(col, x)<-row :]|row<-sm:]

Это опять таки умножение матрицы на вектор, и неспроста авторы DPH главным прототипом своей библиотеки считают NESL. Поэтому можно было и не приводить этот пример, но не упомянуть про Хаскел я не cмог :)

Читать дальше..

Stream computing уже здесь

Пока в новостях носятся с экспериментальным 80-ядерным процессором Intel, NVidia окончательно выпустила свой CUDA SDK на прошлой неделе, и можно сказать что stream computing на оченьмногоядерных платформах готов идти, наконец, в массы.

Оба крупнейших вендора представили свои замечательные девайсы и SDK: у нвидии это CUDA, у ATI -- их CTM SDK.

Однако ATI CTM не выглядит так интересно как CUDA, поскольку при всем пафосе он таки слишком похож на третьи-четвертые шейдеры: архитектура и инструкции похожи, лимит на 512 инструкций, и в качестве высокоуровневого языка предлагается HLSL. Правда спецификации очень подробны, и железкой управлять можно очень тонко. На данный момент ATI предлагает все писать на железко-зависимом ассемблере, и считает это почему-то преимуществом CTM.

А вот CUDA от NVidia намного интереснее. С точки зрения девелопера оно выглядит как натуральный очень-многопроцессорный девайс, причем логикой распараллеливания программы можно управлять (в отличие от шейдеров и CTM).

Вообще рекомендую полистать замечательный мануал к CUDA, за что определенно можно любить NVidia -- так это за красивые понятные и подробные SDK. Будущее параллельных вычислений -- на пальцах и с картинками.

Писать под эту красоту можно на настоящем, немного модифицированном C. Что характерно никаких жестоких ограничений по коду в мануалах к CUDA не приведено, ни размер кода, ни на глубину вложенных циклов на девайсе, ни на количество вложенных вызовов процедур.
Что, кроме всего прочего, позволяет ожидать кучи параллельных функциональных языков под нвидиевские девайсы ;)

Читать дальше..