LINUX.ORG.RU
Форум — Development  

Profiler и shared_ptr

 , ,


0

1 
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 23.96      1.04     1.04 94875867     0.00     0.00  boost::detail::atomic_increment(int*)
 22.35      2.01     0.97 103405863     0.00     0.00  boost::detail::atomic_exchange_and_add(int*, int)
 10.83      2.48     0.47   220469     0.00     0.00  boost::detail::shared_count::~shared_count()
  8.41      2.85     0.36      577     0.00     0.00  boost::detail::shared_count::shared_count(boost::detail::shared_count const&)
  8.29      3.21     0.36 98935041     0.00     0.00  boost::detail::sp_counted_base::release()
  3.46      3.35     0.15 95010731     0.00     0.00  boost::detail::sp_counted_base::add_ref_copy()

Говорит ли это о том, что shared_ptr используется неправильно? Судя по atomic_increment(), там 5 asm инструкций. Почему gprof выдаёт такой overhead?

★★★★★
← Появился ещё один форк Perl: cperl 5.22.1
Глобальные объекты →

Мое ИМХО, shared_ptr нужно использовать только там, где это действительно нужно. В остальных случаях unique_ptr.

panter_dsd ★★★★
()

Скорее всего это говорит о том, что данный код ничего кроме этих атомарных операций не делает.

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

Вероятно, я недопонял выхлоп gprof'a.. пойду курить callgraph ниже в отчёте..

UVV ★★★★★
() автор топика

Откуда там пять инструкций в atomic_increment? Всю жизнь была одна, но с lock-префиксом, который при отсутствии данных в кэше устанавливает сигнал LOCK# и блокирует шину, что даёт просто охрененный пенальти.

mix_mix ★★★★★
()
Ответ на: комментарий от mix_mix

Всю жизнь была одна, но с lock-префиксом, который при отсутствии данных в кэше устанавливает сигнал LOCK# и блокирует шину, что даёт просто охрененный пенальти.

Ok, был не прав. А что подразумевается под пенальти? Можно поподробнее?

UVV ★★★★★
() автор топика
Ответ на: комментарий от UVV

The Intel 64 and IA-32 Architectures Software Developer's Manual - Volume 3A: System Programming Guide, Part 1

7.1.4 Effects of a LOCK Operation on Internal Processor Caches.

For the Intel486 and Pentium processors, the LOCK# signal is always asserted on the bus during a LOCK operation, even if the area of memory being locked is cached in the processor.

For the P6 and more recent processor families, if the area of memory being locked during a LOCK operation is cached in the processor that is performing the LOCK operation as write-back memory and is completely contained in a cache line, the processor may not assert the LOCK# signal on the bus. Instead, it will modify the memory location internally and allow [its] cache coherency mechanism to insure that the operation is carried out atomically. This operation is called «cache locking.» The cache coherency mechanism automatically prevents two or more processors that have the same area of memory from simultaneously modifying data in that area. (emphasis added)

mix_mix ★★★★★
()

Потому что атомные инструкции могут стоить несколько сот циклов каждая.

abacaba ★
()
Ответ на: комментарий от Sorcerer

Sorcerer

Скорее всего это говорит о том, что данный код ничего кроме этих атомарных операций не делает.

Поддержу.

ТС, я надеюсь ты не используешь их везде. Умные указатели по идее использовать надо когда нужно передать (или расшарить) владение объектом. В остальных случаях обычные указатели.

jeuta ★★★★
()

gprof - говно. Выбрось каку. Возьми oprofile или perf.

rupert ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Появился ещё один форк Perl: cperl 5.22.1
Development
Глобальные объекты →