обычный цикл с прыжком наверх как на интеле, и тут же обрабатываются элементы массива, вытаскиваются лоадом и вместо перестановки просто кладутся со смещением:
И третий бранч как раз ведет туда где косвенно вызываются функции как положено. Так что вот, компилятору на отдельные функции плевать он исходит из того что творится в процедуре, а тут цикличные вызовы с принтами и таймклоками в цикле, и смысла нет видимо заморачиваться.
Извините, я не выспался. Я посмотрел файлы, сопоставил функции diff -ом посмотрел глазами main там и там, всё вроде одинаково. Единственное что может быть вот эта вот проверка как то влияет:
То есть он берет из вашей таблицы вызовов текущий адрес по индексу и проверяет зачем то сравнивает с адресом функции etalon дальше там идет предикатное наперстачничество и какой-то мухлеж это уже разобрать довольно сложно.
Если вы про мой код, то это было давно и я не помню где эти файлы. Но там проблема скорей всего была в том, что внешняя процедура с её циклом заняли и так много регистров и когда к ним добавлялись еще базированные-конвейризированные из раскрученного цикла векторизованной функции, регистровый файл видать закончился. Компилятор такие вещи при компиляции всей программы видит и недопускает, а если ему отдельные функции суют да еще с прагмами требующими раскрутки, ему понятное дело ничего не остается.
У вас же код обоих функций абсолютно идентичный, наверное просто не стоило все функции заталкивать в одну программу.
Из консольного вывода от разных размеров массива видно, что эталонный вариант всегда выполняется на 40–50 тактов быстрее. Я не смог понять, с чем это связано (особенности расположения кода в памяти?).
Это может быть связано с тем, что компилятор при выводе показывает один код, а при компиляции полной программы сгенерируект совсем другой, так как исполнение этого когда в контексте другого когда сильно меняет всю картину компилятору и он может например вообще выкинуть векторизацию, вставить какой-то рыхлый цикл с apb и он почему то оказывается быстрей чем все попытки векторизовать это все принудительно. Может конечно это и просто моя ошибка была, но в любом случае дамп бинарника никому ненавредит.
occupancy склеивает занятость устройства и слота. div8.c меряет устройство (раз в 2 такта), а в fma_kernel.sfdivd,5@t19 + aaurwd,5@t20 - слот свободен раньше. Модель пессимистична сознательно.
Он ничего не льет, он усиленно демонстрирует как будет работать языком поддерживая все решения сверху,. Очевидно хочет чтоб его заметили и взяли куда нибудь в экспертный совет, депутатом или хотя бы на фед. каналы начали регулярно приглашать.
Человек всю жизнь занимался непойми чем, ничего толком неумеет. Захотел как Вассерман на старость лет хоть медийно стрельнуть и куда то пристроиться чтоб не встретить конец в нищете и одиночестве.
Получается APB умеет по четырем адресам в память ходить. Скорей всего это только в пределах одного общего массива работает, но все равно любопытно. Про кэш я конечно же ересь сказал, оно же не префетчер в обычном понимании, и само никуда (кроме своего буфера) ничего не подкачивает, так что ничего там не засоряется и не толкается.
Стены инструкций в конце это жесть конечно, при этом удивляет что библиотека EML местами умеет еще быстрее. Так что плотность кода это далеко не все.
А почему в ассемблерном выхлопе операции над двойными и квадро-числами делаются на одинарных регистрах? Или это (очередно) баг вывода lcc -S ?
Обычно для оптимизации работы с данными делают именно чтение линейным, а запись можно раскидывать по адресам, иначе какая раскрутка и какой префетч когда у нас по большому счету 4ре массива в кэше толкаются.
Ну и вместо всех вот этих бесполезных прагм лучше указывать restrict const ✶data_in, restrict ✶data_out чтоб компилятор мог примерно понять что мы делаем с данными в рантайме.
Люди из высоких кабинетов едва ли знают какой у них на рабочем компе процессор стоит. Для них "лунгсон" или "рискфайв" это просто какие-то названия как лисян или фольксваген. Им самим эти лунгсоны с эльбрусами и байкалами нафиг не нужны, они нужны в "каких-то там важных инфраструктурах" с которыми работают специалисты. Интерес высоких людей к этим темам просыпается только тогда, когда есть полностью готовое и проверенное решение типа оборудования от хуавей и экосистемы интел/амд, и под это можно организовать предприятие по продаже этого оборудования в госсектор. Если какой то закон встает на пути на него кладут болт или меняют/обходят, если он мешает важным людям делать важное дело.
С лунгсоном явно другая история, это сырой продукт с плохо развитой экосистемой которое в высоких кабинетах врядли кого-то мог заинтересовать, поэтому китайцы нашли мелкую компанию которая работала с госами и предложила им свой хитрый план. Чем это кончится я думаю очевидно, ведь то что можно юпитеру обычно непростительно быку.
С иртышом то все понятно, но вот этот Лунгсон подозрительно похож на AMD Threadripper первых поколений. Я помню какой-то обзор на LA 3A4000 это был еще обычный MIPS доработанный китайцами, который свободно продавался на алиэкспрессе в составе всяких китайских устройств. А тут на 3A5000-3A6000 вдруг произошел резкий рывок в какую-то свою архитектуру, причем у нее 2 треда на ядро, операции над 128/256 векторами ну и конечно шина HyperTransport с AMD-шным южным мостом.
По первым абзацам примерно понимаю к чему все это клонит. Предлагаю от слов перейти к делу, вот здесь https://git.kolibrios.org/ лежат исходники ОС аля Win98 от российских разработчиков. Поскольку авторы не шибко думали о будущем и перспективах, данная ОС прибита гвоздями к i386 ассемблеру и не может быть портирована ни на мипс/риск-5 ни на эльбрус. На каком то форуме разработчик божился что перепишет таки код на си но видимо былого задора уже нет. Предлагаю ему/им помочь и воплотить задуманное в жизнь. Пока ты сам не возьмешь и не сделаешь, никто не сделает. Хоть весь интернет ахренительными идеями испиши.
Насколько я помню AMD продал китайцам ядра Zen первого поколения. Похоже что китайцы написали свой микрокод, перелопатили подсистему памяти, ну и разработали интерконнект.
Но особенно на это намекает десктопная версия: LS3A6000: 2.0–2.5GHz, 4/8 cores/threads, 16MB L3, 2xDDR4-3200, HyperTransport 3.0 (64-bit superscalar LA664 cores; supporting LoongArch instruction set architecture; supporting 128/256-bit vector instructions; 6-issue out-of-order execution; 4 fixed-point units, 4 vector units, and 4 memory access units )
Реально отличия только в немного измененной подсистеме памяти.
ОТО базируется на математических уравнениях, которые какие-то эффекты и поведение на больших объектах и больших расстояниях предсказывают с очень даже отличной точностью. Это так, но это не дает оснований приносить геометрического гомункула (ака пространство-время) в область естественно-научных знаний и пытаться его там прописать. Природа у всех этих явлений иная (квантовая) и она не обязана соответствовать чьим-либо ожиданиям, а предсказать свойства атомов на зная их состав и марку тот же Менделеев умудрился. И что теперь, бегать теорию эфира пропагандировать что-ли.
Проблема в том что ученые разные, например тот же Сурдин в одном из первых эфиров с Семихатовым вообще удивился узнав что ОТО оказывается чисто математическая модель и с современной физикой не состыкуется. Пусть он и астроном и ему это знать по большому счету не нужно, но тем не менее это показывает что картины мира у ученых разные. Астрофизики которые были у дройдера на эфире один за другим вещали про не квантовую природу гравитации, и данная статья тоже показывает что есть пласт ученых которые будут отстаивать ОТО как теорию до конца.
В калифорнии уже детектор гравитонов сооружают, если все подтвердится, про ОТО как теорию можно будет говорить только в холеварах на форумах, нобелевки за её отстаивание уже не дадут. А ролики где дяди на батуте шарики запускают, придется переносить в категорию #юмор.
Перечитал на проспавшуюся голову, да вы правы "какой наш следующий шаг?" имелось в виду его и разработчиков из МЦСТ. А вот маинтейнер ответил по сути что МЦСТ в этом участвовать нельзя. Короче надо просто исключить упоминания этой и других подсанкционных компаний из разговоров и кода. Ну и россии наверное тоже, таковы современные реалии.
Тоже особо не понял по поводу чего визги. Как я понял из скриншота, некий энтузиаст (не из МЦСТ) написал кому то из маинтейнеров что мол вот там у них в репозитории лежит код, давайте его заапстримим, я мол готов тащить в одно лицо, с чего начнем? Ну и скучающий седой вахтер ему посоветовал начать с поиска опытных людей в команду, а так же с выяснения юридических вопросов можно ли вообще брать тот код и просто так заливать в апстрим. По большому счету отмахнулся да, но мне тоже показалась что энтузиаст не совсем понимает что это не тот проект где добавил пару правил и вот тебе поддержка, нужен кто то кто будет сопровождать архитектуру (тем более такую) постоянно, в идеале это должен быть штатный разработчик из МЦСТ, а не вася седня есть, завтра нету и мне пофиг
Похоже еще веселее, вот три путя:
M_13be8 и M_138a0 практически одинаковые, и ведут примерно вот в такой код:
обычный цикл с прыжком наверх как на интеле, и тут же обрабатываются элементы массива, вытаскиваются лоадом и вместо перестановки просто кладутся со смещением:
И третий бранч как раз ведет туда где косвенно вызываются функции как положено. Так что вот, компилятору на отдельные функции плевать он исходит из того что творится в процедуре, а тут цикличные вызовы с принтами и таймклоками в цикле, и смысла нет видимо заморачиваться.
Извините, я не выспался. Я посмотрел файлы, сопоставил функции diff -ом посмотрел глазами main там и там, всё вроде одинаково. Единственное что может быть вот эта вот проверка как то влияет:
ldd,0 [ %dr12 +f64,lts0 0x17090 -> stage_radix2_vector2_algorithm ], %dr0cmpedb,1 %dr0,f64,lts0 0x123a0 -> stage_radix2_vector2_etalon , %pred1То есть он берет из вашей таблицы вызовов текущий адрес по индексу и проверяет зачем то сравнивает с адресом функции etalon дальше там идет предикатное наперстачничество и какой-то мухлеж это уже разобрать довольно сложно.
Если вы про мой код, то это было давно и я не помню где эти файлы. Но там проблема скорей всего была в том, что внешняя процедура с её циклом заняли и так много регистров и когда к ним добавлялись еще базированные-конвейризированные из раскрученного цикла векторизованной функции, регистровый файл видать закончился. Компилятор такие вещи при компиляции всей программы видит и недопускает, а если ему отдельные функции суют да еще с прагмами требующими раскрутки, ему понятное дело ничего не остается.
У вас же код обоих функций абсолютно идентичный, наверное просто не стоило все функции заталкивать в одну программу.
Это может быть связано с тем, что компилятор при выводе показывает один код, а при компиляции полной программы сгенерируект совсем другой, так как исполнение этого когда в контексте другого когда сильно меняет всю картину компилятору и он может например вообще выкинуть векторизацию, вставить какой-то рыхлый цикл с apb и он почему то оказывается быстрей чем все попытки векторизовать это все принудительно. Может конечно это и просто моя ошибка была, но в любом случае дамп бинарника никому ненавредит.
Да тут не телеграфный, а галюцинирующий:
Какая-то завуалированная реклама написанная нейросетью.
На мой взгляд, начинать "оптимизировать" следовало вот отсюда:
Все остальное переписывание на си-подобный код бессмысленно, либо надо было все на си и писать тогда.
Он ничего не льет, он усиленно демонстрирует как будет работать языком поддерживая все решения сверху,. Очевидно хочет чтоб его заметили и взяли куда нибудь в экспертный совет, депутатом или хотя бы на фед. каналы начали регулярно приглашать.
Человек всю жизнь занимался непойми чем, ничего толком неумеет. Захотел как Вассерман на старость лет хоть медийно стрельнуть и куда то пристроиться чтоб не встретить конец в нищете и одиночестве.
Получается APB умеет по четырем адресам в память ходить. Скорей всего это только в пределах одного общего массива работает, но все равно любопытно.
Про кэш я конечно же ересь сказал, оно же не префетчер в обычном понимании, и само никуда (кроме своего буфера) ничего не подкачивает, так что ничего там не засоряется и не толкается.
Стены инструкций в конце это жесть конечно, при этом удивляет что библиотека EML местами умеет еще быстрее. Так что плотность кода это далеко не все.
А почему в ассемблерном выхлопе операции над двойными и квадро-числами делаются на одинарных регистрах? Или это (очередно) баг вывода
lcc -S?Обычно для оптимизации работы с данными делают именно чтение линейным, а запись можно раскидывать по адресам, иначе какая раскрутка и какой префетч когда у нас по большому счету 4ре массива в кэше толкаются.
Ну и вместо всех вот этих бесполезных прагм лучше указывать
restrict const ✶data_in, restrict ✶data_outчтоб компилятор мог примерно понять что мы делаем с данными в рантайме.Люди из высоких кабинетов едва ли знают какой у них на рабочем компе процессор стоит. Для них "лунгсон" или "рискфайв" это просто какие-то названия как лисян или фольксваген. Им самим эти лунгсоны с эльбрусами и байкалами нафиг не нужны, они нужны в "каких-то там важных инфраструктурах" с которыми работают специалисты. Интерес высоких людей к этим темам просыпается только тогда, когда есть полностью готовое и проверенное решение типа оборудования от хуавей и экосистемы интел/амд, и под это можно организовать предприятие по продаже этого оборудования в госсектор. Если какой то закон встает на пути на него кладут болт или меняют/обходят, если он мешает важным людям делать важное дело.
С лунгсоном явно другая история, это сырой продукт с плохо развитой экосистемой которое в высоких кабинетах врядли кого-то мог заинтересовать, поэтому китайцы нашли мелкую компанию которая работала с госами и предложила им свой хитрый план. Чем это кончится я думаю очевидно, ведь то что можно юпитеру обычно непростительно быку.
С иртышом то все понятно, но вот этот Лунгсон подозрительно похож на AMD Threadripper первых поколений. Я помню какой-то обзор на LA 3A4000 это был еще обычный MIPS доработанный китайцами, который свободно продавался на алиэкспрессе в составе всяких китайских устройств.
А тут на 3A5000-3A6000 вдруг произошел резкий рывок в какую-то свою архитектуру, причем у нее 2 треда на ядро, операции над 128/256 векторами ну и конечно шина HyperTransport с AMD-шным южным мостом.
По первым абзацам примерно понимаю к чему все это клонит.
Предлагаю от слов перейти к делу, вот здесь https://git.kolibrios.org/ лежат исходники ОС аля Win98 от российских разработчиков. Поскольку авторы не шибко думали о будущем и перспективах, данная ОС прибита гвоздями к i386 ассемблеру и не может быть портирована ни на мипс/риск-5 ни на эльбрус. На каком то форуме разработчик божился что перепишет таки код на си но видимо былого задора уже нет. Предлагаю ему/им помочь и воплотить задуманное в жизнь. Пока ты сам не возьмешь и не сделаешь, никто не сделает. Хоть весь интернет ахренительными идеями испиши.
Эльбрус-2 это машина с 10ю процессорами, Cray-2 тоже не процессор.
Что тут с чем сравнивается непонятно, впрочем статью писал чатжпт походу
Этот лунгсон-иртыш очень похож на AMD EPYC первых итераций:
LS3C6000 SpecificationCores : 16(S) 32(D) 64(Q)
Threads : 32(S) 64(D) 128(Q)
Frequency : 844.8GFlops@2.2GHz (S)
1612.8GFlops@2.1GHz (D)
3072.0GFlops@2.0GHz (Q)
L1 Cache : 64KB (instructions) + 64KB (data)
L2 Cache : 256KB (privarate) ~ 4MB(S) 8MB(D) 16MB(Q)
L3 Cache : 32MB (shared)
Memory : 4×72-bit DDR4-3200 controller(S),
8×72-bit DDR4-3200 controller(D/Q)
PCIe : 64 lanes total(S)
128 lanes total(D/Q)
Power : 100W-120W (S)
180W-200W (D)
250W-300W (Q)
Насколько я помню AMD продал китайцам ядра Zen первого поколения.
Похоже что китайцы написали свой микрокод, перелопатили подсистему памяти, ну и разработали интерконнект.
Но особенно на это намекает десктопная версия:
LS3A6000: 2.0–2.5GHz, 4/8 cores/threads, 16MB L3, 2xDDR4-3200, HyperTransport 3.0(64-bit superscalar LA664 cores; supporting LoongArch instruction set architecture; supporting 128/256-bit vector instructions; 6-issue out-of-order execution; 4 fixed-point units, 4 vector units, and 4 memory access units )
Реально отличия только в немного измененной подсистеме памяти.
ОТО базируется на математических уравнениях, которые какие-то эффекты и поведение на больших объектах и больших расстояниях предсказывают с очень даже отличной точностью. Это так, но это не дает оснований приносить геометрического гомункула (ака пространство-время) в область естественно-научных знаний и пытаться его там прописать. Природа у всех этих явлений иная (квантовая) и она не обязана соответствовать чьим-либо ожиданиям, а предсказать свойства атомов на зная их состав и марку тот же Менделеев умудрился. И что теперь, бегать теорию эфира пропагандировать что-ли.
Проблема в том что ученые разные, например тот же Сурдин в одном из первых эфиров с Семихатовым вообще удивился узнав что ОТО оказывается чисто математическая модель и с современной физикой не состыкуется. Пусть он и астроном и ему это знать по большому счету не нужно, но тем не менее это показывает что картины мира у ученых разные.
Астрофизики которые были у дройдера на эфире один за другим вещали про не квантовую природу гравитации, и данная статья тоже показывает что есть пласт ученых которые будут отстаивать ОТО как теорию до конца.
В калифорнии уже детектор гравитонов сооружают, если все подтвердится, про ОТО как теорию можно будет говорить только в холеварах на форумах, нобелевки за её отстаивание уже не дадут. А ролики где дяди на батуте шарики запускают, придется переносить в категорию #юмор.
Перечитал на проспавшуюся голову, да вы правы "какой наш следующий шаг?" имелось в виду его и разработчиков из МЦСТ. А вот маинтейнер ответил по сути что МЦСТ в этом участвовать нельзя. Короче надо просто исключить упоминания этой и других подсанкционных компаний из разговоров и кода. Ну и россии наверное тоже, таковы современные реалии.
Тоже особо не понял по поводу чего визги.
Как я понял из скриншота, некий энтузиаст (не из МЦСТ) написал кому то из маинтейнеров что мол вот там у них в репозитории лежит код, давайте его заапстримим, я мол готов тащить в одно лицо, с чего начнем?
Ну и скучающий седой вахтер ему посоветовал начать с поиска опытных людей в команду, а так же с выяснения юридических вопросов можно ли вообще брать тот код и просто так заливать в апстрим. По большому счету отмахнулся да, но мне тоже показалась что энтузиаст не совсем понимает что это не тот проект где добавил пару правил и вот тебе поддержка, нужен кто то кто будет сопровождать архитектуру (тем более такую) постоянно, в идеале это должен быть штатный разработчик из МЦСТ, а не вася седня есть, завтра нету и мне пофиг