Цитата(phprus @ 7.8.2011, 14:59  ) |
| Интересно, что в случае отключения оптимизации (-O0) ошибка уходит |
походу это не столько глюк буста, сколько глюк
| Цитата(phprus @ 7.8.2011, 14:59 ) |
| Intel Composer XE 12 Update 4 (12.0.4) |
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > Ошибка сегментирования в Boost.ASIO signal 1.47 |
| Автор: phprus 7.8.2011, 14:59 | ||
| Доброго времени суток! В библиотеке Boost.ASIO 1.47 появились средства для работы с системными сигналами (man 2 signal). Но при попытке реализовать обработчик сигналов с использованием этой библиотеки я получаю ошибку сегментирования при использовании компилятора Intel Composer XE 12 Update 4 (12.0.4) и флагов оптимизации "-O3 -funroll-loops -fomit-frame-pointer". Судя по отладчику ошибка возникает в файле boost/asio/detail/signal_handler.hpp:67, это строка:
Но из-за оптимизации отладчик мало что показывает (например, параметры переданные в do_complete показываются неправильные). Интересно, что в случае отключения оптимизации (-O0) ошибка уходит, так-же ошибка не наблюдается при использовании gcc 4.1.2, 4.3.4, 4.5.0, 4.6.1(MinGW) и Intel C++ Compiler 11.1. Если в файле boost/asio/detail/signal_handler.hpp после строки "boost::asio::detail::fenced_block b;" добавить отладочный вывод на экран или sleep(0), то ошибка тоже пропадает. Подскажите пожалуйста идеи по методам дальнейшей отладки Boost для совместимости с компилятором Intel. |
| Автор: boostcoder 7.8.2011, 15:20 |
| а в список рассылки boost написать не пробовал? |
| Автор: phprus 7.8.2011, 18:25 | ||
| Знаний английского для свободного общения в списках рассылка не хватает. Писать/говорить по английски я почти не умею (грубо говоря, так и не научился). Когда написал пост, возникла мысль проверить во что разворачивается boost::asio::detail::fenced_block.
Так вот, в случае GCC срабатывает gcc_sync_fenced_block, а в __INTEL_COMPILER - gcc_x86_fenced_block, хотя __INTEL_COMPILER >= 1100 поддерживает реализацию, которую использует gcc_sync_fenced_block и при использовании gcc_sync_fenced_block приложение не падает (патч во вложении, багрепорт сочиню чуть позже). Остается вопрос, для чего в обработчиках используется fenced_block и почему это имеет такие последствия. |
| Автор: boostcoder 7.8.2011, 19:11 |
| этот баг появился только в версии 1.47.0 ? |
| Автор: volatile 7.8.2011, 19:48 | ||||
походу это не столько глюк буста, сколько глюк
|
| Автор: phprus 7.8.2011, 20:30 |
| boostcoder Обработчик системных сигналов в ASIO появился только в 1.47.0, по этому да. Хотя код в обработчиках операций сокетов аналогичный, но там подобные проблемы не проявляется на всем моем зоопарке компиляторов. volatile, возможно, но приведенное решение этот баг исправляет или скрывает. А так как оптимизирует компилятор Intel значительно лучше чем GCC, то приходится поддерживать и его. |
| Автор: boostcoder 7.8.2011, 21:29 | ||
правда?  |
| Автор: phprus 7.8.2011, 21:55 | ||
Да. Сталкивался с различием в скорости готового кода примерно до 1,5 раз. К примеру использовать SSE(SIMD) инструкции в коде числосчитающих алгоритмов у компилятора от Intel получается лучше, чем у GCC. Также субъективно у компилятора от Intel инлайнить код получается лучше, чем у GCC (субъективно, так как не знаю как это можно объективно оценить). |
| Автор: boostcoder 7.8.2011, 22:20 |
| phprus, интересно бы посмотреть на сравнительные тесты от какой-то компании. надо погуглить.. зы зато LTO и Graphite оптимизаторы есть только у GCC. LTO к примеру, повышает скорость работы не в 1.5 раза, а в среднем 9-12 раз  сам проверял.можешь проверить по этой методике: http://kemiisto.blogspot.com/2010/09/lto.html там видно прирост в ~6 раз. я же, на своих http://code.google.com/p/mingw-builds/downloads/list, на виртуалке, получаю прирост ~9 раз. на реальной машине WinXP - 11. так что интел отдыхает.. как и микрософт... |
| Автор: volatile 8.8.2011, 00:08 | ||||||||
LTO (Link-Time Optimization) у студии есть, называется только оно так: Enable link-time code generation (/GL) Не поленился, взял код с блога Кемисто, откомпилил на студии Результат без /GL:
Результат c /GL:
Как видно, LTO повышает скорость работы данного кода в 7.78 раз. Доведя его до абсолютного равенства 1.734==1.734. Т.е дальше здесь оптимизировать (в этом плане) уже нечего. Добавлено через 2 минуты и 28 секунд
Если что накопаете, скиньте ссылки. Тоже интересно посмотреть. |
| Автор: boostcoder 8.8.2011, 00:17 | ||
не знал..  вообще, похоже многие не знают. ибо со всеми с кем обсуждал, никто не сказал что в студии тоже есть link-time-optimization. Добавлено через 9 минут значит теперь он и у gcc есть  |
| Автор: phprus 8.8.2011, 08:05 | ||
У меня RedHat 5 и штатный GCC 4.1.2 для сравнения, еще есть SLES 11, там GCC 4.3.4, что не многим новее и LTO там нет :( Хотя и интел на RedHat не самый свежий - 11.1 и 12.0.4 на SUSE. А для разработки у меня openSUSE c ICC 12.0.4 и GCC 4.5.0, но даже на ней заметен прирост скорости у Intel. Кроме того прирост порядка 1,5 именно на числосчиталках вида весь код в одном cpp. Там LTO применять просто негде. А вообще мысль интересная, надо еще раз сравнить производительность своего кода, а не только расчетных приложений вдруг что изменилось с последних тестов. |
| Автор: xvr 8.8.2011, 13:54 | ||
Гы. У Intel компилятора это называется IPO и есть еще с версии 8.1 (а может и раньше) Добавлено через 2 минуты и 7 секунд PS. Функциональность Graphite похоже в Intel компиляторе тоже есть (масса loop оптимизаций, включая автораспараллеливание) Добавлено через 3 минуты и 35 секунд PPS. Скорость можно посмотреть на сайте SPEC (http://www.spec.org/cpu2006/results/) |
| Автор: boostcoder 8.8.2011, 14:14 |
сказывается неиспользование msvc и intel  |
| Автор: phprus 8.8.2011, 19:09 |
| Похоже все таки это баг Boost: https://svn.boost.org/trac/boost/ticket/5763 |
| Автор: boostcoder 8.8.2011, 19:18 |
phprus, маладца!  |