Re: Очередной "шедевр" от MS - C/C++

Здравствуйте, alex_public, Вы писали:
_>Но на фоне открывшейся чудесной "особенности" компилятора от MS данные проценты производительности уже перестают иметь какое-либо значение. На мой взгляд компилятор способный по не объяснимым причинам замедлить исполнение куска кода более чем в 100 раз вообще не может быть пригоден к использованию.

Упрощенный пример кода:

#define _USE_MATH_DEFINES
#include <cmath>
#include <time.h>
#include <iostream>

using namespace std;
constexpr auto N_MULTIPLY = 1000000;// 10000000;
constexpr int N_GENERATED = 1000;
double outputs_dbl[N_GENERATED];

template<typename F> void Measure(F f)
{
    int i;
    for (i = 2; i<N_MULTIPLY; i++) {
        for (int j = 0; j<N_GENERATED; j++)  f(i, j);
    }
//    if (i == 0) cout << "msvc";
}
void fun1(int i, int j)
{
    outputs_dbl[j%N_GENERATED] = sin((double)i);
}
void fun2(int i, int j)
{
    outputs_dbl[j] = sin((double)i);
}
int main()
{
    auto start = clock();
    Measure(fun1);
    auto finish = clock();
    double duration = (double)(finish - start) / CLOCKS_PER_SEC;
    cout << "Measure(fun1) - " << duration << " s." << endl;

    start = clock();
    Measure(fun2);
    finish = clock();
    duration = (double)(finish - start) / CLOCKS_PER_SEC;
    cout << "Measure(fun2) - " << duration << " s." << endl;
}

Результат выполнения (intel I5-2520m), VS 2015 update 3. Различные опции оптимизации влияют слабо.

Measure(fun1) — 1.422 s.
Measure(fun2) — 26.15 s.

Если запретить оптимизацию в Release то получится следующее:

Measure(fun1) — 38.862 s.
Measure(fun2) — 38.116 s.

Т.е. оптимизация для fun1 дала выигрыш в 27 раз, а для fun2 в 1,5. Глядя на код, оптимизация конечно должна была быть в N_MULTIPLY раз, так результат работы кода — заполненный массив outputs_dbl значением sin(N_MULTIPLY). Но по каким-то соображениям компилятор этого не сделал.

Почему такие небольшие изменения в коде дают такие результаты интересно только разработчикам компилятора.

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

Здравствуйте, Serg27, Вы писали:

S>Конечно для оценки качества генерации компилятора использовать код такого типа нельзя, так как время выполнения может быть от 0 (просто сгенировать нужный массив на этапе компиляции/загрузки) до плохо оптимизированного. Не зря же используют какие-то более реальные задачи со сложным кодом для проверки оптимизации компилятором.

Очень даже можно. ) Так и представил себе увлекательный поиск решения данной проблемы внутри сложного проекта, а не простенькой тестовой задачки. А так же какие потом будут тёплые чувства в адрес МС, когда по итогам длительного исследования всё же выяснится истинный виновник.

Да, и кстати хочу ещё уточнить, если вдруг кто-то не понял, что проблема то весьма обширная, а не узкоспециализированная на применение функции sin — портится оптимизация любого кода в подобном цикле, а не только для sin. Просто для неё разница в производительности очень сильно бросилась в глаза, что и побудило к расследованию. Но проблема то есть и у банального умножения в таком же цикле, так что это какой-то их глобальный косяк.

И судя по сообщениям на форуме (я сам естественно не проверял) он затрагивает как минимум версии: 2013, 2015, 2017. Так что получаем в итоге весьма показательную картинку... )))

Здравствуйте, уважаемый alex_public!

1) Выражаю большую признательность к моим тестам производительности, которые я поднял из моих архивов и опубликовал на GitHub-е,
специально для оценки различных компиляторов: MSVC и MinGW.

