@ProCxx

Страница 2461 из 2477
Andrey
24.10.2018
08:48:16
Там в Boost обсуждают как стать более привлекательными для пользователей. У кого какие идеи/пожелания?
Достичь большей модульности, чтобы таки не было зависимостей вроде multi_index -> winapi

Alex
24.10.2018
08:49:22
Разве бимап на мультииндексе сделан?
В описании написано, что да, и в зависимостях есть мультииндекс

https://www.boost.org/doc/libs/1_66_0/libs/bimap/doc/html/boost_bimap/bimap_and_boost/dependencies.html

А вот тут написано, что основан на мудьтииндексе https://theboostcpplibraries.com/boost.bimap

Google
Ilia
24.10.2018
08:57:09
Я хочу std::map с двумя или больше ключами, а они мне какого-то монстра суют. Кстати, вы им пользовались? Производительность не сравнивали с тем же std::map (в тех сценариях, на которых возможно сравнение)?
Пользовался. Блин, какоё там может быть сравнение производительности? Там O(logN) и тут O(log N) Нормальная производительность, хорошая. Никаких проблем. Проблема -- это ПОНЯТЬ это поделие и ЗАПРОГРАММИРОВАТЬ.

Alex
24.10.2018
08:59:01
Верю в логарифмическую природу реализации, но есть некоторые сомнения насчёт констант, о которых О-нотация стыдливо умалчивает

Antony
24.10.2018
09:09:51
Кстати, зависимости буста вот тут прописаны https://pdimov.github.io/boostdep-report/ (автоматом генериться)

Alexey
24.10.2018
09:13:21
шоб вам заказчики ТЗ в таком виде давали

Antony
24.10.2018
09:13:24
Там автор сайта во всю работает над уменьшением зависимостей

