ну вообще эти самые то ли 360, то ли 270млрд руб уже выделены. Если их не раздадут разработчикам микроэлектроники -- они просто уйдут в бюджет. Причём на данный момент озвучено всего 12 сквозных проектов. С ограничением по максимальной стоимости. То есть денег ещё есть на несколько проектов.
Так что если надо -- подавайте заявку. Я вот не очень понимаю почему не подают...
на самом деле я был бы совсем не против развития микроархитектуры Эльбруса и по пути "ванильного VLIW". Собственно, даже у Бабаяна была большая программа развития микроархитектуры. То, что озвучивалось -- удвоение числа вычислительных кластеров.
Пороховая бочка, доверха набитая хейтерьём, которое переклинивает от слова «отечественный»
надеюсь, это Вы про "Политику" пишете, а не про тематические разделы. Наша ветка в "процессорах" находится, н никого там от её названия не клинит.
Единственное что: к нам регулярно приходят неофиты и, искренне считая, что своим приходом несут светоч истины, вываливают в ветку стандартный набор мифов об Эльбрусе. Им конечно тяжело вначале приходится, но потом как-то приобтираются, если конечно у них было что-то в мозгах кроме этих мифов.
Человек с ixbt зашёл в барна хабр(с)
я действительно давно в комменты не заходил, и потому удивился как изменилось за это время мнение посетителей хабра на предмет отечественных процессоров. В частности -- как тут минусят этих самых мифоносителей, сразу и без дискуссий. Не, на ixbt таких инструментов бана просто нет, есть только чёрный список, так что в нашей ветке вполе себе уживаются все "сто цветов" мнений относительно Эльбруса.
вполне современный тезис, в свете описанного в самом начале статьи
я как раз не собирался обвинять Вас в ангажированности, и потому наоборот, изначально хотел отделить "современность" дискуссии "VLIW vs [RC]ISC" от её "своевременности". Про второе, естественно, согласен. Ибо в концепции "сквозных проектов" надо найти потребителей, которые будут готовы через 3 года купить разработанное на эти самые "крупные инвестиции". А Эльбрусы покупать никто не готов (тут выше писали о каком-то "главном заранее удовлетворённом заказчике", но это всё из области тех мифов, отсутствие которых -- это главное, что проимпонировало мне в Вашей статье). А из тех причин, по которым потребители не готовы покупать Эльбрусы, "уникальность архитектуры" конечно самая простая, понятная, и никак не устранимая за предлагаемые сроки и деньги. Но я надеялся, что статья не только об этом.
Нет, я не утверждаю, что ARM - это правильная архитектура.
я наверное не очень внятно тут сформулировал: это я утверждал, что с технической точки зрения, ставка на ARM у Байкал Электроникс была правильной. Но, как бы то ни было, уверенно превзойти e2k по производительности Байкал-M удалось пока только в JS. Как это объяснить в рамках Вашего правильного тезиса? Вы же о производительности писали? Не о других свойствах Байкалов (в том числе и -T), которые позволяют легко обыгрывать Эльбрусы в тех немногочисленных тендерах, что удалось провести?
Но сразу скажу, если вы и в дальнейшем будете использовать такую же манеру общения, диалог не сложится.
Вероятно, это я буду виноват. Но, поскольку я очень редко пишу комментарии в статьи на habr-e, а с Вами вообще в первый раз общаюсь, то пока не очень понимаю как мне формулировать свои мысли, чтобы Вы не обиделись. Потому сразу и пригласил Вас в наш междусобойчик, где все друг друга за 20 лет хорошо узнали. Там я стараюсь не обижать даже упёртых эльбрусофилов...
Гарантий нет, но это не повод оставлять всё как есть
Вы считаете, что "сквозные проекты" имеют хоть один шанс не "просквозить как фанера над Парижем" в очередной раз? Ответьте пожалуйста, я перенесу Ваш ответ в нашу "вечную" ветку, и через 3-4 года мы узнаем были ли Вы правы или нет. Там за 20 лет уже много таких предсказаний накопилось...
Сложность развития микроархитектуры, т.к. в случае VLIW это почти всегда влечёт за собой изменение в архитектуре
да, это я пропустил --- упоминание действительно есть. Хотя с этим я бы как раз поспорил. Микроархитектура в том же Итаниум развивалась вполне себе в тренде, о чём Вам уже написали. Однако суть в том, что в e2k она не развивалась (даже не важно по каким именно причинам, например, там не только OoO нет, но даже аппаратного префетча), потому "Эльбрус это просто старые процессоры" --- это не совсем миф. IMHO конечно.
процессорная платформа, которая претендует стать массовой и конкуретной на рынке десктопных и серверных процессоров, не может быть VLIW архитектурой
конечно правильная, но устаревшая лет на 20. Именно тогда и следовало бы выбирать "правильную" архитектуру на основе озвученных автором тезисов. Причём, как мы теперь знаем, названием этой "правильной" архитектуры -- это первые 3 буквы из имени автора. Но 20 лет назад OoO там не было. А когда появилась, то по этому пути пошёл Байкал, но тоже не особо преуспел, и это даже если не принимать во внимание судьбу Опанасенко.
В любом случае, обстоятельства сложились по-другому, и все последние четверть века МЦСТ "пилили" свою собственную e2k, прекрасно зная о её принципиальных недостатках (собственно, в статье так и написано). И по самым скромным оценкам на это уже потрачено несколько сотен миллионов долларов гос.финансирования. Кому именно автор теперь предлагает сказать сакраментальное: "Работа проделана большая, так дело не пойдёт" (с) ?
С другой стороны, вынесенный в название тезис "тупик для развития отечественной линейки general-purpose CPU" вообще с правильным тезисом мало связан, поскольку как минимум предполагает, что существует какой-то нетупиковый путь "развития отечественной линейки general-purpose CPU". Причём автор его знает. Очень интересно было бы чтобы он с нами поделился этим видением.
Иначе где вообще гарантия, что цели Yadro чем-то отличаются от целей МЦСТ, а возможности разработки (в том числе и квалификация разработчиков) успешно заменяется связями в правительстве.
Конечно можно рассмотреть и технические аспекты статьи. Например, автор конечно очень правильно разделил "архитектуру" и "микроархитектуру". И даже указал, что RISC/CISC победил благодаря развитию микроархитектуры. Но почему-то забыл даже упомянуть (а хотелост бы обсудить), что микроархитектура e2k со времён известной статьи в MPR претерпела лишь косметические изменения.
Короче, тут в комментариях мы вряд ли сумеем конструктивно продвинуться в данном вопросе "Тупик или не тупик?". Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?
>Был задан конкретный вопрос, что если по мнению эксперта анролл не нужен — зачем тогда существует лсд?
1. Эксперт — это кто?
2. C ЛСД Вам надо завязывать — тогда глядишь и перестанет чудиться то, чего нет на самом деле.
>Что такое «ширина конвейера»? И почему её не хватает?
число портов запуска, я это уже писал
> Почему же эта ширина конвейера не учитывалась при:
Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
Компилируем то же на icc и
как говорится — найдите отличия ;)
ну и заодно — угадайте, сколько именно тактов работает такой цикл
>А я скажу почему — это всё просто пустой трёп
Знаете, в чём Ваше отличие от автора статьи — в отсутствии рефлексии. Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.
>Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт.
На самом деле, до того как Вы пришли — я этого не говорил.
Поскольку я последние три года занимался в основном оптимизацией для GPU. А там анролл циклов действительно нужен в подавляющем числе ситуаций (хотя конечно ни о каких ускорениях на порядки речи тоже нет).
Но если Вы настаиваете, то я таки сформулирую своё мнение на unroll:
Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.
>Во-первых «около» — это на 50% медленнее?
это на пол-такта медленнее оценки.
>поймать результат лсд
какой результат?
>Отличная история… Вот ведь дураки пацаны— апаратный анроллер запилили
Такое впечатление, что Вы беседуете с голосами в своей голове.
Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
>поймали его ограничение
Кто поймал? Если Вы о 1.5 тактах вместо 1, то никаких сложных объяснений тут искать не надо. Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).
>стоит его зантроллить и он покажет максимальный трупут.
исключительно за счёт ликвидации накладных расходов на саму организацию цикла (сравнение и переход), которые для такого простого цикла на 4 содержательные операции — весьма велики.
Но в общем и целом, после появления в интеловских процессорвах кэша предекодированных uop-ов, раскрутку циклов надо делать очень осторожно — велика вероятность в него не вписаться, и в результате попасть на ограничения куда более узкого места — декодера.
>Могу только сказать — могут
Моя сентенция относилась к конкретному примеру, где было показано ускорение в 30 что ли раз за счёт раскрутки. В данном случае это было явно следствие ошибки, что уже давным-давно выяснили.
А насчет «могут или не могут» — я за время своей практики многое встречал.
Тем не менее — пример приветствуется.
хорошо.
Теперь применяем те же рассуждения к Эльбрусу.
получаем 2 итерации цикла за такт, откуда сразу же следуют два вывода, находящиеся в противоречии с Вашей статьей:
раскрутка цикла делается компилятором Эльбруса автоматически (за такт ядро Эльбруса может сделать только один переход — см доки)
в «расчете на гигагерц» в этом тесте производительность Эльбруса и core-i одинаковые — две итерации за такт (если использовать максимальный уровень оптимизации компилятором)
Таким образом, самый плохой результат (255мс) — это реально 1.5 такта на итерацию, что уже соответствует околотеоретической производительности.
Хорошо.
Осталось понять чему именно соответствует результат 5мс (32 итерации за такт)?
Очевидно, сохранения 32 интов за такт одно ядро i7 сделать не сможет, даже при полной векторизации на AVX2.
Отсюда понимаем, что паттерн оптимизации «Пример 1. Развертывание циклов» соответствует замене приведённого кода каким-то другим, где не надо делать столько сохранений.
конкретно речь о строчке
a[kpp] = k; (тут я специально заменил k++ на kpp, чтобы не рассматривать лишнюю операцию сложения)
Суть:
в исходном коде эту операцию надо сделать 64000*10000=0.64*10^9 раз.
Утверждение: на одном ядре i7 это невозможно сделать за 5мс.
PS: «эффективное использование конвейера,… несколько АЛУ, усовершенствованный кэш, Out of Order Execution» — на это утверждение никак не влияют.
потому что там навскидку видно 5 команд:
есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
В частности, только один для сохранения данных. Так что навскидку получается такт.
В такой простой синтетике обычно сравнивают не разные процессоры, а достигнутую производительность с теоретически возможной.
Сооветственно, как интерпретировать приведённые результаты?
вот берём «Пример 1. Развертывание циклов»
результат для i7: Время, мс 5-255.
Это что, 64000 итераций такого простого цикла много миллисекунд считаются? — как-то очень сомнительно.
Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию, т.е. ждём время исполнения этого кода существенно меньше одной миллисекунды (что не так-то просто и померить, кстати ;)).
Короче, взял Ваш код, обернул тестируемый цикл во внешний с числом итераций 100000 (дабы привести время к человеческим временам, а заодно и исключить краевые эффекты, типа непрогретого кэша), и прогнал на Intel® Core(TM) i5-4460 CPU @ 3.20GHz
результаты
$ g++ -O3 -o t1 t1.cpp; time ./t1
real 0m0.973s
user 0m0.968s
sys 0m0.000s
$ g++ -O2 -o t1 t1.cpp; time ./t1
real 0m2.834s
user 0m2.828s
sys 0m0.000s
$ g++ -O1 -o t1 t1.cpp; time ./t1
real 0m2.796s
user 0m2.792s
sys 0m0.000s
$ g++ -O0 -o t1 t1.cpp; time ./t1
real 0m14.453s
user 0m14.444s
sys 0m0.000s
то есть имеем 7.7/1.5/0.5 тактов процессора на одну итерацию цикла в зависимости от уровня оптимизации.
Первые два более-менее соответствуют ожиданиям, а вот последний — несколько выходит за рамки теории.
Дальше надо разбираться .
ну вообще эти самые то ли 360, то ли 270млрд руб уже выделены. Если их не раздадут разработчикам микроэлектроники -- они просто уйдут в бюджет. Причём на данный момент озвучено всего 12 сквозных проектов. С ограничением по максимальной стоимости. То есть денег ещё есть на несколько проектов.
Так что если надо -- подавайте заявку. Я вот не очень понимаю почему не подают...
нелюбимое дитя.
на самом деле я был бы совсем не против развития микроархитектуры Эльбруса и по пути "ванильного VLIW". Собственно, даже у Бабаяна была большая программа развития микроархитектуры. То, что озвучивалось -- удвоение числа вычислительных кластеров.
надеюсь, это Вы про "Политику" пишете, а не про тематические разделы. Наша ветка в "процессорах" находится, н никого там от её названия не клинит.
Единственное что: к нам регулярно приходят неофиты и, искренне считая, что своим приходом несут светоч истины, вываливают в ветку стандартный набор мифов об Эльбрусе. Им конечно тяжело вначале приходится, но потом как-то приобтираются, если конечно у них было что-то в мозгах кроме этих мифов.
я действительно давно в комменты не заходил, и потому удивился как изменилось за это время мнение посетителей хабра на предмет отечественных процессоров. В частности -- как тут минусят этих самых мифоносителей, сразу и без дискуссий. Не, на ixbt таких инструментов бана просто нет, есть только чёрный список, так что в нашей ветке вполе себе уживаются все "сто цветов" мнений относительно Эльбруса.
я как раз не собирался обвинять Вас в ангажированности, и потому наоборот, изначально хотел отделить "современность" дискуссии "VLIW vs [RC]ISC" от её "своевременности". Про второе, естественно, согласен. Ибо в концепции "сквозных проектов" надо найти потребителей, которые будут готовы через 3 года купить разработанное на эти самые "крупные инвестиции". А Эльбрусы покупать никто не готов (тут выше писали о каком-то "главном заранее удовлетворённом заказчике", но это всё из области тех мифов, отсутствие которых -- это главное, что проимпонировало мне в Вашей статье). А из тех причин, по которым потребители не готовы покупать Эльбрусы, "уникальность архитектуры" конечно самая простая, понятная, и никак не устранимая за предлагаемые сроки и деньги. Но я надеялся, что статья не только об этом.
я наверное не очень внятно тут сформулировал: это я утверждал, что с технической точки зрения, ставка на ARM у Байкал Электроникс была правильной. Но, как бы то ни было, уверенно превзойти e2k по производительности Байкал-M удалось пока только в JS. Как это объяснить в рамках Вашего правильного тезиса? Вы же о производительности писали? Не о других свойствах Байкалов (в том числе и -T), которые позволяют легко обыгрывать Эльбрусы в тех немногочисленных тендерах, что удалось провести?
Вероятно, это я буду виноват. Но, поскольку я очень редко пишу комментарии в статьи на habr-e, а с Вами вообще в первый раз общаюсь, то пока не очень понимаю как мне формулировать свои мысли, чтобы Вы не обиделись. Потому сразу и пригласил Вас в наш междусобойчик, где все друг друга за 20 лет хорошо узнали. Там я стараюсь не обижать даже упёртых эльбрусофилов...
Вы считаете, что "сквозные проекты" имеют хоть один шанс не "просквозить как фанера над Парижем" в очередной раз? Ответьте пожалуйста, я перенесу Ваш ответ в нашу "вечную" ветку, и через 3-4 года мы узнаем были ли Вы правы или нет. Там за 20 лет уже много таких предсказаний накопилось...
да, это я пропустил --- упоминание действительно есть. Хотя с этим я бы как раз поспорил. Микроархитектура в том же Итаниум развивалась вполне себе в тренде, о чём Вам уже написали. Однако суть в том, что в e2k она не развивалась (даже не важно по каким именно причинам, например, там не только OoO нет, но даже аппаратного префетча), потому "Эльбрус это просто старые процессоры" --- это не совсем миф. IMHO конечно.
Основной тезис статьи, а именно
конечно правильная, но устаревшая лет на 20. Именно тогда и следовало бы выбирать "правильную" архитектуру на основе озвученных автором тезисов. Причём, как мы теперь знаем, названием этой "правильной" архитектуры -- это первые 3 буквы из имени автора. Но 20 лет назад OoO там не было. А когда появилась, то по этому пути пошёл Байкал, но тоже не особо преуспел, и это даже если не принимать во внимание судьбу Опанасенко.
В любом случае, обстоятельства сложились по-другому, и все последние четверть века МЦСТ "пилили" свою собственную e2k, прекрасно зная о её принципиальных недостатках (собственно, в статье так и написано). И по самым скромным оценкам на это уже потрачено несколько сотен миллионов долларов гос.финансирования. Кому именно автор теперь предлагает сказать сакраментальное: "Работа проделана большая, так дело не пойдёт" (с) ?
С другой стороны, вынесенный в название тезис "тупик для развития отечественной линейки general-purpose CPU" вообще с правильным тезисом мало связан, поскольку как минимум предполагает, что существует какой-то нетупиковый путь "развития отечественной линейки general-purpose CPU". Причём автор его знает. Очень интересно было бы чтобы он с нами поделился этим видением.
Иначе где вообще гарантия, что цели Yadro чем-то отличаются от целей МЦСТ, а возможности разработки (в том числе и квалификация разработчиков) успешно заменяется связями в правительстве.
Конечно можно рассмотреть и технические аспекты статьи. Например, автор конечно очень правильно разделил "архитектуру" и "микроархитектуру". И даже указал, что RISC/CISC победил благодаря развитию микроархитектуры. Но почему-то забыл даже упомянуть (а хотелост бы обсудить), что микроархитектура e2k со времён известной статьи в MPR претерпела лишь косметические изменения.
Короче, тут в комментариях мы вряд ли сумеем конструктивно продвинуться в данном вопросе "Тупик или не тупик?". Может, перейти в известную ветку на ixbt, в которой e2k уже более 20 лет обсуждается?
это Вы у своих голосов разузнайте. Потом поговорим, если ещё будет о чём. ;)
Да, Вспомнил, кого Вы мне живо напомнили: Глеба Капустина из рассказа Шукшина «Срезал»
1. Эксперт — это кто?
2. C ЛСД Вам надо завязывать — тогда глядишь и перестанет чудиться то, чего нет на самом деле.
>Что такое «ширина конвейера»? И почему её не хватает?
число портов запуска, я это уже писал
> Почему же эта ширина конвейера не учитывалась при:
Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
Компилируем то же на icc и
..B1.5: # Preds ..B1.4 ..B1.5
addl (%rsp,%rdx,4), %edi #13.3
movl %edx, (%rsp,%rdx,4) #14.3
incq %rdx #14.5
cmpq $64000, %rdx #11.21
jl ..B1.5 # Prob 99% #11.21
как говорится — найдите отличия ;)
ну и заодно — угадайте, сколько именно тактов работает такой цикл
>А я скажу почему — это всё просто пустой трёп
Знаете, в чём Ваше отличие от автора статьи — в отсутствии рефлексии. Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.
>Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт.
На самом деле, до того как Вы пришли — я этого не говорил.
Поскольку я последние три года занимался в основном оптимизацией для GPU. А там анролл циклов действительно нужен в подавляющем числе ситуаций (хотя конечно ни о каких ускорениях на порядки речи тоже нет).
Но если Вы настаиваете, то я таки сформулирую своё мнение на unroll:
Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.
это на пол-такта медленнее оценки.
>поймать результат лсд
какой результат?
>Отличная история… Вот ведь дураки пацаны— апаратный анроллер запилили
Такое впечатление, что Вы беседуете с голосами в своей голове.
Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
>поймали его ограничение
Кто поймал? Если Вы о 1.5 тактах вместо 1, то никаких сложных объяснений тут искать не надо. Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).
>стоит его зантроллить и он покажет максимальный трупут.
исключительно за счёт ликвидации накладных расходов на саму организацию цикла (сравнение и переход), которые для такого простого цикла на 4 содержательные операции — весьма велики.
Но в общем и целом, после появления в интеловских процессорвах кэша предекодированных uop-ов, раскрутку циклов надо делать очень осторожно — велика вероятность в него не вписаться, и в результате попасть на ограничения куда более узкого места — декодера.
>Могу только сказать — могут
Моя сентенция относилась к конкретному примеру, где было показано ускорение в 30 что ли раз за счёт раскрутки. В данном случае это было явно следствие ошибки, что уже давным-давно выяснили.
А насчет «могут или не могут» — я за время своей практики многое встречал.
Тем не менее — пример приветствуется.
>там никаких тактом и не пахнет
В реальности получается две итерации за 3 такта. ;)
Теперь применяем те же рассуждения к Эльбрусу.
получаем 2 итерации цикла за такт, откуда сразу же следуют два вывода, находящиеся в противоречии с Вашей статьей:
Хорошо.
Осталось понять чему именно соответствует результат 5мс (32 итерации за такт)?
Очевидно, сохранения 32 интов за такт одно ядро i7 сделать не сможет, даже при полной векторизации на AVX2.
Отсюда понимаем, что паттерн оптимизации «Пример 1. Развертывание циклов» соответствует замене приведённого кода каким-то другим, где не надо делать столько сохранений.
конкретно речь о строчке
a[kpp] = k; (тут я специально заменил k++ на kpp, чтобы не рассматривать лишнюю операцию сложения)
Суть:
в исходном коде эту операцию надо сделать 64000*10000=0.64*10^9 раз.
Утверждение: на одном ядре i7 это невозможно сделать за 5мс.
PS: «эффективное использование конвейера,… несколько АЛУ, усовершенствованный кэш, Out of Order Execution» — на это утверждение никак не влияют.
есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
В частности, только один для сохранения данных. Так что навскидку получается такт.
Сооветственно, как интерпретировать приведённые результаты?
вот берём «Пример 1. Развертывание циклов»
результат для i7: Время, мс 5-255.
Это что, 64000 итераций такого простого цикла много миллисекунд считаются? — как-то очень сомнительно.
Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию, т.е. ждём время исполнения этого кода существенно меньше одной миллисекунды (что не так-то просто и померить, кстати ;)).
Короче, взял Ваш код, обернул тестируемый цикл во внешний с числом итераций 100000 (дабы привести время к человеческим временам, а заодно и исключить краевые эффекты, типа непрогретого кэша), и прогнал на Intel® Core(TM) i5-4460 CPU @ 3.20GHz
real 0m0.973s
user 0m0.968s
sys 0m0.000s
$ g++ -O2 -o t1 t1.cpp; time ./t1
real 0m2.834s
user 0m2.828s
sys 0m0.000s
$ g++ -O1 -o t1 t1.cpp; time ./t1
real 0m2.796s
user 0m2.792s
sys 0m0.000s
$ g++ -O0 -o t1 t1.cpp; time ./t1
real 0m14.453s
user 0m14.444s
sys 0m0.000s
то есть имеем 7.7/1.5/0.5 тактов процессора на одну итерацию цикла в зависимости от уровня оптимизации.
Первые два более-менее соответствуют ожиданиям, а вот последний — несколько выходит за рамки теории.
Дальше надо разбираться .
.L6:
movl -16(%rbp), %eax
cltq
movl -256016(%rbp,%rax,4), %eax
addl %eax, -4(%rbp)
movl -16(%rbp), %eax
leal 1(%rax), %edx
movl %edx, -16(%rbp)
movl -16(%rbp), %edx
cltq
movl %edx, -256016(%rbp,%rax,4)
.L5:
cmpl $63999, -16(%rbp)
jle .L6
-O2, -O1:
[code]
.L4:
addl $1, %edx
addl (%rcx), %eax
addq $4, %rcx
movl %edx, -4(%rcx)
cmpl $64000, %edx
jne .L4
[/code]
-O3:
[code]
.L4:
movdqa %xmm0, %xmm2
paddd (%rdx), %xmm1
addq $16, %rdx
paddd %xmm3, %xmm0
paddd %xmm4, %xmm2
movaps %xmm2, -16(%rdx)
cmpq %rcx, %rdx
jne .L4
[/code]
Там довольно много интересното:
Короче вопрос: как именно Ваши результаты соотносятся с написанным мной?