>больше не дает прирост А непофакту может давать прирост если у него там io операции

Быть может задам глупый вопрос, но. Как определить эффективное количество "одновременно" работающих потоков для каждой конкретной машины?

Нет, вопрос неглупый (в отличие от большинства прозвучавших ответов)) Параллелят не машину, а задачу. "Машина" (вычислительный узел, кластер, grid, и тд) - это средство для её решения. Потоки - это абстракция уровня ОС. Сами по себе они никакого "выигрыша" или "проигрыша" не дают. Это тоже всего лишь средство для организации параллельных вычислений. То, насколько высоким будет ускорение счёта для КОНКРЕТНОГО алгоритма на системе с N вычислительными устройствами (пусть ядрами) по сравнению с последовательным выполнением алгоритма, завист от 1) самого алгоритма, 2) количества устройств. И совершенно правильно вам дали здесь ссылку на закон Амдала. Оценить потенциал для распараллеливания алгоритма можно, например, изобразив его в ярусно-параллельной форме. Но даже если вы очень молодец и написали одноярусный алгоритм (все ветви независимы), то быстрее, чем в N раз, он работать не может по определению. Потоки здесь совршенно не при чём

Быть может задам глупый вопрос, но. Как определить эффективное количество "одновременно" работающих потоков для каждой конкретной машины?

Какой-нибудь университетский учебник по параллельным вычислениям полистайте. Самые первые главы. Можно дедушку Таненбаума

дедушка Таненбаум он силён, есть у автора threads есть неплохое объяснение почему это не всегда так как хочешь

дедушка Таненбаум он силён, есть у автора threads есть неплохое объяснение почему это не всегда так как хочешь

Объяснение того, почему 1000 потоков на 8-ядерном процессоре - плохая идея? Исчерпывающее объяснение есть в учебниках по организации ЭВМ, ОС и параллельных вычилений)

Объяснение того, почему 1000 потоков на 8-ядерном процессоре - плохая идея? Исчерпывающее объяснение есть в учебниках по организации ЭВМ, ОС и параллельных вычилений)

нее, там про более тонкие моменты

А есть ссылка?

А есть ссылка?

Энтони Уильямс

Concurrency in Action

А, понял

Угу

у него есть второе издание, но я его никак не могу найти в электронке не за деньги

Да, недавно вышло совсем. Вроде видел на амазоне

А, пардон. Только pre-order 6 января 2019

была где-то равка типа преиздание

но и первое актуальность не потеряло

благо, ещё до 20 года целый год

Да, недавно вышло совсем. Вроде видел на амазоне

Старая есть в книгопомойке

Старая есть в книгопомойке

а вообще как туда книги попадают?

я про то как туда добавить

Мне кинуть, или в чат с тегом book

у меня есть немного добра для С++17

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

у меня есть немного добра для С++17

да, супер!

да, супер!

оно правда инглишь онли по большей части, перевод стл для 17 я видел от питера, но там что-то недемократичная цена

Кто-нибудь пытался разобраться в пропозал на Modules для C++?

Я правильно понимаю что бинарного стандарта не будет, и g++ и clang перестанут быть совместимыми?

Т.е. я не смогу импотнуть модуль скомпилированный в gcc из clang

Или идея в том чтобы оборачивать все хедеры в модули?

Т.е. системные библиотеки будут поставляться в хедерах как и раньше, а модули будут собираться уже в проекте?

я точно знаю, как узнать размер функции в си. но не под каждый компилятор, и не внутри программы. если компилятор содержит возможность объявления пользовательских секций, то помещаешь функцию внутрь этой секции. при этом надо помнить, что некоторые платформы размещают константы и код в разных секциях. распространённый пример такого объявления - ram_function для cortex m0. далее добавляете в генерацию линкеру map и смотрите размер функции в секции. собственно, вам для чего размер функции? может, есть другие решения?

Спасибо за ответ. Я пытался сделать собственный вид динамических библиотек.

Кто-нибудь пытался разобраться в пропозал на Modules для C++?

Бинарного стандарта скорее всего не будет. Майкрософт предлагает стандартизировать свой формат IFC и обещает его заопенсорсить, но мужики сомневаются.

Я правильно понимаю что бинарного стандарта не будет, и g++ и clang перестанут быть совместимыми?

да, бинарное представление не стандартизированно но вот тут ребята из гцц что то думают https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile&do=view&target=module-abi-2017-09-01.pdf

Я тут начал читать https://clang.llvm.org/docs/Modules.html и там пишут что include автоматически заменяется на модули

Я тут начал читать https://clang.llvm.org/docs/Modules.html и там пишут что include автоматически заменяется на модули

Т.е. если обернуть хедер в модуль, то компилятор это подхватит и заменит include на import

Я тут начал читать https://clang.llvm.org/docs/Modules.html и там пишут что include автоматически заменяется на модули

там вроде про кланговые модули

они отличаются от TS

Т.е. интфейс библиотеки как и раньше нужно будет писать в хедерах. Плюс дополнительно поставлять обёртку для модуля

В общем жизнь с модулями похоже станет сложнее

Т.е. интфейс библиотеки как и раньше нужно будет писать в хедерах. Плюс дополнительно поставлять обёртку для модуля

это другие модули, еще раз

А как TS решает проблему с import std.io; #include <stdio.h>

а разве есть такая проблема?

Почему не будет коллизии?

Кланг как я понимаю заменит include на import и двойного включения не будет

А как TS решает проблему с import std.io; #include <stdio.h>

Что за import? В плюсы завезли модули и я не знал?