Поработаю шлюзом :)
«Очень интересное замечание. Правда я не понял как в ВН028 утроили полосу пропускания.
Она осталась такой же как и у TS201 — два 128-разрядных пакета данных из памяти за такт.
Наверное человека смутило утроение скорости ВН028, по сравнению с аналогом, на БПФ большей размерности.
Всё обьясняется очень просто: как только поток обрабатываемых данных у TS201 начинает превышать
обьем кэша, трафик TS201 начинает снижаться. У ВН028 он остается прежним.
Заменив динамическую память с кэшами на статическую, ВН028 устранил узкое место старой архитектуры
и сделал её более сбалансированной (+ попутно удалилась одна стадия конвейера).
Теперь о „сбалансированности“ архитектуры TS201. Что дают два 128-разрядных пакета данных
за такт? Например, они дают возможность обрабатывать 8 потоков 16-разрядных данных за такт.
ТS201 и делает это. Они дают возможность обрабатывать четыре(!) потока float операндов за такт.
TS201 делает это? Нет. При этом позиционируя себя именно как DSP для обработки таких данных.
Что же у ВН028? А вот он как раз может обрабатывать 4 потока float операндов за такт.
ВН028 однозначно более сбалансирован чем TS201.
Так что если и „колхоз“, то передовой! :D» (C)
«Похоже, что никто не читал юзергайд, но все рассуждают, а некоторые даже осуждают.
Правда многие знают, что вместо динамической памяти, статическая и без кэша. Это уже хорошо :)
Надеюсь скоро узнают, что flops-ов там в 2 раза больше чем у аналога. Что, например, БПФ 1К (cfloat)
ВЦ2 может делать на частоте 400 за тоже время как аналог на 600. Узнают, что в нем тип doule обрабатывается
зв такой же один такт что и float. Что в нём нормальная байтовая адресация и поддержка невыровненного доступа.
Ни слова про собственный компилятор и среду отладки.
Есть там одна ссылка на прайс-лист плат с 5-ю ВЦ2. Там в характеристике пиковой производительности для ВЦ2
по-старинке считается 6 флопс на такт. Для того, кто использует только VDSP и не хочет больше ничего знать,
это верно. Но правильно знать, что 12 флопс за такт и 5 процессоров на 450 МГц дают на пике больше чем аналоги на 600.» (C)
Это всё стоит рассматривать на фоне технологического ландшафта.
Если Эльбрусы были порождены появлением интегральных схем, то к моменту их постановки в серию уже возникли СБИС (VLSI) которые позволили разместить процессор на небольом к-ве микросхем.
Что дешевле, меньше расстояния, можно поднять частоту, меньше ест, надёжнее…
Соответственно было и встречное движение — чтобы разместить процессор на меньшем к-ве микросхем приходится упрощать логику, 32-разрядные системам проще чем 64-разрядным, неожиданный шанс получили 16-разрядные. В очередной раз эволюция прорвалась там, где мало кто ждал.
А в это время на просторах бывшей 1/6 разработчики были больше озабочены вопросом «как прокормить семью».
Это что-то из области «американцы на луне не были» наоборот.
МКП и Э-3 реально существовали, также как и векторный сопроцессор к Э-2.
Эль-90 — разве что на бумаге.
Идеи и опыт, полученные при разработке Эльбрусов несомненно пригодились Интелу.
Но у Интела и своего опыта хватает а идеи… они ведь были описаны, достаточно иметь желание читать.
Спасибо за ссылку. А когда Дийкстра предложил этот механизм? Навскидку я не нашел.
Но в Эльбрусе механизм Dijkstra display содержит зарезервированные индексы — 0 для ОС, 1 для программ, 2 для библиотек. Именно это я имел ввиду когда говорил о привилегиях.
Суперскалярность Эльбруса похожа на Интел , но не очень.
Слово «контекст» употребляется в статье для указания на текущую выполняемую процедуру.
Контекст в смысле контекст потока, используемый ОС для переключения, конечно тоже существовал, но явного описания его я не нашел.
Итаниум появился на 20 лет позже и он совсем в другой парадигме живёт — явного параллелизма.
Сами по себе стековые процессоры появились задолго до Эльбруса и отлично себя показали.
Не знаю что там начали требовать программы через 20 лет, но фортран он и до сих пор фортран, например.
Компилятор С для него не написали, впрочем, в начале 80-х совсем неочевидно было, что тот выстрелит.
«МКП, как и Эльбрус-3, был убит „перестройкой“ — прекращением финансирования обронной тематики. Потому и резали „по живому“, закрывая темы, что финансирование упало многократно, пытались сохранить хоть что-то, при этом волей-неволей приходилось прикрывать почти все разработки.» (C)
Стековые команды отлично совместимы с кэшем.
Внутренний паралеллизм они тоже не исключают.
Э-1 и Э-2 близки по архитектуре, элементная база разная.
Возможно слово переименование у него имело какой-то другой смысл,
чем общепринятый сейчас.
В некотором смысле регистры действительно переименовывались внутри, хотя прямого доступа к ним (к верхушке стека) именно как к регистрам не было.
ДОС Примус (ЕС-1021, если не ошибаюсь), с которой удалось соприкоснуться, легко тянула 32 терминала на 64 килобайтах озу
Но 100К на Эльбрусе — это вряд ли.
Виртуальные машины были на поздних ЕС-ках.
IMHO оно несбалансировано, деградирует при интенсивной вставке/удалении.
Кроме того, предназначено для хранения точек, прямоугольники потребуют удвоения размерности дерева, что усугубит вышеуказанные проблемы.
Не используется (я не знаю, во всяком случае) в СУБД.
Может, дать процессам ручку — чтоб они сами себе коммит делали, когда считают это правильным?
И системе легче и пользователи начнут жить в другой парадигме.
Отчасти так, но мы не знаем в какой последовательности данные потребуются пользователям. Пользователи зачастую знают, но у них нет средств подсказать системе.
Фактически все сведется к случайному чтению/записи диска и бороться с этим бессмысленно.
Хотя, для SSD дисков проблема не столь катастрофична.
А вообще, ваша персистентная память до боли напоминает работу СУБД:
Похожий вопрос, допустим, у меня матрица на несколько гигабайт и я её диагонализую (методом Якоби), много пишу, записи случайно распределены по адресному пространству.
Каждая конкретная страница меняется относительно редко, но в целом поток изменений огромен.
Как быть?
«Очень интересное замечание. Правда я не понял как в ВН028 утроили полосу пропускания.
Она осталась такой же как и у TS201 — два 128-разрядных пакета данных из памяти за такт.
Наверное человека смутило утроение скорости ВН028, по сравнению с аналогом, на БПФ большей размерности.
Всё обьясняется очень просто: как только поток обрабатываемых данных у TS201 начинает превышать
обьем кэша, трафик TS201 начинает снижаться. У ВН028 он остается прежним.
Заменив динамическую память с кэшами на статическую, ВН028 устранил узкое место старой архитектуры
и сделал её более сбалансированной (+ попутно удалилась одна стадия конвейера).
Теперь о „сбалансированности“ архитектуры TS201. Что дают два 128-разрядных пакета данных
за такт? Например, они дают возможность обрабатывать 8 потоков 16-разрядных данных за такт.
ТS201 и делает это. Они дают возможность обрабатывать четыре(!) потока float операндов за такт.
TS201 делает это? Нет. При этом позиционируя себя именно как DSP для обработки таких данных.
Что же у ВН028? А вот он как раз может обрабатывать 4 потока float операндов за такт.
ВН028 однозначно более сбалансирован чем TS201.
Так что если и „колхоз“, то передовой! :D» (C)
Правда многие знают, что вместо динамической памяти, статическая и без кэша. Это уже хорошо :)
Надеюсь скоро узнают, что flops-ов там в 2 раза больше чем у аналога. Что, например, БПФ 1К (cfloat)
ВЦ2 может делать на частоте 400 за тоже время как аналог на 600. Узнают, что в нем тип doule обрабатывается
зв такой же один такт что и float. Что в нём нормальная байтовая адресация и поддержка невыровненного доступа.
Ни слова про собственный компилятор и среду отладки.
Есть там одна ссылка на прайс-лист плат с 5-ю ВЦ2. Там в характеристике пиковой производительности для ВЦ2
по-старинке считается 6 флопс на такт. Для того, кто использует только VDSP и не хочет больше ничего знать,
это верно. Но правильно знать, что 12 флопс за такт и 5 процессоров на 450 МГц дают на пике больше чем аналоги на 600.» (C)
Если Эльбрусы были порождены появлением интегральных схем, то к моменту их постановки в серию уже возникли СБИС (VLSI) которые позволили разместить процессор на небольом к-ве микросхем.
Что дешевле, меньше расстояния, можно поднять частоту, меньше ест, надёжнее…
Соответственно было и встречное движение — чтобы разместить процессор на меньшем к-ве микросхем приходится упрощать логику, 32-разрядные системам проще чем 64-разрядным, неожиданный шанс получили 16-разрядные. В очередной раз эволюция прорвалась там, где мало кто ждал.
А в это время на просторах бывшей 1/6 разработчики были больше озабочены вопросом «как прокормить семью».
МКП и Э-3 реально существовали, также как и векторный сопроцессор к Э-2.
Эль-90 — разве что на бумаге.
Идеи и опыт, полученные при разработке Эльбрусов несомненно пригодились Интелу.
Но у Интела и своего опыта хватает а идеи… они ведь были описаны, достаточно иметь желание читать.
Но в Эльбрусе механизм Dijkstra display содержит зарезервированные индексы — 0 для ОС, 1 для программ, 2 для библиотек. Именно это я имел ввиду когда говорил о привилегиях.
Слово «контекст» употребляется в статье для указания на текущую выполняемую процедуру.
Контекст в смысле контекст потока, используемый ОС для переключения, конечно тоже существовал, но явного описания его я не нашел.
Сами по себе стековые процессоры появились задолго до Эльбруса и отлично себя показали.
Не знаю что там начали требовать программы через 20 лет, но фортран он и до сих пор фортран, например.
Компилятор С для него не написали, впрочем, в начале 80-х совсем неочевидно было, что тот выстрелит.
«МКП, как и Эльбрус-3, был убит „перестройкой“ — прекращением финансирования обронной тематики. Потому и резали „по живому“, закрывая темы, что финансирование упало многократно, пытались сохранить хоть что-то, при этом волей-неволей приходилось прикрывать почти все разработки.» (C)
Стековые команды отлично совместимы с кэшем.
Внутренний паралеллизм они тоже не исключают.
Возможно слово переименование у него имело какой-то другой смысл,
чем общепринятый сейчас.
В некотором смысле регистры действительно переименовывались внутри, хотя прямого доступа к ним (к верхушке стека) именно как к регистрам не было.
Но 100К на Эльбрусе — это вряд ли.
Виртуальные машины были на поздних ЕС-ках.
Да, звучит забавно, не решился подменить.
Кроме того, предназначено для хранения точек, прямоугольники потребуют удвоения размерности дерева, что усугубит вышеуказанные проблемы.
Не используется (я не знаю, во всяком случае) в СУБД.
Но не в качестве эмулятора именно, а скорее для того, чтобы не упустить что-нибудь важное.
И системе легче и пользователи начнут жить в другой парадигме.
Фактически все сведется к случайному чтению/записи диска и бороться с этим бессмысленно.
Хотя, для SSD дисков проблема не столь катастрофична.
А вообще, ваша персистентная память до боли напоминает работу СУБД:
Каждая конкретная страница меняется относительно редко, но в целом поток изменений огромен.
Как быть?