Search
Write a publication
Pull to refresh
313
0.2
Валерий Черепенников @vvvphoenix

Vice President NNRC, Советник Губернатора НО

Send message
По идее подобные алгоритмы надо бы поддерживать добавляя(и убирая) новые блоки на SOC, а не новые инструкции. Но это из области тех самых благих намерений...:(
Я тоже раньше был равнодушен к энергоптреблению. Для существующих систем это и правда не так важно. Но вот при проектировке будущих эти соображения вылезают на первый план. Мы все сильнее упираемся рогами в разного рода power wallы…
Спасибо за ссылочку. Хороший набор бенчей из уважаемого источника. Жалко только что AMD Rome там нет. Картинка была бы полнее.
Н-да. Занятно. Я тот комментарий писал к комментарию про Стивена Морса и его высказывания как он боролся с 8086 в одно личико.

Спасибо. Классный график :) Однако есть ещё некоторое количество "безымянных" опкодов. Ну то есть команда есть, а названия у неё нет. И документации как правило тоже нет. Но если знаешь — можно emitами в код вставлять. Но в целом я думаю они не более 1% инструкций

Писал выше уже. Да этот так. Можно пойти еще дальше и закодировать часто встречающиеся инструкции и последовательности арифметическими (или хаффмановскими кодами). Плата за это — невозможность параллелить декодирование.
Ага. Это хороший пойнт. Google, Amazon и Facebook — никогда не берут топ бины(в отличие от HPC). Они берут системы на 2-3 ступеньки ниже по частоте. Потому что в их прилагах много задержек из за памяти, сетки и тп. И они не хотят платить за циклы, которые процессор намолотит ожидая данные
нет механизма «перерождения» вычислительной системы, кроме как переписывать ПО (пусть даже не 100%) с использованием человека.
На моей памяти таких моментов было несколько. SIMD, многоядерность. И да — каждый из них требовал серьезного перелопачивания всей экосистемы. Ну по крайней мере перекомпиляции. Но каждая такая революция была «бархатной». Происходила постепенно и требовала много времени…
Отличие в том, что ARM должен согласовывать спецификации с каждым из больших вендоров. И шансов ошибиться у него намного меньше при этом. А Интел не должен ни с кем. И часто решения принимаются одним человеком.
Я верю в философскую теорему о том, что «только открытые системы могут быть устойчивы». ARM — открытая система. Интел -нет
Согласен. RISC и CISC — это не четко определенные термины. Скорее «понятия» :)
Подумал о том, что ARM — это консорциум вендоров. А Интел -одна компания, пусть и большая. И решения там принимают люди. Очень умные. Но людям свойственно ошибаться. Поэтому в истории X86 так много было странных решений. Просто эти решения принимались гораздо меньшим числом людей. Иногда вообще одним человеком
Может не надо оживлять призраков. Мало ли… :)
ну по идее 2.5 из 4 нормально. Если это конечно не Linpack. :) Но есть несколько вопросов -сколько всего команд предоставляет архитектура (примерно)? сколько времени разрабатывается компилятор? В интеле компилятор для Itanium задышал лет через 5 только. И самое главное — если в системе добавляются новые инструкции, сколько времени уйдет на перестройку компилятора?
Посмотрел бенчмарки — интересно, спасибо. Потом гляну повнимательнее еще. Первое впечатление — там где требуются длинные SIMD ARM конечно проигрывает. А в остальном — вполне себе ничего
А кто говорил, что он устаревший. Я только говорил, что груз legacy велик. А так он живее всех живых :)
Ну деклараций о намерениях в этом мире всегда хватало… Я то имел в виду, что более или менее реальная жизнь началась, когда ARM взялся за SVE. Имея на вооружении только 128 bit SIMD (NEON) на этом рынка кокнурировать сложно…
Вот что подумал — arm — консорциум вендоров. А Интел — одна компания. И решения в ней принимает гораздо меньшее число людей. А людям свойственно ошибаться. И поэтому в x86 гораздо больше странных решений…
Может все же не стоит оживлять призраков? Мало ли… :)

Согласен. Всегда говорил, что не надо программистам мозги ассемблером забивать. У них и так есть баги, дедлайны и начальство. :) И компилятора тоже не надо, самый лучший язык — Java :)

Вот в том то и дело. Хороший дизайн ISA должен закладывать возможности расширения с самого начала. только вот осознали этот очевидный в общем то факт уже в конце 80'х…

Information

Rating
2,499-th
Location
Нижний Новгород, Нижегородская обл., Россия
Works in
Date of birth
Registered
Activity