2) В то же время, Вы уважаемый alex_public, пытаетесь "навесить ярлык" на прекрасный программный продукт от Microsoft.
Это, к сожалению, НЕ делает Вам, уважаемый alex_public, чести

Можно по-разному относиться к маркетингу/политике "мелкомягких", их модели продаж и т.д.
Но в тоже время, следует отдать должное — их продукты очень даже достойные.

3) Игра опциями настройки компилятора, как бы ими не играть, не позволят серьезно изменить соотношение — т.е.
для Windows систем — (хотим мы это признавать или нет) MS компилятор окажется быстрее конкурента.

Ларчик открывается очень просто:
http://rsdn.org/forum/cpp/6723069.1

Здравствуйте, AlexGin, Вы писали:

AG>3) Игра опциями настройки компилятора, как бы ими не играть, не позволят серьезно изменить соотношение — т.е.
AG>для Windows систем — (хотим мы это признавать или нет) MS компилятор окажется быстрее конкурента.

В данном случае опции не причем, и коллега сказал правильно — налицо баг компилятора, бывает

. есть обходной путь — хорошо.

AG>Ларчик открывается очень просто:
AG>http://rsdn.org/forum/cpp/6723069.1

а это тот самый обходной путь, причем у ТС он гораздо проще — у него "мертвая" ветка кода, которая все равно попадает в asm и влияет на кодогенерацию.

Здравствуйте, Serg27, Вы писали:

S>Упрощенный пример кода:

S>Т.е. оптимизация для fun1 дала выигрыш в 27 раз, а для fun2 в 1,5. Глядя на код, оптимизация конечно должна была быть в N_MULTIPLY раз, так результат работы кода — заполненный массив outputs_dbl значением sin(N_MULTIPLY). Но по каким-то соображениям компилятор этого не сделал.

Для полноты картины:

	тесты VS2008 и VS2010
	Celeron J1900 Win7 x64 Visual Studio 2008 SP1 X86 Release /O1 Measure(fun1) — 103.994 s. Measure(fun2) — 92.975 s. (with cout "msvc") Release /O1 Measure(fun1) — 103.994 s. Measure(fun2) — 92.975 s. (w/o cout "msvc") Release /O2 Measure(fun1) — 94.713 s. Measure(fun2) — 90.441 s. (with cout "msvc") Release /O2 Measure(fun1) — 5.112 s. Measure(fun2) — 1.783 s. (w/o cout "msvc") Visual Studio 2008 SP1 X64 Release /O1 Measure(fun1) — 99.476 s. Measure(fun2) — 95.706 s. (with cout "msvc") Release /O1 Measure(fun1) — 4.503 s. Measure(fun2) — 0.357 s. (w/o cout "msvc") Release /O2 Measure(fun1) — 3.54 s. Measure(fun2) — 0.645 s. (with cout "msvc") Release /O2 Measure(fun1) — 3.69 s. Measure(fun2) — 0.637 s. (w/o cout "msvc") Visual Studio 2010 SP1 X86 Release /O1 Measure(fun1) — 104.399 s. Measure(fun2) — 92.204 s. (with cout "msvc") Release /O1 Measure(fun1) — 103.797 s. Measure(fun2) — 93.03 s. (w/o cout "msvc") Release /O2 Measure(fun1) — 5.118 s. Measure(fun2) — 1.787 s. (with cout "msvc") Release /O2 Measure(fun1) — 5.152 s. Measure(fun2) — 1.818 s. (w/o cout "msvc")

Здравствуйте, alex_public, Вы писали:

_>Очень даже можно. ) Так и представил себе увлекательный поиск решения данной проблемы внутри сложного проекта, а не простенькой тестовой задачки. А так же какие потом будут тёплые чувства в адрес МС, когда по итогам длительного исследования всё же выяснится истинный виновник.

Истинный виновник тут, конечно, тот, кто столь сложным кодом заполняет массив константой, известной на момент компиляции...

