Язык программирования Ficus для вычислений и не только

Сравнение с Питоном проводилось поскольку это флагманский язык для ML/AI, на нем сейчас пишут практически все в этой индустрии.

С Джулией (Julia) интересно было бы сравниться, в следующей статье надо будет обязательно добавить. Это очень неплохой язык, где также реализована поддержка массивов на уровне Matlab, правда, насколько я понимаю, там выбрана динамическая типизация как вариант по-умолчанию, соответственно чисто теоретически эффективность кода будет скорее всего ниже чем в C++ и в Фикусе. На практике же и язык и компилятор и стандартная библиотека находятся в уже очень продвинутом состоянии, в компиляторе реализован вывод типов, есть возможность использовать SIMD-интринзики, есть возможность для конкретных случаев тонко настраивать код, например отключать проверку на диапазон при доступе к массиву, поэтому есть возможность при желании получить довольно быстрый код.

По поводу названия. Ну как-то так получилось, рассматривал названия, начинающиеся на F/Ф, чтобы подчеркнуть функциональность. Случайно узнал что Фикусовые - это целое семейство, включающее большое количество известных растений, от комнатных до совершенно эпических, используемых для совершенно разных целей. Меня такая универсальность и "масштабируемость" очень порадовала.

Прошу прощения, в конце ссылки магическим образом добавился лишний символ. Правильная ссылка https://github.com/vpisarev/ficus

Вопрос вполне справедливый: где деньги, т.е. где обещанная скорость? Дайте немного времени. Считаю что проектные решения, заложенные в языке правильные, но нужно время чтобы их превратить в реальную скорость. Это будет один из главных приоритетов на ближайший период.

Ну и, справедливости ради, это не совсем DSL. Скорее полноценный язык (на котором можно написать компилятор например) с хорошей поддержкой массивов.

Теоретически вызвать Фикус из C/C++ должно быть несложно. Практически в данный момент это не так просто поскольку пока компилятор работает только в режиме генерации кода для приложений.

Вот пример, который воспроизводит ваш C++ код:

fun make_lut_16to8(imin: int, imax: int)
{
    assert(0 <= imin <= imax < 65536)
    [| for i <- 0:65536 {sat_uint8((i - imin)*255./(imax - imin))} |]
}

fun apply_lut(img: uint16 [,], lut: uint8 []) =
    [| for pix <- img {lut[pix]} |]

val L = make_lut_16to8(16, 4096)
val img8 = apply_lut([| for i <- 0:6 for j <- 0:6 {uint16((i+j)*500)}|], L)
println(img8)

Проблема в том что если собрать его с -O3 или -O1, то эти функции подставятся и исчезнут сами по себе. Пока нужно компилировать только с -O0, но тогда скорость будет ниже. Но тем не менее, для проверки можно это сделать. Допустим, если сохранить этот код в файле lutop.fx и собрать, то вы получите каталог ficus/__fxbuild__/lutop/ с кучей .с файлов, включая lutop.c, там будет функция FX_EXTERN_C int _fx_M5lutopFM9apply_lutA2b2A2wA1b(fx_arr_t* img_0, fx_arr_t* lut_0, fx_arr_t* fx_result, void* fx_fv), которую можно вызвать, если соответствующим образом подготовить входные массивы:

_fx_arr_t img = {0, 0, 0, 0, 2, (char*)src_ptr,
   {{height, src_stride}, {width, sizeof(uint16_t)}};
fx_arr_t lut = {0, 0, 0, 0, 1, (char*)lut_ptr, {{65536, 1}};
fx_arr_t result = {0};
int errcode=_fx_M5lutopFM9apply_lutA2b2A2wA1b(&img, &lut, &result, 0);
...

Подобная обертка может располагаться в .с/.cpp файле и она как раз может быть dllexport. После чего останется включить все сгенерированные .c файлы, вместе с runtime, в свой проект. Но конечно это пока не очень простое и не удовлетворительное решение.

Как использовать Фикус из кода на других языках, ну скажем из С/С++? 

Простите, что влезаю в чужой разговор, но Вы уверены, что эти вызываемые процедуры оптимально писать именно на Фикусе? В общем, я бы тоже предложил глянуть в сторону других вариантов - а конкретно фортрана. Модульность там реализована уже довольно давно (начиная с фортрана-95), а поддержка массивов просто близка к идеалу. Язык позволяет удобно писать практически любые расчеты. Начиная от простейших массивных операций (это когда в арифметическом выражении вместо имени переменной можно указать имя массива) и задания почти произвольных сечений массива, и кончая такими операторами, как FORALL и WHERE. Если использовать только чистые функции (которые тоже появились в стандарте фортран-95), то циклы для обработки массивов вообще практически не нужны. А главное, все эти операторы очень эффективно оптимизируются компилятором. Скорость исполнения получается примерно такая же, как на Си, при том, что высокоэффективный код писать значительно проще. (Только не забудьте при тестах производительности включать в обоих языках оптимизацию максимально, иначе неоптимизированная программа кратно проиграет оптимизированной).

Впрочем, насчет легкости кодирования это наверно уже вопрос привычки и вкуса. К примеру, в фортране ввод-вывод - это часть языка, и поэтому есть целый зоопарк операторов ввода-вывода с кучей спецификаторов для работы с разными типами файлов (а в Си это вынесено в библиотеки). Еще один минус фортрана - он "тащит" совместимость со старым кодом, из-за этого в языке до сих пор сохраняются устаревшие операторы и возможности (вроде Include, goto, common и др.). Использовать их никто не заставляет, но документацию это слегка усложняет.

С другой стороны, как ни сравнивай фломастеры вкусом и цветом, а мне все-таки кажется, что написать:

  real(16) ::        a(100), d(100)
  ...
d=sin(a**2)

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

Но и плюсов (простите за каламбур) у фортрана тоже не мало. Я бы сюда отнес развитые инструменты для контроля точности вычислений с плавающей точкой и написания переносимых программ, а также средства для мультиязычного программирования (с помощью интерфейсов можно как вызывать функции из других языков, так и писать свои функции, которые будут передавать параметры в вызывающую программу "по ее правилам"). Или такой нюанс: проверка использования неинициализированных переменных, выхода индекса за границы массива и т.д. и т.п. - это отдельные опции компилятора, и их можно включать/выключать вне зависимости от того, собираю ли я debug-версию или release. (Да, это свойство компилятора, а не языка, но подозреваю, что все основные компиляторы это умеют). Кстати, для желающих в языке сейчас есть минимальные элементы ООП. Но для тех, кто занимается вычислениями, одно из основных преимуществ - это наличие мощных библиотек для всевозможных расчетов, которые обычно прилагаются к компилятору, поэтому их использование выглядит, как использование "стандартных библиотек языка". Само собой, операции с матрицами и линейная алгебра там тоже есть ;-) Причем обычно эти библиотеки имеют версии для расчетов с разной разрядностью (не обязательно все считать в double), и т.д.

В общем, если кому-то будут интересны подробности - пишите, расскажу что смогу (с примерами кода).

Спасибо. Cтиль Julia немного отличается, мне кажется, скорее здесь параллели можно провести со Swift, Scala, Rust. Насчет Ocaml все справедливо - это основной источник влияния.

В качестве лайфхака - если взять редактор с поддержкой лигатур (например, Sublime или VSCode) и соответствующий шрифт, то будет еще красивее. В репозитории Фикуса можно найти один из таких шрифтов.

В препроцессоре Фикуса нет директивы include. Вместо этого есть настоящие модули. Тем самым, локально объявленные в модуле символы не влияют на остальные модули.

Во-вторых, символы препроцессора содержатся в отдельной таблице, и не конфликтуют с символами в коде.

// preprocess_test.fx
@IFNDEF UI
@DEFINE UI "CLI"
@ENDIF
val UI = @{UI} // публикуем значение символа препроцессора в настоящем коде,
               // сохраняем в неизменяемую переменную с таким же именем
println(f"selected UI: {UI}")

запускаем чтобы напечаталось "GUI"

`bin/ficus -run -D UI=GUI preprocess_test.fx`

Автовекторизация/раскрутка циклов в настоящий момент осуществляется только компилятором C/C++, который подхватывает код сгенерированный Фикусом. Наша первая задача - сгенерировать максимально дружественный для векторизации код, не отягощенный динамической типизацией, boxing/unboxing и т.д. Для простых циклов эта задача решается неплохо.

Compile-time выражения не имеют отдельного синтаксиса, но во время компиляции константные выражения подхватываются и заменяются их значениями. Например, при компиляции примера выше про LUT с -O3 (imax - imin) благополучно заменилось на 4080.

Примеров много и в тьюториале на 100 страниц и в подкаталоге examples. Собираюсь написать еще статью, может и не одну, с более подробным обзором фич языка с примерами. Помести я это все в эту статью, объем бы превысил все разумные пределы.

Генерации доков пока нет, это в планах, хотя и не краткосрочных

Обертки над BLAS и LAPACK в самых ближайших планах. Функций там много, но попробуем обернуть хотя бы часть для generic double-precision матриц (ленточные, верхне/нижнетреугольные пока можно отложить)

Именно так. В Фикусе реализованы иммутабельные вектора, добавленные под влиянием доклада Хуана Пуэнте: https://www.youtube.com/watch?v=dbFfpTp3EhA. Для представления потоковых одномерных данных типа звука, текста, финансовых данных и прочее они я думаю вполне бы подошли. Но для изображений, тензоров все-таки пока это не очень эффективно.

да, конечно. См. пример nbody.fx, там используются похожие структуры и определяются над ними операторы: https://github.com/vpisarev/ficus/blob/master/examples/nbody.fx

Спасибо, посмотрел немного на Petalisp. Ну вроде как там есть определенные моменты где он действительно технологически опережает numpy. numpy это чисто библиотека операций над массивами, а тут предоставляются средства для написания собственных циклов, и возможно Лисп'овский компилятор из этого сможет сгенерировать нормальный код. Но синтаксис конечно на любителя Лиспа.

Про unique типы тоже сейчас посмотрел. Если честно, мне это направление не нравится. Я не очень понимаю как с этим работать не натыкаясь постоянно на необходимость делать глубокое копирование чтобы удовлетворить компилятор. Если уж хочется полной функциональной чистоты (хотя такое себе желание), более перспективное направление, с моей точки зрения, это современные неизменяемые структуры данных, такие как RRB вектора и HAMT хэш-таблицы. В Фикусе шаблонный тип 't vector как раз построен на базе RRB. Когда вектор создается с помощью comprehension, то, само собой, он пишется сразу, без создания копий при добавлении каждого элемента, поскольку мы уверены что в момент создания никто больше на него не ссылается:

val rng = RNG(0x12345u64)
// create big vector efficiently,
// no data is reallocated during the process
val bigvec = [< for i <- 0:99999999 {rng.uniform(0.f, 1.f)} >]
val parts = bigvec[:1000] + bigvec[10000:100000] +
            bigvec[1000000:] // reuse parts of the vector,
                             // almost no data is copied
val sz = size(parts)
for i <- 0:1000 {
    val idx = rng.uniform(0, sz)
    // random access is ~O(1) operation
    println(f"{i}. parts[{idx}]={parts[idx]}") 
}

К сожалению, пока аналогов RRB векторов для многомерных массивов не знаю. Вектор из векторов для каждой строки — это слишком неэффективно, да и не нужно, изображения не растут непрерывно вширь и в высоту. Может быть можно что-нибудь соорудить на базе quad-tree, oct-tree и т.д., например, разбить картинку на тайлы, ~128x128 пикселей, и эти тайлы поместить в quad-tree.