Производительность shared_ptr

В shared_ptr атомарный счетчик ссылок, который избыточен, если объекты используются в пределах одного потока. Можно использовать другой умный указатель с неатомарным счетчиком, например, intrusive_ptr из boost, или свой написать.

Не вижу объявления a в сишарпном коде.

Нативный еxe-шничек (3 МБ), сгенерированный под .NET 7 так же быстро выполняется. Сборка мусора там реализована.

Добавил. Но там неинтересно. Класс пустой. Конструктор пустой.

try -O3, Lucke

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

try -O3, Lucke

В приведенном коде нет ничего, что могло бы даже в теории ускориться от -O3.

Если нужен именно GC, а не подсчет ссылок, то для плюсов это тоже есть

метапрогу как то удалось

Ему удалось всё, кроме будильника.

В теории он может выкинуть этот цикл нафик. На практике мне проверять лень.

I love .NET!

потому что вы мало знаете… так бывает.

std::weak_ptr<DemoClass>b = a;

А там точно C# не выкинул твой цикл, потратив 65мс тупо на инициализацию всякого барахла в main?

А так да, бездумное использование shared_ptr в современном плюсовом коде это провал. В том же Rust додумались сделать 2 типа счётчиков ссылок в стандартной библиотеке (Rc, Arc).

На Си++ ты всегда можешь сам сделать сборщик мусора.

А так да, бездумное использование shared_ptr

boost::local_shared_ptr?

Я, кстати, знаю кто это писал, и по чьему запросу ;)

Да миллион васянских реализаций есть. Но нужно std::, иначе толку мало.

Да миллион васянский реализаций есть.

Кгхм. Могу только пожелать удачи проталкивания своих патчей в boost. Да.

Проблема не в сложности проталкивания в буст (снимаю шляпу), а в том, что не все его используют. У каждой более-менее крупной конторы есть свой собственный буст (abseil, chromium, llvm, folly, аркадия, блумберг, итд итп), и их не скрестишь вместе. А умный указатель это такая штука, которая протекает наружу через хедеры.

Вообще я сторонник intrisuve_shared_ptr. В большинстве случаев автор класса знает, как его будут использовать (по значению, ссылке или умному указателю). И нет смысла навешивать это свойство извне.

Проблема не в сложности проталкивания в буст (снимаю шляпу)

For the record - патч не мой, и не с моей подачи (чужие лавры мне не нужны). Но я прекрасно знаю по чьему запросу было сделано, и зачем.

Запустил плюсовый тест, 37 нс. И чо?

Вопрос только один: нахрена в твоем примере шаред пойнтер. А если хочешь взрывозащищенных тормозов в шарпе, чего слова из песни выкидывать — ну так вкрячивай в цикл честный лок через интерлокед на запись b:) и бред про асиливание gc не при чем --- теплое с мягким.

Вопрос только один: нахрена в твоем примере шаред пойнтер

Честно скажу - не смотрел.

Вопрос в другом: там «new» наверняка очень сильно тяжелей самого shared_ptr. О чём разговор?

О том что наброс кривой, сравнение яблок с апельсинами :)

А почему ты пишешь не на сишке?

А зачем тебе копироовать 1000000 раз shared_ptr? Его копирование фактически означает что-то вроде «захвата ресурса», чтобы твой объект не выпилился.

Но это нужно делать только когда есть угроза этого самого выпиливания. Например, сохранить в поле класса/глобальную переменную, которая переживёт скоуп исходной переменной.

Внутри алгоритма, если известно, что кто-то уже держит умный указатель, дальше используются обычные ссылки/указатели. Тебе плюсы дают более точное управление оверхедом, а ты забиваешь гвозди микроскопом.

Кроме того, нужно сделать бенчмарки на последних версиях Java. Тогда C++ окончательно и бесповоротно самозакопаются в могилу, забив все гвозди и заварив все щели.

Включая весь софт, написанный на этом недоязычке

Ты бы на машкодах ещё бы предложил.

Мальчик, в программах объекты постоянно присваиваются друг другу, добавляются в разные списки, ассоциативные массивы и т.д. В нормальных языках управлением жизни объектов занимается сборщик мусора. Ибо ООП без сборщика мусора это как машина без дворников…

Фперед, делайте. Но поскольку качество этих «бенчмарков» будет таким же гавенным как и того что выше, то это все так же будет ни о чем.

