GCC vs MSVC

А под ARM и CELL и MIPS обогнало? а даже не скомпилилось, тогда лесом

ссылочку на MSVC для линукс выдайте или тему как оффтопик в мусорную корзинку ,
потому что причем тут линукс?

а визуал студио точне не icc использует?

> потому что причем тут линукс?

Сравниваются два компилятора, один из которых свободный и под линукс имеется.

Целую нежно, ваш К.О.

> а визуал студио точне не icc использует?

точне

>точне

тогда нужно сравнить с icc

Уже неоднократно сравнивали. Есть даже люди, которые собирают ядро и окружение с icc.

а может К.О. выдаст ссылку и на второй компилятор для линукс?
Иначе пусть топикстартер идет на винфак , т.к. --target=x86-microsoft-windows

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

>конкретного провала GCC и победы компилятора от сами знаете кого, в деле оптимизации кода библиотеки Blitz++.

Там обычный глюк, и говорить о каком-то провале смешно. Ты хотя бы в другой версии gcc пробовал скомпилить ?

>Там обычный глюк

Там ни разу не глюк. Там выражение вида return a[b * c[0]], где c[0] - равна константе (как выяснилось). Да, GCC не осилил это выяснись на этапе компиляции.

> И да начнется обсуждение :)

Чего обсуждать? Что gcc поделка - давно известно.

> Я не большой знаток AT&T-шного синтаксиса, но помоему творится там какая-то муть

Это тебе минус, так что лучше бы осилил посмотреть и исходники:

T_numtype& operator()(TinyVector<int,1> index) { assertInRange(index[0]); return data_[index[0] * stride_[0]]; }

- причем где-то там stride_ для этого случая будет с нулями. Ну и что ты хочешь, собственно, и в чём твоя проблема?

В этой ситуации просто либа написана криво (неоптимальна для твоего случая) - GCC честно выполнил свою задачу, не додумывая за разработчиков либы; за VS ты заплатил - вот он тебе и выпрыгивает из шкуры чтобы отработать твои бабки.

>за VS ты заплатил

Он бесплатный.

express или пререлиз можно бесплатно использовать

Заплатил за компилятор или нет - за винду в любом случае заплатил. Плюс - разработчикам VS платят весьма неплохую зарплату за работу.

> Заплатил за компилятор или нет - за винду в любом случае заплатил

60$ не деньги

> Плюс - разработчикам VS платят весьма неплохую зарплату за работу.

рад за них

> 60$ не деньги

Я рад за тебя. Многие с тобой не согласятся.

>Заплатил за компилятор или нет - за винду в любом случае заплатил.

Некорректно, так как без винды и компилятор под неё не нужен.

>Плюс - разработчикам VS платят весьма неплохую зарплату за работу.

Вы уверены, что все разработчики GCC работают бесплатно?

вообще интересно узнать, как LLVM с этим справится. они вроде активно пишут, сборки у них выглядят прилично. может у них лучше код генерится? тогда нахер бэкэнд гэцеце нужен?

> Некорректно, так как без винды и компилятор под неё не нужен.

В чём некорректность? ЗП. разработчикам VS платят не только с продаж VS, но и винды в том числе.

> Вы уверены, что все разработчики GCC работают бесплатно?

Я такого не писал.

бугага. штука уже так бумажка, карманные деньги на рынок сходить за мясом.

>В чём некорректность? ЗП. разработчикам VS платят не только с продаж VS, но и винды в том числе

Первоначально Вы писали «GCC честно выполнил свою задачу, не додумывая за разработчиков либы; за VS ты заплатил - вот он тебе и выпрыгивает из шкуры чтобы отработать твои бабки», то есть речь шла о сравнении MSVS и GCC, типа одно бесплатное и удовлетворительное, а другое за бабки и крутое. Вот именно с этим я и спорю, так как в реальности они оба как компиляторы под винду бесплатны.

