А как же DVM? Вроде, это активно используется. Нет?

всем общий салам посылать

> Почему не взлетело интересно?

В основном, AFAIK, потому что иногда синхронизироваться всё-таки нужно, и накладные расходы слишком часто перевешивают ускорение от распараллеливания. Т.е. компилятору крайне проблематично определить (на этапе компиляции) правильную гранулярность распараллеливания.

Впрочем, Data Parallel Haskell, как я слышал, живёт и здравствует...

> Впрочем, Data Parallel Haskell, как я слышал, живёт и здравствует...

разве? я слышал, что он помер уже давно...

🤷‍♀️

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

Не правильно. Есть ScaLAPACK для таких вещей

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

А можете пояснить, в чём это удаление выражается?

Ну Вы посмотрите даже на относительно простые manycore-архитектуры в духе Kalray или Tilera. Там масса аппаратных нюансов, которые легко разрушают абстракции в духе вышеприведенной диссертации.

Но там же не для произвольной архитектуры, а для машины с распределённой памятью. То есть, это не manycore

Так manycore в отличие от multicore это как раз машины с наличием распределенной памяти. Потому что без распределенной памяти вы эффективно не сможете масштабировать число вычислителей.

Или вот два примера manycore-чипов из списка TOP500: Pezy-SC2 и SW26010. Никто их на параллельных Haskell-подобных языках не программирует. Там все, увы, гораздо прозаичнее :)

Подскажите как реализовать базовые операции (+, *, >, !=, &&, etc) для языка чтобы было без особой боли сейчас и в будущем. Придумал несколько вариантов:
1. Для примитивов закрепить четкое поведение на уровне компилятора. Для пользовательских типов данных потом добавить в сишном стиле ( operator+(self) -> Self).
2. Делать сразу какие-то интерфейсы/типажи/тайпклассы и реализовывать для примитивов тоже их. Чую что если делать так то нужно сразу расписывать систему типов аж до обобщений, что меня чего-то беспокоит, так как я пока не в курсах как это можно сделать вообще.

Повторю: вопрос как сделать максимально без гемороя и чтобы не пришлось потом городить костыли в будущем

Если "не городить костыли в будущем", то имеет смысл заранее продумать систему типов "аж до обобщений", КМК.

Ок. Думал может есть ещё какие-то подходы, о которых не знал.

Для более быстрого прототипирования можно попробовать http://www.metaborg.org/en/latest/ - там есть специальные DSL для всего: грамматика, проверка типов, выполнение...

Разве что определять всё как функции/методы a-la Smalltalk/Ruby/etc. 😊

Спасибо

А как там с описанием такой машины?

В конце-концов, если взять человека с обычным дипломом программистского ПТУ №8, выдать ему 10 тысяч лет, код на Матлабе, этот человек рано или поздно напишет отлично оптимизированную и распараллеленную программу на языке Цэ или другом портируемом ассемблере.

А с другой стороны, высоколобые и умные люди не могут сварганить какой-то там компилятор.

Обычно это означает, что сама задача недопоставлена. То есть, нехватает каких-то определений, условий, что-то надо уточнять и т.д.