res2001,
В итоге получилось почти как и задумывал вначале, только оказалось, что для указания библиотек Boost есть стандартная переменная BOOST_LIBRARYDIR. Теперь команда сборки проекта выглядит одинаково и для Linux и для Windows и для MacOS:
Дмитрий,
>>Делай как написано в документации буста и cmake и всё заработает
У меня устойчивое впечатление, что вы не вникли в суть вопроса. Так-то у меня и без вашего совета всё собирается и работает на разных платформах. Потрудитесь вникнуть в суть вопроса или займитесь другими делами.
res2001,
> то сделайте каталог с бустом субмодулем в git
Хотелось бы какой-то метод, типа передачи переменной из консоли (-DVAR=PATH), но чтобы проверить, что необходимая библиотека присутствует, а если нет, то как-то сообщить пользователю, что нужно для её получения.
Дмитрий,
>С чего это азио не кроссплатформенный?
Вы правы, он-то кроссплатформенный, только я ещё дописал, что он используется для многоточных вычислений, а это требует ещё и компонета thread, который не является кроссплатформенным:
LINK : fatal error LNK1104: cannot open file 'boost_thread-vc143-mt-x64-1_85.lib'
Поэтому без сборки boost не обойтись. Немного не точно написал.
res2001,
> В винде можно использовать vcpkg для MSVC или pacman в msys2 или что-то еще.
Нене, сборка не должна быть частью системы. Используются MSVC на Win и gcc на Linux, Остальные зависимости удалось нормально исключить, чтобы не сохранять к ним привязку. Скажем так, я использую только boost и остальные зависимости в проекте не нужны даже для сборки. Проект собирается в статическую библиотеку. BOOST собирается без проблем двумя командами и на windows и на Linux. В данный момент после сборки проекта вообще не остаётся никаких следов в системе. Нужно, чтобы так и осталось.
Ivan Ustûžanin,
>>используйте auto и make_shared()
Мне auto тоже нравится, это пока для целей тренировки и запоминания объектов библиотеки, чтобы лучше названия запомнить, которыми приходится оперировать.
Ivan Ustûžanin, Надо же! Я проглядел, что вы написали smart_ptr<SomeClass>(&object)
ещё вчера! Мне показалось, что написано "make_shared". И именно эта конструкция и оказалась ошибочной!
Ivan Ustûžanin, Разобрался в чём дело.
Это я написал вчера, когда повёлся на маркетинг, что std::shared_ptr - "умные". Думал, что, наверное, разберуться сами. А оказалось, что нет. Приводить к типу "std::shared_ptr" не очень хорошая идея оказалась. )))
Ivan Ustûžanin, Спасибо за подсказки в любом случае, я про такие тонкости с make_shared не знал, но с другой стороны и начал этим заниматься, чтобы и в плюсах разобраться.
>>так Exception или падение?
Там именно подение. У меня там есть перехват std::exception, но на access violation - это как "против лома нет приёма".
Если разберусь с ошибкой - напишу, в чём было дело.
Ivan Ustûžanin,
>>выкиньте этот Contour(), make_shared() и так делает новый объект
Спасибо за подсказку, не знал, что так можно, но наверное так работает только если есть конутруктор по-умолчанию. Выкинул, но не помогло (в том плане, что shared_ptr создаёт объект, но Exception всё равно вылетае на старом месте). Так-то иногда надо вызвать явный конструктор с параметрами.
Ivan Ustûžanin, Это не полный код, который может ввести в заблуждение. Далее frame_outer_boundary добавляется в std::vector, который приходит сильно из другого блока кода. И сыпется точно не на этом объекте:
В стандартных примерах по ссылке, которые вы прислали, не очень понятно почему вызываются деструкторы - толи new выходит из области действия блока кода, то ли shared_ptr-ы. Не ясно кто стартует вызов деструкторов - сами исходные объекты или shared_ptr ?
Ivan Ustûžanin,
И честно говоря мне не очень понятно что такое "объект создан на стеке, то как его в shared_ptr не пихай, его деструкторы будут вызваны при выходе из блока". Вот на скрине объект создан на стеке или нет?
mayton2019 В принципе я так и поступил в итоге - стал нагружать данными в несколько потоков, которая стала близка к количеству ядер и тогда загрузка ядер стала заметно подниматься почти до 100%. У меня сложилось впечатление, что при одном потоке операционка так умело перекидывала эту задачу в однопоточном режиме между ядрами, что диспетчер задач даже при работе в быстром режиме отображения нагрузки не успевал отслеживать настоящую нагрузку на одно ядро. А как только не осталось ядер для перебрасывания, тут-то процессор и завым всеми вентиляторами. )))
Так что видимо проблема была просто в некачественном отображении загрузки на ядро в диспетчере задач! В подтверждении этого предположения говорит факт, что профайлер студии писал 4-5% от общей загрузки всего процессора по этой задаче, что примерно и соответствует полной нагрузке одного ядра в 24 ядерной системе, на которой всё это и работает.
В результате чего каждый вызов сишного кода из питона создает новый поток для выполнения очень простой и короткой операции.
Точно нет. Если данные удаётся разделить на 20 независимых потоков, то исчитаются они в 20 раз быстрее, даже при делении потоков в Python. В данном случае у меня есть Cишная библиотека, которую я подключаю к Python (такая схема работы, нужно затащить сишную программу через обёртку, это точно не узкое место). На чистых тестах в C++ один поток тоже может считаться также долго, как и через python. Разницы нет. Вся логика уже в C++. Питон только подготавливает данные, а там их не много. Массив на 2000 точек по три [[0.5, 1.1, 0.0], ...] и список индексов примерно такого же размера или меньше. Для питона переварить такое в виде того же процесса подготовки данных для передачи в C++ вообще ни о чём.
Wataru, Эта самая параллельность тут роли не играет. Если у меня случается один большой расчёт, то и идёт он в один поток, думаю, что RtlUserThreadStart отображается с учётом того, что он выполняет задачу, а не потому что долго вызывается. Если у меня случается так, что тот же объём данных можно разбить на независмые 20 потоков, то и считаются они в 20 раз быстрее. Ниже написал, что может быть я немного ошибся с оценкой производительности, но в целом меня смущает, что я не вижу загрузки хотя бы по одному ядру на 100% в диспетчере задач. Что работает процесс расчёта, что не работает - нет какого-либо отклонения ни в одном ядре. Однако стоит запустить несколько процессов в параллель, тогда видно, что некоторые ядра нагрузились по 100%, но это если потоков много. Если так в целом судить, то скорее всего может быть я неправильно интерпретирую данные? но в принципе хотелось бы понять, где вообще программа тупит.
Из читаемого в профайлере:
почему 54% на скобке?
В итоге получилось почти как и задумывал вначале, только оказалось, что для указания библиотек Boost есть стандартная переменная BOOST_LIBRARYDIR. Теперь команда сборки проекта выглядит одинаково и для Linux и для Windows и для MacOS:
Понятно, что под linux/macos надо обратные дроби. А так теперь всё норм собирается. CMakeLists.txt больше править не надо.
Всем спасибо.