Вы таки верите в бесплатный сыр и пиво? Это ваше право, я не буду вас переубеждать :)

> Вы таки верите в бесплатный сыр и пиво? Это ваше право, я не буду вас переубеждать :)

винда - таки большой рынок, и в данном случае это не бесплатный сыр, а заработанный кусок хлеба

Пробовал еще с 3.3.6, 4.1.0 и даже 2.95.4 из МСВС.

И еще в догонку о зарплатах и стоимости. Каким образом это относится к обсуждаемой теме :) Да и что то мне подсказывает что разработчики GCC тоже не фига не за бесплатно работают, и кстати у кого больше зарплата это еще вопрос, к делу, кстати, тоже не относящийся.

З.Ы. Считать чужие деньги ИМХО дурной тон :)

> Каким образом это относится к обсуждаемой теме

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

> Считать чужие деньги ИМХО дурной тон

IMHO это придумано чтобы рассказывать лузерам, обдирая их как липку - ну или если в аристократов хочется поигратся :)

ты лучше скажи какая разница в скорости.

> ты лучше скажи какая разница в скорости

Непонятно разница в скорости между чем и чем имелась ввиду. Если для operator() то VC выигрывает у gcc примерно в 6 раз, для одномерного blitz::Array, если для декодера Витерби (упомянутого мной на rsdn-е) то где-то в 3 раза (естественно при реализации его на основе blitz::Array). Правда, ради справедливости стоит отметить, что переписанный на std::valarray декодер в случае G++ показал примерно 10% выигрыш по скорости перед VC. Но это, скорее, плевок в сторону реализации STL идущей в составе с VS, а не проигрыш компилятора.

ну и чего тут пыжится? какие-то оптимизации в gcc реализованы, какие-то в msvc.

> Если для operator() то VC выигрывает у gcc примерно в 6 раз,

На основании чего ты делаешь это заявление? Оно противоречит действительности, т.к. его очевидно интерпретировать - что именно operator() в языке C++ в GCC медленнее чем в VS.

На основании исходников blitz и твоего листинга асма легко убедится, что VC просто выкинул умножение, которое было в blitz в _функции_ operator(), т.к. множитель-переменная принимает значение в другом месте программы равное нулю, и никогда его не меняет.

Так что при чем тут оператор (), перегрузка функций и прочие возвышенные вещи?

Или же все посты выше тех кто ответил на тему - просто флуд, который и читать никто не собирается?

Надо битотрах на Си писать. С этим ++ вечно какие-то проблемы.

> 60$ не деньги

а одного компьютера - вполне достаточно, да ? :)

> а одного компьютера - вполне достаточно, да ? :)

а у меня на двух других линукс, а на еще одном Mac OS :P

> Непонятно разница в скорости между чем и чем имелась ввиду

сорри, прочитал пост по диагонали. Увы, gcc всю жизнь был таким :(. Если не влом то запости багрепорт им, вдруг пофиксят.

> вообще интересно узнать, как LLVM с этим справится. они вроде активно пишут, сборки у них выглядят прилично. может у них лучше код генерится? тогда нахер бэкэнд гэцеце нужен?

Я пробовал llvm-gcc 2.4. На сжатии flac'ом, 7z'ом и gzip'ом он слил обычному gcc 4.3.3 раза в полтора (точные цифры сейчас к сожалению сказать не могу).

> 8048a47: 89 f6 mov %esi,%esi
?
> 8048a49: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi
?? eiz? чем этот дамп сгенерен? (казалось, что это objdump)
> 8048a66: 83 c2 01 add $0x1,%edx
???

Тут оптимизации вообще включены?

> чем этот дамп сгенерен? (казалось, что это objdump)

Он родимый :)

> Тут оптимизации вообще включены?

Угу.

> а у меня на двух других линукс, а на еще одном Mac OS :P

Вас щас сожрут-с

А вообще Джобс мог бы вложиться в gcc