Собственно все тут уже поняли что Вы любите .NET (звучит как пропаганда ЛГБТ почти что) и ничего не понимаете в обсуждаемой теме. Так что переубедить Вы никого не сможете, а вот опозориться сильнее чем уже опозорились - вполне…

Программы очень разные бывают. И уповать на gc могут только обладатели кривых ручонок, тотальное решение всех проблем дизайна через gc просто приводит тормозам на ровном месте. Вот прямо как в .NET, да-да.

Причем тут уповать или нет. На C# написать тормознутый код еще надо умудриться. А на C++ пожалуйста. Постоянные копирования объектов. Неэффективный shared_ptr, который тоже копируется. А в .NET указатели на объекты вообще могут в регистриках храниться. И все архибыстро. Неэффективность не размазана по всему коду, а сборщик мусора подсчитывает ссылки лишь изредка, во время сборки мусора.

Стеклянный хуй разбить и порезать руки — это про тебя :)

Опытный

Всё, пацаны, пистец, удача из цпп уходит …

Но почему, но почему
Расстаться всё же нам пришлось,
Ведь было всё у нас всерьёз 15-го марта пля?

C# написать тормознутый код еще надо умудриться. А на C++ пожалуйста

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

Опытный

Да я верю что ты опытный испытатель стеклянных хуев :) но только их и троллинга тупостью.

На C# написать тормознутый код еще надо умудриться. А на C++ пожалуйста.

Да, на С++ надо уметь писать, там порог вхождения выше чем на С#. Зато правильно написанный на плюсах код рвет шарпы как тузик грелку. Но Вы, очевидно, такой написать не сможете - поэтому радуйтесь шарпам, они для Ваших хэллоуворлдов самое оно. Хотя мне кажется вижуал бейсик Вам бы лучше подошел;-)

Пока плюсатник будет думать, что ему взять: ссылку, константную ссылку, умный указатель или просто класс, шарпист и явист уже напишут читабельный, быстрый и безопасный код

Все так, если программу можно написать на C# или другом высокоуровневом языке, то не стоит писать ее на С, C++, Rust.

Нуб типа тебя не напишет примерно ничего ни на чем.

Напишут. Безопасный и читаемый, но нифига не быстрый. Именно потому что для написания быстрого кода надо думать и знать что под капотом у всех этих указателей.

Главное – успеть написать правильно написанный плюсовый код до того, как у проекта исчерпается бюджет.

С учётом того, что shared_ptr не работает с циклическими ссылками, в программах на плюсах принято иметь некую иерархию объектов кто кем владеет. В целом в нормально спроектированной программе вряд ли будет 1000000 владельцев одним объектом, которым обязательно нужно это владение документально оформить.

В проектах где я участвую код на яве/шарпах не успеет досчитать до того момента как у проекта закончится бюджет…

Ты где-нибудь видел этот «правильный» код на C++?

Абсолютно везде, от HTML-движков до видеоигр - говно размазанное по умным указателям. Которое течет, глючит и тормозит.

Видел, мы такой пишем. И не только мы.

Абсолютно везде…

4.2, причём лютое. Вы, очевидно, не могли видеть весь код написанный в мире. Но Ваше заявление говорит о Вас лично - Вы не видели в жизни ничего кроме говнокода или Вы воспринимаете любой код как говнокод. Я конечно соболезную (и Вам и Вашим коллегам/работодателям), но причём тут С++?!

Но Ваше заявление говорит о Вас лично - Вы не видели в жизни ничего кроме говнокода или Вы воспринимаете любой код как говнокод.

Типичный лиспер, что с него взять :)

Включая весь софт, написанный на этом недоязычке

.NET и Java написаны на С++.

По крайней мере ключевые их части.

Вот статистика по .NET

C# 79.5%
C++ 10.6%
C 8.0%

Ты где-нибудь видел этот «правильный» код на C++?

На userver например можешь посмотреть. Там всё вполне не плохо.

Погабе тоже на крестах написан

if (waiter != kNotSignaledState) {
    WakeUpWaiter(*reinterpret_cast<impl::TaskContext*>(waiter));
  }

…

private:
  std::atomic<std::uintptr_t>& state_;
  impl::TaskContext& current_;

Опять указатели. При этом поле это ссылка. Видать, пытались преодолеть уродство крестов, но так и не получилось. Руки опустились :)