Статья:
Кто сегодня самый шустрый-3?

Автор(ы): Владислав Чистяков

Авторы:
Владислав Чистяков

Аннотация:
К тому времени, когда мы занялись написанием этого теста (а вернее, отбросили около пяти вариантов из-за их непригодности) подоспели Borland C++ Builder 6.0 (BCB) и релиз VS.Net (VS7, т.е. входящие в него VC7 и C#). Естественно, что мы с радостью протестировали и их.

Ниже приведены их результаты и результаты выполнения нашего нового Float-теста.

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

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

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

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

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

Здравствуйте, <Аноним>, Вы писали:

А>Вот и имеете то, что имеете

А>Режьте меня на части — не может быть JIT-язык быстрее, чем компилируемый. Ну никак! Иначе я давно бы писал на Java, которую, кстати, очень люблю. Да и C# как брата-близнеца тоже.

Before MSIL can be executed, it must be converted by a .NET Framework Just In Time (JIT) compiler to native code, which is CPU-specific code that runs on the same computer architecture that the JIT compiler is running on. Because the runtime supplies a JIT compiler for each CPU architecture that the runtime operates on, developers can write a set of MSIL that can be JIT-compiled and executed on computers with different architectures. (If your managed code calls platform-specific native APIs or a class libary that is platform-specific, your code is limited to running on a specific operating system.)

(C)MSDN

Ребят, ну существуют же определенный ГОСТы и нормативы по поводу тестирования компиляторов. Ну сложение флоатов в цикле — это уже ни в какие ворота не лезет. Особенно мне понравилось тестирование Intel компилятора на Атлоне ;) Или еще лучше — это тесты одной строчки кода в цикле ;)

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

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

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

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

p.S.> Очень рекомендую ознакомиться с условиями тестирования компиляторов, которых придерживались другие авторы подобных научных работ. Вы будете удивлены тому, что не так все просто :)

Немного не понятно bcc — это действительно бесплатный компилятор, но который поставляется и как компилятор в составе Builder C++. BCB — это всего лишь среда разработки, которая для компилирования использует bcc. Естественно она не может быть компилятором. В Builder C++ версии 5 сейчас поставляется bcc версии продукта 5.0 файла 5.5.5.1 (см файл bcc32.exe),Это версия сейчас и поставляется бесплатно.В Builder C++ версии 6 сейчас используется bcc версии продукта 6.0 файла 5.6.0.0. Следовательно в тесте сравнивались не bcc и bcb, а две подверсии компилятора bcc 5.5 и 5.6. В этом случае настораживает большай разница результатов между ними. По моему опять вкралась какая то ошибка. Либо bcc не так хорош, либо "bcb" — не так плох. Возможно дело в том, что для bcc оптимизацию настраивали черех коммандную строку, а для "bcb" — через IDE.

Виноват. Снимаю предыдущее замечание. Я оказался не прав. BCB не использует коммандный компилятор bcc, а загружает comp32p.dll — Borland C/C++ Compiler DLL с такими же версиями, что и у коммандного компилятора bcc, Так что bcb и bcc — это действительно разные компиляторы.

Гы! Кульно! По-моему я на iXbt видел сравнительные тесты компиляторов под win32. Там, конечно, посерьезнее к этому подходили и результаты явно отличались. Я очень хорошо запомнил, что именно на float тестах Intel компилятор с P4 оптимизацией показывал результаты в !НЕСКОЛЬКО! раз выше bcc. И дельфи почти везде красовалась на последнем месте, иногда уступая свое место яве. Ну там, конечно, не строки RTL библиотек сравнивали :-) И все-таки сравнивать Яву с C++ очень пошло, т.к. результаты работы ява приложений скорее зависят не от компилятора :)
2Автор: Звиняй за прямоту — просто слишком уж фантастические у тебя результаты, хотя, с такими условиями все возможно.