Нужны какие-то реальные вычисления, то, что компилятор не может выкинуть сам. Ну, например, вычисление знаков числа pi, начиная с задаваемого из командной строки...

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, LaptevVV, Вы писали:

S>>>На 64 битах результат подтверждаю.
LVV>>В смысле — в 100 раз хуже gcc?

_>В 100 раз хуже и gcc и себя самого (но только при наличие никчемной строки).

Не нужно потешаться над такими сложными продуктами как компиляторы. Мне приходилось очень часто сталкиваться с багами как GCC, так и MSVC.
Вот к примеру чуть более года назад столкнулся с ошибочной кодогенерацией GCC 4.8, который предоставляет Google для сборки андройда. Собирал я тогда 6-ой андройд для мобилки (до этого собирал 4-ый андрой при помощи GCC 4.7). Так вот после сборки оказалось, что WiFi драйвер по страшному чудит. В dmesg логе было видно место возникновения паники, но в этом месте ничего криминального не было. При чём небольшое изменения кода смещало место возникновения паники.
При исследовании при помощи изменения кода и просмотра ARM кода в IDA удалось понять, что бага не в коде, а в компиляторе. И проблема была в том, что эта версия GCC при обильном инлайне нескольких функций начинала некорректно работать с переменными на стеке. В IDA отчётливо наблюдал тот факт, что место на стеке использовалось несколькими переменными. Т.е. с какого то перепугу GCC посчитала, что далее по коду переменная Х уже не используется и можно регистр R использовать для новой переменной N. И это была роковая ошибка GCC (регистр R содержал лютую дичь), из-за которой сбой происходил только после нескольких возвратов из функций.
Использование GCC 4.9.4 решило проблему.

А буквально недавно пришлось компилить OpenSSH-Win32 под VS2010 SP1. Так вот при линковке sshd.exe линкер просто падал. Но подал с выдачей названия c-файла, который он посчитал дурным. Довольно быстро локализовал проблемное место: обычный switch и три case. Пришлось один из кейсов вынести за предел switch'а , что бы кодогенерация была корректной. В дизасм заглядывать было влом.

Здравствуйте, AlexGin, Вы писали:

AG>2) В то же время, Вы уважаемый alex_public, пытаетесь "навесить ярлык" на прекрасный программный продукт от Microsoft.
AG>Это, к сожалению, НЕ делает Вам, уважаемый alex_public, чести

Т.е. ты считаешь, что описанное поведение — это не ошибка компилятора, а нормальная ситуация? )))

AG>Можно по-разному относиться к маркетингу/политике "мелкомягких", их модели продаж и т.д.
AG>Но в тоже время, следует отдать должное — их продукты очень даже достойные.

Если говорить про продукцию для C++, то они были безусловным лидером в данной области целое десятилетие (начиная с середины 90-ых), а потом проспали следующее десятилетие, сделав ставку на .net. Сейчас вроде снова стараются — посмотрим что выйдет в будущем. Но судя по подобным косякам работать там надо ещё очень много.

AG>3) Игра опциями настройки компилятора, как бы ими не играть, не позволят серьезно изменить соотношение — т.е.
AG>для Windows систем — (хотим мы это признавать или нет) MS компилятор окажется быстрее конкурента.
AG>Ларчик открывается очень просто:
AG>http://rsdn.org/forum/cpp/6723069.1

Даже если забыть про данный косяк... Ты разве не посмотрел на результаты измерений в моём первом сообщение данной темы? Даже в исправленном состояние msvc уступает gcc на данных тестах. Да, там цифры порядка 10%, а не в разы, но тем не менее в пользу gcc. Просто надо было выставить в тесте правильные опции для него, а не использовать дефолтные (которые делают не полную оптимизацию и ориентируются на процессоры типа Пентиумов), как судя по цифрам сделал ты.

