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

V>>Гипертрединг 2x в Интел потребовал всего лишь ~12% увеличение кол-ва логических вентилей, если склероз не изменяет.
V>>У Sun для 4x гипертрединга что-то менее 18% увеличения кол-ва вентилей вышло (у них лучше кодировка инструкций, компиляторы порождают более простой код)
S>Гипертрединг не добавляет мощности.

Ес-но, он добавляет выхлоп от имеющейся мощности, и небольшое увеличение кол-ва вентилей лишь показывает печальную реальность — кол-во выч.блоков рассчитывается "на крайний случай", т.е. большинство их простаивает грубо 90% времени, отсюда появляется смысл в аппаратной многопоточности.

И да, ядра с гипертредингом имеют чуть большее кол-во выч.блоков в АЛУ, но небольшое увеличение для 2x и затем еще меньшее увеличения от этого до 4x показывает эффект от аппаратной реализации СМО.


S>Чтобы объехать Интел, нужно а) добавить FMA-блоков и б) обеспечить, чтобы они не простаивали в ожидании памяти.

Ес-но.
Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.


V>>Основная проблема многоядерников — это когерентность памяти.
S>Смотря на каких задачах.

На обычных многопоточных, даже независимых по данным.
Эту независимость приходится организовывать физически разметкой лейаута.
Вот у тебя есть некий объект, в нём работает пара потоков, их локальные данные необходимо разносить по линейкам кеша.
В мейнстримовых языках пока мало "подсказок" компилятору насчёт этого, приходится размечать память вручную.

И еще бы заранее знать на каких процах оно будет исполняться, т.е. размер линейки кеша... ))


V>>Т.е. лишние тормоза зачастую, возня с физическим разнесением конкурентно обрабатываемых независимых данных по линейкам этого кеша и прочие постыдные для 21-го века танцы с бубном, которые исполняет программист, а не компилятор + железо.
S>И каким чудом можно эти танцы с бубном переложить на компилятор+железо?

Размечать блоки данных, которые локальные для некоего потока, т.е. чтобы была возможность разметить несколько таких блоков в лейауте объекта.
Дальнейшая автоматизация в компиляторе, потом на реальном железе на уровне загрузчика ОС со стандартной коррекцией адресов в процессе загрузки.

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


S>И даст ли это переложение хотя бы 30-кратный рост производительности, не говоря уже о 200?

Разнесение локальных данных на некоторых алгоритмах даёт до 3-10 раз, кстате, зависит от соотношения стоимости полезных вычислений и стоимости обеспечения когерентности.
А так же от везения — исполняются ли целевые конкурирующие за память потоки в одном ядре с гипертредингом, или в разных.

И эта эффективность в случае разных ядер достигается за счёт разгрузки механизма обеспечения когерентности памяти, а у того тоже предельный трафик не бесконечный.

Т.е., тут двойной выхлоп: (1) убираются задержки, связанные с обеспечением когерентности памяти и (2) подсистема обеспечения когерентности освобождается для других конкурентных задач/процессов, давая тем больше эффективности.


V>>Для этого надо взглянуть на спецификации языка Эль-22, который обещает некий "полный параллелизм".
S>Я об этом уже написал.

Ты написал лишь два базовых вида, хотя существовали системы с железным параллелизмом на уровне задач — это более высокоуровневые механизмы, реализованные в железе.
Это когда железо автоматически обслуживает начало и окончание вычислительных потоков через железные же примитивы синхронизации, т.е. создание и завершение потока вычисления практически ничего не стоит. В таких системах распараллеливание циклов начинает давать профит при намного меньших оборотах цикла, чем в современных многопоточных ОС (и даже в сравнении с мануально наваянными зелеными потоками).

Разумеется, подходы к параллелизму будут еще допиливаться, коль с ростом частоты уже давно понятно, что обломались, т.е. теперь будет рост только вширь, а значит нужна поддержка для извлечения хорошего КПД от большого кол-ва выч.блоков. Такие темы примерно раз в 5 лет тут возникают, давно понятно что делать, но "проклятое легаси" пугает, конечно... ))


V>>Рискну предположить, что увидим нечто подобное. ))
S>Рискну предположить, что мы вообще ничего не увидим. Но надежда, как водится, умирает последней.

Да нет, они в макетах всё неплохо демонстрировали.
Умудрились же в самую эпоху развала создать нехилую архитектуру E2k, которая была натурально революционной по меркам второй половины 90-х...
А что не сумели воплотить в актуальном техпроцессе — это не к разработчикам проца вопросы, а к технологиям страны в целом, конечно, и к банальным вложениям денег.

Но именно разрабатывать нестандартные, но востребованные и офигенно крутые на момент разработки архитектуры они умеют и уже показали это ранее.

E2k — это переосмысление архитектуры мощного сигнального процессора, способного на равных тягаться с топами даже в "обычных задачах".
А по числодроблению (как проц позиционировался) он на тот момент уделывал топовые Интелы почти на порядок на сравнимых частотах.

Будь тогда возможность воплотить в железе на актуальном техпроцессе в начале нулевых — все бы офигели, конечно... ))