Поверь. Мы сам не знали что результаы будут именно такими. Небыло уна и заление чего-нибудь шибко умное залепить. Просто хотелось посмотреть на, что способны компиляторы в нашей повседневной жизни. Другие сравнения они какие-то комплексные. Из них не ясно что в коомпиляторе хоршо, а что не. Тут же все по полочкам...

Кстати, ты бы кинул ссылку на iXbt-ешное тестирование.

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

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

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

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

Сюда загляните тоже
www.pi8plus.ru/algcom

Не могу скачать "Тестовые проекты — 90КБ"
А "http://www.rsdn.ru/article/preview/vlad/PERFTEST.ZIP" существует?

На ixbt сравнивались компиляторы VC и Intel ни bcc ни delphi там нет.

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

В свое время на лабах по Архитектуре высокопроизводительных процессоров мы писали фичи примерно такой сложности. Часто даже процессор не играл роли в быстродействии.
Необходимо задать реальный тест — обработка звука,изображения,видео.
Такой тест, нпример, как вызов виртуального метода в цикле не дает никакого представления о качестве компиляции. Нужно вызывать чтото более реальное.
Если сравнивать вызовы PostMessage и SendMessage, то часто можно наблюдать ситуацию,когда PostMessage вызывается в разы дольше при одинаковых условиях.

Единственный тест нормальный — это сортировки.
Но из-за модели многозадачности Windows секундные результаты тестов — это ерунда.
Необходима часовая загрузка с прибиванием всяких дрянных сервисов.
Вот здесь выльется траблы с Джавой — при использовании памяти время начнет жрать ее Гарбэдж-коллектор. А реальный алгоритмы оптимизации графов из нескольких тысяч узлов, линков и всякой дряни покажут отставание минимум в пять раз.

Неделя на С++ и больше месяца на Джава — это результат !
К примеру — проект, где я работаю, обсчитывает граф иногда по несколько недель при максимальм использовании памяти — до 2 Gb. Джава, скорее всего, уйдет в своп, аки дети в школу.

Будет ли произведено тестирование этой платформы?

Ой. Это мы лахонулись. Вот настоящий адрес:
http://rsdn.ru/article/devtools/perftest/PerfTest.zip

Да, надо бы. Но похоже разницы с Дельфи 6 особой не будет.

>Необходимо задать реальный тест — обработка звука,изображения,видео.

И что в этом реального? Обработка видео и звука — это давно область применения SIMD-инструкций и ручной оптимизиации. Ну, и главное, что этими задачами занимаются 0.01% людей.

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

Этого и не утвержалось. Но интересно было посмотреть и на эти результаты.

>Если сравнивать вызовы PostMessage и SendMessage, то часто можно наблюдать ситуацию,когда PostMessage вызывается в разы дольше при одинаковых условиях.

А причем тут это? PostMessage и SendMessage — это разные алгоритмы посылки сообщений в виндовс. Мы же не сравниваем расчет Pi и быструю сортировку?

>Единственный тест нормальный — это сортировки.

А чем ненормален тот же расчет Pi или конкатенация строк?

>Но из-за модели многозадачности Windows секундные результаты тестов — это ерунда.

Вот не обоснованные выводы — это точно ерунда. А результаты вполне повторяемые. Вам шашечки или ехать?

>Вот здесь выльется траблы с Джавой — при использовании памяти время начнет жрать ее Гарбэдж-коллектор.

Ява и на малых объемах показала результаты работы с памятью куда хуже чем та же Дельфи. Но про долгострочную перспективу вы точно заблуждаетесь. Как раз при долгострочной работе GC дает преимущество, так как только алгоритм сборки мусора может обеспечить поддержание памяти в нефрагментированном состоянии.


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

Чтобы это утверждать, сначало нужно провести такой эксперимент. Пришлите нам алгоритм и исходный граф, который вы считаете "реальными", мы перепишем его на все тестируемые языки и проверим в действии. К тому же, для Явы это далеко не так плохо. Совсем недавно за счастье можно было считать десятикратное отставание.