Кстати, самое забавное, что ты даже и для msvc полноценную оптимизацию использовать не можешь. Потому как судя по цифрам у тебя процессор минимум с avx, а то и с avx2, но ты это у себя никак не использовал, получая даже от msvc производительность в разы хуже возможной.

Здравствуйте, acDev, Вы писали:

D>Для полноты картины:
D>

	тесты VS2008 и VS2010
	D>Celeron J1900 Win7 x64 D>Visual Studio 2008 SP1 X86 D>Release /O1 Measure(fun1) — 103.994 s. Measure(fun2) — 92.975 s. (with cout "msvc") D>Release /O1 Measure(fun1) — 103.994 s. Measure(fun2) — 92.975 s. (w/o cout "msvc") D>Release /O2 Measure(fun1) — 94.713 s. Measure(fun2) — 90.441 s. (with cout "msvc") D>Release /O2 Measure(fun1) — 5.112 s. Measure(fun2) — 1.783 s. (w/o cout "msvc") D>Visual Studio 2008 SP1 X64 D>Release /O1 Measure(fun1) — 99.476 s. Measure(fun2) — 95.706 s. (with cout "msvc") D>Release /O1 Measure(fun1) — 4.503 s. Measure(fun2) — 0.357 s. (w/o cout "msvc") D>Release /O2 Measure(fun1) — 3.54 s. Measure(fun2) — 0.645 s. (with cout "msvc") D>Release /O2 Measure(fun1) — 3.69 s. Measure(fun2) — 0.637 s. (w/o cout "msvc") D>Visual Studio 2010 SP1 X86 D>Release /O1 Measure(fun1) — 104.399 s. Measure(fun2) — 92.204 s. (with cout "msvc") D>Release /O1 Measure(fun1) — 103.797 s. Measure(fun2) — 93.03 s. (w/o cout "msvc") D>Release /O2 Measure(fun1) — 5.118 s. Measure(fun2) — 1.787 s. (with cout "msvc") D>Release /O2 Measure(fun1) — 5.152 s. Measure(fun2) — 1.818 s. (w/o cout "msvc")

В 2008 и 2010 версиях данной ошибки похоже нет. И да, в данном коде от Serg27 не требуется раскомментировать строку с cout (её вообще можно убрать оттуда), т.к. в его варианте func1 уже является аналогом моего кода с раскоментированным cout, а func2 является аналогом кода с закомментированным.

Здравствуйте, Erop, Вы писали:

_E>Истинный виновник тут, конечно, тот, кто столь сложным кодом заполняет массив константой, известной на момент компиляции...

E>Нужны какие-то реальные вычисления, то, что компилятор не может выкинуть сам. Ну, например, вычисление знаков числа pi, начиная с задаваемого из командной строки...

Тесты конечно достаточно сомнительные. Но того, что ты упомянул, я в них что-то не вижу. Где там по твоему заполнение массива константой известной на момент компиляции?

Здравствуйте, alex_public, Вы писали:

_>Т.е. ты считаешь, что описанное поведение — это не ошибка компилятора, а нормальная ситуация? )))
Ситуация предсказуемая — тяжелые вычисления или выноси в отдельный рабочий поток, или прокачивай сообщения ОС.
Иначе — терпи тормоза

К багам компилятора — это отношения не имеет (от слова совсем).

AG>Можно по-разному относиться к маркетингу/политике "мелкомягких", их модели продаж и т.д.
AG>Но в тоже время, следует отдать должное — их продукты очень даже достойные.

