Я, кстати, поглядел на это "конечно, посерьезнее к этому подходили". Забавно, что Intel гоняется с -O3, а VC без -Ob2. Т.е. в тестах VC не задействуется самая эффективная из оптимизаций — автоматическая илнлайн-подстановка, а -O3 в Inel-е как раз ее подразумевает. Думаю если добавить эту опцию, то все встанет на свои места.

В том-то и дело, что полученные тесты очень далеки от истины, например, в вышеуказанном примере цикл Intel компилятором оптимизируется в НОЛЬ! Угадай почему. Комплексные тесты это отнюдь не излишество, т.к. комплексные тесты это характеристика процесса, а не результата, т.к. грамотно построенные тесты могут обеспечивать детальной статистикой даже при комплексном решении. Слишком многие моменты, влияющие на результаты тестов, Вами просто не учитываются, а вот компилятором очень даже учитываются... Ну НЕЛЬЗЯ складывать цифры или вызывать функцию-член в цикле 5 миллионов раз и по этому характеризовать скорость компилятора. Я еще раз повторюсь — почитайте литературу, а потом беритесь за подобные статьи.

Вызовы методов конечно не показатель, и об этом сказано. Но алгоритмы очень даже показательны. А "ум" компилятора, ты сильно преувеличиваешь.

Если уж о чем-то и говорить, так о том, что языки типа Явы и Шарпа имеют много других черт замедляющих реальный код. Более естественные тесты это хорошо. Но надо знать и на что способен компилятор в конкретных случаях.

Согласен, но тогда лучше бы назвать статью — "Кто лучше всех оптимизирует цикл ;)"...
А по поводу "ума компиляторов" — тут я с тобой не соглашусь. Попробуй написать несколько простых приложений, использующих math.h и сравни полученные ассемблерные дампы Дельфей и Intel компилятора. И тестировать все-таки лучше на Intel процессорах, т.к. именно эти процессоры имеют численный перевес. Очень многие производители highPerfomance ПО используют именно этот компилятор (включая нашу фирму — одна из команд занимается разработкой MainMemory DB — где производительность имеет ключевое значение). Разумеется, мы неоднократно проводили тестирование производительности различных компиляторов и базируясь на результатах сделали свой выбор.

Есть набор стандартных тестов для тестирования качества оптимизатора. Поищите по словам Drystone, Whetstone, Linpack (это названия бенчмарков. Первый как раз на float).

Можно попробовать взять отсюда : http://www.nullstone.com

Здравствуйте, Владислав Чистяков, Вы писали:

А почему не тестировалась работа с динамической памятью? Можно подумать что все существующие программы делают токо перемножение вещественных чисел.

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

D>Здравствуйте, Владислав Чистяков, Вы писали:

D>А почему не тестировалась работа с динамической памятью? Можно подумать что все существующие программы делают токо перемножение вещественных чисел.
А потому, что при работе с динамической памятью основное время занимают сами операции выделения/освобождения памяти. Они никак не характеризуют компилятор (выделением/освобождением памяти занимаются библиотечные или системные фукнкции), а характеризуют алгоритм менеджмента памяти. Эти функции очень дороги (в смысле процессорного времени), а посему искажают результат тестирования.

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

D>А почему не тестировалась работа с динамической памятью? Можно подумать что все существующие программы делают токо перемножение вещественных чисел.

Как же не тестировалось? Тест TreeSort как раз и тестирует хип. Другое дело, что конечно там много аспектов которые в одном тесте охватить трудно. Так дотнет намного лучше себя чувствует если происходит не массовое выделение, а выделение и освобождение чередуются.

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

adb>Есть набор стандартных тестов для тестирования качества оптимизатора. Поищите по словам Drystone, Whetstone, Linpack (это названия бенчмарков. Первый как раз на float).

И как Вы себе видите их реализации на Дельфи, Яву и Шарп?

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

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

D>>Здравствуйте, Владислав Чистяков, Вы писали:

D>>А почему не тестировалась работа с динамической памятью? Можно подумать что все существующие программы делают токо перемножение вещественных чисел.
_>А потому, что при работе с динамической памятью основное время занимают сами операции выделения/освобождения памяти. Они никак не характеризуют компилятор (выделением/освобождением памяти занимаются библиотечные или системные фукнкции), а характеризуют алгоритм менеджмента памяти. Эти функции очень дороги (в смысле процессорного времени), а посему искажают результат тестирования.

Ну если ты имеешь в виду компилятор — это такая программа в виде одного экзешника без всяких библиотек, то может ты и прав. А так как каждый компилятор поставляется со своей библиотекой, то это очень даже неплохой показатель его качества(если уместно здесь это слово). Вот если бы я сказал что надо протестировать компилятор на скорость работы с виртуальной павмятью например, то тут можено и поспорить, т.к. вся работа компилятора состоит в основном в вызове АПИшной функции.
Вот например в Делфи существует свой менеджер памяти, борландцы его переписали сами исключительно для увеличения производительности, особенно это скажется в случаях частой выделении и освобождении памяти.Так что тестировать надо весь программный продукт, а не только сам компилятор, и сравнивать насколько хороший он создал код. Но разумеется не надо бросаться в крайности и сравнивать скорость работы MFC & VCL. Сравнению падлежат че части компилятора без которых он использоваться не может(например та же CRT)ну или очень затруднительно.

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

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

adb>>Есть набор стандартных тестов для тестирования качества оптимизатора. Поищите по словам Drystone, Whetstone, Linpack (это названия бенчмарков. Первый как раз на float).

VD>И как Вы себе видите их реализации на Дельфи, Яву и Шарп?

