Фантазии на тему vector processing language

матлаб же

С пунктами 2 и 5 фэйл. Ну и оно огромное и дорогое.

C 5 можно поспорить. Там есть тулкит для встраиваемых систем, а еще есть vhdl кодер и верифер. Огромное потому, что интерпретатор, но есть и компилятор.

А что там с CUDA-бэкэндом? Когда я в последний раз смотрел, там можно было только линковаться с функциями на CUDA C.

В одном только п. 4 затаилось как минимум полдесятка нерешенных исследовательских проблем.

Всё уж реализовано давно, правда не очень эстетично. Есть и работает thrust, как бы есть и как бы работает accelerate.

Вы в каком университете сейчас на постдоке находитесь?

В последней версии некоторые тулкиты (например, нейросети) могут быть запущены на GPU модификацией строки запуска.

К чему этот сарказм? Я же говорю, что мне хватит тех же алгоритмов thrust, но в более компактной записи, вроде 0 + [a] вместо уродливатого

thrust::reduce(a.begin(), a.end(), (float)0, thrust::plus<float>());

Это хорошо, но немного не то: библиотек на CUDA много, а вот для написания своей требуется уж слишком много букв.

Ну как же, столько народу бьется, публикует, а у кого-то уже все давно реализовано. Вот и интересно, где такой скромняга окопался.

google://thrust

google://accelerate-cuda

Идите им рассказывайте, как всё плохо, и как нельзя сделать то, что они сделали. </discuss>

Ты даже не понимаешь, что сделано в accelerate, и что ты просишь в своем п.4.

На моем рабочем компьютере с матлабом видеокарта amd, поэтому я не имею возможности экспериментировать в направлении gpu-вычислений. Прочитал в аннотации, хмыкнул и занялся «своими баранами», может это пока не работает.

Ты даже не понимаешь, что сделано в accelerate

Там сделан кодогенератор, который в шаблоны функций на CUDA С (которые прямо в хаскельный код встроены с помощью language-c-quote) подставляет сгенерированный с помощью библиотеки language-c код, затем каждый раз (!) в рантайме вызывает nvcc, загружает полученный объектник и через FFI вызывает функцию. Это работает, но неэффективно. Идея интересная, но реализация несколько удручает.

и что ты просишь в своем п.4.

Уточняю: примерно то же самое. Но без костылей с компиляцией на каждый вызов. Мне, наверное, лучше знать, что я имею в виду, не правда ли?

И отсюда до

встроены прямо в язык
жёстко оптимизированы
подгонкой размеров ядер/буферов под конкретное железо

еще несколько лет работы. Это, учти, при том, что и cache awareness/obliviousness, и loop interchange/fusion/fission/tiling — хорошо изученные проблемы.

Вот бы и остальным знать, что ты имеешь ввиду. Пока что ты просишь цветочек аленький.

встроены прямо в язык

Если это можно описать на шаблонах и функциях высшего порядка в уже готовых языках, то какие проблемы с языком, специально для этого предназначенным?

жёстко оптимизированы

Я-то надеялся, что это будет очевидно. Суть этого пункта в том, что цель — перенести большинство низкоуровневых оптимизаций из пользовательского кода в кодогенератор. Насколько оптимизация будет сильной, к делу не относится.

подгонкой размеров ядер/буферов под конкретное железо

В MAGMA и fftw так уже сделано, статьи есть. Ну и см. предыдущий пункт.

У вас баттхёрт из-за ревности к технологии, в которой вы себя считали единственным специалистом?

fftw так уже сделано, статьи есть

И статьи эти ты, конечно, не читал. Иначе бы знал, что cache complexity для FFT не зависит от размера кэша лишь асимптотически, а параметр отсечки надо подбирать под каждую машину руками. И что cache obliviousness показана только для divide-and-conquer алгоритмов, есть статьи. И что даже для divide-and-conquer есть ограничения. А ведь еще уровней кэша в каждой машине много. И есть статьи, где показывается, что если отсечку выбирать локально оптимально для каждого уровня, то не это не даст глобально оптимального решения. Но ты тоже не читал.

перенести большинство низкоуровневых оптимизаций

О том, что они низкоуровневые в основном потому, что требуют сведений о машине, а как совместить высокий уровень абстракции с указанием параметров машины еще никто не знает, ты, конечно, не читал. Вот, скажем, prefix networks для разных машин скомпилировать в par/seq-конструкции можно очень по-разному.

Иначе бы знал, что cache complexity для FFT

Мы не говорим об FFT. Мы говорим об алгоритмах, которые есть в thrust и Prelude. Т.е., прежде всего, о traversable (map) и foldable (reduce).

А ведь еще уровней кэша в каждой машине много.

Я рад, что вы всё это знаете. Не нужно лишний раз это показывать, мы не на экзамене.

как совместить высокий уровень абстракции с указанием параметров машины еще никто не знает

