А практически появление таких публикаций (как самого исследования на сайте университета джна хопкинса, так и заметок о нём в сми) говорит о смене "политики партии".
Не могу понять логическую цепочку, которая привела вас к такому выводу. Извините. Более того - я считаю вывод полностью неверным, так как люди делают публикации о чем считают нужным (тем более я уже устал повторять, что это не исследование потому что это лишь пре-принт не прошедший ревью).
Дополнительно я надеюсь, что вы таки ответите на весь список вопросов из поста выше.
Я апеллирую к факту появления в СМИ исследования с соответствующими выводами.
Тут есть проблема - технически СМИ могут писать о чем угодно. Например может существовать СМИ, пишущее о том что земля плоская (тут не уверен, но вроде бы у плоскоземельщиков были свои сайты и они формально - СМИ), но это же не значит, что это так и есть.
Ни про качество исследования ни, тем более, про внутреннюю кухню университета джона хопкинса я не писал.
Вы позже сказали, процитирую:
Что значит нет доверия источнику? Это не источник риторики, а главный разработчик самих мероприятий. Как по мне, они наоборот тянули до последнего с объявлением.
Я указал что авторы статьи не являются разработчиками, а то что один из них работает в Университете Джона Хоппкинса - это лишь совпадение (и поэтому препринт опубликован именно на сайте университета).
Дополнительно - я утверждаю что это не исследование, а пре-принт (черновик статьи, не прошедший проверку), это все таки очень разные вещи. Как статья пройдет весь процесс ревью и публикации - так можно будет назвать это исследованием.
И в третьих, из цитаты выше у меня скаладывается ощущение что вы именно что утверждаете что источнику надо доверять и качество статьи хорошее. Простите если я Вас неправильно понял (и в таком случаи, понял неправильно Вас не один я, а значит совет: выражайтесь яснее)
Автором исследования являются конкретно "Jonas Herby, Lars Jonung, and Steve H. Hanke" и "The views expressed in each working paper are those of the authors and not necessarily those of the institutions that the authors are affiliated with." (кстати только 1 авторов из университета Джона Хопкинса). Конкретно ни один из них не принимал участия в разработке мероприятий (по вашей же ссылке перечислены основные авторы). Также прежде чем ссылаться на статью имеет смысл прочитать её целиком, конкретно в этом случаи важно помнить что это пре-принт статьи, не прошедшей peer review и на который уже есть множество ответов специалистов в области и журналистов, например: [1] и [2]
В общем, я настоятельно рекомендую ознакомиться со статьей, прежде чем на нее ссылаться (если её вдумчиво прочитать то даже без прямого знакомства с темой она оставляет кучу вопросов, в первую очередь к статистическому анализу и составлению выборки).
Я может быть не совсем корректно выразился. Я вчера так и сделал (там еще надо в main'е одну строку закоментировать, так как она не под ifdef'ом) на M1, получил крайне посредственный результат, примерно на порядок хуже чем дает STREAM на 1 потоке. Так как на ryzen'е я тогда прогнать не мог, то я предположил что оптимизированные функции должны дать лучше производительность (честно, код не особо читал).
На Ryzen'е разница не такая драматическая - всего в 4 раза (1 поток дает чуть-чуть меньше 40 ГБ в секунду у меня, 1 поток в тесте по твоей ссылке - чуть меньше 10).
Мне лень портировать те два бенчмарка, что имеют ассемблерные вставки и используют интринсики на ARM, а без него выходят довольно так себе, если честно.
Для последовательного STREAM дает очень близкие к теоретически возможным результаты.
Ну вот не совсем соглашусь - на первый взгляд кажется, что чтение идет по sizeof(void*) байт за раз, я бы сказал что "совсем произвольное" это по байту. Не то чтобы это принципиально но все таки (результаты по байту скорее всего будут ровно пропорционально хуже). В принципе если поделить на sizeof(void*) то будет очень близко к 10**9/latency, что вполне ожидаемо (на m1 у меня вышло около 60 МБ в секунду - то есть примерно соответствует задеркже в 128нс, в реальности там около 110, на десктопе у меня вышло 86 МБ/с, то есть по задержкам выходит около 93нс, что тоже похоже на правду, у памяти у меня около 85-и в реальности).
Так для последовательного чтения результаты очень сильно занижены еще. По хорошему последовательный код должен быть другим (см. подход в STREAM).
в задачах, требующих больших объёмов памяти, ему с 16 гигабайтами памяти делать нечего.
Предполагая, что речь про мой тест - у меня 64 ГБ рам (собственно только поэтому я и взял ноут на M1 Max). Но в целом все равно смешные объемы по сравнению с типичными серверами.
Тут я бы хотел увидеть что такое "совсем произвольный". Чтение по 1 байту из случайных мест? Ну тут ты не сможешь прыгнуть выше головы, это правда (со своими ~80-120ns доступа ты просто физически больше чем 10**9/время_доступа операций за секунду не сделаешь - в данном случаи я в целом, а не конкретно о M1). Даже 100-150 мегабайт это для "совсем случайного" доступа слишком много, кстати.
M1 всех обгоняет за счет скорости работы памяти, которая в 4 раза быстрее, так что тут ничего удивительного во всех задача требующих больших объёмов данных он будет опережать конкурентов (особенно заметно при компиляции c++).
Там не так просто.
Во первых у простого М1 скорость памяти не так сильно отличается от типичных x86. У M1 Pro - где-то в 4 раза больше чем у типичных x86, у M1 Max общая ПСП - в 8, но только CPU часть не может эффективно его использовать и максимум что можно получить - примерно 250 ГБ в секунду. Но и тут не так просто - потому что с 1 перф кластера ты получаешь не более 100 с небольшим гигабайт в секунду пропускной способности, а с эффективного - около 50-и сверху.
Во вторых, компиляция в ПСП не настолько и упирается. Собственно на примере линейки видно что скорость компиляции на равном количестве ядер (если взять допустим 4 перф ядра) совсем не меняется при переходе с М1 на М1 Макс, хотя казалось бы.
Плюс это не объясняет почему мой M1 Max дает именно в сборке софта те же результаты (лишь чуть больше) чем мой же десктоп на Ryzen 3900X, хотя у меня доступная процессору ПСП на ноуте в 250 ГБ в секунду, а на десктопе всего лишь 51.6 (память у меня 3200MHz всего лишь). Я это проверял на сборке двух довольно больших проектов и получил что M1 конечно быстрее, но всего процентов на 10.
интересно, какой у вас процессор в ноутбуке, какие итоговые параметры сборки?\
Конкретно в этом - Apple M1 Max - и собственно то что результаты получились лучше чем у автора скорее подтверждают предположения что код банально упирается в память (разница как раз раза в 2 с небольшим по пропускной способности на 1 ядро между моим ноутом и тем на чем гонял автор).
В итоге я не очень игрался, просто взял "-Ofast -mtune=native" и несколько флагов просто для получения диагностики про векторизацию ("-Rpass-analysis=loop-vectorize -Rpass=loop-vectorize -Rpass-missed=loop-vectorize")
Собственно начал я с -O3, получил 2.9 секунды, но решил посмотреть что там с векторизацией и увидел что там некоторые циклы clang считает как неэффективные для векторизации, на Ofast у него чуть иной cost-model и он больше векторизует, в итоге получил 1.6 секунды.
Ради интереса я еще пару минут поигрался с флагами, но больше результатов не получал на последнем коммите. Потом прогнал тест на всех коммитах начиная с первого (чтоб проверить что часть претензий про время проверки вообще разумно). Пришлось правда тащить мелкий патчик потому что у автора было изначально вывод результатов раз в 100 итераций и простое умножение на 10 добавляло погрешность в 10% по сравнению с выводом раз в 1000. Получилось такое (во всех случаях "-Ofast -mtune=native", Apple Clang 13.0.0 из последнего xcode'а, mpi из brew, clang также используется как mpicc:
Вариант 0 - 6.48 +- 0.01с
Вариант 1 - 3.30 +- 0.01с
Вариант 2 - 3.18 +- 0.01с
Вариант 3 - 1.85 +- 0.01с
Вариант 4 - 1.85 +- 0.01с
Вариант 5 - 1.84 +- 0.01с
Вариант 6 - 1.84 +- 0.01с
Вариант 7 - 1.72 +- 0.01с
Вариант 8 - 1.62 +- 0.01с
В принципе все это можно автоматизировать за пару минут и прогон 8-и вариантов суммарно занимает меньше 10 минут. Собственно после чего автору и предъявил претензию о выборе компилятора и бездоказательности векторизации (недостаточно проделанной работе по оптимизации под другие системы или доказательства, что такая оптимизация уже делается компилятором).
А да, проверка корректности, так как на момент как я это все гонял, автор не привел ожидаемый вывод при корректной работе, делалась в сравнении с x86 десктопом где код собирался clang'ом и отдельно gcc с консервативным -O2 и я просто убедился зрительно, что вывод не поменялся и на маке с Ofast такой же.
UPD: делал буквально так (версия mpi естественно может поменяться в зависимости от системы и времени когда кто-то будет пытаться это снова запустить):
make clean && make CC=clang MPICC=clang CFLAGS="-Ofast -mtune=native -Rpass-analysis=loop-vectorize -Rpass=loop-vectorize -Rpass-missed=loop-vectorize -I/opt/homebrew/Cellar/open-mpi/4.1.2/include" LDFLAGS="-L/opt/homebrew/Cellar/open-mpi/4.1.2/lib -lmpi" && ./prog -n 1000 -m 1000
P. S. любопытно, что комментарии единственного человека, который попробовал запустить у себя код, сразу заминусовали.
Это вполне ожидаемо, минусы коменту накидали либо те, кому Эльбрус нравится, либо те кто считают что я за качество материала на автора наехал незаслуженно (по другим метрикам я предполагаю что первых было большинство).
Дать Индии денег на строительство завода, несколько иное нежели "маленький контракт".
Сравните стоимость заводика с тем, что получает Индия от нормальных отношений с США и ЕС.
Но это была шутка, джентельмены. Разумеется индусы не пойдут на такой риск. Хотя...
Вы таки определитесь - у вас весь этот тред был шуткой или он весь - "хотя...". Текст в интернете не передает достаточно информации, чтобы я, как читатель, мог бы с уверенностью что-либо утверждать.
Имея такой завод Индия могла бы производить нам требуемые микросхемы, почти легально. :-)
Если РФ будет дальше попадать под более жесткие санкции, то в момент как компании лишатся доступа к TSMC они же лешаться и доступа к гипотетическому заводу в Индии. Все потому, что без санкционных технологий наладить производство по современным нормам не выйдет. А дальше уже вопрос к Индии - захотят ли они в такой ситуации рискнуть сотрудничеством с США и другими странами, ради маленького контракта с Россией (и тут я сомневаюсь, что они пойдут на конфликт).
Чтобы взять готовое и модернизировать нужно чтобы это готовое было (а тут из не-купленного оборудования только то что осталось от СССР и разработано в конце 80-х), чтобы это готовое понимали (поэтому не выйдет разобрать STM'овское или AMDшное оборудование которое в 2000-х купили), а также чтобы сопутствующие отрасли делали нужного качества продукцию (условно, та же оптика и хим промышленность - иначе смысл делать свое с таким посылом, если оптику и материалы надо импортировать?).
Так как в целом немного понятно куда копать надо, теоретически можно пройти путь не за 30-35 лет на которое сейчас отставание, а лет за 20. Естестенно если вкладываться в это по-полной (а по-полной - это суммы порядка триллионов долларов) и если попутно эти вложения будут расходоваться целевым образом.
Это только речь про технологию, без учета персонала и ученых, которые эту технологию будут разрабатывать.
Я думаю, нашим правителям стоило бы посотрудничать с Индией в этом направлении (читай - незаметно подкинуть деньжат на заводик с целью получить квоты на производство своих микросхем).
А какую проблему (кроме того куда потратить деньги) это решит? В случаи санкций, о которых в этом треде речь, запрет будет касаться всех, кто использует технологии, то есть и гипотетический индийский заводик будет недоступен и SMIC тоже.
Более того - микроэлектроника это такая отрась, где ты вкладываешь хх млрд USD сейчас в оборудование и строительство завода, а работать оно начинает лет так через 5+ (если не будет как с HSMC).
Если это в статье не упомянуто, то как я могу знать что вы это проверяли? Опять же, пример на базе эксперимента выше (да, с clang'ом) я привел - то есть я еще и дополнительно видел что не все что стоит векторизуется корректно с тем что привдено (правда да, на другом компиляторе, но у меня нет под рукой систем на разумном по новизне Intel'е).
Если честно, Вы хотите слишком многого от меня.
У меня это общая претензия к статьям подобного рода. Ваша - не первая. Я считаю что уровень материала претендует на интересность, но недостаточно высокий в целом, в виду недостаточных времязатрат на исследование. И чтобы оно было интереснее - нужно провести подобного уровня исследование и для x86 и в данном случаи для ppc. Исследование выбора компилятора тоже полезное свойство.
Иначе, статья производит обманчивое впечатление сравнени за счет того что вы в ней сравниваете результат с другими параллельно с вашим приключением по оптимизации. Тут либо посыл менять, либо делать нормальное сравнение.
Может конечно у меня просто высокие требования к материалам, но я не вижу принципиальных проблем адрессовать комментарии, которые я оставил за разумное время.
Немного дополню почему я спрашиваю про векторизацию - я попробовал погонять код на ноутбуке (понятно, что сравнение не совсем корректно) и чуть-чуть поиграть с флагами сборки, как раз чтобы проверить векторизацию кода. Да, у меня на ноуткбе clang, а не Intel'овский компилятор, но у него в более подробном выводе про векторизацию циклов (-Rpass-analysis=loop-vectorize -Rpass=loop-vectorize -Rpass-missed=loop-vectorize) видно что не все из них векторизуются на -O3 и на Ofast ситуация чуть лучше (на O3 итерация занимает 2.9 секунды, на Ofast - 1.6с, без каких либо дополнительных изменений в коде и при сохранении того же самого вывода, то есть предполагаю что в таком случаи задача все же корректна решена).
Отсюда вопрос, в том как хорошо интеловский компилятор векторизовал написанный код (это опуская вопрос почему был выбран Compiler Classic вместо их нового, да и в целом почему не сравнивали с gcc или llvm, которые немного более распространены среди простых людей)
Флаг компиляции никоим образом не гарантирует, что компилятор что-то векторизовал, тем более Intel C++ Compiler Classic это не самый популярный компилятор с не самыми очевидными наборами флагов (который тем более предлагается заменить на oneAPI C++ Compiler на базе LLVM), например я попросту не помню какие флаги там включают возможность использования AVX, так как последний раз с ним сталкивался лет 5 назад. Также с Power - флаги сборки не гарантируют что компилятор успешно векторизовал цикл, пока не доказано обратного. Ну и AVX2 - они таки 256-и битные регистры должен использвать.
В таком случаи к статье фундаментальная претензия иного рода - вы потратили сколько-то (с виду не мало) времени на оптимизацию кода под одну платформу, но при этом не проделали такой же работы с другими. Без явного указания этих моментов (что статья не преследовала цели сравнить оптимизации на каждой платформе) создается ложное ощущение, что вы считаете код под PPC и Intel эквивалентно оптимизированным. То есть тут либо проделать такую же работу по ним, либо disclaimer в начало. Ну и ценность статьи соответственно падает.
Хм... Это опять же не очевидно, так как в материале код явно используется как бенчмарк и сравнения платформ приводятся параллельно в одной сводной таблице.
Шаг "Векторизация" пропущен для Intel и Power. Кажется тут нужно добавить свидетельства, что компилятор успешно смог использовать AVX2 (ну или хотя бы SSE) и AltiVec соответственно.
Даже если на (1) компилятор на первый взгляд справился на x86/ppc, то было бы неплохо посмотреть и оценить, насколько это хорошо сделано (проделать ту же работу, которая была сделана для Эльбруса).
В целом, правила хорошего тона для публикации бенчмарков - публиковать краткую информацию как ими пользоваться. Это полезно, чтобы любой читатель мог пойти и воспроизвести результаты работы и независимым образом их проверить (или добавить еще машин для сравнения). В целом сюда же еще и ожидаемый вывод было бы неплохо приложить, чтобы у пользователя через эн лет на каком-нибудь совершенно другом железе не возникло вопросов "как проверить, что код до сих пор работает корректно?".
Также правило хорошего тона - выкладывать открытый код для таких бенчмарков. Тут важно понимать, что пока у кода нет явной лицензии, он является собственностью разработчика и технически - проприетарным. Его использование где либо - крайне затруднительно (в том числе очень спорно, можно ли его в принципе даже читать и запускать). Если есть сложности выбрать лицензию - есть сервисы, вкратце рассказывающие про них или сделавшие простенькие wizard'ы.
Не могу понять логическую цепочку, которая привела вас к такому выводу. Извините. Более того - я считаю вывод полностью неверным, так как люди делают публикации о чем считают нужным (тем более я уже устал повторять, что это не исследование потому что это лишь пре-принт не прошедший ревью).
Дополнительно я надеюсь, что вы таки ответите на весь список вопросов из поста выше.
Тут есть проблема - технически СМИ могут писать о чем угодно. Например может существовать СМИ, пишущее о том что земля плоская (тут не уверен, но вроде бы у плоскоземельщиков были свои сайты и они формально - СМИ), но это же не значит, что это так и есть.
Вы позже сказали, процитирую:
Я указал что авторы статьи не являются разработчиками, а то что один из них работает в Университете Джона Хоппкинса - это лишь совпадение (и поэтому препринт опубликован именно на сайте университета).
Дополнительно - я утверждаю что это не исследование, а пре-принт (черновик статьи, не прошедший проверку), это все таки очень разные вещи. Как статья пройдет весь процесс ревью и публикации - так можно будет назвать это исследованием.
И в третьих, из цитаты выше у меня скаладывается ощущение что вы именно что утверждаете что источнику надо доверять и качество статьи хорошее. Простите если я Вас неправильно понял (и в таком случаи, понял неправильно Вас не один я, а значит совет: выражайтесь яснее)
В какой? И из какой Вашей фразы это можно понять?
Автором исследования являются конкретно "Jonas Herby, Lars Jonung, and Steve H. Hanke" и "The views expressed in each working
paper are those of the authors and not necessarily those of the institutions that the authors are affiliated with." (кстати только 1 авторов из университета Джона Хопкинса). Конкретно ни один из них не принимал участия в разработке мероприятий (по вашей же ссылке перечислены основные авторы). Также прежде чем ссылаться на статью имеет смысл прочитать её целиком, конкретно в этом случаи важно помнить что это пре-принт статьи, не прошедшей peer review и на который уже есть множество ответов специалистов в области и журналистов, например: [1] и [2]
В общем, я настоятельно рекомендую ознакомиться со статьей, прежде чем на нее ссылаться (если её вдумчиво прочитать то даже без прямого знакомства с темой она оставляет кучу вопросов, в первую очередь к статистическому анализу и составлению выборки).
Я может быть не совсем корректно выразился. Я вчера так и сделал (там еще надо в main'е одну строку закоментировать, так как она не под ifdef'ом) на M1, получил крайне посредственный результат, примерно на порядок хуже чем дает STREAM на 1 потоке. Так как на ryzen'е я тогда прогнать не мог, то я предположил что оптимизированные функции должны дать лучше производительность (честно, код не особо читал).
На Ryzen'е разница не такая драматическая - всего в 4 раза (1 поток дает чуть-чуть меньше 40 ГБ в секунду у меня, 1 поток в тесте по твоей ссылке - чуть меньше 10).
Мне лень портировать те два бенчмарка, что имеют ассемблерные вставки и используют интринсики на ARM, а без него выходят довольно так себе, если честно.
Для последовательного STREAM дает очень близкие к теоретически возможным результаты.
Ну вот не совсем соглашусь - на первый взгляд кажется, что чтение идет по sizeof(void*) байт за раз, я бы сказал что "совсем произвольное" это по байту. Не то чтобы это принципиально но все таки (результаты по байту скорее всего будут ровно пропорционально хуже). В принципе если поделить на sizeof(void*) то будет очень близко к 10**9/latency, что вполне ожидаемо (на m1 у меня вышло около 60 МБ в секунду - то есть примерно соответствует задеркже в 128нс, в реальности там около 110, на десктопе у меня вышло 86 МБ/с, то есть по задержкам выходит около 93нс, что тоже похоже на правду, у памяти у меня около 85-и в реальности).
Так для последовательного чтения результаты очень сильно занижены еще. По хорошему последовательный код должен быть другим (см. подход в STREAM).
Предполагая, что речь про мой тест - у меня 64 ГБ рам (собственно только поэтому я и взял ноут на M1 Max). Но в целом все равно смешные объемы по сравнению с типичными серверами.
Тут я бы хотел увидеть что такое "совсем произвольный". Чтение по 1 байту из случайных мест? Ну тут ты не сможешь прыгнуть выше головы, это правда (со своими ~80-120ns доступа ты просто физически больше чем 10**9/время_доступа операций за секунду не сделаешь - в данном случаи я в целом, а не конкретно о M1). Даже 100-150 мегабайт это для "совсем случайного" доступа слишком много, кстати.
Там не так просто.
Во первых у простого М1 скорость памяти не так сильно отличается от типичных x86. У M1 Pro - где-то в 4 раза больше чем у типичных x86, у M1 Max общая ПСП - в 8, но только CPU часть не может эффективно его использовать и максимум что можно получить - примерно 250 ГБ в секунду. Но и тут не так просто - потому что с 1 перф кластера ты получаешь не более 100 с небольшим гигабайт в секунду пропускной способности, а с эффективного - около 50-и сверху.
Во вторых, компиляция в ПСП не настолько и упирается. Собственно на примере линейки видно что скорость компиляции на равном количестве ядер (если взять допустим 4 перф ядра) совсем не меняется при переходе с М1 на М1 Макс, хотя казалось бы.
Плюс это не объясняет почему мой M1 Max дает именно в сборке софта те же результаты (лишь чуть больше) чем мой же десктоп на Ryzen 3900X, хотя у меня доступная процессору ПСП на ноуте в 250 ГБ в секунду, а на десктопе всего лишь 51.6 (память у меня 3200MHz всего лишь). Я это проверял на сборке двух довольно больших проектов и получил что M1 конечно быстрее, но всего процентов на 10.
Да, совпадают. И буст у моего 3900x на одном потоке примерно до 4.5 ГГц идет (и успевает на задаче разогнаться).
Про gcc и clang согласен, разница не принципиальная.
А какой именно Ryzen? У меня просто десктоп - ryzen 3900x, я на нем получаю цифры крайне близкие к тому что у автора на его i7-9700k.
Конкретно в этом - Apple M1 Max - и собственно то что результаты получились лучше чем у автора скорее подтверждают предположения что код банально упирается в память (разница как раз раза в 2 с небольшим по пропускной способности на 1 ядро между моим ноутом и тем на чем гонял автор).
В итоге я не очень игрался, просто взял "-Ofast -mtune=native" и несколько флагов просто для получения диагностики про векторизацию ("-Rpass-analysis=loop-vectorize -Rpass=loop-vectorize -Rpass-missed=loop-vectorize")
Собственно начал я с -O3, получил 2.9 секунды, но решил посмотреть что там с векторизацией и увидел что там некоторые циклы clang считает как неэффективные для векторизации, на Ofast у него чуть иной cost-model и он больше векторизует, в итоге получил 1.6 секунды.
Ради интереса я еще пару минут поигрался с флагами, но больше результатов не получал на последнем коммите. Потом прогнал тест на всех коммитах начиная с первого (чтоб проверить что часть претензий про время проверки вообще разумно). Пришлось правда тащить мелкий патчик потому что у автора было изначально вывод результатов раз в 100 итераций и простое умножение на 10 добавляло погрешность в 10% по сравнению с выводом раз в 1000. Получилось такое (во всех случаях "-Ofast -mtune=native", Apple Clang 13.0.0 из последнего xcode'а, mpi из brew, clang также используется как mpicc:
Вариант 0 - 6.48 +- 0.01с
Вариант 1 - 3.30 +- 0.01с
Вариант 2 - 3.18 +- 0.01с
Вариант 3 - 1.85 +- 0.01с
Вариант 4 - 1.85 +- 0.01с
Вариант 5 - 1.84 +- 0.01с
Вариант 6 - 1.84 +- 0.01с
Вариант 7 - 1.72 +- 0.01с
Вариант 8 - 1.62 +- 0.01с
В принципе все это можно автоматизировать за пару минут и прогон 8-и вариантов суммарно занимает меньше 10 минут. Собственно после чего автору и предъявил претензию о выборе компилятора и бездоказательности векторизации (недостаточно проделанной работе по оптимизации под другие системы или доказательства, что такая оптимизация уже делается компилятором).
А да, проверка корректности, так как на момент как я это все гонял, автор не привел ожидаемый вывод при корректной работе, делалась в сравнении с x86 десктопом где код собирался clang'ом и отдельно gcc с консервативным -O2 и я просто убедился зрительно, что вывод не поменялся и на маке с Ofast такой же.
UPD: делал буквально так (версия mpi естественно может поменяться в зависимости от системы и времени когда кто-то будет пытаться это снова запустить):
Это вполне ожидаемо, минусы коменту накидали либо те, кому Эльбрус нравится, либо те кто считают что я за качество материала на автора наехал незаслуженно (по другим метрикам я предполагаю что первых было большинство).
Сравните стоимость заводика с тем, что получает Индия от нормальных отношений с США и ЕС.
Вы таки определитесь - у вас весь этот тред был шуткой или он весь - "хотя...". Текст в интернете не передает достаточно информации, чтобы я, как читатель, мог бы с уверенностью что-либо утверждать.
Если РФ будет дальше попадать под более жесткие санкции, то в момент как компании лишатся доступа к TSMC они же лешаться и доступа к гипотетическому заводу в Индии. Все потому, что без санкционных технологий наладить производство по современным нормам не выйдет. А дальше уже вопрос к Индии - захотят ли они в такой ситуации рискнуть сотрудничеством с США и другими странами, ради маленького контракта с Россией (и тут я сомневаюсь, что они пойдут на конфликт).
Чтобы взять готовое и модернизировать нужно чтобы это готовое было (а тут из не-купленного оборудования только то что осталось от СССР и разработано в конце 80-х), чтобы это готовое понимали (поэтому не выйдет разобрать STM'овское или AMDшное оборудование которое в 2000-х купили), а также чтобы сопутствующие отрасли делали нужного качества продукцию (условно, та же оптика и хим промышленность - иначе смысл делать свое с таким посылом, если оптику и материалы надо импортировать?).
Так как в целом немного понятно куда копать надо, теоретически можно пройти путь не за 30-35 лет на которое сейчас отставание, а лет за 20. Естестенно если вкладываться в это по-полной (а по-полной - это суммы порядка триллионов долларов) и если попутно эти вложения будут расходоваться целевым образом.
Это только речь про технологию, без учета персонала и ученых, которые эту технологию будут разрабатывать.
А какую проблему (кроме того куда потратить деньги) это решит? В случаи санкций, о которых в этом треде речь, запрет будет касаться всех, кто использует технологии, то есть и гипотетический индийский заводик будет недоступен и SMIC тоже.
Более того - микроэлектроника это такая отрась, где ты вкладываешь хх млрд USD сейчас в оборудование и строительство завода, а работать оно начинает лет так через 5+ (если не будет как с HSMC).
Если это в статье не упомянуто, то как я могу знать что вы это проверяли? Опять же, пример на базе эксперимента выше (да, с clang'ом) я привел - то есть я еще и дополнительно видел что не все что стоит векторизуется корректно с тем что привдено (правда да, на другом компиляторе, но у меня нет под рукой систем на разумном по новизне Intel'е).
У меня это общая претензия к статьям подобного рода. Ваша - не первая. Я считаю что уровень материала претендует на интересность, но недостаточно высокий в целом, в виду недостаточных времязатрат на исследование. И чтобы оно было интереснее - нужно провести подобного уровня исследование и для x86 и в данном случаи для ppc. Исследование выбора компилятора тоже полезное свойство.
Иначе, статья производит обманчивое впечатление сравнени за счет того что вы в ней сравниваете результат с другими параллельно с вашим приключением по оптимизации. Тут либо посыл менять, либо делать нормальное сравнение.
Может конечно у меня просто высокие требования к материалам, но я не вижу принципиальных проблем адрессовать комментарии, которые я оставил за разумное время.
Немного дополню почему я спрашиваю про векторизацию - я попробовал погонять код на ноутбуке (понятно, что сравнение не совсем корректно) и чуть-чуть поиграть с флагами сборки, как раз чтобы проверить векторизацию кода. Да, у меня на ноуткбе clang, а не Intel'овский компилятор, но у него в более подробном выводе про векторизацию циклов (-Rpass-analysis=loop-vectorize -Rpass=loop-vectorize -Rpass-missed=loop-vectorize) видно что не все из них векторизуются на -O3 и на Ofast ситуация чуть лучше (на O3 итерация занимает 2.9 секунды, на Ofast - 1.6с, без каких либо дополнительных изменений в коде и при сохранении того же самого вывода, то есть предполагаю что в таком случаи задача все же корректна решена).
Отсюда вопрос, в том как хорошо интеловский компилятор векторизовал написанный код (это опуская вопрос почему был выбран Compiler Classic вместо их нового, да и в целом почему не сравнивали с gcc или llvm, которые немного более распространены среди простых людей)
Флаг компиляции никоим образом не гарантирует, что компилятор что-то векторизовал, тем более Intel C++ Compiler Classic это не самый популярный компилятор с не самыми очевидными наборами флагов (который тем более предлагается заменить на oneAPI C++ Compiler на базе LLVM), например я попросту не помню какие флаги там включают возможность использования AVX, так как последний раз с ним сталкивался лет 5 назад.
Также с Power - флаги сборки не гарантируют что компилятор успешно векторизовал цикл, пока не доказано обратного. Ну и AVX2 - они таки 256-и битные регистры должен использвать.
В таком случаи к статье фундаментальная претензия иного рода - вы потратили сколько-то (с виду не мало) времени на оптимизацию кода под одну платформу, но при этом не проделали такой же работы с другими. Без явного указания этих моментов (что статья не преследовала цели сравнить оптимизации на каждой платформе) создается ложное ощущение, что вы считаете код под PPC и Intel эквивалентно оптимизированным. То есть тут либо проделать такую же работу по ним, либо disclaimer в начало. Ну и ценность статьи соответственно падает.
Хм... Это опять же не очевидно, так как в материале код явно используется как бенчмарк и сравнения платформ приводятся параллельно в одной сводной таблице.
Спасибо за файл с лицензией.
К автору несколько вопросов/комментариев есть:
Шаг "Векторизация" пропущен для Intel и Power. Кажется тут нужно добавить свидетельства, что компилятор успешно смог использовать AVX2 (ну или хотя бы SSE) и AltiVec соответственно.
Даже если на (1) компилятор на первый взгляд справился на x86/ppc, то было бы неплохо посмотреть и оценить, насколько это хорошо сделано (проделать ту же работу, которая была сделана для Эльбруса).
В целом, правила хорошего тона для публикации бенчмарков - публиковать краткую информацию как ими пользоваться. Это полезно, чтобы любой читатель мог пойти и воспроизвести результаты работы и независимым образом их проверить (или добавить еще машин для сравнения). В целом сюда же еще и ожидаемый вывод было бы неплохо приложить, чтобы у пользователя через эн лет на каком-нибудь совершенно другом железе не возникло вопросов "как проверить, что код до сих пор работает корректно?".
Также правило хорошего тона - выкладывать открытый код для таких бенчмарков. Тут важно понимать, что пока у кода нет явной лицензии, он является собственностью разработчика и технически - проприетарным. Его использование где либо - крайне затруднительно (в том числе очень спорно, можно ли его в принципе даже читать и запускать). Если есть сложности выбрать лицензию - есть сервисы, вкратце рассказывающие про них или сделавшие простенькие wizard'ы.