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

V>>Порядок вложения циклов обхода для приведённого мною алгоритма.
V>>В статье другие идентификаторы, т.е. ijk не те, что я привёл.
S>В статье — ровно те же i, j, k.

Есть матрица с горизонтальным обходом (пусть переменная цикла будет i), вертикальным обходом (j) и результирующая, где накапливаются суммы умножений (k).
Соответственно, есть 6 вариантов вложений циклов друг в друга.


S>Поясните. Лучше всего — приведите пример "наивного" кода, который является наиболее оптимальным.

Я уже озвучил:

По классике наилучший результат из наивных даёт схема kji.

Т.е. на внешнем цикле запись, на втором — пробегание по памяти "скачками", и на внутреннем цикле пробегание по памяти упорядоченно.

Немного забавно, что цепляемся за подобные "задачи", которые дают студентам-первокурсникам в кач-ве лабораторок (бенчмарки различных вариантов реализации умножения матриц).
ИМХО, в подобных вещах опытным спецам остаточно обратить внимание коллег на некую подробность и вопрос должен считаться исчерпанным.


V>>Но почему-то интелловская либа ускоряет только в 10 раз.
S>У вас есть ссылка, подтверждающая эту оценку?

В гугле есть сразу несколько ссылок.


V>>Наверно потому что ей недоступны "оптимизации", которые приведены в статье по твоей ссылке?
S>Конечно же доступны.

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


V>>Ведь характер задачи заранее неизвестен.
S>Известен: умножение матриц.

Матрицы матрицам рознь.


V>>Того монстра, что они породили, пусть погоняют на небольших матрицах и увидят, что вряд ли сделали лучше.
V>>Как бы не хуже.
S>Очень вряд ли там будет хуже. Дружелюбность к кэшу очень редко ухудшает работу в случае, когда выигрыша за счёт кэша нет.

Там для небольших матриц избыточность телодвижений.
Ну и плюс тот код банально не работает на матрицах размерности ниже ширины ручной раскрутки циклов.


V>>Ну и на матрицах небольшого размера тот код просто упадёт, т.к. некорректный.
S>Конкретно тот код зависит только от кратности размеров. Для того, чтобы он работал для произвольных матриц, там надо к каждому циклу прикрутить "голову" и "хвост" для выравнивания данных.

В либах так и происходит — обязательно есть ветвления (чаще по switch).
Как в самом начале — по размерностям матриц, так и при обслуживании "хвостов" некратных размеров.

Для заведомо известных размеров кучу телодвижений можно нивелировать, ес-но.


S>А эти случаи, в свою очередь, нетрудно отловить, и обработать более простым алгоритмом.

Да всё можно сделать.
Мы тут переливаем из пустого в порожнее вокруг первого же моего утверждения:
— готовые библиотеки дают хороший старт;
— при надобности конкретные места можно уже вылизывать врукопашную.

Мне хотелось обратить внимание, что для Эльбруса как либы, так и рукопашное вылизывание дают, не побоюсь пафоса, чудовищный профит.


S>Впрочем, это всё несущественные подробности. Только что вы писали, что под интел как ни крути — а больше не накрутишь. Когда оказалось, что накрутишь — вы начинаете вилять.

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


V>>В сети есть несколько тестов MKL, поэтому в сравнении с EML Интел всё еще отстаёт примерно в два раза, при том что процы работают на разной тактовой.
S>У есть ссылка, подтверждающая эту оценку? Я не нашёл ни одного теста, где бы совместно гонялись MKL и EML.

А как они могут гоняться совместно? ))


V>>В отличе от, подсказки насчёт раскрутки циклов есть и для x86/x64 архитектуры.
V>>Это не то же самое, что писать на асме.
S>Подсказки насчёт раскрутки циклов мало что дают.

В статье про Эльбрус они дали всё.


S>В статье про эльбрус автор не пользовался интринсиками, зато пользовался знанием таймингов команд.

Не таймингов, а архитектуры ядер.
Различные Эльбрусы различаются кол-вом и быстродействием ядер при устаканенной архитектуре.


S>Это ещё хуже — то есть вместо того, чтобы напрямую написать компилятору, какой код ты от него хочешь, приходится шаманить при помощи подбора параметров. Цитирую уместный фрагмент:
S>

S>При оптимизации гнезда циклов важно не упираться в ресурсы аппаратуры: количество вещественных операций, которое мы можем выполнять в одной ШК, количество доступных регистров. Поэтому для архитектуры e8c было бы правильным подобрать параметры следующим образом:

S>Подбор параметров unroll&fuse по i на 8 и по j на 6...

Это верно и для регистров SSE.
Т.е. конкретные твои интриситки либо расчитаны на SSE1-SSE4 (8 регистров XMMx), либо на AVX+ (16 регистров YMMx)

Я лишь указал, что вместо того, чтобы руками писать на ассемблере-интистиках (как по твоей ссылке), для Эльбруса (по моей ссылке) был использован вариант, где код генерится компилятором, которому лишь подсказывают степень раскрутки цикла.


S>То есть при смене процессора придётся заново подбирать эти параметры.

При смене версии SSE/AVX в твоём случае придётся переписывать код. ))


V>>С этим фруктом всё было понятно изначально.
S>Неа.

Это тебе нет, хотя конкретно тебе говорили, как оно будет, и оно так и было.
Зато ты фантазировал безудержно, помнится.
(не только ты, но ты громче всех)


V>>И заметь — оно пошло вперёд, как только дотнет повернулся к нейтиву лицом, потому что заинтересовал более широкие слои населения.
S>Оно пошло вперёд, как только дотнет повернулся лицом к опенсорсу.

Этого недостаточно.
Джава давно повернулась лицом к опенсорсу, но огромного кол-ва ревьюверов джава-машинки я не наблюдаю.
Потому что простого поворачивания к опенсорсу мало, надо повернуться лицом к тем, для кого память и тики проца всё еще ресурс.

Если джава не повторит за дотнетом поворачивание лицом к таким людям — постепенно уйдёт примерно туда же, куда ушел популярный когда-то Perl.

На последних дотнетах я снижаю нагрузку на GC более чем на порядок.
Джава в нынешнем виде просто обречена...


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

Это ты запутался в истории происходящего. ))
Сначала стали контрибутить нейтивные фишки, и только затем подтянулась широкая общественность.
Т.е. между тем, как открыли в опенсорс и тем, как подтянулось приличное кол-во людей, прошло прилично времени.

Лично я тоже обратил внимание на .Net Core только когда пошли нейтивные вкусняшки.
До этого пару лет было даже не любопытно.


V>>Но компилятор С++ не отдали, и этот компилятор от MS один из лучших в мире, особенно в деле LTO.
V>>И не отдадут в обозримом будущем.
S>То, что один из — это точно. Лучший — вряд ли.

Не вряд ли.
Где-то, сугубо местами его бьёт и GCC и IC, но вот разве что местами.
А по всему остальному фронту огребают. ))


S>Gcc — тоже один из лучших в мире. При этом за gcc не стоит компания с капитализацией Microsoft.

Я уже рассказывал, что не так с GCC и как он умудрился догнать MS VC.
В общем, история похожа на развитие стандартов интернета.
Когда-то MS хотела и могла развивать стандарты интернета, но W3C запорол это дело на корню по банальной причине — альтернативные браузеры были не готовы.
Т.е. под новые стандарты мог быть готов только IE.

В итоге, скорость развития стандартов интернета стала в точности равна скорокти развития WebKit/Chromium и кода Мозиллы.

Аналогично вышло с С++ — этот язык так должго находился в застое из-за невозможности альтернативных реализаций удовлетворять стандарт.
Поэтому, GCC не догнал сам по себе MS VC — он гнался за стоячим.

Собсно, эта история и побудила MS забить как на свой браузер, так и на своё нейтивное поколение когда-то.
Плюс проигрыш в суде насчёт Джавы — там тоже MS не разрешили развивать стандарты Джавы, хотя Ораклу, почему-то, потом разрешили.

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

Именно из-за этого случился зайстой в IT-области как таковой в течении всех нулевых, примерно до 2012-го, когда этот застой стал уже слишком бросаться в глаза.
Такой был мощный подъем на отрезке 95-2000, и такой обломс в течении 10-ти лет затем.

Разумеется, конкретно ты был не при чём, просто ты был тогда удобным мальчиком для битья, полезным сам знаешь кем, который безо-всякого принуждения озвучивал точку зрения именно тех людей, из-за ущербности мыслительного аппарата которых IT так обделалось, что аж на десятилетие. Пинать тебя было банально удобно. Жаль, ты не понимал и половины того, что тебе говорили, бо обитаешь в своём параллельном мире, связь с реальностью минимальная. ))

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