Вполне нормально. Я в свое время переписывал эти бенчи на Java. Они использовались как раз для сравнения качества нашего оптимизатора. Сомневаюсь, что с дельфями или шарпом будут какие-нибудь специфические проблемы.

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

D>>>Здравствуйте, Владислав Чистяков, Вы писали:

D>>>А почему не тестировалась работа с динамической памятью? Можно подумать что все существующие программы делают токо перемножение вещественных чисел.
_>>А потому, что при работе с динамической памятью основное время занимают сами операции выделения/освобождения памяти. Они никак не характеризуют компилятор (выделением/освобождением памяти занимаются библиотечные или системные фукнкции), а характеризуют алгоритм менеджмента памяти. Эти функции очень дороги (в смысле процессорного времени), а посему искажают результат тестирования.

D>Ну если ты имеешь в виду компилятор — это такая программа в виде одного экзешника без всяких библиотек, то может ты и прав. А так как каждый компилятор поставляется со своей библиотекой, то это очень даже неплохой показатель его качества(если уместно здесь это слово). Вот если бы я сказал что надо протестировать компилятор на скорость работы с виртуальной павмятью например, то тут можено и поспорить, т.к. вся работа компилятора состоит в основном в вызове АПИшной функции.
D>Вот например в Делфи существует свой менеджер памяти, борландцы его переписали сами исключительно для увеличения производительности, особенно это скажется в случаях частой выделении и освобождении памяти.Так что тестировать надо весь программный продукт, а не только сам компилятор, и сравнивать насколько хороший он создал код. Но разумеется не надо бросаться в крайности и сравнивать скорость работы MFC & VCL. Сравнению падлежат че части компилятора без которых он использоваться не может(например та же CRT)ну или очень затруднительно.
Да, я в курсе про тот менеджер в Делфи.
А с чем его сравнивать, если в unmanaged C++ runtime от Микрософт такого менеджера нет, и вызывается системные функции работы с памятью?
С другой стороны, ежели мы возьмем обработку комплексных чисел или векторов/матриц, то тут делфи почти наверняка останется далеко позади С++, поскольку работа VCL-контейнеров (если я ничего не путаю, с Делфи не работал) организовывается через виртуальные функции, а Си-шные шаблонные контейнеры обходятся без виртуальных вызовов...
Если копаться дальше, мы найдем еще кучу фич, которые в одной среде есть, в другой их нет. И тогда начнем оценивать вес фич, их сумму у каждого из продуктов...
Но это уже пойдет лирика и полный субъективизм. Что кому на данный час важнее, тот и будет это оценивать высоко, а остальные фичи ни в фиг не ставить...
Так что, я думаю, не стОит в этот анализ довешивать еще сравнение библиотек.

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

adb>Вполне нормально. Я в свое время переписывал эти бенчи на Java. Они использовались как раз для сравнения качества нашего оптимизатора. Сомневаюсь, что с дельфями или шарпом будут какие-нибудь специфические проблемы.

А какой там объем кода? И еще... на http://www.nullstone.com лежат каие-то странные (зашифрованные что ли...) зипы. Что-то я никак не въеду как с ними бороться.

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

VD>... Небыло уна и заление чего-нибудь шибко умное залепить...
VD>[поскипано за ненадобностью чёрными пиратами]

Ну, Влад!

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

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

adb>>Вполне нормально. Я в свое время переписывал эти бенчи на Java. Они использовались как раз для сравнения качества нашего оптимизатора. Сомневаюсь, что с дельфями или шарпом будут какие-нибудь специфические проблемы.

VD>А какой там объем кода? И еще... на http://www.nullstone.com лежат каие-то странные (зашифрованные что ли...) зипы. Что-то я никак не въеду как с ними бороться.

Ага PGP там. Они по идее должны выслать ключ в ответ на высланный тобой. Объем там наверняка большой. Но я раздобыл другие бенчмарки, которые сам когда-то на Java переводил. Выслал по почте в профайле.

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

M>То что этот компилятор работает не хуже других на Athlon — это уже показатель. Бо он его поддерживает. Если же проводить тесты на Intel машинах, то полагаю, ситуация существенно изменится (это как сравнение C# с ngen и без него).

На моем проекте применение компилятора от Intel дает примерно 2-х кратный прирост скорости.

Недавно игрался с компиляторами (от MS и от Intel) для Xscale процесоров.
Гонял тест, рисующий фракталы.
Intel compiler был в 4 раза быстрее. Впрочем это не удивительно.
Компилятор от MS похоже совсем никак не использует особенности процессоров Xscale.
Но больше всего меня поразило то, что когда в своем тесте я убрал строчку,
которая ставит пиксель нужного цвета на экран, то тест стал выполняться мгновенно.
Т.е. Intel compiler грубо говоря "догадался",
что можно "безболезненно" удалить кусок кода, формирующий фрактал и никуда его не выводящий

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

adb>Ага PGP там. Они по идее должны выслать ключ в ответ на высланный тобой. Объем там наверняка большой. Но я раздобыл другие бенчмарки, которые сам когда-то на Java переводил. Выслал по почте в профайле.

Спасибо. Приеду через две недели из отпуска погляжу.

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

B>Но больше всего меня поразило то, что когда в своем тесте я убрал строчку,
B>которая ставит пиксель нужного цвета на экран, то тест стал выполняться мгновенно.
B>Т.е. Intel compiler грубо говоря "догадался",
B>что можно "безболезненно" удалить кусок кода, формирующий фрактал и никуда его не выводящий

Это вроде делают все оптимизаторы. Удаление неработающего кода.

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

R3>Ну, Влад!
R3>

Руки с клавиш съехали, а прочесть, что написал в лом было.