>Неделя на С++ и больше месяца на Джава — это результат !

Я бы сказал, что такие задачи сами по себе являются уникальными и требуют чуть ли не ручной оптимизации на асме.

>Джава, скорее всего, уйдет в своп, аки дети в школу.

Вот слова "скорее всего" мы как раз и не можем допускать. Поймите, воспроизвести, к примеру, ваш проект на Яве (а тем более на всех остальных подопытных языках) да еще так, чтобы можно было говорить об адекватности примененных алгоритмов, физически невозможно. Именно поэтому приходится пользоваться короткими легко проверяемыми тестами.

А если конкретнее?

Извеняюсь. Или я промазал, или что-то глюкнуло.

>Необходимо задать реальный тест — обработка звука,изображения,видео.

И что в этом реального? Обработка видео и звука — это давно область применения SIMD-инструкций и ручной оптимизиации. Ну, и главное, что этими задачами занимаются 0.01% людей.

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

Этого и не утвержалось. Но интересно было посмотреть и на эти результаты.

>Если сравнивать вызовы PostMessage и SendMessage, то часто можно наблюдать ситуацию,когда PostMessage вызывается в разы дольше при одинаковых условиях.

А причем тут это? PostMessage и SendMessage — это разные алгоритмы посылки сообщений в виндовс. Мы же не сравниваем расчет Pi и быструю сортировку?

>Единственный тест нормальный — это сортировки.

А чем ненормален тот же расчет Pi или конкатенация строк?

>Но из-за модели многозадачности Windows секундные результаты тестов — это ерунда.

Вот не обоснованные выводы — это точно ерунда. А результаты вполне повторяемые. Вам шашечки или ехать?

>Вот здесь выльется траблы с Джавой — при использовании памяти время начнет жрать ее Гарбэдж-коллектор.

Ява и на малых объемах показала результаты работы с памятью куда хуже чем та же Дельфи. Но про долгострочную перспективу вы точно заблуждаетесь. Как раз при долгострочной работе GC дает преимущество, так как только алгоритм сборки мусора может обеспечить поддержание памяти в нефрагментированном состоянии.


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

Чтобы это утверждать, сначало нужно провести такой эксперимент. Пришлите нам алгоритм и исходный граф, который вы считаете "реальными", мы перепишем его на все тестируемые языки и проверим в действии. К тому же, для Явы это далеко не так плохо. Совсем недавно за счастье можно было считать десятикратное отставание.

>Неделя на С++ и больше месяца на Джава — это результат !

Я бы сказал, что такие задачи сами по себе являются уникальными и требуют чуть ли не ручной оптимизации на асме.

>Джава, скорее всего, уйдет в своп, аки дети в школу.

Вот слова "скорее всего" мы как раз и не можем допускать. Поймите, воспроизвести, к примеру, ваш проект на Яве (а тем более на всех остальных подопытных языках) да еще так, чтобы можно было говорить об адекватности примененных алгоритмов, физически невозможно. Именно поэтому приходится пользоваться короткими легко проверяемыми тестами.

Нашей целью было дать проверенную информацию, чтобы люди не основывали свои расуждения на слухах и предрассудках.

Думаю, было интересно и VB.NET протестировать. А то вы VB6 включили (хотя про него и так все ясно), а VB.NET все же куда актуальнее.

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

Есть набор стандартных тестов для тестирования качества оптимизатора. Поищите по словам 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>[поскипано за ненадобностью чёрными пиратами]

Ну, Влад!

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

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

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

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

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

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

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

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

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

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

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

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

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

Там было немного сложнее чем обычно.
Он соптимизировал несколько функций...
Оптимизатор от MS не смог в этой же ситуации распознать "неработающий" код.

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

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