_>Если говорить про продукцию для C++, то они были безусловным лидером в данной области целое десятилетие (начиная с середины 90-ых), а потом проспали следующее десятилетие, сделав на .net. Сейчас вроде снова стараются — посмотрим что выйдет в будущем. Но судя по подобным косякам работать там надо ещё очень много.
Тренд на современный C++ (С++11 и C++14) у "мелкомягких" развивается уже примерно 5 лет (с 2012 студии).
А то что ты здесь именуешь "косяками" — просто говорит о твоём малом опыте работы с GUI подсистемой.
Скажем так — прокачка сообщений — это НЕ костыль, а особенность программирования подобных систем.
Здесь рассматривать многопоточность (вынос в рабочий поток) стоит, но только для несколько иных случаев.
Для такого простого случая, тем боле НЕ в Production — ИМХО можно и через прокачку.

_>Даже если забыть про данный косяк... Ты разве не посмотрел на результаты измерений в моём первом сообщение данной темы?
Смотрел и результаты:
a) Меня радует, что эти мои старые тесты кого-то заинтересовали. Также радует, что доработан в современном стиле (те же лямбды);
b) В то же время, меня беспокоит, что "причёсывание" этих тестов вполне может повлиять на конечные результаты;
c) Сами цифры — IMHO зависят сильно от опций оптимизации компиляцией (здесь есть целое поле для разночтений

).

_>Даже в исправленном состояние msvc уступает gcc на данных тестах. Да, там цифры порядка 10%, а не в разы, но тем не менее в пользу gcc. Просто надо было выставить в тесте правильные опции для него, а не использовать дефолтные
Хорошо, на следующей неделе — дополнительно поэкспериментирую с опциями MinGW и MSVC опишу тут результаты.

_>(которые делают не полную оптимизацию и ориентируются на процессоры типа Пентиумов), как судя по цифрам сделал ты.
Пока что — я НЕ выставлял специально никаких опций — это делает Qt Vs Addin и его настройки.
В данном случае я полагался именно на продукт Qt. Есть уверенность, что авторы Qt Vs Addin применяют эффективные настройки и опции компилятора.
Насчёт того, что играя опциями можно ускорить (даже тот же msvc результат) — идея ценная, хорошая (хотя есть ощущение, что Qt уже всё дало на MAX: для всех поддерживаемых ими компиляторов).

_>Кстати, самое забавное, что ты даже и для msvc полноценную оптимизацию использовать не можешь. Потому как судя по цифрам у тебя процессор минимум с avx, а то и с avx2...
+100500
Вполне возможно — это правильный вариант! Спасибо!

z

Здравствуйте, Erop, Вы писали:

E>Истинный виновник тут, конечно, тот, кто столь сложным заполняет массив константой, известной на момент компиляции...

Массив заполняется случайными значениями, перемноженными на индекс прохода по циклу.

E>Нужны какие-то реальные вычисления, то, что компилятор не может выкинуть сам. Ну, например, вычисление знаков числа pi, начиная с задаваемого из командной строки...

Тоже один из вариантов...

Здравствуйте, AlexGin, Вы писали:

_>>Т.е. ты считаешь, что описанное поведение — это не ошибка компилятора, а нормальная ситуация? )))
AG>Ситуация предсказуемая — тяжелые вычисления или выноси в отдельный рабочий поток, или прокачивай сообщения ОС.
AG>Иначе — терпи тормоза

А ты случаем не путаешь медленные вычисления и замораживание интерфейса при таких вычислениях (естественно в том случае, если это писал криворукий программист)? ))) Потому как от второй проблемы расстановка дополнительных циклов обработки сообщений ещё может помочь, а вот с первой проблемой ничем подобным помочь нельзя. А то бы иначе сейчас все суперкомпьютеры выстроились в очередь за "прокачкой сообщений от ОС"...

AG>К багам компилятора — это отношения не имеет (от слова совсем).

Самое забавное, что ты даже не понял что ты собственно сделал в своём коде и почему он снова заработал. ) И тебя даже не смущает тот факт, что если заменить цикл обработки сообщений на какой-нибудь cout<<"xaxa"; то всё равно проблема решается.

