Тайна лишнего CMP или зачем Володька сбрил усы?

[dmbreaker]

Можно плюсовать уже только за суровую модификацию кода прямо в памяти :)

[kostik450]

Эту технику я почерпнул из своей предыдущей статьи — как ни странно на x64 это тоже работает на ура.

[DustCn]

Это тест ради теста или у него есть какое-то прикладное применение?
Оптимизирование скалярной функции в отрыве от «места применения» само по себе странное занятие, если вы только не пишете какую-то матбиблиотеку.

[kostik450]

Это точно, матбиблиотека уже написана, но вот какой компилятор взять, чтобы работало быстро — вот в чем вопрос. Раньше (лет 10 назад) это никого не волновало, можно и нужно было писать на голом асме и это работало всегда быстро. Сейчас же на асме писать бесполезно, компилятор все-равно сделает лучше. Я хотел было использовать компилятор от Intel, но оказывается и MS тоже весьма неплох. Осталось еще пощупать gcc (он же mingw) и clang.

[mejedi]

Если очень нужно то можно и на ассемблере критичные функции реализовать, как например в OpenSSL сделано.

[kostik450]

А когда новые процы появятся — какие-нибудь Indy Bridge — опять всё переписывать?

[mejedi]

Если появилась новая инструкция которая значительно ускоряет ваш алгоритм — пишите еще один вариант кода. В противном случае не надо заморачиваеться.

Речь же не идет о том, чтобы писать «обычный» код лучше компилятора; речь идет о доступе к вычислительным возможностям, к которым сложно доступиться конвенциональными средствами.

[DustCn]

Ассемблер как меч джедая — лучше держать в запасе… Код становится непортируемым…

[readmaxym]

предлагаю еще раз подумать что делает связка

...
cmp	 rdx, QWORD PTR [rdi+24]
...
adc	 rdx, 0

если есть код

+ (c[0] < a[0])

[kostik450]

В том-то и дело, что вместо

    c[0] = a[0] + b[0];
    c[1] = a[1] + b[1] + (c[0] < a[0]);

Хотелось бы иметь

    Carry = _add_with_carry(&c[0], a[0],  b[0]);
    c[1] = a[1] + b[1] + Carry;

И тогда cmp вообще нигде не фигурирует.

[readmaxym]

цель понятна,

а дальше мешаються кони, люди, разрядности…

причем без указания реальной причины,
смотрим стандарты:

Section 6.2.5, para. 9, and the C standard [ISO/IEC 9899:2011], states:
    A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

www.securecoding.cert.org/confluence/display/seccode/INT30-C.+Ensure+that+unsigned+integer+operations+do+not+wrap

и по signed:
www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow?showComments=false

Пока не прийдут изменения стандарта — явная поддержка Carry в C/C++ будет (если будет) уникальна для каждого компилятора, поэтому они, разраб. компиляторов и не особо стремятся

В итоге: как реальная работа и в срезе одного компилятора, одного test case — отлично.

до установления первопричины не был сделан последний шаг, один шаг.