А -Ob2 было включено? Ошибкой многих кто сравнивает компилятор MS и Intel является, то что они не включают в MS опцию автоматической инлайн-подстановки. А это Intel C++ ее автоматом включает. В моих тестах после включении Ob2 в VC7/7.1 на целочисленных вычислениях скорость была не хуже (а порой и лучше) чем у Intel-а.

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

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

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

VD>А -Ob2 было включено? Ошибкой многих кто сравнивает компилятор MS и Intel является, то что они не включают в MS опцию автоматической инлайн-подстановки. А это Intel C++ ее автоматом включает. В моих тестах после включении Ob2 в VC7/7.1 на целочисленных вычислениях скорость была не хуже (а порой и лучше) чем у Intel-а.

Да, это было сделано.
Мой "эксперимент", на самом деле состоял из 3-х разных тестов.
Нужно было построить фрактал, используя:
— double вычисления,
— GPP
— собственный класс, инкапсулирующий GPP.
Из GPP использовались только арифметика над числами с фиксированной точкой.
Точных результатов у меня сейчас под рукой нет, но результаты были примерно следующими.
Для MS компилятора потребовалось около 50 сек для 1-го теста, меньше 2 сек — для 2-го и 3-го тестов.
В случае с компилятором от Intel потребовалось менее 13 сек для double вычислений,
и те же самые 2 сек в других случаях.

Если исключить инлайн-подстановки, то в случае с MS
1-й и 2-й тесты показали такой же результат как и раньше,
а вот 3-й тест потребовал около 9 сек.
Intel, с отключенной инлайн-подстановкой потребовал около 11 сек на 3-й тест.

Повторюсь, все это было сделано на системе c PXA255 и WinCE.NET 4.1.
Т.е. Intel compiler для Xscale очевидно пораждает лучший код,
но сам компилятор, к сожалению имеет кучу проблем.
Но это уже другая история...

Собственно, сабж.

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

Поэтому надо было равнять Arrays.sort (Java) с std::sort (C++), хотя это и смешно.

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

D>Никто не пишет сортировок вручную.

Месье имеет мандат говорить от имени всех?

D> Реализации строк, векторов, иных коллекций и алгоритмов давно написаны и просто обязаны использоваться любым серьезным программистом, не желающим терять свое (не побоюсь слова, драгоценное) время.

В первую очередь нужно беречь драгоценное время пользователей. А оно как раз и зависит от качества применяемых алгоритмов. И в том же С++ очень часто прибегают к ручной реализации тех или иных алгоритмов.

D>Поэтому надо было равнять Arrays.sort (Java) с std::sort (C++), хотя это и смешно.

Задачей статьи было сравнение по нескольким критериям различных (и серьезно-разлиных) средств разработки/компиляторов. Тест сортировки призван был показать качество генерации кода и оптимальность рабты с большими объемами памяти. Именно для этого алгоритм обязан был быть идентичным во всех языках.

Лирика: Встроенные функции таких языков как Ява или дотнета оптимизированы для встроенных (и не только) типов данных путем банальной реализации алгоритмов на С++, так что такой тест вылился бы в соревнование С++-программистов — писателей стандартных библиотек. К тому же тот же std::sort различается как небо и земля в разных реализациях STL. Ведь хотя поклонники С++ и утверждают, что STL — это стандарт, но на практике стандартом является только интерфейс (кстати тоже редко соблюдаемый на 100%), а реализации отданы на откуп разработчикам. Причем никто не заставляет не только пользоваться библиотекой идущей в поставке компилятора, но и вообще пользоваться STL. А по числу применений скорее всего в С++ на сегодня будет победителем вообще qsort .

VD>Месье имеет мандат говорить от имени всех?
Нет, за всех не распишусь. Есть же люди, которые за рулем кофе пьют и лифтах сексом занимаются.