_>>Даже если забыть про данный косяк... Ты разве не посмотрел на результаты измерений в моём первом сообщение данной темы?
AG>Смотрел и результаты:
AG>a) Меня радует, что эти мои старые тесты кого-то заинтересовали. Также радует, что доработан в современном стиле (те же лямбды);
AG>b) В то же время, меня беспокоит, что "причёсывание" этих тестов вполне может повлиять на конечные результаты;
AG>c) Сами цифры — IMHO зависят сильно от опций оптимизации компиляцией (здесь есть целое поле для разночтений

).

Безусловно. Но если мы возьмём настройки дающие максимально возможную производительность на каждом из компиляторов и при этом один из них будет давать чуть более быстрый код, то можно будет сказать, что он эффективнее? )

_>>Даже в исправленном состояние msvc уступает gcc на данных тестах. Да, там цифры порядка 10%, а не в разы, но тем не менее в пользу gcc. Просто надо было выставить в тесте правильные опции для него, а не использовать дефолтные
AG>Хорошо, на следующей неделе — дополнительно поэкспериментирую с опциями MinGW и MSVC опишу тут результаты.

Поставь для начала (я использовал не такие, но это самый простой вариант для начальной оценки эффекта) в MinGW опции "-O3 -march=native" — сразу оценишь разницу. )))

_>>(которые делают не полную оптимизацию и ориентируются на процессоры типа Пентиумов), как судя по цифрам сделал ты.
AG>Пока что — я НЕ выставлял специально никаких опций — это делает Qt Vs Addin и его настройки.
AG>В данном случае я полагался именно на продукт Qt. Есть уверенность, что авторы Qt Vs Addin применяют эффективные настройки и опции компилятора.

С таким подходом нельзя даже приближаться к тестам на производительность. И да, дефолтные опции Qt весьма далеки от максимальной эффективности.

Здравствуйте, AlexGin, Вы писали:

AG>Здравствуйте, Erop, Вы писали:

E>>Истинный виновник тут, конечно, тот, кто столь сложным заполняет массив константой, известной на момент компиляции...

AG>Массив заполняется случайными значениями, перемноженными на индекс прохода по циклу
Егор абсолютно прав. Посмотрите код внимательно. Там где "Массив заполняется случайными значениями, перемноженными на индекс прохода по циклу" проблем нет (это в коде ТС). В моем коде оставлено только два варианта с одинаковым результатом вычислений, причем результат мог быть вычислен во время компиляции. цитата:

Т.е. оптимизация для fun1 дала выигрыш в 27 раз, а для fun2 в 1,5. Глядя на код, оптимизация конечно должна была быть в N_MULTIPLY раз, так результат работы кода — заполненный массив outputs_dbl значением sin(N_MULTIPLY). Но по каким-то соображениям компилятор этого не сделал.

Напомню, что N_MULTIPLY = 1000000. Т.е gcc тоже облажался с оптимизацией... Причем очень сильно...

Я не поленился и сделал bug report — connect.microsoft.com
Предмет бага — разный уровень оптимизации для очень близкого кода. Посланный код основан на rsdn

P.S.
Хотел бы еще раз отметить, что для этого вырожденного кода включение оптимизации в одном случае дает выигрыш в 27 раз, а в другом в 1.5. При идеальной же оптимизации выигрыш должен был быть в N_MULTIPLY = 1000000 раз. С этим не справился ни один компилятор...
P.P.S.
Самого кода пока не видно. Они декларируют задержку в появлении загруженных файлов от нескольких часов до суток.

После того как я послал bug report в MS, я решил проверить, а как справляется с этим вырожденным примером CLang (по мнению многих лучший компилятор нашего времени). Так как toolset Clang установлен у меня в VS2015, то это делается переключением toolset в настройках проекта.

Code

#include <cmath>
#include <time.h>
#include <iostream>

using namespace std;

