Size: a a a

2020 December 01

m

magras in pro.cxx
хм. А я правильно понимаю, что gcc/clang либо еще не реализовали пропосал с signed modulo arithmetic или это баг?
https://godbolt.org/z/TWeK9G

Потому что согласно моим представлениям такая оптимизация противоречит С++20.
источник

m

magras in pro.cxx
cppref утверждает что реализовано в gcc 9 и clang 9.
источник

m

magras in pro.cxx
Кажется приняли альтернативную формулировку где переполнение signed все еще UB.
источник

m

magras in pro.cxx
Да, вот цитата из стандарта: https://eel.is/c++draft/basic.fundamental#2
источник

AT

Alexander Tulikov in pro.cxx
magras
хм. А я правильно понимаю, что gcc/clang либо еще не реализовали пропосал с signed modulo arithmetic или это баг?
https://godbolt.org/z/TWeK9G

Потому что согласно моим представлениям такая оптимизация противоречит С++20.
А такой был? Зафиксировали представление знаковых в дополнительном коде, а для него нельзя без накладных расходов реализовать арифметику по модулю, что не согласуется с тем, что не платишь за то, чем не пользуешься.
источник

m

magras in pro.cxx
Alexander Tulikov
А такой был? Зафиксировали представление знаковых в дополнительном коде, а для него нельзя без накладных расходов реализовать арифметику по модулю, что не согласуется с тем, что не платишь за то, чем не пользуешься.
Так если используется two's complement арифметика модульная арифметика является естественным результатом. Собственно в процессоре нет отдельных команд для знакового и беззнакового сложения. Разница есть только в интерпретации результата. Накладные расходы могут возникнуть только из-за того, что компилятор использовал UB для оптимизации как в примере выше.

Вот кусочек из пропосала:

> The main change between [P0907r0] and the subsequent revision is to maintain undefined behavior when signed integer overflow occurs, instead of defining wrapping behavior. This direction was motivated by:
> * Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs;
> * Implementation leeway for tools such as sanitizers;
> * Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug.
источник

p

paperbot_cpp in pro.cxx
magras
Так если используется two's complement арифметика модульная арифметика является естественным результатом. Собственно в процессоре нет отдельных команд для знакового и беззнакового сложения. Разница есть только в интерпретации результата. Накладные расходы могут возникнуть только из-за того, что компилятор использовал UB для оптимизации как в примере выше.

Вот кусочек из пропосала:

> The main change between [P0907r0] and the subsequent revision is to maintain undefined behavior when signed integer overflow occurs, instead of defining wrapping behavior. This direction was motivated by:
> * Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs;
> * Implementation leeway for tools such as sanitizers;
> * Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug.
источник

AT

Alexander Tulikov in pro.cxx
magras
Так если используется two's complement арифметика модульная арифметика является естественным результатом. Собственно в процессоре нет отдельных команд для знакового и беззнакового сложения. Разница есть только в интерпретации результата. Накладные расходы могут возникнуть только из-за того, что компилятор использовал UB для оптимизации как в примере выше.

Вот кусочек из пропосала:

> The main change between [P0907r0] and the subsequent revision is to maintain undefined behavior when signed integer overflow occurs, instead of defining wrapping behavior. This direction was motivated by:
> * Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs;
> * Implementation leeway for tools such as sanitizers;
> * Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug.
Да, туплю, посмотрел предложение, там под накладными расходами подразумевается, что на UB при переполнении уже слишком много завязано и нет смысла от него уходить.
источник

V

Vladimir in pro.cxx
Ofee
Кажется, что никак. Либо работать с шаблоном непосредственно внутри тела Extractor, либо, как вариант — завести шаблон алиаса на интересующий вас шаблон. Но других способов манипулировать шаблонами или передавать их куда-то я не знаю, кажется
Спасибо, почему же никак. Как раз ваш вариант с шаблоном алиаса делает то что нужно.
источник
2020 December 02

VS

Vlad Serebrennikov in pro.cxx
magras
Так если используется two's complement арифметика модульная арифметика является естественным результатом. Собственно в процессоре нет отдельных команд для знакового и беззнакового сложения. Разница есть только в интерпретации результата. Накладные расходы могут возникнуть только из-за того, что компилятор использовал UB для оптимизации как в примере выше.

Вот кусочек из пропосала:

> The main change between [P0907r0] and the subsequent revision is to maintain undefined behavior when signed integer overflow occurs, instead of defining wrapping behavior. This direction was motivated by:
> * Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs;
> * Implementation leeway for tools such as sanitizers;
> * Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug.
честно говоря, я не знаток того, как арифметика реализована в процессоре, но есть доклад с cppcon'а, где хорошо показано, что гарантии при переполнении беззнаковых типов заставляют компилятор генерировать менее оптимальный машинный код

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

CD

Constantine Drozdov in pro.cxx
Vlad Serebrennikov
честно говоря, я не знаток того, как арифметика реализована в процессоре, но есть доклад с cppcon'а, где хорошо показано, что гарантии при переполнении беззнаковых типов заставляют компилятор генерировать менее оптимальный машинный код

насколько я понял из доклада автора этого предложения, основной целью было запретить все остальные представления (дополнение до единицы и знаковый бит) как морально устаревшие. (смотрел давно и могу ошибаться)
ну... использовали uint32 в качестве size_t, получили результат
источник

VS

Vlad Serebrennikov in pro.cxx
Constantine Drozdov
ну... использовали uint32 в качестве size_t, получили результат
так это же в самый раз для 32-битного кода
источник

CD

Constantine Drozdov in pro.cxx
Vlad Serebrennikov
так это же в самый раз для 32-битного кода
это 64-битный код, и вся суть именно в том, что компилятор int32 положил в uint64 регистр
источник

VS

Vlad Serebrennikov in pro.cxx
а, тогда пересматривать надо, но сейчас лучше спать пойти
источник

m

magras in pro.cxx
Constantine Drozdov
это 64-битный код, и вся суть именно в том, что компилятор int32 положил в uint64 регистр
Это не совсем правда: пишут в %eax и %ebp. Но с изначальным утверждением что корень проблемы в использовании u32 в вычислении где результат u64, я согласен.
источник

m

magras in pro.cxx
Забавно что я буквально вчера встретился с подобной проблемой в своем микробенчмарке: из-за того что одна из переменных в выражении имела большую разрядность, в асме появлялись лишние инструкции для конвертации, которые искажали результат.
источник

CD

Constantine Drozdov in pro.cxx
magras
Это не совсем правда: пишут в %eax и %ebp. Но с изначальным утверждением что корень проблемы в использовании u32 в вычислении где результат u64, я согласен.
вроде в i32 для чтения данных rdx:rsi/rdx:rdi пара используется, нет?
источник

m

magras in pro.cxx
Constantine Drozdov
вроде в i32 для чтения данных rdx:rsi/rdx:rdi пара используется, нет?
Это уже при индексировании. В начале значения индекса помещают в eax и ebp. Это обнуляет верхние 32 бита и дальше при индексировании используются rax/rbp.
источник

m

magras in pro.cxx
edi, esi - это вообще аргументы функции.

upd: скорее всего*
источник

ИС

Иван Срайчук... in pro.cxx
Constantine Drozdov
вроде в i32 для чтения данных rdx:rsi/rdx:rdi пара используется, нет?
это для 64 битных,
 register d extended
источник