Аннотация:
К тому времени, когда мы занялись написанием этого теста (а вернее, отбросили около пяти вариантов из-за их непригодности) подоспели Borland C++ Builder 6.0 (BCB) и релиз VS.Net (VS7, т.е. входящие в него VC7 и C#). Естественно, что мы с радостью протестировали и их.
Ниже приведены их результаты и результаты выполнения нашего нового Float-теста.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
То что этот компилятор работает не хуже других на Athlon — это уже показатель. Бо он его поддерживает. Если же проводить тесты на Intel машинах, то полагаю, ситуация существенно изменится (это как сравнение C# с ngen и без него).
Жизнь, как игра —
идея паршивая,
графика обалденная...
В свое время на лабах по Архитектуре высокопроизводительных процессоров мы писали фичи примерно такой сложности. Часто даже процессор не играл роли в быстродействии.
Необходимо задать реальный тест — обработка звука,изображения,видео.
Такой тест, нпример, как вызов виртуального метода в цикле не дает никакого представления о качестве компиляции. Нужно вызывать чтото более реальное.
Если сравнивать вызовы PostMessage и SendMessage, то часто можно наблюдать ситуацию,когда PostMessage вызывается в разы дольше при одинаковых условиях.
Единственный тест нормальный — это сортировки.
Но из-за модели многозадачности Windows секундные результаты тестов — это ерунда.
Необходима часовая загрузка с прибиванием всяких дрянных сервисов.
Вот здесь выльется траблы с Джавой — при использовании памяти время начнет жрать ее Гарбэдж-коллектор. А реальный алгоритмы оптимизации графов из нескольких тысяч узлов, линков и всякой дряни покажут отставание минимум в пять раз.
Неделя на С++ и больше месяца на Джава — это результат !
К примеру — проект, где я работаю, обсчитывает граф иногда по несколько недель при максимальм использовании памяти — до 2 Gb. Джава, скорее всего, уйдет в своп, аки дети в школу.
Гы! Кульно! По-моему я на iXbt видел сравнительные тесты компиляторов под win32. Там, конечно, посерьезнее к этому подходили и результаты явно отличались. Я очень хорошо запомнил, что именно на float тестах Intel компилятор с P4 оптимизацией показывал результаты в !НЕСКОЛЬКО! раз выше bcc. И дельфи почти везде красовалась на последнем месте, иногда уступая свое место яве. Ну там, конечно, не строки RTL библиотек сравнивали :-) И все-таки сравнивать Яву с C++ очень пошло, т.к. результаты работы ява приложений скорее зависят не от компилятора :)
2Автор: Звиняй за прямоту — просто слишком уж фантастические у тебя результаты, хотя, с такими условиями все возможно.
p.S.> Очень рекомендую ознакомиться с условиями тестирования компиляторов, которых придерживались другие авторы подобных научных работ. Вы будете удивлены тому, что не так все просто :)
With Best Regards, Robert Y. Tarasow
RealTimeTech Inc, Multimedia Team
Ребят, ну существуют же определенный ГОСТы и нормативы по поводу тестирования компиляторов. Ну сложение флоатов в цикле — это уже ни в какие ворота не лезет. Особенно мне понравилось тестирование Intel компилятора на Атлоне ;) Или еще лучше — это тесты одной строчки кода в цикле ;)
With Best Regards, Robert Y. Tarasow
RealTimeTech Inc, Multimedia Team
Немного не понятно 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.
>Необходимо задать реальный тест — обработка звука,изображения,видео.
И что в этом реального? Обработка видео и звука — это давно область применения SIMD-инструкций и ручной оптимизиации. Ну, и главное, что этими задачами занимаются 0.01% людей.
>Такой тест, нпример, как вызов виртуального метода в цикле не дает никакого представления о качестве компиляции.
Этого и не утвержалось. Но интересно было посмотреть и на эти результаты.
>Если сравнивать вызовы PostMessage и SendMessage, то часто можно наблюдать ситуацию,когда PostMessage вызывается в разы дольше при одинаковых условиях.
А причем тут это? PostMessage и SendMessage — это разные алгоритмы посылки сообщений в виндовс. Мы же не сравниваем расчет Pi и быструю сортировку?
>Единственный тест нормальный — это сортировки.
А чем ненормален тот же расчет Pi или конкатенация строк?
>Но из-за модели многозадачности Windows секундные результаты тестов — это ерунда.
Вот не обоснованные выводы — это точно ерунда. А результаты вполне повторяемые. Вам шашечки или ехать?
>Вот здесь выльется траблы с Джавой — при использовании памяти время начнет жрать ее Гарбэдж-коллектор.
Ява и на малых объемах показала результаты работы с памятью куда хуже чем та же Дельфи. Но про долгострочную перспективу вы точно заблуждаетесь. Как раз при долгострочной работе GC дает преимущество, так как только алгоритм сборки мусора может обеспечить поддержание памяти в нефрагментированном состоянии.
>А реальный алгоритмы оптимизации графов из нескольких тысяч узлов, линков и всякой дряни покажут отставание минимум в пять раз.
Чтобы это утверждать, сначало нужно провести такой эксперимент. Пришлите нам алгоритм и исходный граф, который вы считаете "реальными", мы перепишем его на все тестируемые языки и проверим в действии. К тому же, для Явы это далеко не так плохо. Совсем недавно за счастье можно было считать десятикратное отставание.
>Неделя на С++ и больше месяца на Джава — это результат !
Я бы сказал, что такие задачи сами по себе являются уникальными и требуют чуть ли не ручной оптимизации на асме.
>Джава, скорее всего, уйдет в своп, аки дети в школу.
Вот слова "скорее всего" мы как раз и не можем допускать. Поймите, воспроизвести, к примеру, ваш проект на Яве (а тем более на всех остальных подопытных языках) да еще так, чтобы можно было говорить об адекватности примененных алгоритмов, физически невозможно. Именно поэтому приходится пользоваться короткими легко проверяемыми тестами.
Нашей целью было дать проверенную информацию, чтобы люди не основывали свои расуждения на слухах и предрассудках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>Необходимо задать реальный тест — обработка звука,изображения,видео.
И что в этом реального? Обработка видео и звука — это давно область применения SIMD-инструкций и ручной оптимизиации. Ну, и главное, что этими задачами занимаются 0.01% людей.
>Такой тест, нпример, как вызов виртуального метода в цикле не дает никакого представления о качестве компиляции.
Этого и не утвержалось. Но интересно было посмотреть и на эти результаты.
>Если сравнивать вызовы PostMessage и SendMessage, то часто можно наблюдать ситуацию,когда PostMessage вызывается в разы дольше при одинаковых условиях.
А причем тут это? PostMessage и SendMessage — это разные алгоритмы посылки сообщений в виндовс. Мы же не сравниваем расчет Pi и быструю сортировку?
>Единственный тест нормальный — это сортировки.
А чем ненормален тот же расчет Pi или конкатенация строк?
>Но из-за модели многозадачности Windows секундные результаты тестов — это ерунда.
Вот не обоснованные выводы — это точно ерунда. А результаты вполне повторяемые. Вам шашечки или ехать?
>Вот здесь выльется траблы с Джавой — при использовании памяти время начнет жрать ее Гарбэдж-коллектор.
Ява и на малых объемах показала результаты работы с памятью куда хуже чем та же Дельфи. Но про долгострочную перспективу вы точно заблуждаетесь. Как раз при долгострочной работе GC дает преимущество, так как только алгоритм сборки мусора может обеспечить поддержание памяти в нефрагментированном состоянии.
>А реальный алгоритмы оптимизации графов из нескольких тысяч узлов, линков и всякой дряни покажут отставание минимум в пять раз.
Чтобы это утверждать, сначало нужно провести такой эксперимент. Пришлите нам алгоритм и исходный граф, который вы считаете "реальными", мы перепишем его на все тестируемые языки и проверим в действии. К тому же, для Явы это далеко не так плохо. Совсем недавно за счастье можно было считать десятикратное отставание.
>Неделя на С++ и больше месяца на Джава — это результат !
Я бы сказал, что такие задачи сами по себе являются уникальными и требуют чуть ли не ручной оптимизации на асме.
>Джава, скорее всего, уйдет в своп, аки дети в школу.
Вот слова "скорее всего" мы как раз и не можем допускать. Поймите, воспроизвести, к примеру, ваш проект на Яве (а тем более на всех остальных подопытных языках) да еще так, чтобы можно было говорить об адекватности примененных алгоритмов, физически невозможно. Именно поэтому приходится пользоваться короткими легко проверяемыми тестами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Поверь. Мы сам не знали что результаы будут именно такими. Небыло уна и заление чего-нибудь шибко умное залепить. Просто хотелось посмотреть на, что способны компиляторы в нашей повседневной жизни. Другие сравнения они какие-то комплексные. Из них не ясно что в коомпиляторе хоршо, а что не. Тут же все по полочкам...
Кстати, ты бы кинул ссылку на iXbt-ешное тестирование.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Виноват. Снимаю предыдущее замечание. Я оказался не прав. BCB не использует коммандный компилятор bcc, а загружает comp32p.dll — Borland C/C++ Compiler DLL с такими же версиями, что и у коммандного компилятора bcc, Так что bcb и bcc — это действительно разные компиляторы.
