Сообщение Очередной "шедевр" от MS от 11.03.2017 7:47
Изменено 11.03.2017 8:45 alex_public
Очередной "шедевр" от MS
Краткая предыстория. Изначально было такое http://rsdn.org/forum/cpp/6721686.1
И так, я взял тесты предложенные моим собеседником в изначальной теме. Они конечно довольно сомнительные, но почему бы не проверить и на них (ведь хороший продукт должен качественно оптимизировать любой код). Только я их слегка переписал, чтобы ими можно было адекватно пользоваться (GUI в тестах???) и чтобы не было совсем стыдно за код. Но ключевая часть осталась неизменной (как я наивно думал):
Так вот запустив этот код (правда тогда в нём не было закомментированной строки) я получил такой замечательный результат:
Не, я конечно и делал этот тест для демонстрации преимущества gcc, но разница более чем в 100 раз показалась всё же каким-то перебором. Тем более, что мой собеседник демонстрировал совсем других цифры. Тут была явно какая-то ошибка. Но я не мог подумать на компилятор и начал искать у себя — перебирал разные опции компилятора, варианты подключения библиотек и т.п. Но ничего не помогало. Я уже даже начал думать о магическом влияние Qt и т.п. невероятных вещах, когда мне в голову пришла совершенно наркоманская мысль: у моего собеседника в теле цикла было уведомление GUI о прогрессе прохождения теста (которое я естественно выкинул при переписывание) — поставлю ка и я нечто подобное (закомментированная строка в коде выше, причём самое забавное, что cout там никогда не выполняется). И что вы думаете? Оно заработало нормально:
Эти результаты меня уже ничем не удивили — всё как я и предполагал, gcc быстрее, но на небольшие проценты.
Но на фоне открывшейся чудесной "особенности" компилятора от MS данные проценты производительности уже перестают иметь какое-либо значение. На мой взгляд компилятор способный по не объяснимым причинам замедлить исполнение куска кода более чем в 100 раз вообще не может быть пригоден к использованию.
P.S. Возможно это уже общеизвестная тут информация, а это только я не знал про данную "особенность". Просто я уже давно не пользуюсь продуктом от MS и поэтому был не в курсе, а сейчас столкнулся и решил поделиться.
P.P.S. В тесте использовались компиляторы: MinGW4.9.2/MingGW6.3.0 (между ними нет разницы на данных тестах) и "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506".
Автор: AlexGin
Дата: 10.03.17
забавное сообщение, на которое я собирался ответить прямо там в темке, отметив что не стоит браться за тесты производительности тем, кто не может выставить правильные опции компиляторам, а пользуется только дефолтными (а они очень разные у разных компиляторов). Однако перед написанием ответа я решил всё же установить компилятор от MS, чтобы удостовериться, что за прошедшее время ничего не изменилось и он по прежнему слабенький, как я и говорил. Но в процессе этого теста вылезло ТАКОЕ, что я сразу же забыл об изначальной дискуссии и решил написать отдельное сообщение про это.Дата: 10.03.17
И так, я взял тесты предложенные моим собеседником в изначальной теме. Они конечно довольно сомнительные, но почему бы не проверить и на них (ведь хороший продукт должен качественно оптимизировать любой код). Только я их слегка переписал, чтобы ими можно было адекватно пользоваться (GUI в тестах???) и чтобы не было совсем стыдно за код. Но ключевая часть осталась неизменной (как я наивно думал):
код теста | |
| |
Так вот запустив этот код (правда тогда в нём не было закомментированной строки) я получил такой замечательный результат:
результат1 | |
| |
Не, я конечно и делал этот тест для демонстрации преимущества gcc, но разница более чем в 100 раз показалась всё же каким-то перебором. Тем более, что мой собеседник демонстрировал совсем других цифры. Тут была явно какая-то ошибка. Но я не мог подумать на компилятор и начал искать у себя — перебирал разные опции компилятора, варианты подключения библиотек и т.п. Но ничего не помогало. Я уже даже начал думать о магическом влияние Qt и т.п. невероятных вещах, когда мне в голову пришла совершенно наркоманская мысль: у моего собеседника в теле цикла было уведомление GUI о прогрессе прохождения теста (которое я естественно выкинул при переписывание) — поставлю ка и я нечто подобное (закомментированная строка в коде выше, причём самое забавное, что cout там никогда не выполняется). И что вы думаете? Оно заработало нормально:
результат2 | |
| |
Эти результаты меня уже ничем не удивили — всё как я и предполагал, gcc быстрее, но на небольшие проценты.
Но на фоне открывшейся чудесной "особенности" компилятора от MS данные проценты производительности уже перестают иметь какое-либо значение. На мой взгляд компилятор способный по не объяснимым причинам замедлить исполнение куска кода более чем в 100 раз вообще не может быть пригоден к использованию.
P.S. Возможно это уже общеизвестная тут информация, а это только я не знал про данную "особенность". Просто я уже давно не пользуюсь продуктом от MS и поэтому был не в курсе, а сейчас столкнулся и решил поделиться.
P.P.S. В тесте использовались компиляторы: MinGW4.9.2/MingGW6.3.0 (между ними нет разницы на данных тестах) и "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506".
Очередной "шедевр" от MS
Краткая предыстория. Изначально было такое http://rsdn.org/forum/cpp/6721686.1
И так, я взял тесты предложенные моим собеседником в изначальной теме. Они конечно довольно сомнительные, но почему бы не проверить и на них (ведь хороший продукт должен качественно оптимизировать любой код). Только я их слегка переписал, чтобы ими можно было адекватно пользоваться (GUI в тестах???) и чтобы не было совсем стыдно за код. Но ключевая часть осталась неизменной (как я наивно думал):
Так вот запустив этот код (правда тогда в нём не было закомментированной строки) я получил такой замечательный результат:
Не, я конечно и делал этот тест для демонстрации преимущества gcc, но разница более чем в 100 раз показалась всё же каким-то перебором. Тем более, что мой собеседник демонстрировал совсем других цифры. Тут была явно какая-то ошибка. Но я не мог подумать на компилятор и начал искать у себя — перебирал разные опции компилятора, варианты подключения библиотек и т.п. Но ничего не помогало. Я уже даже начал думать о магическом влияние Qt и т.п. невероятных вещах, когда мне в голову пришла совершенно наркоманская мысль: у моего собеседника в теле цикла было уведомление GUI о прогрессе прохождения теста (которое я естественно выкинул при переписывание) — поставлю ка и я нечто подобное (закомментированная строка в коде выше, причём самое забавное, что cout там никогда не выполняется). И что вы думаете? Оно заработало нормально:
Эти результаты меня уже ничем не удивили — всё как я и предполагал, gcc быстрее, но на небольшие проценты.
Но на фоне открывшейся чудесной "особенности" компилятора от MS данные проценты производительности уже перестают иметь какое-либо значение. На мой взгляд компилятор способный по не объяснимым причинам замедлить исполнение куска кода более чем в 100 раз вообще не может быть пригоден к использованию.
P.S. Возможно это уже общеизвестная тут информация, а это только я не знал про данную "особенность". Просто я уже давно не пользуюсь продуктом от MS и поэтому был не в курсе, а сейчас столкнулся и решил поделиться.
P.P.S. В тесте использовались компиляторы: MinGW4.9.2/MingGW6.3.0 (между ними нет разницы на данных тестах) и "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506".
Автор: AlexGin
Дата: 10.03.17
забавное сообщение, на которое я собирался ответить прямо там в темке, отметив что не стоит браться за тесты производительности тем, кто не может выставить правильные опции компиляторам, а пользуется только дефолтными (а они очень разные у разных компиляторов). Однако перед написанием ответа я решил всё же установить компилятор от MS, чтобы удостовериться, что за прошедшее время ничего не изменилось и он по прежнему слабенький, как я и говорил. Но в процессе этого теста вылезло ТАКОЕ, что я сразу же забыл об изначальной дискуссии и решил написать отдельное сообщение про это.Дата: 10.03.17
И так, я взял тесты предложенные моим собеседником в изначальной теме. Они конечно довольно сомнительные, но почему бы не проверить и на них (ведь хороший продукт должен качественно оптимизировать любой код). Только я их слегка переписал, чтобы ими можно было адекватно пользоваться (GUI в тестах???) и чтобы не было совсем стыдно за код. Но ключевая часть осталась неизменной (как я наивно думал):
код теста | |
| |
Так вот запустив этот код (правда тогда в нём не было закомментированной строки) я получил такой замечательный результат:
результат1 | |
| |
Не, я конечно и делал этот тест для демонстрации преимущества gcc, но разница более чем в 100 раз показалась всё же каким-то перебором. Тем более, что мой собеседник демонстрировал совсем других цифры. Тут была явно какая-то ошибка. Но я не мог подумать на компилятор и начал искать у себя — перебирал разные опции компилятора, варианты подключения библиотек и т.п. Но ничего не помогало. Я уже даже начал думать о магическом влияние Qt и т.п. невероятных вещах, когда мне в голову пришла совершенно наркоманская мысль: у моего собеседника в теле цикла было уведомление GUI о прогрессе прохождения теста (которое я естественно выкинул при переписывание) — поставлю ка и я нечто подобное (закомментированная строка в коде выше, причём самое забавное, что cout там никогда не выполняется). И что вы думаете? Оно заработало нормально:
результат2 | |
| |
Эти результаты меня уже ничем не удивили — всё как я и предполагал, gcc быстрее, но на небольшие проценты.
Но на фоне открывшейся чудесной "особенности" компилятора от MS данные проценты производительности уже перестают иметь какое-либо значение. На мой взгляд компилятор способный по не объяснимым причинам замедлить исполнение куска кода более чем в 100 раз вообще не может быть пригоден к использованию.
P.S. Возможно это уже общеизвестная тут информация, а это только я не знал про данную "особенность". Просто я уже давно не пользуюсь продуктом от MS и поэтому был не в курсе, а сейчас столкнулся и решил поделиться.
P.P.S. В тесте использовались компиляторы: MinGW4.9.2/MingGW6.3.0 (между ними нет разницы на данных тестах) и "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506".