LINUX.ORG.RU

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

 ,


1

1

Вчера отвечал в чью-то тему про парсинг, привёл небольшой пример. Потом, слушая музыку, незаметно для себя написал инфиксный недо-бэйсик и вспомнил, что как раз хотел почитать про llvm. Дальше, в общем, понятно.

В последующих влажных фантазиях я понял, что хочу видеть следующий недоязычок узкого назначения:

1) для SIMD модели

2) чисто функциональный (параллелизм же)

3) IO сводится к только семантике in-place и out-of-place обновления

4) map, fold, filter и некоторые другие функции высшего порядка встроены прямо в язык и жёстко оптимизированы, вплоть до разогрева с подгонкой размеров ядер/буферов под конкретное железо. Все они сильно подсахарены.

5) Встраиваемый вплоть до, грубо говоря, eval("2+2")

6) CPU и GPU бэкэнды

Вопрос: может такой уже есть? Вроде фич-то немного совсем.



Последнее исправление: dmfd (всего исправлений: 1)

Ответ на: комментарий от dmfd

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

anonymous
()
Ответ на: комментарий от anonymous

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

dmfd
() автор топика

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

mkmks
()
Ответ на: комментарий от mkmks

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

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

anonymous
()
Ответ на: комментарий от mkmks

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

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

dmfd
() автор топика
Ответ на: комментарий от anonymous

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

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

mkmks
()
Ответ на: комментарий от mkmks

google://thrust

google://accelerate-cuda

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

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

anonymous
()
Ответ на: комментарий от mkmks

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

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

dmfd
() автор топика
Ответ на: комментарий от mkmks

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

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

И отсюда до

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

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

mkmks
()
Ответ на: комментарий от dmfd

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

mkmks
()
Ответ на: комментарий от mkmks

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

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

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

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

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

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

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

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

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

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

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

mkmks
()
Ответ на: комментарий от mkmks

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

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

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

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

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

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

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

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

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

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

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

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

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

mkmks
()
Ответ на: комментарий от mkmks

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

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

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

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

dmfd
() автор топика
Ответ на: комментарий от anonymous

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

mkmks
()
Ответ на: комментарий от mkmks

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

dmfd
() автор топика
Ответ на: комментарий от Manhunt

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

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

mkmks
()
Ответ на: комментарий от mkmks

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

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

Nikola

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

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

не читал

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

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

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

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

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

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

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

mkmks
()
Ответ на: комментарий от mkmks

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

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

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

mkmks
()
Ответ на: комментарий от mkmks

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

mkmks
()
Ответ на: комментарий от ebantrop

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

dmfd
() автор топика

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

Коммутативность и приоритет операторов жёстко заданы. Элементарные типы только те, что есть в 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

dmfd
() автор топика
Ответ на: комментарий от bga_

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

dmfd
() автор топика
Ответ на: комментарий от dmfd

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

bga_ ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.