Здравствуйте, vdimas, Вы писали:
V>Я так обозначил кол-во аппаратных потоков на ядро: 2 у Интел и 4 у Sun.
Это бессмысленные цифры. Интересует не количество потоков, а производительность.

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

V>В каком из Эльбрусов и меньше чем где?
В любом реализованном меньше чем в любом современном Интеле.
Напомню, что Интел ставит 2 FMA модуля на ядро. То есть за 1 такт ядро может выполнить 16 64-разрядных арифметических операций.
На фоне этого 6 АЛУ на ядро как-то не смотрятся.

V>Не подскажешь, в каком из мейнстримовых интелов каждое ядро способно выполнить 8 целочисленных и 24 вещественных команды за один такт?
В любом. Вещественные-то поди 32 бита? Таких операций интел может сделать 32.
И это — про простые гражданские копеешные AVX2. Если мы возьмём топовый пень с AVX512, то сравнение станет совсем нечестным.

V>А в каком из мейнстримовых интелов присутствует 6 векторных АЛУ на ядро?
Размер вектора какой? Кстати, почему-то в руководстве о векторности АЛУ нет ни слова. Сколько и каких значений складывает команда adds?

V>Плохой пример, без обид — чтобы перемножение матрицы на VLIW имело смысл параллелить по потокам (по ядрам), это должна быть достаточно большая матрица. Прям охеренная. ))
Всё верно. Как и на обычном суперскаляре.

V>Опять плохой пример — размер массива должен быть чудовищным, чтобы выбор сортировки слиянием был оправдан.
Надо будет замерить как-нибудь.

V>Именно так весь современный многопоток и живёт, взять ту же асинхронщину в дотнете — много на ней матриц умножают? ))
Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java. И для этого не пришлось ни ломать JIT, ни переписывать компилятор, ни раскладывать данные по линейкам кеша.

V>Стоимость обслуживания этой асинхронщины дороже нашей подобной системы раз эдак в 50, и вовсе не только из-за дотнета как такового (в смысле, плохооптимизированного джита), а потому что миллиард легаси пришлось удовлетворить с его контекстами исполнения и даже поддержкой корректной работы COM. И там мильярд невылизанных мест именно с т.з. доступа к данным из различных потоков.
Понятно, что можно криво написать софт. Непонятно, что тут может бать Бабаяновское железо.

V>Это мейнстримовый случай, чем приходится заниматься вообще всегда, когда есть обмен данными между потоками.
Пример LMAX Disruptor показывает, что не всегда.

V>Да согласен.
V>Тем более, что возмущаюсь от необходимости делать эту обезьянью работу вручную. ))
Ну, так что сдерживает-то? Сказки про комитеты, которые запрещают вам ковыряться в носу, рассказывать не надо. Простой вариант: берём дотнет, изобретаем набор атрибутов для лэйаута, делаем свой компайл-тайм-генератор типов
с выровненными по кэшу данными. Работы на один вечер.
Если не знаем, на чём будет исполняться код — переносим генератор в рантайм. Работы на два вечера.
Или берём clang, llvm, и делаем то же самое прямо в кодогенераторе. Работы на пару недель.

При условии, конечно, что есть понимание а) в чём именно состоит обезьянья работа и б) какую информацию нужно размечать атрибутами.
Вы утверждаете, что у вас всё это есть. Ну, так за чем же дело стало?

V>Имелись ввиду задачи активного обмена данными м/у потоками.
Для начала нужно понять, зачем вообще потребовался активный обмен данными между потоками. Может, там надо по-другому работу распределить?

V>Блин, "более удачные структуры данных"... ))
А то.

V>E2k в макетах сначала показали в 90-е (это все последующие микропроцессорные Эльбрусы которые).
Речь в топике про Эльбрус-Б. Эль-22, напомню, к E2K никакого отношения не имеет.