VD>В первую очередь нужно беречь драгоценное время пользователей. А оно как раз и зависит от качества применяемых алгоритмов. И в том же С++ очень часто прибегают к ручной реализации тех или иных алгоритмов.
Если программист начнет тратить время на сортировку и переписывание контейнеров, то у него останется намного меньше времени на собственно его алгоритмы. К тому же, в Java применяется сортировка Bentley-McIlroy, являющаяся на сегодняшний день самой быстрой, приемлимой по скорости даже на вырожденных массивах.

VD>Задачей статьи было сравнение по нескольким критериям различных (и серьезно-разлиных) средств разработки/компиляторов. Тест сортировки призван был показать качество генерации кода и оптимальность рабты с большими объемами памяти. Именно для этого алгоритм обязан был быть идентичным во всех языках.
Было такое наблюдение, проведенное специалистами Apple — 80% времени программы проводили внутри стандартной библиотеки. А сравнивать по памяти языки со встроенной поддержкой GC и без нее попросту глупо. Равно как и вызовы методов без оптимизаций.

VD>Лирика: Встроенные функции таких языков как Ява или дотнета оптимизированы для встроенных (и не только) типов данных путем банальной реализации алгоритмов на С++, так что такой тест вылился бы в соревнование С++-программистов — писателей стандартных библиотек. К тому же тот же std::sort различается как небо и земля в разных реализациях STL. Ведь хотя поклонники С++ и утверждают, что STL — это стандарт, но на практике стандартом является только интерфейс (кстати тоже редко соблюдаемый на 100%), а реализации отданы на откуп разработчикам. Причем никто не заставляет не только пользоваться библиотекой идущей в поставке компилятора, но и вообще пользоваться STL. А по числу применений скорее всего в С++ на сегодня будет победителем вообще qsort .
Такие личности вектора через индекс итерируют, строки сливают при помощи strcat, а про ostream_iterator не слышали даже от старших товарищей. Это не программисты на С++, это чистые С-шники, которые понятия не имеют ни об ООП, ни о шаблонах проектирования. А по поводу разных реализаций STL могу сказать следующее: SGI STL и gcc STL — одно и то же, а STLport является просто мультиплатформенной переделкой SGI STL. Единственный, кто действительно отличается начинкой (хотя практика свидетельствует, что различия эти некритичны) — это VC STL от Dinkumware. Так что слухи о разности реализаций несколько преувеличены.

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

d> по поводу разных реализаций STL могу сказать следующее: SGI STL и gcc
d> STL — одно и то же, а STLport является просто мультиплатформенной
d> переделкой SGI STL. Единственный, кто действительно отличается начинкой
d> (хотя практика свидетельствует, что различия эти некритичны) — это VC STL
d> от Dinkumware.

Еще можно встретить реализацию от Rogue Wave.

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

VD>Кстати, ты бы кинул ссылку на iXbt-ешное тестирование.
Вот..
Тест SPEC CPU2000 Часть 5: компиляторы (C/C++ и Fortran)
Тест SPEC CPU2000: конфигурационные файлы сайта iXBT.com
Тест SPEC CPU2000. Часть 5: компиляторы. Дополнение 1
Тест SPEC CPU2000. Часть 5: компиляторы. Дополнение 2 — результаты работы под операционной системой Linux

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

Дык это.. продолжение-то будет?