constexpr auto N_MULTIPLY = 1000000;// 10000000;
constexpr int N_GENERATED = 1000;
namespace
{
    double outputs_dbl[N_GENERATED];
}
template<typename F> void Measure(F f)
{
    for (int i = 2; i<N_MULTIPLY; i++) {
        for (int j = 0; j<N_GENERATED; j++)  f(i, j);
    }
}
template<typename F> void Measure2(F f)
{
    int i = 1;
    for (i = 2; i<N_MULTIPLY; i++) {
        for (int j = 0; j<N_GENERATED; j++)  f(i, j);
    }
    if (i == 0) cout << "msvc";
}

void fun1(int i, int j)
{
    outputs_dbl[j%N_GENERATED] = sin((double)i);
}
inline void fun2(int i, int j)
{
    outputs_dbl[j] = sin((double)i);
}
int main()
{
    auto start = clock();
    Measure(fun1);
    auto finish = clock();
    double duration = (double)(finish - start) / CLOCKS_PER_SEC;
    cout << "Measure(fun1) - " << duration << " s." << endl;
//    cout << outputs_dbl[0] << " " << outputs_dbl[N_GENERATED - 1] << " " << sin((double)(N_MULTIPLY - 1)) << endl;

    start = clock();
    Measure(fun2);
    finish = clock();
    duration = (double)(finish - start) / CLOCKS_PER_SEC;
    cout << "Measure(fun2) - " << duration << " s." << endl;

    start = clock();
    Measure2(fun1);
    finish = clock();
    duration = (double)(finish - start) / CLOCKS_PER_SEC;
    cout << "Measure2(fun1) - " << duration << " s." << endl;

    start = clock();
    Measure2(fun2);
    finish = clock();
    duration = (double)(finish - start) / CLOCKS_PER_SEC;
    cout << "Measure2(fun2) - " << duration << " s." << endl;

}

MS VC++ результат:

Measure(fun1) — 1.481 s.
Measure(fun2) — 26.168 s.
Measure2(fun1) — 1.392 s.
Measure2(fun2) — 0.207 s.

CLang результат:

Measure(fun1) — 30.267 s.
Measure(fun2) — 27.868 s.
Measure2(fun1) — 29.742 s.
Measure2(fun2) — 27.921 s.

командная строка компилятора:

-fpic "stdafx.h" -fstack-protector "x64\Release\" -fno-strict-aliasing -ffunction-sections -gline-tables-only -O3 -x c++-header -D "NDEBUG" -D "_CONSOLE" -D "_UNICODE" -D "UNICODE" -fno-rtti -fomit-frame-pointer -fdata-sections -fno-ms-compatibility -fexceptions -o "x64\Release\testRSDN.obj" -fms-extensions -fno-short-enums

Вывод в стиле ТС :))
!!!Как видно Clang уступает MSVC и вообще не пригоден к использованию!!!!

Здравствуйте, Serg27, Вы писали:

S>Я не поленился и сделал bug report — connect.microsoft.com
Мне говорили — там аттачи больше года не работают. Не появятся через день — смело вставляй ссылку.

Здравствуйте, alex_public, Вы писали:

_>А ты случаем не путаешь медленные вычисления и замораживание интерфейса при таких вычислениях (естественно в том случае, если это писал криворукий программист)? ))) Потому как от второй проблемы расстановка дополнительных циклов обработки сообщений ещё может помочь, а вот с первой проблемой ничем подобным помочь нельзя. А то бы иначе сейчас все суперкомпьютеры выстроились в очередь за "прокачкой сообщений от ОС"...

Hint: multithreading — это единственное решение данной проблемы в Production.

_>Самое забавное, что ты даже не понял что ты собственно сделал в своём и почему он снова заработал. ) И тебя даже не смущает тот факт, что если заменить цикл обработки сообщений на какой-нибудь cout<<"xaxa"; то всё равно проблема решается.