Да, это проблема. Но некоторые параметры в любом случае можно кое-как подогнать слепым разогревом.

Вот, скажем, prefix networks для разных машин скомпилировать в par/seq-конструкции можно очень по-разному.

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

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

Человека, только собирающегося почитать про LLVM, задавить большого труда не надо.

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

То он приводит в пример реализацию FFT, то он о ней не хочет говорить. То он хочет компилировать из одного исходника под CPU и GPU, то подуразумевает лишь чуть разные характеристики одной архитектуры.

Вам там в одной голове не тесно?

То он хочет компилировать из одного исходника под CPU и GPU

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

попросив «немного фич»

Которые, в третий раз повторяю, все до одной есть в thrust.

Посмотрите заголовок темы. Надо ли быть столь непримиримым?

Конечно, надо. Потому что ни один из существующих языков перечисленным требованиями не удоволетворяет. И еще лет пять не будет. Но поскольку ТС не понимает, о чем говорит, он будет вбивать произвольные ключевые слова в гугль, выхватывать результаты из контекста, размахивать ими и орать, что вот, вот, немного фич, все готово уже.

Не, я понимаю, вы вышли из тайги, где про thrust и stl ещё ничего не знают, на конференциях друг другу рассказывают о том, какими неподъёмно сложными вещами они занимаются. Но после этого-то треда, надеюсь, некое прояснение наступило?

http://people.csail.mit.edu/jrk/halide12/

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

Такие наколенные библиотечки шаблонов написаны десятками штук (конкретно thrust это уровень Obsidian'а по состоянию на 2009 год или Nikola'ы на 2010). Но проблема-то не в том, чтобы слепить библиотечку шаблонов, а в том, чтобы иметь расширяемую инфраструктуру компилятора, вроде Delite. Чтобы можно было и свойства высокоуровневых абстракций использовать без хитрых анализов, и новые оптимизации легко добавлять, и на каждую радикально отличающуюся архитектуру не писать шаблоны заново. Но Delite все равно пока еще не торт.

наколенные библиотечки

Thrust — это библиотека из состава CUDA SDK, с неплохим коммьюнити.

Nikola

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

Дальше, простите, не читал. Я рад, что вы, наконец, погуглили, но пока ещё недостаточно хорошо.

не читал

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

встроены прямо в язык
жёстко оптимизированы
под конкретное железо

Ты ж даже не понимаешь, что библиотечка шаблонов это еще не язык. У тебя нет понимания, какие проблемы ты просишь решить. Тебе даже гуглить будет вредно. Будешь как товарищ тремя постами выше — выцеплять из контекста по ключевым словам.

на которую никто не ссылается

Да ладно, ссылаются не менее, чем на добро того же пошиба, типа Accelerate.

слегла разложившаяся

В глаза сношаешься что ли? На ICFP'12 было. Это «разложившаяся»?

Будешь как товарищ тремя постами выше — выцеплять из контекста по ключевым словам.

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

ЛОР это юмористический ресурс. Технические дискуссии здесь вести бессмысленно. За конкретикой надо на stackoverflow, а не на ЛОР.

Конкретно в данном треде мне забавен очередной всезнающий «физик». Отчего-то все (все!) «физики», получившие образование в РФ, знают все обо всем. У них же коллайдер! Петабайты данных в секунду! Суперкомпьютеры! Кто ж разбирается в параллельных вычислениях, как не физики?!

У меня даже начальник был такой «физик», считал, что построение компиляторов равняется lex/yacc, программировал на сишечке емаксовыми макросами и столь же искренне, как ТС, удивлялся, что же не так. С тех пор я их коллекционирую.

У меня даже начальник был такой «физик»

И с тех пор у тебя жжение в заднепроходном отверстии, как только видишь «физиков»? Так тебе не на юмористический ресурс, а к психотерапевту.

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

Wolfram Mathematica

Не слишком близко. Хотя пункт 4 там в какой-то мере реализован.

Продолжаем фантазировать.

Коммутативность и приоритет операторов жёстко заданы. Элементарные типы только те, что есть в CUDA, +векторы из них. Алгебраические типы не нужны (SIMD), хватит кортежей.

Сахар:

a+b    -> a+b
[f a]    -> ([f ((a!!).(i+)) | i <-  [0..length a-1]]) или (map f a) в зависимости от типа f. Как быть с граничными условиями пока не знаю.
a + [b]    -> foldl (+) a b
[a] + b    -> foldr (+) b a
+ [a]    -> foldl1 (+) a
[a] +    -> foldr1 (+) a
[a] + [b]    -> foldl1 (+) $ zip a b

ты сейчас apl семейство изобретаешь

Ага, я уже их нашёл. Но там что-то динамика сплошная, и CUDA-бэкэнда я ни у кого не видел, prove me wrong.

про куду не скажу но dyalog apl всю жизнь был супер быстрым и юзает simd/многопроцессорность по полной