V>>Порядок вложения циклов обхода для приведённого мною алгоритма.
V>>В статье другие идентификаторы, т.е. ijk не те, что я привёл.
S>В статье — ровно те же i, j, k.

Есть матрица с горизонтальным обходом (пусть переменная цикла будет i), вертикальным обходом (j) и результирующая, где накапливаются суммы умножений (k).
Соответственно, есть 6 вариантов вложений циклов друг в друга.


S>Поясните. Лучше всего — приведите пример "наивного" кода, который является наиболее оптимальным.

Я уже озвучил:

По классике наилучший результат из наивных даёт схема kji.

Т.е. на внешнем цикле запись, на втором — пробегание по памяти "скачками", и на внутреннем цикле пробегание по памяти упорядоченно.

Немного забавно, что цепляемся за подобные "задачи", которые дают студентам-первокурсникам в кач-ве лабораторок (бенчмарки различных вариантов реализации умножения матриц).
ИМХО, в подобных вещах опытным спецам остаточно обратить внимание коллег на некую подробность и вопрос должен считаться исчерпанным.


V>>Но почему-то интелловская либа ускоряет только в 10 раз.
S>У вас есть ссылка, подтверждающая эту оценку?

В гугле есть сразу несколько ссылок.


V>>Наверно потому что ей недоступны "оптимизации", которые приведены в статье по твоей ссылке?
S>Конечно же доступны.

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


V>>Ведь характер задачи заранее неизвестен.
S>Известен: умножение матриц.

Матрицы матрицам рознь.


V>>Того монстра, что они породили, пусть погоняют на небольших матрицах и увидят, что вряд ли сделали лучше.
V>>Как бы не хуже.
S>Очень вряд ли там будет хуже. Дружелюбность к кэшу очень редко ухудшает работу в случае, когда выигрыша за счёт кэша нет.

Там для небольших матриц избыточность телодвижений.
Ну и плюс тот код банально не работает на матрицах размерности ниже ширины ручной раскрутки циклов.


V>>Ну и на матрицах небольшого размера тот код просто упадёт, т.к. некорректный.
S>Конкретно тот код зависит только от кратности размеров. Для того, чтобы он работал для произвольных матриц, там надо к каждому циклу прикрутить "голову" и "хвост" для выравнивания данных.

В либах так и происходит — обязательно есть ветвления (чаще по switch).
Как в самом начале — по размерностям матриц, так и при обслуживании "хвостов" некратных размеров.

Для заведомо известных размеров кучу телодвижений можно нивелировать, ес-но.


S>А эти случаи, в свою очередь, нетрудно отловить, и обработать более простым алгоритмом.

Да всё можно сделать.
Мы тут переливаем из пустого в порожнее вокруг первого же моего утверждения:
— готовые библиотеки дают хороший старт;
— при надобности конкретные места можно уже вылизывать врукопашную.

Мне хотелось обратить внимание, что для Эльбруса как либы, так и рукопашное вылизывание дают, не побоюсь пафоса, чудовищный профит.


S>Впрочем, это всё несущественные подробности. Только что вы писали, что под интел как ни крути — а больше не накрутишь. Когда оказалось, что накрутишь — вы начинаете вилять.

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


V>>В сети есть несколько тестов MKL, поэтому в сравнении с EML Интел всё еще отстаёт примерно в два раза, при том что процы работают на разной тактовой.
S>У есть ссылка, подтверждающая эту оценку? Я не нашёл ни одного теста, где бы совместно гонялись MKL и EML.

А как они могут гоняться совместно? ))


V>>В отличе от, подсказки насчёт раскрутки циклов есть и для x86/x64 архитектуры.
V>>Это не то же самое, что писать на асме.
S>Подсказки насчёт раскрутки циклов мало что дают.

В статье про Эльбрус они дали всё.


S>В статье про эльбрус автор не пользовался интринсиками, зато пользовался знанием таймингов команд.

Не таймингов, а архитектуры ядер.
Различные Эльбрусы различаются кол-вом и быстродействием ядер при устаканенной архитектуре.


S>Это ещё хуже — то есть вместо того, чтобы напрямую написать компилятору, какой код ты от него хочешь, приходится шаманить при помощи подбора параметров. Цитирую уместный фрагмент:
S>

S>При оптимизации гнезда циклов важно не упираться в ресурсы аппаратуры: количество вещественных операций, которое мы можем выполнять в одной ШК, количество доступных регистров. Поэтому для архитектуры e8c было бы правильным подобрать параметры следующим образом:

S>Подбор параметров unroll&fuse по i на 8 и по j на 6...

Это верно и для регистров SSE.
Т.е. конкретные твои интриситки либо расчитаны на SSE1-SSE4 (8 регистров XMMx), либо на AVX+ (16 регистров YMMx)

Я лишь указал, что вместо того, чтобы руками писать на ассемблере-интистиках (как по твоей ссылке), для Эльбруса (по моей ссылке) был использован вариант, где код генерится компилятором, которому лишь подсказывают степень раскрутки цикла.


S>То есть при смене процессора придётся заново подбирать эти параметры.

При смене версии SSE/AVX в твоём случае придётся переписывать код. ))


V>>С этим фруктом всё было понятно изначально.
S>Неа.

Это тебе нет, хотя конкретно тебе говорили, как оно будет, и оно так и было.
Зато ты фантазировал безудержно, помнится.
(не только ты, но ты громче всех)


V>>И заметь — оно пошло вперёд, как только дотнет повернулся к нейтиву лицом, потому что заинтересовал более широкие слои населения.
S>Оно пошло вперёд, как только дотнет повернулся лицом к опенсорсу.

Этого недостаточно.
Джава давно повернулась лицом к опенсорсу, но огромного кол-ва ревьюверов джава-машинки я не наблюдаю.
Потому что простого поворачивания к опенсорсу мало, надо повернуться лицом к тем, для кого память и тики проца всё еще ресурс.

Если джава не повторит за дотнетом поворачивание лицом к таким людям — постепенно уйдёт примерно туда же, куда ушел популярный когда-то Perl.

На последних дотнетах я снижаю нагрузку на GC более чем на порядок.
Джава в нынешнем виде просто обречена...


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

Это ты запутался в истории происходящего. ))
Сначала стали контрибутить нейтивные фишки, и только затем подтянулась широкая общественность.
Т.е. между тем, как открыли в опенсорс и тем, как подтянулось приличное кол-во людей, прошло прилично времени.

Лично я тоже обратил внимание на .Net Core только когда пошли нейтивные вкусняшки.
До этого пару лет было даже не любопытно.


V>>Но компилятор С++ не отдали, и этот компилятор от MS один из лучших в мире, особенно в деле LTO.
V>>И не отдадут в обозримом будущем.
S>То, что один из — это точно. Лучший — вряд ли.

Не вряд ли.
Где-то, сугубо местами его бьёт и GCC и IC, но вот разве что местами.
А по всему остальному фронту огребают. ))


S>Gcc — тоже один из лучших в мире. При этом за gcc не стоит компания с капитализацией Microsoft.

Я уже рассказывал, что не так с GCC и как он умудрился догнать MS VC.
В общем, история похожа на развитие стандартов интернета.
Когда-то MS хотела и могла развивать стандарты интернета, но W3C запорол это дело на корню по банальной причине — альтернативные браузеры были не готовы.
Т.е. под новые стандарты мог быть готов только IE.

В итоге, скорость развития стандартов интернета стала в точности равна скорости развития WebKit/Chromium и кода Мозиллы.

Аналогично вышло с С++ — этот язык так долго находился в застое из-за невозможности альтернативных реализаций удовлетворять стандарт.
Поэтому, GCC не догнал сам по себе MS VC — он гнался за стоячим.

Собсно, эта история и побудила MS забить как на свой браузер, так и на своё нейтивное поколение когда-то.
Плюс проигрыш в суде насчёт Джавы — там тоже MS не разрешили развивать стандарты Джавы, хотя Ораклу, почему-то, потом разрешили.

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

Именно из-за этого случился зайстой в IT-области как таковой в течении всех нулевых, примерно до 2012-го, когда этот застой стал уже слишком бросаться в глаза.
Такой был мощный подъем на отрезке 95-2000, и такой обломс в течении 10-ти лет затем.

Разумеется, конкретно ты был не при чём, просто ты был тогда удобным мальчиком для битья, полезным сам знаешь кем, который безо-всякого принуждения озвучивал точку зрения именно тех людей, из-за ущербности мыслительного аппарата которых IT так обделалось, что аж на десятилетие. Пинать тебя было банально удобно. Жаль, ты не понимал и половины того, что тебе говорили, бо обитаешь в своём параллельном мире, связь с реальностью минимальная. ))