Сообщение Re[11]: Эльбрус мёртв, да здравствует Эльбрус-Б! от 21.05.2025 21:15
Изменено 21.05.2025 21:22 vdimas
Re[11]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, Sinclair, Вы писали:
V>>И да, ядра с гипертредингом имеют чуть большее кол-во выч.блоков в АЛУ, но небольшое увеличение для 2x и затем еще меньшее увеличения от этого до 4x показывает эффект от аппаратной реализации СМО.
S>Там нет никаких 2х и 4х. Иначе бы никто не называл это "гипертредингом" и не было бы понятия "честные ядра".
Я так обозначил кол-во аппаратных потоков на ядро: 2 у Интел и 4 у Sun.
V>>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
S>Как мы в прошлый раз выяснили, в Эльбрусе этих блоков меньше.
В каком из Эльбрусов и меньше чем где?
S>Независимо от наличия или отсутствия упоров.
Эдак тебя заносит. ))
Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт?
А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?
V>>На обычных многопоточных, даже независимых по данным.
S>На "обычных многопоточных" данные и так не пересекаются, безо всяких усилий по разметке.
"Страшно далеки они от народа" (С) А. Герцен.
S>Например, при перемножении матриц каждый из потоков работает со своим сегментом матрицы.
Плохой пример, без обид — чтобы перемножение матрицы на VLIW имело смысл параллелить по потокам (по ядрам), это должна быть достаточно большая матрица. Прям охеренная. ))
Это узкий класс задач.
Гораздо чаще в многопотоке различные "агенты" обмениваются инфой через каналы, очереди, флаги, семафоры, future(s)/task(s) и т.д.
S>При сортировке слиянием каждый из потоков сортирует свой сегмент. И так далее.
Опять плохой пример — размер массива должен быть чудовищным, чтобы выбор сортировки слиянием был оправдан.
S>Чтобы когерентность начала как-то сильно мешать, надо специально писать многопоточный код так, чтобы потоки наступали друг другу на пятки.
Именно так весь современный многопоток и живёт, взять ту же асинхронщину в дотнете — много на ней матриц умножают? ))
Стоимость обслуживания этой асинхронщины дороже нашей подобной системы раз эдак в 50, и вовсе не только из-за дотнета как такового (в смысле, плохооптимизированного джита), а потому что миллиард легаси пришлось удовлетворить с его контекстами исполнения и даже поддержкой корректной работы COM. И там мильярд невылизанных мест.
V>>В мейнстримовых языках пока мало "подсказок" компилятору насчёт этого, приходится размечать память вручную.
S>Это, КМК, очень специальный случай.
Это мейнстримовый случай, чем приходится заниматься вообще всегда, когда есть обмен данными между потоками.
V>>И еще бы заранее знать на каких процах оно будет исполняться, т.е. размер линейки кеша... ))
S>Или учитывать это при джите
Да согласен.
Тем более, что возмущаюсь от необходимости делать эту обезьянью работу вручную. ))
V>>Разнесение локальных данных на некоторых алгоритмах даёт до 3-10 раз, кстате, зависит от соотношения стоимости полезных вычислений и стоимости обеспечения когерентности.
S>Возможно, выбор более удачной структуры данных даст ускорение в 3-10 раз и без ручной подгонки линеек кеша.
Ты иногда как с другой стороны Луны.
Имелись ввиду задачи активного обмена данными м/у потоками.
Это весьма интересная тема и я с удовольствием на эту тему поспорил бы, если бы было о чем спорить с оппонентом.
Блин, "более удачные структуры данных"... ))
Не надо вытягивать из меня инфу, хосподя, надо направлять спор, если есть другие или дополняющие собственные наблюдения — именно так происходят предметные обсуждения.
А с 0-ля мне придётся давать слишком много и толку будет ровно ноль всё равно, т.к. мне заведомо не будет толку от этого, а ты через неделю всё равно забудешь подробности.
V>>Да нет, они в макетах всё неплохо демонстрировали.
S>Макеты Эльбрус-Б? Да ладно!
E2k в макетах сначала показали в 90-е (Это все последующие Эльбрусы которые).
И это был отрыв башки на тот момент, в плане вычислительной отдачи на единицу тактовой.
Какие там в опу топовые пни на тот момент... Тогдашние пни выглядели как микросхемы от первых калькуляторов в своей отдаче на единицу тактовой.
V>>И да, ядра с гипертредингом имеют чуть большее кол-во выч.блоков в АЛУ, но небольшое увеличение для 2x и затем еще меньшее увеличения от этого до 4x показывает эффект от аппаратной реализации СМО.
S>Там нет никаких 2х и 4х. Иначе бы никто не называл это "гипертредингом" и не было бы понятия "честные ядра".
Я так обозначил кол-во аппаратных потоков на ядро: 2 у Интел и 4 у Sun.
V>>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
S>Как мы в прошлый раз выяснили, в Эльбрусе этих блоков меньше.
В каком из Эльбрусов и меньше чем где?
S>Независимо от наличия или отсутствия упоров.
Эдак тебя заносит. ))
Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт?
А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?
V>>На обычных многопоточных, даже независимых по данным.
S>На "обычных многопоточных" данные и так не пересекаются, безо всяких усилий по разметке.
"Страшно далеки они от народа" (С) А. Герцен.
S>Например, при перемножении матриц каждый из потоков работает со своим сегментом матрицы.
Плохой пример, без обид — чтобы перемножение матрицы на VLIW имело смысл параллелить по потокам (по ядрам), это должна быть достаточно большая матрица. Прям охеренная. ))
Это узкий класс задач.
Гораздо чаще в многопотоке различные "агенты" обмениваются инфой через каналы, очереди, флаги, семафоры, future(s)/task(s) и т.д.
S>При сортировке слиянием каждый из потоков сортирует свой сегмент. И так далее.
Опять плохой пример — размер массива должен быть чудовищным, чтобы выбор сортировки слиянием был оправдан.
S>Чтобы когерентность начала как-то сильно мешать, надо специально писать многопоточный код так, чтобы потоки наступали друг другу на пятки.
Именно так весь современный многопоток и живёт, взять ту же асинхронщину в дотнете — много на ней матриц умножают? ))
Стоимость обслуживания этой асинхронщины дороже нашей подобной системы раз эдак в 50, и вовсе не только из-за дотнета как такового (в смысле, плохооптимизированного джита), а потому что миллиард легаси пришлось удовлетворить с его контекстами исполнения и даже поддержкой корректной работы COM. И там мильярд невылизанных мест.
V>>В мейнстримовых языках пока мало "подсказок" компилятору насчёт этого, приходится размечать память вручную.
S>Это, КМК, очень специальный случай.
Это мейнстримовый случай, чем приходится заниматься вообще всегда, когда есть обмен данными между потоками.
V>>И еще бы заранее знать на каких процах оно будет исполняться, т.е. размер линейки кеша... ))
S>Или учитывать это при джите
Да согласен.
Тем более, что возмущаюсь от необходимости делать эту обезьянью работу вручную. ))
V>>Разнесение локальных данных на некоторых алгоритмах даёт до 3-10 раз, кстате, зависит от соотношения стоимости полезных вычислений и стоимости обеспечения когерентности.
S>Возможно, выбор более удачной структуры данных даст ускорение в 3-10 раз и без ручной подгонки линеек кеша.
Ты иногда как с другой стороны Луны.
Имелись ввиду задачи активного обмена данными м/у потоками.
Это весьма интересная тема и я с удовольствием на эту тему поспорил бы, если бы было о чем спорить с оппонентом.
Блин, "более удачные структуры данных"... ))
Не надо вытягивать из меня инфу, хосподя, надо направлять спор, если есть другие или дополняющие собственные наблюдения — именно так происходят предметные обсуждения.
А с 0-ля мне придётся давать слишком много и толку будет ровно ноль всё равно, т.к. мне заведомо не будет толку от этого, а ты через неделю всё равно забудешь подробности.
V>>Да нет, они в макетах всё неплохо демонстрировали.
S>Макеты Эльбрус-Б? Да ладно!
E2k в макетах сначала показали в 90-е (Это все последующие Эльбрусы которые).
И это был отрыв башки на тот момент, в плане вычислительной отдачи на единицу тактовой.
Какие там в опу топовые пни на тот момент... Тогдашние пни выглядели как микросхемы от первых калькуляторов в своей отдаче на единицу тактовой.
Re[11]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, Sinclair, Вы писали:
V>>И да, ядра с гипертредингом имеют чуть большее кол-во выч.блоков в АЛУ, но небольшое увеличение для 2x и затем еще меньшее увеличения от этого до 4x показывает эффект от аппаратной реализации СМО.
S>Там нет никаких 2х и 4х. Иначе бы никто не называл это "гипертредингом" и не было бы понятия "честные ядра".
Я так обозначил кол-во аппаратных потоков на ядро: 2 у Интел и 4 у Sun.
V>>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
S>Как мы в прошлый раз выяснили, в Эльбрусе этих блоков меньше.
В каком из Эльбрусов и меньше чем где?
S>Независимо от наличия или отсутствия упоров.
Эдак тебя заносит. ))
Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт?
А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?
V>>На обычных многопоточных, даже независимых по данным.
S>На "обычных многопоточных" данные и так не пересекаются, безо всяких усилий по разметке.
"Страшно далеки они от народа" (С) А. Герцен.
S>Например, при перемножении матриц каждый из потоков работает со своим сегментом матрицы.
Плохой пример, без обид — чтобы перемножение матрицы на VLIW имело смысл параллелить по потокам (по ядрам), это должна быть достаточно большая матрица. Прям охеренная. ))
Это узкий класс задач.
Гораздо чаще в многопотоке различные "агенты" обмениваются инфой через каналы, очереди, флаги, семафоры, future(s)/task(s) и т.д.
S>При сортировке слиянием каждый из потоков сортирует свой сегмент. И так далее.
Опять плохой пример — размер массива должен быть чудовищным, чтобы выбор сортировки слиянием был оправдан.
S>Чтобы когерентность начала как-то сильно мешать, надо специально писать многопоточный код так, чтобы потоки наступали друг другу на пятки.
Именно так весь современный многопоток и живёт, взять ту же асинхронщину в дотнете — много на ней матриц умножают? ))
Стоимость обслуживания этой асинхронщины дороже нашей подобной системы раз эдак в 50, и вовсе не только из-за дотнета как такового (в смысле, плохооптимизированного джита), а потому что миллиард легаси пришлось удовлетворить с его контекстами исполнения и даже поддержкой корректной работы COM. И там мильярд невылизанных мест именно с т.з. доступа к данным из различных потоков.
V>>В мейнстримовых языках пока мало "подсказок" компилятору насчёт этого, приходится размечать память вручную.
S>Это, КМК, очень специальный случай.
Это мейнстримовый случай, чем приходится заниматься вообще всегда, когда есть обмен данными между потоками.
V>>И еще бы заранее знать на каких процах оно будет исполняться, т.е. размер линейки кеша... ))
S>Или учитывать это при джите
Да согласен.
Тем более, что возмущаюсь от необходимости делать эту обезьянью работу вручную. ))
V>>Разнесение локальных данных на некоторых алгоритмах даёт до 3-10 раз, кстате, зависит от соотношения стоимости полезных вычислений и стоимости обеспечения когерентности.
S>Возможно, выбор более удачной структуры данных даст ускорение в 3-10 раз и без ручной подгонки линеек кеша.
Ты иногда как с другой стороны Луны.
Имелись ввиду задачи активного обмена данными м/у потоками.
Это весьма интересная тема и я с удовольствием на эту тему поспорил бы, если бы было о чем спорить с оппонентом.
Блин, "более удачные структуры данных"... ))
Не надо вытягивать из меня инфу, хосподя, надо направлять спор, если есть другие или дополняющие собственные наблюдения — именно так происходят предметные обсуждения.
А с 0-ля мне придётся давать слишком много и толку будет ровно ноль всё равно, т.к. мне заведомо не будет толку от этого, а ты через неделю всё равно забудешь подробности.
V>>Да нет, они в макетах всё неплохо демонстрировали.
S>Макеты Эльбрус-Б? Да ладно!
E2k в макетах сначала показали в 90-е (Это все последующие Эльбрусы которые).
И это был отрыв башки на тот момент, в плане вычислительной отдачи на единицу тактовой.
Какие там в опу топовые пни на тот момент... Тогдашние пни выглядели как микросхемы от первых калькуляторов в своей отдаче на единицу тактовой.
V>>И да, ядра с гипертредингом имеют чуть большее кол-во выч.блоков в АЛУ, но небольшое увеличение для 2x и затем еще меньшее увеличения от этого до 4x показывает эффект от аппаратной реализации СМО.
S>Там нет никаких 2х и 4х. Иначе бы никто не называл это "гипертредингом" и не было бы понятия "честные ядра".
Я так обозначил кол-во аппаратных потоков на ядро: 2 у Интел и 4 у Sun.
V>>Вот как раз в Эльбрусе этих блоков больше, потому что идёт упор на спекулятивное исполнение, а не на ОоО, т.е. конкурирующие результаты вычислений часто отбрасываются.
S>Как мы в прошлый раз выяснили, в Эльбрусе этих блоков меньше.
В каком из Эльбрусов и меньше чем где?
S>Независимо от наличия или отсутствия упоров.
Эдак тебя заносит. ))
Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт?
А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?
V>>На обычных многопоточных, даже независимых по данным.
S>На "обычных многопоточных" данные и так не пересекаются, безо всяких усилий по разметке.
"Страшно далеки они от народа" (С) А. Герцен.
S>Например, при перемножении матриц каждый из потоков работает со своим сегментом матрицы.
Плохой пример, без обид — чтобы перемножение матрицы на VLIW имело смысл параллелить по потокам (по ядрам), это должна быть достаточно большая матрица. Прям охеренная. ))
Это узкий класс задач.
Гораздо чаще в многопотоке различные "агенты" обмениваются инфой через каналы, очереди, флаги, семафоры, future(s)/task(s) и т.д.
S>При сортировке слиянием каждый из потоков сортирует свой сегмент. И так далее.
Опять плохой пример — размер массива должен быть чудовищным, чтобы выбор сортировки слиянием был оправдан.
S>Чтобы когерентность начала как-то сильно мешать, надо специально писать многопоточный код так, чтобы потоки наступали друг другу на пятки.
Именно так весь современный многопоток и живёт, взять ту же асинхронщину в дотнете — много на ней матриц умножают? ))
Стоимость обслуживания этой асинхронщины дороже нашей подобной системы раз эдак в 50, и вовсе не только из-за дотнета как такового (в смысле, плохооптимизированного джита), а потому что миллиард легаси пришлось удовлетворить с его контекстами исполнения и даже поддержкой корректной работы COM. И там мильярд невылизанных мест именно с т.з. доступа к данным из различных потоков.
V>>В мейнстримовых языках пока мало "подсказок" компилятору насчёт этого, приходится размечать память вручную.
S>Это, КМК, очень специальный случай.
Это мейнстримовый случай, чем приходится заниматься вообще всегда, когда есть обмен данными между потоками.
V>>И еще бы заранее знать на каких процах оно будет исполняться, т.е. размер линейки кеша... ))
S>Или учитывать это при джите
Да согласен.
Тем более, что возмущаюсь от необходимости делать эту обезьянью работу вручную. ))
V>>Разнесение локальных данных на некоторых алгоритмах даёт до 3-10 раз, кстате, зависит от соотношения стоимости полезных вычислений и стоимости обеспечения когерентности.
S>Возможно, выбор более удачной структуры данных даст ускорение в 3-10 раз и без ручной подгонки линеек кеша.
Ты иногда как с другой стороны Луны.
Имелись ввиду задачи активного обмена данными м/у потоками.
Это весьма интересная тема и я с удовольствием на эту тему поспорил бы, если бы было о чем спорить с оппонентом.
Блин, "более удачные структуры данных"... ))
Не надо вытягивать из меня инфу, хосподя, надо направлять спор, если есть другие или дополняющие собственные наблюдения — именно так происходят предметные обсуждения.
А с 0-ля мне придётся давать слишком много и толку будет ровно ноль всё равно, т.к. мне заведомо не будет толку от этого, а ты через неделю всё равно забудешь подробности.
V>>Да нет, они в макетах всё неплохо демонстрировали.
S>Макеты Эльбрус-Б? Да ладно!
E2k в макетах сначала показали в 90-е (Это все последующие Эльбрусы которые).
И это был отрыв башки на тот момент, в плане вычислительной отдачи на единицу тактовой.
Какие там в опу топовые пни на тот момент... Тогдашние пни выглядели как микросхемы от первых калькуляторов в своей отдаче на единицу тактовой.