Сообщение Re[6]: Откуда эта лютая любовь к знаковым целым? от 14.05.2020 5:12
Изменено 14.05.2020 5:27 netch80
Re[6]: Откуда эта лютая любовь к знаковым целым?
Здравствуйте, Alexander G, Вы писали:
AG>>>Обычное деление достаточно больших чисел int64_t / uint64_t, компиляция MSVC x64, беззнаковые ощутимо быстрее. Нужно воспроизвести?
N>>Это уже речь про деление, а перед этим было про умножение
N>>Вообще, если настроение, киньте код, я сверю в своих условиях.
AG> // чтобы не выоптимизировались; компиляторы пока ещё не научились оптимизировать атомики
Ошибаетесь: clang (>=6) научился
пришлось заменить везде тут на `volatile int`.
AG> std::cout << Benchmark<std::uint64_t>{}.Run().count() << "ms unsinged\n";
AG> std::cout << Benchmark<std::int64_t>{}.Run().count() << "ms singed\n";
Проверил.
Intel i3-4170 — ~12% добавки (тут и дальше — на знаковых).
Intel i3-8145U — ~12 добавки.
Intel Xeon E5345: ~25% добавки.
AMD Athlon(tm) 64 Processor 3500+: ~8% добавки.
AMD Ryzen 5 2400G: разницы нет.
Подходящего ARM под рукой нет. Если есть — проверьте там
Ну что тут сказать... почему-то у Intel такая специфика: они всегда хуже делают арифметику, а деление у них вообще в загоне. Правильные методы работы с денормализованными (которые не тратят до 200 тактов на операцию) AMD начал внедрять на несколько лет раньше — пока Intel отделывался флажками типа "плевать на них, все меняем на ноль". Деление плавучих по Голдсмиту — тоже раньше (пока Intel сохранял SRT, знаменитый по FDIV bug). Может, для своих целей оно им и правильно...
AG>>>Обычное деление достаточно больших чисел int64_t / uint64_t, компиляция MSVC x64, беззнаковые ощутимо быстрее. Нужно воспроизвести?
N>>Это уже речь про деление, а перед этим было про умножение
N>>Вообще, если настроение, киньте код, я сверю в своих условиях.
AG> // чтобы не выоптимизировались; компиляторы пока ещё не научились оптимизировать атомики
Ошибаетесь: clang (>=6) научился
пришлось заменить везде тут на `volatile int`.
AG> std::cout << Benchmark<std::uint64_t>{}.Run().count() << "ms unsinged\n";
AG> std::cout << Benchmark<std::int64_t>{}.Run().count() << "ms singed\n";
Проверил.
Intel i3-4170 — ~12% добавки (тут и дальше — на знаковых).
Intel i3-8145U — ~12 добавки.
Intel Xeon E5345: ~25% добавки.
AMD Athlon(tm) 64 Processor 3500+: ~8% добавки.
AMD Ryzen 5 2400G: разницы нет.
Подходящего ARM под рукой нет. Если есть — проверьте там
Ну что тут сказать... почему-то у Intel такая специфика: они всегда хуже делают арифметику, а деление у них вообще в загоне. Правильные методы работы с денормализованными (которые не тратят до 200 тактов на операцию) AMD начал внедрять на несколько лет раньше — пока Intel отделывался флажками типа "плевать на них, все меняем на ноль". Деление плавучих по Голдсмиту — тоже раньше (пока Intel сохранял SRT, знаменитый по FDIV bug). Может, для своих целей оно им и правильно...
Re[6]: Откуда эта лютая любовь к знаковым целым?
Здравствуйте, Alexander G, Вы писали:
AG>>>Обычное деление достаточно больших чисел int64_t / uint64_t, компиляция MSVC x64, беззнаковые ощутимо быстрее. Нужно воспроизвести?
N>>Это уже речь про деление, а перед этим было про умножение
N>>Вообще, если настроение, киньте код, я сверю в своих условиях.
AG> // чтобы не выоптимизировались; компиляторы пока ещё не научились оптимизировать атомики
Ошибаетесь: clang (>=6) научился
пришлось заменить везде тут на `volatile int`.
AG> std::cout << Benchmark<std::uint64_t>{}.Run().count() << "ms unsinged\n";
AG> std::cout << Benchmark<std::int64_t>{}.Run().count() << "ms singed\n";
Проверил. Я дополнительно подновил на возможность замены делителя, сравнил без умножения и менял делимое, везде одинаково:
Intel i3-4170 — ~12% добавки (тут и дальше — на знаковых).
Intel i3-8145U — ~12% добавки.
Intel Xeon E5345: ~25% добавки.
Intel i5-1035G1: разницы нет.
AMD Athlon(tm) 64 Processor 3500+: ~8% добавки.
AMD Ryzen 5 2400G: разницы нет.
Подходящего ARM под рукой нет. Если есть — проверьте там
Ну что тут сказать... почему-то у Intel очень долго была такая специфика: они всегда хуже делали арифметику, а деление у них вообще в загоне. Правильные методы работы с денормализованными (которые не тратят до 200 тактов на операцию) AMD начал внедрять на несколько лет раньше — пока Intel отделывался флажками типа "плевать на них, все меняем на ноль". Деление плавучих по Голдсмиту — тоже раньше (пока Intel сохранял SRT, знаменитый по FDIV bug). Может, для своих целей оно им и правильно... Но то, что на 10-м поколении Core разница ушла — показывает, что и они умеют учиться.
AG>>>Обычное деление достаточно больших чисел int64_t / uint64_t, компиляция MSVC x64, беззнаковые ощутимо быстрее. Нужно воспроизвести?
N>>Это уже речь про деление, а перед этим было про умножение
N>>Вообще, если настроение, киньте код, я сверю в своих условиях.
AG> // чтобы не выоптимизировались; компиляторы пока ещё не научились оптимизировать атомики
Ошибаетесь: clang (>=6) научился
пришлось заменить везде тут на `volatile int`.
AG> std::cout << Benchmark<std::uint64_t>{}.Run().count() << "ms unsinged\n";
AG> std::cout << Benchmark<std::int64_t>{}.Run().count() << "ms singed\n";
Проверил. Я дополнительно подновил на возможность замены делителя, сравнил без умножения и менял делимое, везде одинаково:
Intel i3-4170 — ~12% добавки (тут и дальше — на знаковых).
Intel i3-8145U — ~12% добавки.
Intel Xeon E5345: ~25% добавки.
Intel i5-1035G1: разницы нет.
AMD Athlon(tm) 64 Processor 3500+: ~8% добавки.
AMD Ryzen 5 2400G: разницы нет.
Подходящего ARM под рукой нет. Если есть — проверьте там
Ну что тут сказать... почему-то у Intel очень долго была такая специфика: они всегда хуже делали арифметику, а деление у них вообще в загоне. Правильные методы работы с денормализованными (которые не тратят до 200 тактов на операцию) AMD начал внедрять на несколько лет раньше — пока Intel отделывался флажками типа "плевать на них, все меняем на ноль". Деление плавучих по Голдсмиту — тоже раньше (пока Intel сохранял SRT, знаменитый по FDIV bug). Может, для своих целей оно им и правильно... Но то, что на 10-м поколении Core разница ушла — показывает, что и они умеют учиться.