Доброго времени суток!

В библиотеке 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.

а в список рассылки boost написать не пробовал?

Знаний английского для свободного общения в списках рассылка не хватает.
Писать/говорить по английски я почти не умею (грубо говоря, так и не научился).

Когда написал пост, возникла мысль проверить во что разворачивается 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 и почему это имеет такие последствия.

Присоединённый файл ( Кол-во скачиваний: 5 )
 boost_1_47_0_intel_segfault_in_asio_signal.diff.txt 2,71 Kb

этот баг появился только в версии 1.47.0 ?

походу это не столько глюк буста, сколько глюк

boostcoder
Обработчик системных сигналов в ASIO появился только в 1.47.0, по этому да.
Хотя код в обработчиках операций сокетов аналогичный, но там подобные проблемы не проявляется на всем моем зоопарке компиляторов.

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

Это сообщение отредактировал(а) phprus - 7.8.2011, 20:42

правда?  

Да. Сталкивался с различием в скорости готового кода примерно до 1,5 раз.
К примеру использовать SSE(SIMD) инструкции в коде числосчитающих алгоритмов у компилятора от Intel получается лучше, чем у GCC. Также субъективно у компилятора от Intel инлайнить код получается лучше, чем у GCC (субъективно, так как не знаю как это можно объективно оценить).

phprus, интересно бы посмотреть на сравнительные тесты от какой-то компании. надо погуглить..

зы
зато LTO и Graphite оптимизаторы есть только у GCC. LTO к примеру, повышает скорость работы не в 1.5 раза, а в среднем 9-12 раз  сам проверял.
можешь проверить по этой методике: http://kemiisto.blogspot.com/2010/09/lto.html
там видно прирост в ~6 раз. я же, на своих собственноручно собранных mingw`ах, на виртуалке, получаю прирост ~9 раз. на реальной машине WinXP - 11.
так что интел отдыхает.. как и микрософт...

Это сообщение отредактировал(а) boostcoder - 7.8.2011, 22:21

 
LTO (Link-Time Optimization) у студии есть, называется только оно так:
Enable link-time code generation (/GL)

Не поленился, взял код с блога Кемисто, откомпилил на студии
Результат без /GL:


Результат c /GL:


Как видно, LTO повышает скорость работы данного кода в 7.78 раз.
Доведя его до абсолютного равенства 1.734==1.734. Т.е дальше здесь оптимизировать (в этом плане) уже нечего.

Добавлено через 2 минуты и 28 секунд

Если что накопаете, скиньте ссылки. Тоже интересно посмотреть.

не знал..  
вообще, похоже многие не знают. ибо со всеми с кем обсуждал, никто не сказал что в студии тоже есть link-time-optimization.

Добавлено через 9 минут
значит теперь он и у gcc есть  

У меня 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 применять просто негде.

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

Гы. У Intel компилятора это называется IPO и есть еще с версии 8.1 (а может и раньше)

Добавлено через 2 минуты и 7 секунд
PS. Функциональность Graphite похоже в Intel компиляторе тоже есть (масса loop оптимизаций, включая автораспараллеливание)

Добавлено через 3 минуты и 35 секунд
PPS. Скорость можно посмотреть на сайте SPEC (SPECCPU)

сказывается неиспользование msvc и intel  

Похоже все таки это баг Boost: https://svn.boost.org/trac/boost/ticket/5763