Аннотация:
Сравнение производительности кода, сгенерированного различными компиляторами С++ на различных аппаратных платформах. За основу статьи взят материал отчета Technical Report on C++ Performance комитета WG21. Набор тестов расширен, в некоторых случаях предлагаемый код модифицирован. Приведен более подробный анализ возникающих накладных расходов.
[оффтопик]
Я конечно все понимаю, но... Где можно добыть хотя бы старые выпуски журнала... Поиск по инету показал, шо у нас в РБ его купить можно разве что только тут по цене 4$ за один единственный выпуск №6 за 2003.
Кстати высказывались как то мысли выкладывать полные статьи со старых выпусков журналов. Жаль что на том и заглохло...
[/оффтопик]
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Даже прямо как-то странно... или смешно...
Нет замеров для самого популярного в мире компилятора С++ (Visual C++)
Нет замеров для самой популярной в мире ОС (Windows)
Нет замеров для второго по популярности в мире процессора AMD x86
Что такое "Intel, 32 бита" не понятно. Толи Pentium 3, толи Pentium 4, толи Pentium Core...
Что такое "Intel, 64 бита" совсем не понятно. Толи это семейство x86-64, толи Itanium. Разница колоссальная. Ниже вроде упоминается IA-64 (название десятилетней давности).
Sun UltraSPARC-II отстаёт на два семейства от современного Sun UltraSPARC-IV.
Нет, я, конечно, когда тут замеры привожу, я тоже не всё идеально делаю, но я и статьи писать не берусь
Можно, конечно сказать, что цифры только для представления картины и максимальная точность и актуальность тут не нужна. Я не согласен. Тут нельзя когда-то что-то замерить и потом запомнить результат на 10 лет. Аппаратные и программные платформы постоянно эволюционируют. Слишком часто приходится слышать, что деления — это долго, что исключения — это медленно, что обращения к памяти — это быстро и т.д.
Вобщем я считаю, что уж если что-то мерить, то самое последнее и актуальное, потому что я не уверен, что результаты из статьи будут актуальны даже для моей сейчашней платформы...
Здравствуйте, remark, Вы писали:
R>Даже прямо как-то странно... или смешно... R>Нет замеров для самого популярного в мире компилятора С++ (Visual C++)
Видимо побоялись, что он порвёт все остальные компиляторы
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, remark, Вы писали:
R>>Даже прямо как-то странно... или смешно... R>>Нет замеров для самого популярного в мире компилятора С++ (Visual C++) AD>Видимо побоялись, что он порвёт все остальные компиляторы
Занимательные результаты в статье... По своему опыту могу сказать, что Intel генерит код, в среднем работающий быстрее чем MSVC.
Названия таблиц надо приводить над оными, а не под. То, что сейчас — нонсенс, откройте любую книгу и убедитесь(кстати, аналогичное форматирование таблиц во многих статьях RSDN. Думаю, не стОит пояснять, что это некорретно).
По содержанию — как уже отмечалось, довольно странный и скудный набор компиляторов, платформ и паттеронов теста, чтобы назвать это сравнением. Например, где тестирование различных циклов, условий с различными операндами. Ну а уж анализа просто нет вообще. Голые цифры — это не анализ. Надо разбираться — почему именно такой результат вплоть до уровня нативного кода, чтобы понять, что привело к нему в случае конкретной платформы компилятора и делать рекомендации по использованию конструкций, дабы уменьшить эти расходы. Т.е. понимать, как именно работает кодогенератор на разных уровнях. А так — это просто повышение энтропии, и ничего более
Заключение
…
Библиотека ввода-вывода C++ неизбежно будет становиться эффективнее и эффективнее.
Почему? Не разделяю ваш оптимизм.
Кстати, некоторые горе-экспериментаторы пользуясь библиотекой iostreams утверждают, что в области ввода-вывода Java обгоняет C++ .
Пётр Седов (ушёл с RSDN)
Re: Производительность компиляторов С++
От:
Аноним
Дата:
17.08.07 08:26
Оценка:
"...Производительность компиляторов С++..."
"...Сравнение производительности кода, сгенерированного различными компиляторами С++..."
Вам не кажется что это разные вещи? Производительность компилятора и производительность сгенеренного кода?
Лично меня оч. интересует 1й вопрос. Я и зашёл почитать эту статью, в надежде узнать, будет ли свет в оконце, и приблизиться ли хоть чей то компилятор по производительности к дельфи? Или так и придётся мучаться часами собирая сторонни библиотеки?
А в статье речь пошла о качестве сгенерированного кода. Имхо, название статьи надо изменить.
Здравствуйте, Аноним, Вы писали:
А>"...Производительность компиляторов С++..." А>"...Сравнение производительности кода, сгенерированного различными компиляторами С++..."
А>Вам не кажется что это разные вещи? Производительность компилятора и производительность сгенеренного кода? А>Лично меня оч. интересует 1й вопрос. Я и зашёл почитать эту статью, в надежде узнать, будет ли свет в оконце, и приблизиться ли хоть чей то компилятор по производительности к дельфи? Или так и придётся мучаться часами собирая сторонни библиотеки?
Если не устраивает скорость работы компилятора, то всегда можно скомпилировать на -O0, т.е. без оптимизаций. А если хочется чтобы код быстро работал, то уж придётся подождать. Причём trade-off уже у каждого компилятора разный — кто-то оптимизирует не очень, но работает шустро, кто-то наоборот.
У меня замечение по поводу наименования 64-битной платформы Intel. В статье фактическая ошибка — название IA-64 относится к платформе Itanium и ничего общего с x86 не имеет. Правильное название Intel64. И, конечно, не мешало бы упомянуть для какого железа происходила оптимизация и на каком железе пускались тесты.
Также вопрос по поводу версии icc — почему 9.1, а не 10.0?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>>Также вопрос по поводу версии icc — почему 9.1, а не 10.0? CC>Десятка еще сыровата
Сыровата для чего? У неё со стабильностью, на сколько я знаю, вполне всё не плохо. Но для тестов производительности это вообще не важно, поэтому производительность всегда тестируют на последних версиях компиляторов.
Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>>>Также вопрос по поводу версии icc — почему 9.1, а не 10.0? CC>>Десятка еще сыровата
БД>Сыровата для чего? У неё со стабильностью, на сколько я знаю, вполне всё не плохо. Но для тестов производительности это вообще не важно, поэтому производительность всегда тестируют на последних версиях компиляторов.
Неделю-две назад было еще пару существенных багов в компилере... Последняя стабильная версия 9.1.038.
Может уже конечно и исправили...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Неделю-две назад было еще пару существенных багов в компилере... Последняя стабильная версия 9.1.038. CC>Может уже конечно и исправили...
1. при чём тут стабилити баги, когда нас интересует производительность?
2. в девятке ошибок тоже хватает. Просто о них не все знают, тоже самое и в десятке. Интересно, что вы имеете ввиду под багами?
ССР>Авторы: ССР> sergesatsky ССР> twinpeek
ССР>Аннотация: ССР>Сравнение производительности кода, сгенерированного различными компиляторами С++ на различных аппаратных платформах. За основу статьи взят материал отчета Technical Report on C++ Performance комитета WG21. Набор тестов расширен, в некоторых случаях предлагаемый код модифицирован. Приведен более подробный анализ возникающих накладных расходов.
Написали бы статью о производительности программистов С++ и как эту производительность улучшить.
ССР>Авторы: ССР> sergesatsky ССР> twinpeek
ССР>Аннотация: ССР>Сравнение производительности кода, сгенерированного различными компиляторами С++ на различных аппаратных платформах. За основу статьи взят материал отчета Technical Report on C++ Performance комитета WG21. Набор тестов расширен, в некоторых случаях предлагаемый код модифицирован. Приведен более подробный анализ возникающих накладных расходов.
В формуле на рис.1 [Рисунок 1. Среднее геометрическое (СГ) соотношений времени вычисления суммы чисел с плавающей точкой] T0 можно вынести за знак корня (при условии, что базовые значения T0...T12 сохранены на момент вычисления СГ). Оптимизация!
Судя по статье, Intel C++ вообще плохой компилятор, да ещё и платный (под Windows) Какой смысл тогда его использовать?
Мой опыт использования Intel C++ говорит о том, что по сравнению с Visual C++, кода Intel генерирует неприлично много (раз в 10 больше), а скомпилированная программа работает в полтора раза медленнее.
Здравствуйте, Aleх, Вы писали:
A>Мой опыт использования Intel C++ говорит о том, что по сравнению с Visual C++, кода Intel генерирует неприлично много (раз в 10 больше), а скомпилированная программа работает в полтора раза медленнее.
Здравствуйте, Бабокин Дмитрий, Вы писали:
БД>Здравствуйте, Aleх, Вы писали:
A>>Мой опыт использования Intel C++ говорит о том, что по сравнению с Visual C++, кода Intel генерирует неприлично много (раз в 10 больше), а скомпилированная программа работает в полтора раза медленнее.
БД>Может ещё и пример покажешь на котором медленее?
Много кода. Не буду же я весь выкладывать. Ну то есть, отдельных маленьких тестов я не проводил. Просто скомпилировал проект, который делал в студии.
Могу только сказать, что интенсивно использовал шаблоны.
Как я понимаю, Intel C++ может генерировать код лучше, если программа написана почти на Си, ну и в основном состоит из арифметических операций с числами.
Например, я могу сказать, что ещё пробовал компилировать графическую библиотеку AGG. Без профилированных оптимизаций скорость скомпилированной программы была такая же как и на Visual C++. С ними — примерно на 20 процентов быстрее. Но это тоже не особо хорошая оптимизация, учитывая то, что как заявлено, Intel C++ умеет оптимизировать под SIMD. 20 процентов в скорости работы программы пользователю заметить очень сложно.
PS Если сделаю небольшой тестовый пример, на котором медленнее, обязательно выложу.
Aleх wrote:
> Как я понимаю, Intel C++ может генерировать код лучше, если программа > написана почти на Си, ну и в основном состоит из арифметических операций > с числами.
Я как-то давно, года два назад, наверное... компилировал им libxml2/libxslt — работало процентов на 30, не меньше, быстрее.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Aleх, Вы писали:
A>Мой опыт использования Intel C++ говорит о том, что по сравнению с Visual C++, кода Intel генерирует неприлично много (раз в 10 больше), а скомпилированная программа работает в полтора раза медленнее.
А у меня есть опыт, когда VC8 (VS2005) компилирует неприлично долго и сгенерированный код работает гораздо медленней по сравнению с BCB5. Более чем в 2 раза. Это точно. А по-моим субъективным ощущениям — в 10 раз. И, если мне не изменяет память, с компиляцией на VS2003 все будет гораздо хуже.
Таким образом получаем, что BCB5 — абсолютный чемпион
Здравствуйте, Aleх, Вы писали:
A>Мой опыт использования Intel C++ говорит о том, что по сравнению с Visual C++, кода Intel генерирует неприлично много (раз в 10 больше), а скомпилированная программа работает в полтора раза медленнее.
Мой опыт говорит о том, что Intel рвет вижуалку раза в два на вычислительных задачах. Конкретно: криптография.
Код генерит медленнее, inline пользует интенсивнее — отсюда разный размер кода.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
(при условии, что базовые значения T0...T12 сохранены на момент вычисления СГ). Оптимизация! 
