Сообщение Re[13]: Эльбрус мёртв, да здравствует Эльбрус-Б! от 25.05.2025 5:00
Изменено 25.05.2025 5:05 netch80
Re[13]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, vdimas, Вы писали:
V>>>В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров.
V>>>Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность.
N>>Так "утилизация выч. блоков" никогда не была прямой целью.
V>Это совершенно новая для меня мысль. ))
Да ну. "Идеальный вариант — реализации нет, а задача выполняется" ([Г.Альтшуллер]).
Важно выполнение команд, как можно быстрее, при условии, что точно и без перегрева. А сколько и каких вычислительнных блоков — какая разница? Потому просто нет смысла на этом концентрироваться. Хотя я понимаю, когда мыслишь в идеях, что важен в первую очередь SIMD, а его блоки дорогие, то начинаешь смещаться в эту сторону. Ну вот видимо потому в EPIC-Эльбрусах всё остальное страдает
N>>А вот сократить задержки на команды в целом — да.
V>Это в "лапшееобразном" коде т.н. "бизнес-логики", где куча if-ов и простейших перемещений данных в памяти, зачастую даже без вычислений.
V>Т.е. где код заведомо неэффективный-непродуманный с произвольной итерацией по графу косвенно связанных блоков данных произвольной же глубины этих связей.
V>Именно под такой непродуманный код требуется ОоО.
Что он "лапшеобразный" — согласен. А вот что он "непродуманный" — нет.
Напоминаю, ещё когда в 1951-м или около того начали выпускать на рынок первые коммерческие компьютеры, спрос на "экономические" задачи оказался в 5 раз выше чем на вычислительные. А с тех пор стало только хуже. Ты повторяешь за Intel, когда они при проектировании Pentium4 оставили в фаворе только мультим*дию. Напомнить, чем закончилась история Pentium4?
V>А где происходят именно полезные вычисления над сколь-нибудь заметными объёмами данных,
Удивительно, что ты не сказал "прекрасные полезные вычисления"</irony>
V>там все эти вещи прекрасно обыгрываются через prefetch, да и сам лейаут данных в памяти продуман всяко лучше, чем эти бесконечные виноградные гроздья т.н. бизнес-объектов в памяти, особенно в языках наподобие Джавы или C#, провоцирующих просто чудовищную косвенность хранения данных, что предсказать промахи кеша на этапе компиляции действительно невозможно. ))
Дададад. Теперь осталось только вернуться в реальность и оценить долю задач с SIMD среди вероятных применений EPIC-Эльбруса...
V>>>В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров.
V>>>Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность.
N>>Так "утилизация выч. блоков" никогда не была прямой целью.
V>Это совершенно новая для меня мысль. ))
Да ну. "Идеальный вариант — реализации нет, а задача выполняется" ([Г.Альтшуллер]).
Важно выполнение команд, как можно быстрее, при условии, что точно и без перегрева. А сколько и каких вычислительнных блоков — какая разница? Потому просто нет смысла на этом концентрироваться. Хотя я понимаю, когда мыслишь в идеях, что важен в первую очередь SIMD, а его блоки дорогие, то начинаешь смещаться в эту сторону. Ну вот видимо потому в EPIC-Эльбрусах всё остальное страдает
N>>А вот сократить задержки на команды в целом — да.
V>Это в "лапшееобразном" коде т.н. "бизнес-логики", где куча if-ов и простейших перемещений данных в памяти, зачастую даже без вычислений.
V>Т.е. где код заведомо неэффективный-непродуманный с произвольной итерацией по графу косвенно связанных блоков данных произвольной же глубины этих связей.
V>Именно под такой непродуманный код требуется ОоО.
Что он "лапшеобразный" — согласен. А вот что он "непродуманный" — нет.
Напоминаю, ещё когда в 1951-м или около того начали выпускать на рынок первые коммерческие компьютеры, спрос на "экономические" задачи оказался в 5 раз выше чем на вычислительные. А с тех пор стало только хуже. Ты повторяешь за Intel, когда они при проектировании Pentium4 оставили в фаворе только мультим*дию. Напомнить, чем закончилась история Pentium4?
V>А где происходят именно полезные вычисления над сколь-нибудь заметными объёмами данных,
Удивительно, что ты не сказал "прекрасные полезные вычисления"</irony>
V>там все эти вещи прекрасно обыгрываются через prefetch, да и сам лейаут данных в памяти продуман всяко лучше, чем эти бесконечные виноградные гроздья т.н. бизнес-объектов в памяти, особенно в языках наподобие Джавы или C#, провоцирующих просто чудовищную косвенность хранения данных, что предсказать промахи кеша на этапе компиляции действительно невозможно. ))
Дададад. Теперь осталось только вернуться в реальность и оценить долю задач с SIMD среди вероятных применений EPIC-Эльбруса...
Re[13]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, vdimas, Вы писали:
V>>>В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров.
V>>>Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность.
N>>Так "утилизация выч. блоков" никогда не была прямой целью.
V>Это совершенно новая для меня мысль. ))
Да ну. "Идеальный вариант — реализации нет, а задача выполняется" ([Г.Альтшуллер]).
Важно выполнение команд, как можно быстрее, при условии, что точно и без перегрева. А сколько и каких вычислительнных блоков — какая разница? Потому просто нет смысла на этом концентрироваться. Хотя я понимаю, когда мыслишь в идеях, что важен в первую очередь SIMD, а его блоки дорогие, то начинаешь смещаться в эту сторону. Ну вот видимо потому в EPIC-Эльбрусах всё остальное страдает
N>>А вот сократить задержки на команды в целом — да.
V>Это в "лапшееобразном" коде т.н. "бизнес-логики", где куча if-ов и простейших перемещений данных в памяти, зачастую даже без вычислений.
V>Т.е. где код заведомо неэффективный-непродуманный с произвольной итерацией по графу косвенно связанных блоков данных произвольной же глубины этих связей.
V>Именно под такой непродуманный код требуется ОоО.
Что он "лапшеобразный" — согласен. А вот что он "непродуманный" — нет.
Напоминаю, ещё когда в 1951-м или около того начали выпускать на рынок первые коммерческие компьютеры, спрос на "экономические" задачи оказался в 5 раз выше чем на вычислительные. А с тех пор стало только хуже. Ты повторяешь за Intel, когда они при проектировании Pentium4 оставили в фаворе только мультим*дию. Напомнить, чем закончилась история Pentium4?
V>А где происходят именно полезные вычисления над сколь-нибудь заметными объёмами данных,
Удивительно, что ты не сказал "прекрасные полезные вычисления"</irony>
V>там все эти вещи прекрасно обыгрываются через prefetch, да и сам лейаут данных в памяти продуман всяко лучше, чем эти бесконечные виноградные гроздья т.н. бизнес-объектов в памяти, особенно в языках наподобие Джавы или C#, провоцирующих просто чудовищную косвенность хранения данных, что предсказать промахи кеша на этапе компиляции действительно невозможно. ))
Дададад. Теперь осталось только вернуться в реальность и оценить долю задач с SIMD среди вероятных применений EPIC-Эльбруса... особенно когда его позиционируют в походные лаптопы. Или через 25 лет после первых радостных репортов на основании симуляции эмулятора — от этой идеи начали отказываться? Без иронии, я плотно не слежу.
V>>>В любом случае, эффективно обыграть эту проблему с целью утилизации выч. блоков получилось только с аппаратной многопоточностью, а не через ОоО и переименование регистров.
V>>>Единственно что, 2x аппаратная многопоточность оказалась недостаточной, более хорошо выглядели 4x и даже 16x многопоточность.
N>>Так "утилизация выч. блоков" никогда не была прямой целью.
V>Это совершенно новая для меня мысль. ))
Да ну. "Идеальный вариант — реализации нет, а задача выполняется" ([Г.Альтшуллер]).
Важно выполнение команд, как можно быстрее, при условии, что точно и без перегрева. А сколько и каких вычислительнных блоков — какая разница? Потому просто нет смысла на этом концентрироваться. Хотя я понимаю, когда мыслишь в идеях, что важен в первую очередь SIMD, а его блоки дорогие, то начинаешь смещаться в эту сторону. Ну вот видимо потому в EPIC-Эльбрусах всё остальное страдает
N>>А вот сократить задержки на команды в целом — да.
V>Это в "лапшееобразном" коде т.н. "бизнес-логики", где куча if-ов и простейших перемещений данных в памяти, зачастую даже без вычислений.
V>Т.е. где код заведомо неэффективный-непродуманный с произвольной итерацией по графу косвенно связанных блоков данных произвольной же глубины этих связей.
V>Именно под такой непродуманный код требуется ОоО.
Что он "лапшеобразный" — согласен. А вот что он "непродуманный" — нет.
Напоминаю, ещё когда в 1951-м или около того начали выпускать на рынок первые коммерческие компьютеры, спрос на "экономические" задачи оказался в 5 раз выше чем на вычислительные. А с тех пор стало только хуже. Ты повторяешь за Intel, когда они при проектировании Pentium4 оставили в фаворе только мультим*дию. Напомнить, чем закончилась история Pentium4?
V>А где происходят именно полезные вычисления над сколь-нибудь заметными объёмами данных,
Удивительно, что ты не сказал "прекрасные полезные вычисления"</irony>
V>там все эти вещи прекрасно обыгрываются через prefetch, да и сам лейаут данных в памяти продуман всяко лучше, чем эти бесконечные виноградные гроздья т.н. бизнес-объектов в памяти, особенно в языках наподобие Джавы или C#, провоцирующих просто чудовищную косвенность хранения данных, что предсказать промахи кеша на этапе компиляции действительно невозможно. ))
Дададад. Теперь осталось только вернуться в реальность и оценить долю задач с SIMD среди вероятных применений EPIC-Эльбруса... особенно когда его позиционируют в походные лаптопы. Или через 25 лет после первых радостных репортов на основании симуляции эмулятора — от этой идеи начали отказываться? Без иронии, я плотно не слежу.