Здравствуйте, ononim, Вы писали:
V>>На твоём графике надо читать так, что Microchip Technology противопоставляется Atmel и AVR? O>В серъезных девайсах доля AVR тождественно равна нулю.
Еще и ссылка нерелевантная.
V>>Это ж двойное пробитие двойного дна. V>>Кароч, кыш отседа, школота. O>Кыш-кыш хипстерье.
Да школота, без вариантов. ))
Последние лет 7+ Atmel более переехал на ARM-ядра.
Но у AVR была ж целая эпоха, про которую школота ни слухом, ни духом.
В исходном посте была ретроспектива, но ты и этого умудрился не уловить.
A>Почему тогда не вспомнить как Transmeta пыталась укрепиться на рынке со своими VLIW-процессорами?
Crusoe юыли обычные 32хбитные процы. Они ничем не были качественно лучше имеющихся процов для конечных потребителей. Переход на дешевые и шустрые 64 бита, при посредственном 32хбитном режиме совместимости — это возможно рынок бы съел, но он не съел просто дешевые 32битные crusoe посредственной производительности — таких камней и так было в избытке.
И не съел дорогие IA64 с посредственным (а изначально никаким) 32хбитным режимом совместимости от интела, так как уже были дешевые AMD64. А топ менежмент вместо того чтобы брать рынок демпингом — начал тупо играть монопольными связями.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Gt_, Вы писали:
Gt_>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву
Meldown не всегда важен. Скажем, если я на своем личном компьютере вычислительные рассчеты вычисляю, что мне до вашего meldown'а?
Здравствуйте, netch80, Вы писали:
N>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
У Эльбруса есть же, вроде, команда предвыборки. Так что она ШК запускает предвыборку, потом идет еще несколько команд, которые чем-то другим занимаются, потом очередная ШК обрабатывает ранее заказанные данные.
Другой вопрос, что это требует очень умного компилятора. А успехи компиляторных наук, насколько я в курсе, не оправдали надежд, которые на них возлагались в 70-е. Возможно, если бы в моде были более другие языки программирования, более предназначенные для статического анализа, ситуация была бы несколько другая, но пока имеем, что имеем...
Здравствуйте, ononim, Вы писали:
A>>Почему тогда не вспомнить как Transmeta пыталась укрепиться на рынке со своими VLIW-процессорами? O>Crusoe юыли обычные 32хбитные процы. Они ничем не были качественно лучше имеющихся процов для конечных потребителей. Переход на дешевые и шустрые 64 бита, при посредственном 32хбитном режиме совместимости — это возможно рынок бы съел, но он не съел просто дешевые 32битные crusoe посредственной производительности — таких камней и так было в избытке. O>И не съел дорогие IA64 с посредственным (а изначально никаким) 32хбитным режимом совместимости от интела, так как уже были дешевые AMD64. А топ менежмент вместо того чтобы брать рынок демпингом — начал тупо играть монопольными связями.
Transmeta со своими VLIW-процессорами никогда не толкалась в тех же нишах, на которые целился VLIW от Intel (EPIC/IA64).
Получись у Transmeta в середине 2000-х и внутри современных планшетов/мобильников/нетбуков были бы не ARM'ы, а множество VLIW.
Для бытовой же техники, вроде домашних роутеров, сотовых и VoIP-телефонов, более чем достаточно MIPS'ов.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Gt_, Вы писали:
Gt_>>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву
Pzz>Meldown не всегда важен. Скажем, если я на своем личном компьютере вычислительные рассчеты вычисляю, что мне до вашего meldown'а?
а типа мелтдаун будет спрашивать чего ты там хочешь делать на личном компютере. может ему биткоины майнить важнее.
Gt_>>а типа мелтдаун будет спрашивать чего ты там хочешь делать на личном компютере. может ему биткоины майнить важнее.
Pzz>Мелтдаун позволяет читать память, а не запускать произвольный код.
Здравствуйте, Gt_, Вы писали:
Gt_>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву
Meltdown — обычный аппаратный баг и он уже исправлен в последних процессорах Intel, без потери производительности.
Gt_>>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву C>Meltdown — обычный аппаратный баг и он уже исправлен в последних процессорах Intel, без потери производительности.
интел то чем вам насалолил ? баг архитектурный, не только в интеле. он и ibm power и в арме. без защищенного режима в стиле эльбруса это и не вылечить. причем мелтдаун лишь одна из самых очевидных вариаций. там еще парочку вариаций уже наковряли.
Pzz>У Эльбруса есть же, вроде, команда предвыборки. Так что она ШК запускает предвыборку, потом идет еще несколько команд, которые чем-то другим занимаются, потом очередная ШК обрабатывает ранее заказанные данные.
Pzz>Другой вопрос, что это требует очень умного компилятора. А успехи компиляторных наук, насколько я в курсе, не оправдали надежд, которые на них возлагались в 70-е. Возможно, если бы в моде были более другие языки программирования, более предназначенные для статического анализа, ситуация была бы несколько другая, но пока имеем, что имеем...
А каким образом компилятор будет знать за сколько тактов придут данные и насколько заранее надо запускать предвыборку?
Если все в кеше уже, то наверное проще, и то я не уверен что латенси не будет плавать (например из-за обеспечения когерентности).
А в случае внешней памяти все вообще становится очень плохо.
Потом команда предвыборки это все-таки команда, ее еще надо из памяти прочитать, да в кеше место занимает.
Да и она у всех наверное есть, использовать ее тяжело.
Здравствуйте, Gt_, Вы писали:
Gt_>>>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву C>>Meltdown — обычный аппаратный баг и он уже исправлен в последних процессорах Intel, без потери производительности. Gt_>интел то чем вам насалолил ?
Intel — основная жертва. Meltdown работает из-за того, что биты защиты проверяются после спекуляции. В AMD сразу всё работало правильно, потому Meltdown'у он не подвержен.
Gt_>баг архитектурный, не только в интеле. он и ibm power и в арме. без защищенного режима в стиле эльбруса это и не вылечить. причем мелтдаун лишь одна из самых очевидных вариаций. там еще парочку вариаций уже наковряли.
Это семейство Spectre, которое, действительно, архитектурное.
Здравствуйте, Marty, Вы писали: M>https://alexanius-blog.blogspot.com/2017/01/2017.html — чувак размышляет, как из C сделать C++
Да там вообще сплошной фейспалм. От чувака, который занимается _компиляторами_, ожидается чуть больше понимания в этих вопросах.
Из простейшего — "убрать слова register / auto / inline". Он, как автор компилятора, запросто может их игнорировать безо всякого вмешательства комитета по стандартизации.
Из более сложного — рассуждения про eval и рекомпиляцию. Ну, как бы в 2017 году быть не в курсе того, как устроен JIT в CLR/JVM — очень, очень странно.
В общем, складывается впечатление, что автор вообще никаких языков, кроме С, вблизи не видел. Слышал что-то про С++, но дальше — fog of war.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gardener, Вы писали:
G>А каким образом компилятор будет знать за сколько тактов придут данные и насколько заранее надо запускать предвыборку?
Ну в принципе, скорость DRAM примерно одинаковая...
G>Если все в кеше уже, то наверное проще, и то я не уверен что латенси не будет плавать (например из-за обеспечения когерентности).
Я сильно сомневаюсь, что Эльбрус аппаратно сильно парится насчет обеспечения когерентности. Вообще, из известных мне процессоров аппаратная когерентность встречается только у интела/амд. У всяких прочих армов и мипсов это делается програмно.
Здравствуйте, a7d3, Вы писали:
A>Касаемо полезности динамического анализа для реордеринга операций — в эльбрусах это решили компенсирующим кодом. Для того чтобы спокойно обыгрывать коллизии с зависимостях между отдельными load/store операциями, относительно которых компилятор не был уверен. Такой подход получился опять же проще и дешевле чем в x86.
A>И т.д. и т.п.
Такое впечатление, что ты знаешь систему команд Эльбруса.
Поделись информацией!
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, a7d3, Вы писали:
A>>Касаемо полезности динамического анализа для реордеринга операций — в эльбрусах это решили компенсирующим кодом. Для того чтобы спокойно обыгрывать коллизии с зависимостях между отдельными load/store операциями, относительно которых компилятор не был уверен. Такой подход получился опять же проще и дешевле чем в x86.
A>>И т.д. и т.п.
A>Такое впечатление, что ты знаешь систему команд Эльбруса. A>Поделись информацией!
G>>А каким образом компилятор будет знать за сколько тактов придут данные и насколько заранее надо запускать предвыборку?
Pzz>Ну в принципе, скорость DRAM примерно одинаковая...
У меня пяти-портовый DDR контроллер. Когда система idle, латенси практически стабильная с всплесками думается из-за рефреша. А вот когда идет большой трафик пакетов, то все — различается в несколько раз от чтения до чтения. Несколько мастеров лезут в эту память, пишут-читают, контроллер еще шедулит запросы по-разному. Бороться с этим можно конечно, но побороть до конца нельзя. И цена растет.
И там же три небольших процессора идут к одному арбитру, а потом уже одинь путь в DDR controller. И тут уже латенси прыгает вообще сильно когда они все лезут в память.
G>>Если все в кеше уже, то наверное проще, и то я не уверен что латенси не будет плавать (например из-за обеспечения когерентности).
Pzz>Я сильно сомневаюсь, что Эльбрус аппаратно сильно парится насчет обеспечения когерентности. Вообще, из известных мне процессоров аппаратная когерентность встречается только у интела/амд. У всяких прочих армов и мипсов это делается програмно.
Ну и потом, все системы разные. Как DDR latency может быть разные, так и архитектуры (интерконнект и прочее), не перекомпилировать же каждый раз.
И потом, данные или код могут быть в кеше уже, а могут и нет. Могут быть в L1 или L2. Не угадаешь latency.
Здравствуйте, netch80, Вы писали:
N>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая.
А на деле, даже вшивые RISC-микроконтроллеры имеют до 4-х стадий исполнения команды.
N>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
Команды fapb загружаются в специальный буфер инструкций предподкачки (Prefetch Instruction Buffer -PIB) и, циклически повторяясь, работают асинхронно по отношению к основной программе. Подкачанные ими данные помещаются в специальный буфер предварительно подкачанных массивов (Array Prefetch Buffer — APB), откуда непосредственно перед использованием пересылаются синхронными командами пересылки элементов массивов (mova) в регистровый файл. Таким образом, компилятор, обнаружив в программе регулярный доступ к данным, может реализовать предварительное асинхронное их считывание, забросив операции считывания на достаточное для подкачки расстояние от команд, использующих данные. Далее можно в коде программы заменить все инструкции загрузки из памяти (load) на инструкции пересылки данных (mova) из буфера APB.
Здравствуйте, Sinclair, Вы писали:
S>Из простейшего — "убрать слова register / auto / inline". Он, как автор компилятора, запросто может их игнорировать безо всякого вмешательства комитета по стандартизации.
Он пишет философский текст о том, каким должен был бы быть язык С, если его проектировать сейчас, с учетом накопленного опыта. Понятно, что это текст философский, никто так делать не будет, потому что груз совместимости и всякое такое.
Слова register/auto/inline в современном С действительно, лишние.
S>Из более сложного — рассуждения про eval и рекомпиляцию. Ну, как бы в 2017 году быть не в курсе того, как устроен JIT в CLR/JVM — очень, очень странно.
Ты высказался про имплементацию, он высказался про спецификацию языка.