Хочется узнать:
корректировки в связи с новыми версиями (C#, C++)
VB.NET наконец-то
F#
Delphi.NET
Mono
и последний интел на интеле

Вот... Сорри за наглость

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Еще можно встретить реализацию от Rogue Wave.

И что характерно скорости различных алгоритмов у них у всех разные.

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

В общем, спорить с тобой просто неохота. Скажу что хотели то и сравнивали. И результаты интерпретировали соотвественно тому что делали.

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

ВВ>корректировки в связи с новыми версиями (C#, C++)

Эти языки я проверял. Шарп и МС++ несколько ускорились. Обычное С++ не очень. Думается из-за того, что оптимизировали Джит, а не компиляторы.

ВВ>VB.NET наконец-то
ВВ>F#

Не знаю я эти SML-и (или что это там?).

ВВ>Delphi.NET

Нету пока ее у меня.

ВВ>Mono

Моно не тестировал, но по ощищениям он медленнее чем Шарп от МС.

ВВ>и последний интел на интеле

Видимо пора задуматься о Шутрике 4. За одно попытаться исправить те ошибки которые были ранее. И добавить несколько тестов.

Ладно. Будет время попробуем.

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

VD>Да, надо бы. Но похоже разницы с Дельфи 6 особой не будет.

Не буду вдаваться в разборки правильности тестов. Тем не менее, не поленился и сделал тесты для D7 и D8.NET. Тесты проведены на P4/2400 с 533 шиной с 512M памяти. время в миллисекундах

D8 — 7672
d7 — 8000

выставлялись все параметры проекта по умолчанию. Оптимизация включена. и там и там проекты — VCL приложения.

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

ВВ>>Delphi.NET

http://www.rsdn.ru/Forum/Message.aspx?mid=554657&amp;only=1

Автор:
Дата: 01.03.04

VD>В общем, спорить с тобой просто неохота. Скажу что хотели то и сравнивали. И результаты интерпретировали соотвественно тому что делали.

Вот и имеете то, что имеете

Режьте меня на части — не может быть JIT-язык быстрее, чем компилируемый. Ну никак! Иначе я давно бы писал на Java, которую, кстати, очень люблю. Да и C# как брата-близнеца тоже.

WH>

WH>Before MSIL can be executed, it must be converted by a .NET Framework Just In Time (JIT) compiler to native code, which is CPU-specific code that runs on the same computer architecture that the JIT compiler is running on. Because the runtime supplies a JIT compiler for each CPU architecture that the runtime operates on, developers can write a set of MSIL that can be JIT-compiled and executed on computers with different architectures. (If your managed code calls platform-specific native APIs or a class libary that is platform-specific, your code is limited to running on a specific operating system.)

Спасибо! Я-то думал, что это за технология такая — JIT.
Спрошу так — есть разница в скорости между инлайн-функцией и ее виртуальным аналогом? Что может сделать JIT с таким кодом? Второе, C++ только выполняется, а IL еще и компилируется, и профилируется, и границы проверяет. И третье, ну режьте меня — на сегодняшний день нет IL-платформы, которая бы выдержала 2Гб аллокацию с приемлимой производительностью.

Здравствуйте, <Аноним>, Вы писали:

А>Не буду вдаваться в разборки правильности тестов. Тем не менее, не поленился и сделал тесты для D7 и D8.NET. Тесты проведены на P4/2400 с 533 шиной с 512M памяти. время в миллисекундах

А>D8 — 7672
А>d7 — 8000

Не понял... экто какой тест? Может приведешь более полное описание?

Здравствуйте, <Аноним>, Вы писали:

А>Режьте меня на части — не может быть JIT-язык быстрее, чем компилируемый. Ну никак! Иначе я давно бы писал на Java, которую, кстати, очень люблю. Да и C# как брата-близнеца тоже.

А что препятствует? Не, ну, я еще понимаю аргументы о ЖЦ. Но джит? У него даже приемущество есть. Он же может оптимизировать под конкретный процессор. Уже сейчас оптимизация лучше чем у компиляторов С++ 90-ых кодов. И думаю не загорами время когда они сравняются.

Здравствуйте, <Аноним>, Вы писали:

А>Спрошу так — есть разница в скорости между инлайн-функцией и ее виртуальным аналогом?

Дотнет не ява. В нем можно смело делать не виртуальные функции. Да в общем то и Яве можно. Более того. При наличии всего исходного кода (мсила или байткода) можно проанализировать его и сделать спекулятивные предположения о том, что виртуальные вызовы излишни (а это так в 90%) и устранить их. Интересно что Ява 1.4.2 уже делает это в некоторых случаях. Об этом же написано в описании проетка Интела — Star Jit.

А> Что может сделать JIT с таким кодом?

Ответа выше достаточно?

А> Второе, C++ только выполняется, а IL еще и компилируется, и профилируется,

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

А> и границы проверяет.

А вот это уже давно не проблема. Одна из оптимизаций джита — это вынесение общих частей из гиклов. Вот и с проверками выхода за пределы циклов та же фигня. Одна проверка на цикла скорости не замедлит. За-то надежность приложения она увеличит. Несты подтверждают, что циклы по массивам встроенных типов работают в дотнете практически с той же скоростью что и в лучших компиляторах С++.

А> И третье, ну режьте меня — на сегодняшний день нет IL-платформы, которая бы выдержала 2Гб аллокацию с приемлимой производительностью.

А в чем проблема то? Поставь 3 гига на машину и дотнет займет тебе 2 как милинький. Блоки такого размера обрабатываются отдельным хипом по правилам близким к стандартым хипам С++ или ОС.

Здравствуйте, <Аноним>, Вы писали:

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

ВВ>>>Delphi.NET

А>http://www.rsdn.ru/Forum/Message.aspx?mid=554657&amp;only=1

Автор:
Дата: 01.03.04

В моем тесте было дцать отдельных тестов и конфигурация. Тут же я так и не понял что и где тестировалось.

Пара поправок.

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

VD>Дотнет не ява. В нем можно смело делать не виртуальные функции. Да в общем то и Яве можно. Более того. При наличии всего исходного кода (мсила или байткода) можно проанализировать его и сделать спекулятивные предположения о том, что виртуальные вызовы излишни (а это так в 90%) и устранить их. Интересно что Ява 1.4.2 уже делает это в некоторых случаях. Об этом же написано в описании проетка Интела — Star Jit.

Делает это не JIT, а HotSpot. Причем делает гораздо больше, чем просто раскрытие однозначно невиртуальных функций.

VD>Ну, профелируется это пого только в планах... но все же... Джит-компиляция не занимает не так много времени. Так что на скорости работы большинства программ это не отражается. Профилировка теоже не постоянно будет идти (да и ее можно выключать). За-то ее результат может существенно улучшить скорость.

В HotSpot'е профилируется уже лет эдак 4-5. И именно на основе профайл-информации некоторые виртуальные вызовы раскрываются в следующую конструкцию:

if (variable instance_of class_a)
{
   class_a.foo();  // здесь понятное дело инлайн
}else{
   variable.foo();
}

Подобная замена происходит если variable в >80% (примерно. точной цифры конечно же не знаю) является объектом класса class_a. Если в какой-то момент HotSpot поймет, что эта цифра уже не 80%, то произойдет откат оптимизации.

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

VD>Здравствуйте, <Аноним>, Вы писали:

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

ВВ>>>>Delphi.NET

А>>http://www.rsdn.ru/Forum/Message.aspx?mid=554657&amp;only=1

Автор:
Дата: 01.03.04

VD>В моем тесте было дцать отдельных тестов и конфигурация. Тут же я так и не понял что и где тестировалось.

Был выполнен один тест. Тот, исходник которого в статье. Вернее я сделал два теста, с использованием VCL и консолького приложения. Могут вот еще собрать все в таблицу:

VCL wo VCL w/o Cons wo Cons w/o
-------------------------------------------------
Delphi 8 7672 7906 7188 7200
Delphi 7 8000 8359 5625 5829


время в миллисекундах

VCL wo — VCL с оптимизацией
VCL w/o — VCL без оптимизации
Cons wo — консольное приложение с оптимизацией
Cons w/o — консольное приложение без оптимизации

В VCL приложении тестовый код выполнялся в обработчике нажатия на кнопку.

У меня просто есть возможность делать этот тест, я его сделал. Без каких-либо выводов с моей стороны.

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

SV>Сюда загляните тоже
SV>www.pi8plus.ru/algcom
результаты у меня получились несколько иные..
compilers.htm
exe'шники:
test.rar rar3.2 280кб
test.zip 980кб

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

VD>>Дотнет не ява. В нем можно смело делать не виртуальные функции. Да в общем то и Яве можно. Более того. При наличии всего исходного кода (мсила или байткода) можно проанализировать его и сделать спекулятивные предположения о том, что виртуальные вызовы излишни (а это так в 90%) и устранить их. Интересно что Ява 1.4.2 уже делает это в некоторых случаях. Об этом же написано в описании проетка Интела — Star Jit.

adb>Делает это не JIT, а HotSpot.

А что такое по твоему HotSpot?

adb> Причем делает гораздо больше, чем просто раскрытие однозначно невиртуальных функций.

Я вроде о том же.

adb>В HotSpot'е профилируется уже лет эдак 4-5.

Только тлку с него ноль. Про планы — это я про дотнет. Надеюсь там это даст лучший результат.

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

ED>Был выполнен один тест. Тот, исходник которого в статье. Вернее я сделал два теста, с использованием VCL и консолького приложения. Могут вот еще собрать все в таблицу:

ED>               VCL wo  VCL w/o  Cons wo Cons w/o 
ED>-------------------------------------------------
ED>Delphi 8        7672    7906      7188    7200
ED>Delphi 7        8000    8359      5625    5829

Про какую тогда статью речь то? Прогони тест из шустрика. Он билже к жизни. И не один. Думаю в дельфи 8 он скомпилируется без особых проблем.

VD>А что препятствует? Не, ну, я еще понимаю аргументы о ЖЦ. Но джит? У него даже приемущество есть. Он же может оптимизировать под конкретный процессор. Уже сейчас оптимизация лучше чем у компиляторов С++ 90-ых кодов. И думаю не загорами время когда они сравняются.

Препятствует практика, которая показывает, что Java уходит в глубокий своп при больших аллокациях памяти (как это было сказано в одном из сообщений выше). И что значит компиляторы С++ 90-х годов? GCC 3.3.2 и VC 7.1 свежи как розы в букете на 8 марта. Не-е-т, простите, я не понимаю, как managed код со всеми своими вносящими избыточность наворотами может быть быстрее unmanaged при устранении этой самой избыточности в run-time.

Ладно, хватит мне спорить. Я сам как-нибудь это досконально проверю, и будет тогда у народа Yet Another Comparison Paper.

logout

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

VD>>А что препятствует? Не, ну, я еще понимаю аргументы о ЖЦ. Но джит? У него даже приемущество есть. Он же может оптимизировать под конкретный процессор. Уже сейчас оптимизация лучше чем у компиляторов С++ 90-ых кодов. И думаю не загорами время когда они сравняются.

D>Препятствует практика, которая показывает, что Java уходит в глубокий своп при больших аллокациях памяти (как это было сказано в одном из сообщений выше).

Это не подтверждается опытом разработчиков использующих Ёджиби и Джэспэ.

D> И что значит компиляторы С++ 90-х годов?

То и значит.

D> GCC 3.3.2 и VC 7.1 свежи как розы в букете на 8 марта.

Видимо потому что они появились намного позже 90-ых.

D> Не-е-т, простите, я не понимаю, как managed код со всеми своими вносящими избыточность наворотами может быть быстрее unmanaged при устранении этой самой избыточности в run-time.

Да где избыточность то? Я еще соглашусь, что С++ позволяет за счет хаков оптимизировать отдельные вещи. Но на счет изсбыточности это сказки про белого бычка.

D>Ладно, хватит мне спорить. Я сам как-нибудь это досконально проверю, и будет тогда у народа Yet Another Comparison Paper.

Можеш даже присоедениться кнашим тестам и научно доказать вред этой избыточности.