Сообщение Re[3]: Очередной "шедевр" от MS от 11.03.2017 22:27
Изменено 11.03.2017 23:14 AlexGin
Re[3]: Очередной "шедевр" от MS
Здравствуйте, alex_public, Вы писали:
_>Т.е. ты считаешь, что описанное поведение — это не ошибка компилятора, а нормальная ситуация? )))
Ситуация предсказуемая — тяжелые вычисления или выноси в отдельный рабочий поток, или прокачивай сообщения ОС.
Иначе — терпи тормоза
К багам компилятора — это отношения не имеет (от слова совсем).
AG>Можно по-разному относиться к маркетингу/политике "мелкомягких", их модели продаж и т.д.
AG>Но в тоже время, следует отдать должное — их продукты очень даже достойные.
_>Если говорить про продукцию для C++, то они были безусловным лидером в данной области целое десятилетие (начиная с середины 90-ых), а потом проспали следующее десятилетие, сделав на .net. Сейчас вроде снова стараются — посмотрим что выйдет в будущем. Но судя по подобным косякам работать там надо ещё очень много.
Тренд на современный C++ (С++11 и C++14) у "мелкомягких" развивается уже примерно 5 лет (с 2012 студии).
А то что ты здесь именуешь "косяками" — просто говорит о твоём малом опыте работы с GUI подсистемой.
Скажем так — прокачка сообщений — это НЕ костыль, а особенность программирования подобных систем.
Здесь рассматривать многопоточность (вынос в рабочий поток) стоит, но только для несколько иных случаев.
Для такого простого случая, тем боле НЕ в Production — ИМХО можно и через прокачку.
_>Даже если забыть про данный косяк... Ты разве не посмотрел на результаты измерений в моём первом сообщение данной темы?
Смотрел и код и результаты:
a) Меня радует, что эти мои старые тесты кого-то заинтересовали.
b) В то же время, меня беспокоит, что "причёсывание" этих тестов вполне может повлиять на результаты.
_>Даже в исправленном состояние msvc уступает gcc на данных тестах. Да, там цифры порядка 10%, а не в разы, но тем не менее в пользу gcc. Просто надо было выставить в тесте правильные опции для него, а не использовать дефолтные (которые делают не полную оптимизацию и ориентируются на процессоры типа Пентиумов), как судя по цифрам сделал ты.
Я НЕ выставлял специально никаких опций — это делает Qt Vs Addin и его настройки.
В данном случае я полагался именно на продукт Qt.
Насчёт того, что играя опциями можно ускорить (даже тот же msvc результат) — идея ценная, хорошая.
_>Кстати, самое забавное, что ты даже и для msvc полноценную оптимизацию использовать не можешь. Потому как судя по цифрам у тебя процессор минимум с avx, а то и с avx2...
+100500
Вполне возможно — это правильный вариант! Спасибо!
_>Т.е. ты считаешь, что описанное поведение — это не ошибка компилятора, а нормальная ситуация? )))
Ситуация предсказуемая — тяжелые вычисления или выноси в отдельный рабочий поток, или прокачивай сообщения ОС.
Иначе — терпи тормоза
К багам компилятора — это отношения не имеет (от слова совсем).
AG>Можно по-разному относиться к маркетингу/политике "мелкомягких", их модели продаж и т.д.
AG>Но в тоже время, следует отдать должное — их продукты очень даже достойные.
_>Если говорить про продукцию для C++, то они были безусловным лидером в данной области целое десятилетие (начиная с середины 90-ых), а потом проспали следующее десятилетие, сделав на .net. Сейчас вроде снова стараются — посмотрим что выйдет в будущем. Но судя по подобным косякам работать там надо ещё очень много.
Тренд на современный C++ (С++11 и C++14) у "мелкомягких" развивается уже примерно 5 лет (с 2012 студии).
А то что ты здесь именуешь "косяками" — просто говорит о твоём малом опыте работы с GUI подсистемой.
Скажем так — прокачка сообщений — это НЕ костыль, а особенность программирования подобных систем.
Здесь рассматривать многопоточность (вынос в рабочий поток) стоит, но только для несколько иных случаев.
Для такого простого случая, тем боле НЕ в Production — ИМХО можно и через прокачку.
_>Даже если забыть про данный косяк... Ты разве не посмотрел на результаты измерений в моём первом сообщение данной темы?
Смотрел и код и результаты:
a) Меня радует, что эти мои старые тесты кого-то заинтересовали.
b) В то же время, меня беспокоит, что "причёсывание" этих тестов вполне может повлиять на результаты.
_>Даже в исправленном состояние msvc уступает gcc на данных тестах. Да, там цифры порядка 10%, а не в разы, но тем не менее в пользу gcc. Просто надо было выставить в тесте правильные опции для него, а не использовать дефолтные (которые делают не полную оптимизацию и ориентируются на процессоры типа Пентиумов), как судя по цифрам сделал ты.
Я НЕ выставлял специально никаких опций — это делает Qt Vs Addin и его настройки.
В данном случае я полагался именно на продукт Qt.
Насчёт того, что играя опциями можно ускорить (даже тот же msvc результат) — идея ценная, хорошая.
_>Кстати, самое забавное, что ты даже и для msvc полноценную оптимизацию использовать не можешь. Потому как судя по цифрам у тебя процессор минимум с avx, а то и с avx2...
+100500
Вполне возможно — это правильный вариант! Спасибо!
Re[3]: Очередной "шедевр" от MS
Здравствуйте, alex_public, Вы писали:
_>Т.е. ты считаешь, что описанное поведение — это не ошибка компилятора, а нормальная ситуация? )))
Ситуация предсказуемая — тяжелые вычисления или выноси в отдельный рабочий поток, или прокачивай сообщения ОС.
Иначе — терпи тормоза
К багам компилятора — это отношения не имеет (от слова совсем).
AG>Можно по-разному относиться к маркетингу/политике "мелкомягких", их модели продаж и т.д.
AG>Но в тоже время, следует отдать должное — их продукты очень даже достойные.
_>Если говорить про продукцию для C++, то они были безусловным лидером в данной области целое десятилетие (начиная с середины 90-ых), а потом проспали следующее десятилетие, сделав на .net. Сейчас вроде снова стараются — посмотрим что выйдет в будущем. Но судя по подобным косякам работать там надо ещё очень много.
Тренд на современный C++ (С++11 и C++14) у "мелкомягких" развивается уже примерно 5 лет (с 2012 студии).
А то что ты здесь именуешь "косяками" — просто говорит о твоём малом опыте работы с GUI подсистемой.
Скажем так — прокачка сообщений — это НЕ костыль, а особенность программирования подобных систем.
Здесь рассматривать многопоточность (вынос в рабочий поток) стоит, но только для несколько иных случаев.
Для такого простого случая, тем боле НЕ в Production — ИМХО можно и через прокачку.
_>Даже если забыть про данный косяк... Ты разве не посмотрел на результаты измерений в моём первом сообщение данной темы?
Смотрел и и результаты:
a) Меня радует, что эти мои старые тесты кого-то заинтересовали. Также радует, что код доработан в современном стиле (те же лямбды);
b) В то же время, меня беспокоит, что "причёсывание" этих тестов вполне может повлиять на конечные результаты.
_>Даже в исправленном состояние msvc уступает gcc на данных тестах. Да, там цифры порядка 10%, а не в разы, но тем не менее в пользу gcc. Просто надо было выставить в тесте правильные опции для него, а не использовать дефолтные (которые делают не полную оптимизацию и ориентируются на процессоры типа Пентиумов), как судя по цифрам сделал ты.
Я НЕ выставлял специально никаких опций — это делает Qt Vs Addin и его настройки.
В данном случае я полагался именно на продукт Qt. Есть уверенность, что авторы Qt Vs Addin применяют эффективные настройки и опции компилятора.
Насчёт того, что играя опциями можно ускорить (даже тот же msvc результат) — идея ценная, хорошая (хотя есть ощущение, что Qt уже всё дало на MAX).
_>Кстати, самое забавное, что ты даже и для msvc полноценную оптимизацию использовать не можешь. Потому как судя по цифрам у тебя процессор минимум с avx, а то и с avx2...
+100500
Вполне возможно — это правильный вариант! Спасибо!
_>Т.е. ты считаешь, что описанное поведение — это не ошибка компилятора, а нормальная ситуация? )))
Ситуация предсказуемая — тяжелые вычисления или выноси в отдельный рабочий поток, или прокачивай сообщения ОС.
Иначе — терпи тормоза
К багам компилятора — это отношения не имеет (от слова совсем).
AG>Можно по-разному относиться к маркетингу/политике "мелкомягких", их модели продаж и т.д.
AG>Но в тоже время, следует отдать должное — их продукты очень даже достойные.
_>Если говорить про продукцию для C++, то они были безусловным лидером в данной области целое десятилетие (начиная с середины 90-ых), а потом проспали следующее десятилетие, сделав на .net. Сейчас вроде снова стараются — посмотрим что выйдет в будущем. Но судя по подобным косякам работать там надо ещё очень много.
Тренд на современный C++ (С++11 и C++14) у "мелкомягких" развивается уже примерно 5 лет (с 2012 студии).
А то что ты здесь именуешь "косяками" — просто говорит о твоём малом опыте работы с GUI подсистемой.
Скажем так — прокачка сообщений — это НЕ костыль, а особенность программирования подобных систем.
Здесь рассматривать многопоточность (вынос в рабочий поток) стоит, но только для несколько иных случаев.
Для такого простого случая, тем боле НЕ в Production — ИМХО можно и через прокачку.
_>Даже если забыть про данный косяк... Ты разве не посмотрел на результаты измерений в моём первом сообщение данной темы?
Смотрел и и результаты:
a) Меня радует, что эти мои старые тесты кого-то заинтересовали. Также радует, что код доработан в современном стиле (те же лямбды);
b) В то же время, меня беспокоит, что "причёсывание" этих тестов вполне может повлиять на конечные результаты.
_>Даже в исправленном состояние msvc уступает gcc на данных тестах. Да, там цифры порядка 10%, а не в разы, но тем не менее в пользу gcc. Просто надо было выставить в тесте правильные опции для него, а не использовать дефолтные (которые делают не полную оптимизацию и ориентируются на процессоры типа Пентиумов), как судя по цифрам сделал ты.
Я НЕ выставлял специально никаких опций — это делает Qt Vs Addin и его настройки.
В данном случае я полагался именно на продукт Qt. Есть уверенность, что авторы Qt Vs Addin применяют эффективные настройки и опции компилятора.
Насчёт того, что играя опциями можно ускорить (даже тот же msvc результат) — идея ценная, хорошая (хотя есть ощущение, что Qt уже всё дало на MAX).
_>Кстати, самое забавное, что ты даже и для msvc полноценную оптимизацию использовать не можешь. Потому как судя по цифрам у тебя процессор минимум с avx, а то и с avx2...
+100500
Вполне возможно — это правильный вариант! Спасибо!