Здравствуйте, netch80, Вы писали:

V>>Не Эльбрус, конечно, но круче архитектуры x64 в бесконечное кол-во раз.
V>>Смотришь, и глаз радуется. ))
N>Чему именно радуется?
N>VLIW? Так неуместно же для такой области.

Какой "такой"?
Современный комп/ноут/планшет — это платформа для аудио-видео приложений.
Людям надо общаться, смотреть киношки, играть в игрушки.
Сейчас даже обучающий софт очень и очень интерактивный.
Или читался "голосовая".
Ну конечно, только такая мультимедийные архитектуры, как Эльбрус или IA64 максимально уместны.

А вот x86 максимально неуместна для таких приложений.
Аудио-кодеки для интернета всё-равно же в CPU выполняются.
Ты же работал с SIP когда-то, должен помнить. ))


N>Структура команды? Так после блока разбора переменность длины и всякие префиксы/суффиксы уже пофиг. А вот необходимость связывать в бандлы — мешает.

Не вижу раскрытия темы.


N>128 регистров? Никто их столько не используют, 99.9% кода даже 32 не занимают.

Дык, есть команды обращения к текущему "окну" шириной в 8 или 32 регистра.

Как раз операционка может использовать одни регистры, прикладные приложения — другие, причем разные.
Для текущего потока один раз выставляет адрес "окна" регистров.
Оч удобно, как по мне. Можно добиться, чтобы было меньше свопа регистрового файла при переключении контекстов/потоков.



N>Равнозначность регистров? Переименование решает эту проблему для большинства случаев.

Самая большая ложь, которую я вижу тут постоянно. ))
Переименование регистров не решает проблему кучи лишних пар PUSH/POP, вызванных этой неуниверсальностью.



V>>И оно дешевле в пересчёте на транзистор при аналогичных объемах выпуска...
N>Дешевле что именно?

Производительность к кол-ву транзисторов.


N>Всё равно сейчас процентов 80 это кэш.

Дык, с удвоенным кешем L0 и процы почти вдвое больше стоят. ))


N>Дальше блоки предсказаний и разбора кода — ну, вот на последнем можно кое-как сэкономить.

А это, батенька, у нас основной тепловыделитель, то бишь ограничитель частоты.


V>>И тут AMD обломала весь кайф )))
N>Да-да. Просто они сделали то, что можно было очень легко сделать прямо сейчас и получить плавный переход.

Ну, для AMD речь стояла не о "плавном переходе", а о "жить или умереть".
AMD пришлось продать все свои заводы в США и перейти на полностью заказной выпуск чипов.
Но на эти деньги от проданных заводов они разработали и отладили новую архитектуру, т.е. банально выжили как экономическая единица.


N>Причём воспользоваться минимальными усилиями в плане собственно компиляции (open64 вообще на коленке сляпан, а доработать gcc было легко

Да как легко-то? Куча новых регистров (Rx), способ линковки и релокации символов другой совершенно.
Всё это потребовало денег и людских ресурсов.


N>(Я говорю о том, что и при этом можно было целую пачку вещей улучшить, но они забили болт.)

Да какой болт? ))
AMD на последнем финансовом издыхании всё это делала.
Что смогли, то сделали.

Собсно, цель была дать возможности работать 32-разрядным приложениям в 64-битной ОС. Только научив свою архитектуру такой работе можно было выжить. Вот с этим моментом они справились просто на отлично. Согласись, что остальные моменты на фоне этого, главного, просто меркнут.


N>Причём, я уверен, если бы они подождали развития новых технологий ещё лет 20, а потом бы стали строить что-то подобное Itanium — у них бы получилось лучше.

Ну, они украли дековскую Альфу и наш Эльбрус. Им надо было конвертировать наворованно в прибыль "сейчас", а не "потом". ))


N>А так — попытка построения в 2000 на концепциях в лучшем случае начала 90-х. Если не раньше.

Э-э-э... Давай уточним. Речь идёт о концепциях суперкомпьютеров, которые (концепции) решили применить в декстопном проце.
Так-то практически все концепции даже современных процов уже были опробованы еще в 70-80-е.
И защищенная память, и ОоО и вообще всё.


N>Ну ты вот веришь, что вложениями могло бы её поднять до чего-то сносного. Я — не верю. Причины тут прожужжались уже много раз.

Да нет никаких причин, кроме запроса рынка.


N>2. Оно само разбирает цикл уже на этапе JIT или native generation. На уровне IL это цикл.

Дык, на уровне исходника тоже цикл. Ничего не меняется, оптимизирующий компилятор должен этот IL преобразовать.


N>Я бы скорее ожидал что-то в духе Agnerʼовского ForwardCom (где длина вектора, обработанного одной командой, в принципе не ограничена) — переложить это на конкретную ограниченную длину уже банально. Хотя и оно заточено под текущую схему концепций соотношения команды и кэша.

Ну это когда оптимизатор совсем уж тупой. ))