Sorry, но это ты не понял:
Любой "оконный" вывод в современных графических операционных системах связан с обменом сообщениями операционной системы.
Без них не отработает ничего(ни вывод std::cout на консоль, ни обновление прогресс бара).
В данном случае, этот вывод (за счёт прокачки сообщений реализованной в недрах OS Windows) просто обеспечивал "сторонний эффект".
Только вот тут редкий случай, когда данный "сторонний эффект" действует положительно, а не отрицательно

Когда я явно сделал ту же прокачку — всё вернулось на свои места.

_>Поставь для начала (я использовал не такие, но это самый простой вариант для начальной оценки эффекта) в MinGW опции "-O3 -march=native" — сразу оценишь разницу.
Хорошо, попробую!

_>С таким подходом нельзя даже приближаться к тестам на производительность. И да, дефолтные опции Qt весьма далеки от максимальной эффективности.

Пойми правильно, уважаемый alex_public, что я ведь не собираюсь "с пеной у рта" доказывать, что MSVC — the best

Просто хочу докопаться до истины.
Окажется, что в этом эксперименте оба компилятора примерно одинаковы, или даже MinGW чуть быстрее — милости просим!

Здравствуйте, Serg27, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:

AG>>Здравствуйте, Erop, Вы писали:

E>>>Истинный виновник тут, конечно, тот, кто столь сложным заполняет массив константой, известной на момент компиляции...

AG>>Массив заполняется случайными значениями, перемноженными на индекс прохода по циклу
S>Егор абсолютно прав. Посмотрите внимательно. Там где "Массив заполняется случайными значениями, перемноженными на индекс прохода по циклу" проблем нет (это в ТС). В моем коде оставлено только два варианта с одинаковым результатом вычислений, причем результат мог быть вычислен во время компиляции. цитата:
S>

S>Т.е. оптимизация для fun1 дала выигрыш в 27 раз, а для fun2 в 1,5. Глядя на код, оптимизация конечно должна была быть в N_MULTIPLY раз, так результат работы кода — заполненный массив outputs_dbl значением sin(N_MULTIPLY). Но по каким-то соображениям компилятор этого не сделал.

S>Напомню, что N_MULTIPLY = 1000000. Т.е gcc тоже облажался с оптимизацией... Причем очень сильно...
Вообще-то в моём случае:

    const int N_MULTIPLY = 10000000;

То есть десять миллионов, вы уважаемый Serg27, почему-то эту константу приняли на порядок меньше.

Вот мой тестовый пример:
https://github.com/AlexGin/Math/blob/master/mainwindow.cpp

P.S. Как ускорить прохождение теста, без изменения константы, а рассказал здесь:
http://rsdn.org/forum/cpp/6723069.1

P.P.S. Считать ли данное поведение багом — это вопрос.
Посмотрим, что ответят на это разработчики из MS.

Здравствуйте, Serg27, Вы писали:

S>После того как я послал bug report в MS, я решил проверить, а как справляется с этим вырожденным примером CLang (по мнению многих лучший компилятор нашего времени).

Он хороший компилятор с точки зрения сообщений об ошибках в сложном c++ коде,
плюс исходники у него намного лучше читаются по сравнению с gcc,
больше честно говоря на моих проектах я плюсов не заметил,
хотя то, что они за столь короткое время настигли остальные компилятор,
помоему это огромное достижение,

но тем не менее для пузомерок на x86/amd64 всегда впереди всех был компилятор от Intel, разве нет?

	От:	Serg27
	Дата:	11.03.17 18:23
	Оценка:	18 (2)

	От:	alex_public
	Дата:	11.03.17 20:26
	Оценка:	+2

	От:	AlexGin
	Дата:	11.03.17 21:01
	Оценка:

	От:	pilgrim_
	Дата:	11.03.17 21:06
	Оценка:	+1

	От:	acDev
	Дата:	11.03.17 21:28
	Оценка:	1 (1)

	От:	Zhendos
	Дата:	12.03.17 13:12
	Оценка: