Тута образовалось две занятные темы. Быстродействие видеосистем и умножение матриц. И вот что мне подумалось, мы разговариваем здесь только в контексте современной традиционной архитектуре. А ведь эти задачи решаемы. Нужно просто отойти от догм традиционной архитектуры.
Что я подразумеваю под традиционной архитектурой. Традиционная архитектура процессор, обращающийся к памяти и последовательно выполняющий команды. То бишь, Фон Нейман во всей его красе и недостатках. Если я скажу, что у архитектуры имеется большой недостаток, я Атлантиды не открою. Это еще сделал Бэкус в знаменитой Тьюринговой лекции Can programming be liberated from the von Neuman style? (правда думаю что это настолько очевидно, что кто-то мог это ляпнуть и раньше). А именно, bottleneck в шине памяти. Можно сколько угодно убыстрять работу памяти, работу процессора, но шину между процессором и памятью убыстрить такими же темпами не удастся. Это в принципе заметно и сейчас – добавление процессора не дает скачка в 100%.
Как решить проблему быстродействия? Легко. C помощью параллельных вычислений. Большинство часто встречающихся и в то же время тяжелых для процессора алгоритмов, как то сортировка, или то же умножение матриц легко делается с помощью алгоритмов разделяй и властвуй. Те же матрицы могут быть разделена на несколько, раздельно вычислены частями и затем вычислены уже в одну матрицу. Или возьмем, ту же видеопамять. Допустим у нас существует 10 процессоров. Каждый работает со своей областью памяти. При приходе команды на вывод строки, команда разделяется по разделам памяти, и каждый процессор выполняет вывод своих символов. Если нельзя увеличить быстроту шины, то почему бы и не увеличить количество шин. Я верю что данная архитектура будет более производительной чем традиционная. И это в принципе доказано. mainframe системы как раз и строятся на параллельных алгоритмах и архитектурах. Мы слишком привыкли к традиционной архитектуре. Все что делается и делалось, например те же учебники по алгоритмам, подразумевают традиционную архитектуру с последовательным выполнением команд.
Некоторые естественно сразу подумали, а ведь современная архитектура уже параллельна. NUMA хоть в виде кэша есть(NUMA – Non uniform Memory Architecture. Каждый процессор имеет свою локальную память). Ну и внутри у него несколько Risk процессоров(а сейчас и ядер несколько). В общем все это есть, а вот счастья нет. Потому как не работает это все на полную мощность. И никогда не заработает, пока все, от железа до OS и компилятора и программиста не смогут распараллелить вычисление сознательно и вручную. Но зато можно сказать, что аппаратных проблем для стандартного писюка уже нет.
Сейчас OS распараллеливает программы и потоки. Ничего хорошего и удобного я об этом сказать не могу. Кроме грыжи и расшатанных нервов такая синхронизация не приносит. И процессор, который на внутреннем уровне состоит из нескольких процессоров, выполняет один поток команд. Мы платим деньги только за один поток команд. А теперь представим, у нас есть несколько управляемых процессоров. У каждого процессора есть своя личная память. Мы загружаем в каждый процессор подпрограмму, и выполняем независимо. Пускай даже эти процессоры работают медленнее чем теперешние, но выигрыш мы получим. Единственное что, языки не поддерживают данное начинание.
Mainstream языки ориентированы на последовательное выполнение команд. Максимум поддержки – это ручная синхронизация данных в виде какой-нибудь lock или critical_section. Ничего кроме торможения, и нелокализованных ошибок это не приносит. Но ведь компилятор имеет всю информацию для того, чтобы организовать параллельную обработку данных. И язык должен вынудить программиста писать программы, которые легко распараллелить. Я не сторонник функциональных языков, но они могут такое. Они вынуждают разделять функциональность на функции без состояния. Только входные и выходные параметры. О синхронизации данных, можно забыть. Можно ли это организоваться в ООП программах? Наверняка можно. Есть фичи типа активных объектов. Это когда объект имеет свой поток выполнения. Считай что набор подпрограмм для процессора. Может данная фича мне и не нравится(это мое личное IMHO) но она все-таки есть. И наверняка есть другие способы безопасного распараллеливания. Я боюсь даже догадываться о том, что можно придумать. У компилятора – вся необходимая информация есть. Если он откажется от мысли, что код должен быть именно такой каким его написали, то ограничения снимаются и возможности повышаются.
Возможна ли революция? По моему нет. Практически все что можно в языках программирования придумали в 50-60 годах. И в том числе Algol, Lisp и параллельное программирование. Ничего кардинально нового не появилось. В mainstream остался только Алгол, который стал вбирать многие средства Lisp(и вбирает до сих пор). Но Лиспом он не стал и не станет. Так же и в архитектурах. Intel вбирает в себя параллельную архитектуру (и вбирает до сих пор), но параллельным не станет. А следовательно будем дальше мучиться с синхронизацией shared memory, и оптимизацией качества кода для конкретного процессора.