Здравствуйте, netch80, Вы писали:

V>>Не Эльбрус, конечно, но круче архитектуры x64 в бесконечное кол-во раз.
V>>Смотришь, и глаз радуется. ))
N>Чему именно радуется?
N>VLIW? Так неуместно же для такой области.

Какой "такой"?
Современный комп/ноут/планшет — это платформа для аудио-видео приложений.
Людям надо общаться, смотреть киношки, играть в игрушки.
Сейчас даже обучающий софт очень и очень интерактивный.
Или читалка "голосовая".
Ну конечно, только такая мультимедийные архитектуры, как Эльбрус или IA64 максимально уместны.

А вот x86 максимально неуместна для таких приложений.
Аудио-кодеки для интернета всё-равно же в CPU выполняются.
Ты же работал с SIP когда-то, должен помнить. ))


N>Структура команды? Так после блока разбора переменность длины и всякие префиксы/суффиксы уже пофиг. А вот необходимость связывать в бандлы — мешает.

Не вижу раскрытия темы.


N>128 регистров? Никто их столько не используют, 99.9% кода даже 32 не занимают.

Дык, есть команды обращения к текущему "окну" шириной в 8 или 32 регистра.

Как раз операционка может использовать одни регистры, прикладные приложения — другие, причем разные.
Для текущего потока один раз выставляет адрес "окна" регистров.
Оч удобно, как по мне. Можно добиться, чтобы было меньше свопа регистрового файла при переключении контекстов/потоков.



N>Равнозначность регистров? Переименование решает эту проблему для большинства случаев.

Самая большая ложь, которую я вижу тут постоянно. ))
Переименование регистров не решает проблему кучи лишних пар PUSH/POP, вызванных этой неуниверсальностью.



V>>И оно дешевле в пересчёте на транзистор при аналогичных объемах выпуска...
N>Дешевле что именно?

Производительность к кол-ву транзисторов.


N>Всё равно сейчас процентов 80 это кэш.

Дык, с удвоенным кешем L0 и процы почти вдвое больше стоят. ))


N>Дальше блоки предсказаний и разбора кода — ну, вот на последнем можно кое-как сэкономить.

А это, батенька, у нас основной тепловыделитель, то бишь ограничитель частоты.


V>>И тут AMD обломала весь кайф )))
N>Да-да. Просто они сделали то, что можно было очень легко сделать прямо сейчас и получить плавный переход.

Ну, для AMD речь стояла не о "плавном переходе", а о "жить или умереть".
AMD пришлось продать все свои заводы в США и перейти на полностью заказной выпуск чипов.
Но на эти деньги от проданных заводов они разработали и отладили новую архитектуру, т.е. банально выжили как экономическая единица.


N>Причём воспользоваться минимальными усилиями в плане собственно компиляции (open64 вообще на коленке сляпан, а доработать gcc было легко

Да как легко-то? Куча новых регистров (Rx), способ линковки и релокации символов другой совершенно.
Всё это потребовало денег и людских ресурсов.


N>(Я говорю о том, что и при этом можно было целую пачку вещей улучшить, но они забили болт.)

Да какой болт? ))
AMD на последнем финансовом издыхании всё это делала.
Что смогли, то сделали.

Собсно, цель была дать возможности работать 32-разрядным приложениям в 64-битной ОС. Только научив свою архитектуру такой работе можно было выжить. Вот с этим моментом они справились просто на отлично. Согласись, что остальные моменты на фоне этого, главного, просто меркнут.


N>Причём, я уверен, если бы они подождали развития новых технологий ещё лет 20, а потом бы стали строить что-то подобное Itanium — у них бы получилось лучше.

Ну, они украли дековскую Альфу и наш Эльбрус. Им надо было конвертировать наворованно в прибыль "сейчас", а не "потом". ))


N>А так — попытка построения в 2000 на концепциях в лучшем случае начала 90-х. Если не раньше.

Э-э-э... Давай уточним. Речь идёт о концепциях суперкомпьютеров, которые (концепции) решили применить в декстопном проце.
Так-то практически все концепции даже современных процов уже были опробованы еще в 70-80-е.
И защищенная память, и ОоО и вообще всё.


N>Ну ты вот веришь, что вложениями могло бы её поднять до чего-то сносного. Я — не верю. Причины тут прожужжались уже много раз.

Да нет никаких причин, кроме запроса рынка.


N>2. Оно само разбирает цикл уже на этапе JIT или native generation. На уровне IL это цикл.

Дык, на уровне исходника тоже цикл. Ничего не меняется, оптимизирующий компилятор должен этот IL преобразовать.


N>Я бы скорее ожидал что-то в духе Agnerʼовского ForwardCom (где длина вектора, обработанного одной командой, в принципе не ограничена) — переложить это на конкретную ограниченную длину уже банально. Хотя и оно заточено под текущую схему концепций соотношения команды и кэша.

Ну это когда оптимизатор совсем уж тупой. ))