Andrey
24.10.2018
09:13:40
причем это прямые зависимости, некоторые из них могут подтянуть и другие
это утверждение не согласуется с тем, что написано здесь (https://pdimov.github.io/boostdep-report/master/module-weights.html), кому верить?

Egor
24.10.2018
09:15:13
решать тебе

Александр
24.10.2018
10:30:30
Подскажите, как может называться идиома/паттерн/etc: Есть пул объектов. Хочется иметь функцию, которая возвращает (магический) указатель/ссылку на объект в пуле, причем пока этот указатель/ссылка жива, любое другое обращение к пулу (в частности из другого потока) за этим же объектом будет висеть в ожидании (как на мьютексе). Вижу реализацию так: возвращать некий указателеподобный объект, который внутри себя держит ссылку на объект и ссылку на мьютекс (сам мьютекс в пуле). Соответственно лочим мьютекс на создании, освобождаем на удалении.

Andre
24.10.2018
10:31:58
Пул Караева

Александр
24.10.2018
10:47:52
Про пул можно даже забыть. Пусть есть один объект, надо получить атомарный эксклюзивный вью на него

Alexey
24.10.2018
10:49:08
не забудь сделать свой указателеподобный объект перемещаемым и не копируемым

Google
Alexey
24.10.2018
10:49:25
но вообще всё правильно говоришь

Александр
24.10.2018
10:50:14
У меня ощущение, что я придумал велосипед и это уже реализовано по 10 раз, а я просто не знаю названия

Anatoly
24.10.2018
10:50:54
@smertig Если будешь несколько таких объектов "извлекать" из пула готовься к дедлоку, либо предоставляй специальные гарды, которые упорядочивают наложение блокировки.

A.D.
24.10.2018
10:50:57
Exclusive iterator?

Spoonson
24.10.2018
10:51:19
const borrow

A.D.
24.10.2018
10:51:58
я выдумал название, если что.

Alexander
24.10.2018
10:52:01
@smertig, https://habr.com/post/328348/ — "execute around pointer", красивая идиома и реализация

A.D.
24.10.2018
10:53:03
ой-ёй, рекурсивный мьютекс звучит как "зимние вечера отладки", имхо

Anatoly
24.10.2018
10:53:45
recursive mutex в пределах потока, но да, надо бы иметь какие-то гарантии от дедлока
скорее всего тебе надо будет интерфейсно решить способ извлечения из пула нескольких объектов, тогда порядок наложения блокировки будет контролироваться тобой и дедлок не возникнет

Александр
24.10.2018
10:54:32
ой-ёй, рекурсивный мьютекс звучит как "зимние вечера отладки", имхо
Без него код будет страшным. Вообще, изначальная реализация была просто как визитирор пула с локом перед вызовом коллбэка

A.D.
24.10.2018
10:55:07
ну, я за то, чтобы спрятать такие подробности под капот интерфейса

Александр
24.10.2018
10:55:14
A.D.
24.10.2018
10:56:37
хотя я пока остановился на варианте Lockable<Container> lc, т.е. у меня клиентский код знает, что контейнер надо лочить явно.

так легче компоновать.

Александр
24.10.2018
10:57:57
Клиентский код может и знает, но надеяться на программиста стоит поменьше

всем спасибо за советы

Alexander
24.10.2018
11:27:34
касательно вчершаней темы об использовании clang вместо msvc на виндовой платформе - Firefox уже тоже использует clang для билдов на винде

Ruslan
24.10.2018
11:28:06
Андроид задепрекейтил gcc

В пользу clang

Google
Andrew
24.10.2018
11:31:21
попкорн.jpg

Alexander
24.10.2018
11:36:14
ну осталось только подождать, чтобы clang начал оптимизировать хотя бы на уровне gcc

Andrew
24.10.2018
11:41:06
Ну в отдельных вещах он и перегоняет.

Alexander
24.10.2018
11:41:57
Ну в отдельных вещах он и перегоняет.
я честно гонял довольно много бенчмарков. но так и не нашёл, где Clang был бы быстрее не на уровне погрешности

есть, правда, компилятор AOCC, который бывает заметно шустрее

шустрее для AMD процессоров, естессно

Александр
24.10.2018
11:48:41
всем спасибо за советы
Для тех, кто следил за моей проблемой: изначально необходимость в атомарном вью исходила из желания полностью забыть про вероятность состояния гонки. Но в таком случае высока вероятность получения дедлока и трудноуловимых багов (как выше подчеркнул @anatolijs). Прямо сейчас пришла в голову мысль отказаться от полного лока объекта, позволив возвращать ссылку, которая не даёт атомарный доступ к объекту, а скорее просто продлевает время его жизни, а уже конкретные поля объекта покрывать мьютексами/атомиками при надобности

Alexen
24.10.2018
11:49:37
Ну у меня лежит где-то тест где при работе с контейнерами кланг показывает более шустрый чем гцц результат, все никак не доберусь его по нормальному оформить и выкатить гццшникам втф

А ну и на арм у кланг вполне не плохой результат по коду

я честно гонял довольно много бенчмарков. но так и не нашёл, где Clang был бы быстрее не на уровне погрешности
Могу знакомого попинать на тему хайлоад, плюс тест допинать так как в этом некриминальном с первого взгляда тесте гцц таки сливает клангу очень сильно

Alexander
24.10.2018
11:56:08
надо подождать, пока в компиляторы запилят наконец-то нормальную оптимизацию динамических аллокаций

тогда всё ещё шустрее будет

Alexen
24.10.2018
11:57:19
Ну сейчас она есть но не очень как-то

Alexander
24.10.2018
11:57:29
Matway
24.10.2018
12:03:33
надо подождать, пока в компиляторы запилят наконец-то нормальную оптимизацию динамических аллокаций
Не могу себе представить более-менее не обезьяний код, где можно оптимизировать динамические аллокации. О чём речь?

Александр
24.10.2018
12:05:07
пул заранее выделен, удаления, добавления не производится в соседнем потоке?
пул - статичный массив указателей на объекты, часть элементов может быть удалена (= nullptr). собственно продление жизни ссылкой для того и нужно, чтобы соседний поток не стёр элемент, пока мы его юзаем

Александр
24.10.2018
12:07:22
не пойму, как продление осуществляется
ну не автоматически, конечно. рядом с каждым объектом кладём атомарный счетчик ссылок и удаляем только при его занулении. отличие от shared_ptr есть - тот поток, что удалил объект из пула, должен обязательно дождаться зануления счетчика ссылок

Google
Alexander
24.10.2018
12:08:23
Не могу себе представить более-менее не обезьяний код, где можно оптимизировать динамические аллокации. О чём речь?
речь о том, что компиляторы сейчас не могут даже выкинуть неиспользуемые контейнеры из функции, если они используют динамические аллокации

Alexander
24.10.2018
12:09:24
Matway
24.10.2018
12:10:09
такой код может появляться в ходе рефакторинга
То есть как промежуточный г.код?

Matway
24.10.2018
12:13:29
дыа
Ну, это то, что я называю "обезьяний код". Так получилось, что я довольно сильно выиграл от оптимизаций динамических аллокаций в LLVM. Конкретно - у нас есть высокоуровневый язык, компилятор которого не заморачиваясь генерирует IR, использующий динамические аллокации, а LLVM opt потом улучшает, что сможет. Но когда я это делал, у меня возникла мысль - а зачем же на самом деле эти оптимизации появились? Я не смог придумать примера нормального плюсового кода, который такая оптимизация сможет улучшить. Думал, у кого ещё есть такие примеры.

A.D.
24.10.2018
12:15:36
Alexander
24.10.2018
12:15:57
A.D.
24.10.2018
12:16:29
а вот об этом смотрите 2-3 ноября мой доклад на корхарде :)
какого размера должна быть функция, чтобы можно было потерять в ней контейнер? )

Alexander
24.10.2018
12:16:32
а если серьезно, то да, они этого не замечают. и да, они это будут замечать, только чуточку позже. Так как, повторюсь, данная оптимизация ещё не реализована

вот, любуйтесь ?

A.D.
24.10.2018
12:18:06
да ну, какой-то, имхо, специфический сценарий

Страница 2461 из 2477