Комментарии 16
Здравствуйте. С огромным интересом прочитал цикл про стековое представление. Задача обобщения представления параллелизма в коде программы, судя по комментариям, понятна очень не всем, :), но это, наверное, нормально. Скажите, а подход Мультиклета Вы анализировали? Фактически, насколько я понимаю, они сделали именно то, что Вы предлагаете — закодировали дерево операций в бинарном представлении, только, дополнительно, научились в определённой степени обходиться вообще без регистров (прямое соединение нескольких АЛУ в рантайме). Я, к сожалению, не нашёл времени разобраться в этой архитектуре совсем детально, но навскидку подход кажется очень правильным.
Здравствуйте!
С Мультиклетом дотошно не разбирался, первое впечатление… неоднозначное.
Общий коммутатор мне не нравится, как эффективно всё это компилировать не очень понятно.
Но может это просто первое впечатление.
С Мультиклетом дотошно не разбирался, первое впечатление… неоднозначное.
Общий коммутатор мне не нравится, как эффективно всё это компилировать не очень понятно.
Но может это просто первое впечатление.
Но подход-то 100% Ваш? Положить явное дерево в бинарный код и скрыть за деревьями реализацию (степень параллелизма) реального хардвера. Ведь бинарник мультиклета, насколько я понимаю, делает именно это — там параметр инструкции — это чтение из регистра, памяти или прямо указание на выход другой инструкции. (За это, кстати, они заплатили полной невозможностью использовать хоть как-то инфраструктуру gcc, да и, думаю, llvm тоже в терминах деревьев исполняемый код генерировать не умеет.)
В тексте упоминаются стековые компьютеры, но странно, что нет упоминания стекового процессора GreenArrays 144
http://www.greenarraychips.com/home/products/
http://www.greenarraychips.com/home/products/
Этот продукт эксплуатирует другую идею — раз стековый процессор такой простой, давайте наделаем их целую кучу на одном кристалле и посмотрим что из этого получится.
А еще раньше были транспьютеры.
А еще раньше машиносчетные станции :)
На мой взгляд это продукт.с очень узкой экологической нишей.
А еще раньше были транспьютеры.
А еще раньше машиносчетные станции :)
На мой взгляд это продукт.с очень узкой экологической нишей.
Интересно, существуют процессоры, в которых нет регистров, но есть стек, вершина которого (некоторое количество машинных слов) хранится не в памяти, а во внутреннем(-их) регистре(-ах)? Ещё видится полезным, чтобы стек был не единственным, чтобы их было хотя бы два, чтобы переключаться между ними.
Вот, например: http://bernd-paysan.de/4stack.html
Подход интересный, но вы пишете о конвеерах, на мой взгляд любая конвеерезация и кешы очень плохо согласуются с быстрой реакцией на внешние раздражители, то есть если надо будет обработать прерывание, то конвеер придётся сбросить и кеш очистить, а это очень времязатратно и чем эти штуки были мощнее тем хуже. Какие есть идеи на этот счёт?
Второй момент, как мне кажется он напрямую уже коснулся Мультиклета вот тут я описываю:(http://multiclet.com/community/boards/3/topics/27?r=1636#message-1636). Суть, в кратце: несколько потоков это не для скорости выполнения, а необходимость, как логическая еденица в написании программ (две разные программы выполняемые одновременно и т.п.), соответственно одно суперчислодробильное ядро (хорошо конвееризованное в вашем случае) это не панацея и надо ещё думать как плотненько вычислить несколько потоков с совершенно разными требованиями к вычислительным ресурсам. То есть, сильно укрупняться мы не можем — много ресурсов будет использоваться неэффективно, сильно упрощаться — тоже, тогда один неделимый поток будет еле ползти. Если вы думаете о максимальной производительности, подумайте и об этом.
Второй момент, как мне кажется он напрямую уже коснулся Мультиклета вот тут я описываю:(http://multiclet.com/community/boards/3/topics/27?r=1636#message-1636). Суть, в кратце: несколько потоков это не для скорости выполнения, а необходимость, как логическая еденица в написании программ (две разные программы выполняемые одновременно и т.п.), соответственно одно суперчислодробильное ядро (хорошо конвееризованное в вашем случае) это не панацея и надо ещё думать как плотненько вычислить несколько потоков с совершенно разными требованиями к вычислительным ресурсам. То есть, сильно укрупняться мы не можем — много ресурсов будет использоваться неэффективно, сильно упрощаться — тоже, тогда один неделимый поток будет еле ползти. Если вы думаете о максимальной производительности, подумайте и об этом.
Если я правильно понял, имеются ввиду затраты на переключение потоков.
Вытеснение потока очень дорогая операция уже хотя бы потому,
что скорее всего произойдет полное вытеснение его данных из кэша.
Данные высокоприоритетных потоков можно было бы не вытеснять,
но увы, кэширование ведется в физических адресах.
С другой стороны, если переключение происходит 1000 раз в секунду на ядро при
частоте в 1Ггц, несколько тысяч потерянных тактов составят всего-лишь несколько процентов потерянной производительности.
Вытеснение потока очень дорогая операция уже хотя бы потому,
что скорее всего произойдет полное вытеснение его данных из кэша.
Данные высокоприоритетных потоков можно было бы не вытеснять,
но увы, кэширование ведется в физических адресах.
С другой стороны, если переключение происходит 1000 раз в секунду на ядро при
частоте в 1Ггц, несколько тысяч потерянных тактов составят всего-лишь несколько процентов потерянной производительности.
Вы озвучиваете "классическую" проблему "универсальности", если хочется "реального времени", то придется пожертвовать "скоростью", и наоборот. В условиях, когда просессора начинают делиться на уровне ядер по специализации, и на управляющие/сопроцессора, реализовать гомогенную систему делать смысла нет. Решение только одно, на прерывания должен реагировать специализированный процессор с OS.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Суперскалярный стековый процессор: скрещиваем ужа и ежа