Вообще, данная оптимизация похожа на идею «если str не изменился, то и tmp не изменится, значит. пересчитывать его оставшиеся 99 раз не надо». Но не понятно, почему эта оптимизация не работает на уровне целых функий.
Нашел самое слабое, что только было:
root@server:~# ./test
Method1: 0.003400, 0
Method2: 0.205300, 0
Method3: 0.245900, 0
Конфигурация — та же, что была в виртуалке на Pentium D, но AMD Sempron(tm) Processor 2800+, работающий на 1607.941 мгц.
Сдаётся мне, что дело всё-таки в gcc-4.5. Сделал objdump (предварительно обернув всё в extern «C»), на выходе — что-то совсем странное: pastebin.com/TMphA6cs
При этом вызывается — клон функции. Видимо, он как-то учёл, что строка состоит целиком из ашек. Увы, у меня сейчас нет возможности протестировать с более старым gcc. Можно попробовать включить volatile для основной строки, но это фактически будет равно варианту без оптимизации,
Если это действительно оказалось фичей компилятора, а не идейной, то прошу прощения за поднятый шум :-)
Кстати, больше ни одну функцию оптимизатор не стал оптимизировать «клонированием».
Это уже интересный результат — кинул Вам в ПМ ssh на сервер, где я только что получил обратный — 0.00-0.01user для моего варианта и 0.07-0.08user для Вашего.
Неоптмизированные в среднем там выполняются одинаковое время (0.58-0.62).
Но и так Вы уже подловили оптимизатор:
Method1: 0.298900, 1
Method2: 0.077400, 1
Method3: 0.117500, 1
Хотя, clone всё равно остался и вызывается.
Method1: 0.003300, 0
Method2: 0.233900, 0
Нашел самое слабое, что только было:
root@server:~# ./test
Method1: 0.003400, 0
Method2: 0.205300, 0
Method3: 0.245900, 0
Конфигурация — та же, что была в виртуалке на Pentium D, но AMD Sempron(tm) Processor 2800+, работающий на 1607.941 мгц.
Сдаётся мне, что дело всё-таки в gcc-4.5. Сделал objdump (предварительно обернув всё в extern «C»), на выходе — что-то совсем странное: pastebin.com/TMphA6cs
При этом вызывается — клон функции. Видимо, он как-то учёл, что строка состоит целиком из ашек. Увы, у меня сейчас нет возможности протестировать с более старым gcc. Можно попробовать включить volatile для основной строки, но это фактически будет равно варианту без оптимизации,
Если это действительно оказалось фичей компилятора, а не идейной, то прошу прощения за поднятый шум :-)
Кстати, больше ни одну функцию оптимизатор не стал оптимизировать «клонированием».
gcc-4.5.1, slackware64-current, core i5 m520:
C -O3
borisko@vaio:~/test-num$ ./test2
Method1: 0.003000, 0
Method2: 0.079900, 0
Method3: 0.116000, 0
C -O0
Method1: 0.730300, 0
Method2: 0.323600, 0
Method3: 0.284900, 0
gcc-4.5.1, slackware-current, в qemu-kvm виртуалке, Pentium D E5500:
С -O3
root@server:~/test0# ./test
Method1: 0.002400, 0
Method2: 0.090500, 0
Method3: 0.112700, 0
C -O0
Method1: 0.340100, 0
Method2: 0.305500, 0
Method3: 0.280500, 0
Видимо, всё зависит не только от сути, но и от конкретных особенностей оптимизатора компилятора.
Совсем не понятно, что случилось с первым методом без оптимизации на 64битном процессоре.
Неоптмизированные в среднем там выполняются одинаковое время (0.58-0.62).
Можете рассказать Вашу версию gcc и архитектуру?
borisko@vaio:~/test-num$ cat test.cpp
borisko@vaio:~/test-num$ g++ -o test_your -O3 test.cpp
borisko@vaio:~/test-num$ g++ -o test_my -O3 -DMY_METHOD test.cpp
borisko@vaio:~/test-num$ time ./test_your
real 0m0.129s
user 0m0.083s
sys 0m0.045s
borisko@vaio:~/test-num$ time ./test_my
real 0m0.054s
user 0m0.012s
sys 0m0.040s
Зато, мой вариант работает быстрее Вашего больше, чем в 8 раз.
P.S. о_О Ваш первый комментарий за последние почти 4 года.
P.S. о_О Ваш первый комментарий за последние почти 4 года.