@ProCxx

Страница 2430 из 2477
Alexey
12.10.2018
17:35:44
Нет такого
В смысле короткоживущие и долгоживущие

static locals - в сегменте данных навсегда

Aidar
12.10.2018
17:38:26
Последнее может и часто практикует возврат нуля

Google
Крис
12.10.2018
17:38:44
но в целом лучше разбивай исходя из потановки задачи, здравого смысла и hardware_concurrency().
Ваше сообщение про потоки Пуассона меня выбило из колеи. Пока буду hardware_concurrency(), а там если время останется напишу пару бенчей и буду искать

Крис
12.10.2018
17:41:55
Побитый
12.10.2018
18:04:37
Ладно, пока остановимся на варианте количество потоков = std::thread::hardware_concurrency(). В любом случае, спасибо.
Есть какой то закон, который устанавливает зависимость эффективности распараллеливания от линейности алгоритма.

https://ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0

Вкратце - зависит от алгоритма, не который ты параллелишь

Крис
12.10.2018
18:05:54
Вкратце - зависит от алгоритма, не который ты параллелишь
Я спрашивал как раз про методы оценки алгоритмов для получения оптимального числа потоков

Побитый
12.10.2018
18:06:57
Я спрашивал как раз про методы оценки алгоритмов для получения оптимального числа потоков
А чё там может быть оптимальнее количества аппаратных потоков?

Крис
12.10.2018
18:07:12
Побитый
12.10.2018
18:07:36
Вот я и хочу узнать, может ли
Узнаешь - расскажи мне)

Крис
12.10.2018
18:08:04
Узнаешь - расскажи мне)
Ну вы, видимо уверены, что ничего быстрее быть не может(и я не знаю почему, мне неочевидно)

Побитый
12.10.2018
18:09:38
Ну вы, видимо уверены, что ничего быстрее быть не может(и я не знаю почему, мне неочевидно)
Ну типа параллельность все равно засчет ядер создаётся, и если одно ядро не умеет выполнять больше одного потока (с учётом гипертрединга), то откуда возьмётся прирост?

Другие потоки будут просто делить ядро между собой

Google
Побитый
12.10.2018
18:10:00
А это вряд ли может ускорить

Я так это представляю

Stolyarchuk
12.10.2018
18:30:17
Другие потоки будут просто делить ядро между собой
Делить потоки будет планировщик.. Потоки буду тупо ждать

Arseny
12.10.2018
20:03:53
Вот я и хочу узнать, может ли
Может быть выгодно больше, если временами все-таки приходится немного ждать. Ну и про гипертреадинг нужно помнить

Max
12.10.2018
20:04:21
Другие потоки будут просто делить ядро между собой
ну я так понял, что речь тут о том, что другие потоки не делят. Всегда есть боьшая пачка просто чего-то ждущих, и пачка работающих. И они по какому-то принципу переходят друг в друга.

Arseny
12.10.2018
20:12:16
Еще много потоков поможет, если мы глупые и делим задачу между потоками перед началом выполнения, а не в процессе.

Aleksei
12.10.2018
21:06:41
Быть может задам глупый вопрос, но. Как определить эффективное количество "одновременно" работающих потоков для каждой конкретной машины?
по количеству логических ядер. Больше не дает прироста по факту. Есть такая концепция как worker threads. Суть в том чтобы некоторые задачи, время выполнения которых велико, отдаются в работу фоновым потокам. Такая модель работы потоков называется concurrency. Главный поток приложения при этом ест очень мало и в расчетах не участвует. Второй вариант - parallelism - остановить главный поток, запустить кучку рабочих, скормить им данные и по завершению их всех возобновить работу главного потока. Если нужно сделать быстрые расчеты и результатом пользоваться дальше - нужен параллелизм. Иначе лучше подойдет канкарренси. Почему количество ограничего логическими потоками процессора: потому что все что больше будет требовать лишнее время на смену контекстов и возрастет количество локов всякоразных мутексов, что тоже время.

Dan
12.10.2018
21:23:25
Иногда я тоже думаю так поступить. Уж очень неоднозначный это бот

Anatoly
12.10.2018
21:29:27
по количеству логических ядер. Больше не дает прироста по факту. Есть такая концепция как worker threads. Суть в том чтобы некоторые задачи, время выполнения которых велико, отдаются в работу фоновым потокам. Такая модель работы потоков называется concurrency. Главный поток приложения при этом ест очень мало и в расчетах не участвует. Второй вариант - parallelism - остановить главный поток, запустить кучку рабочих, скормить им данные и по завершению их всех возобновить работу главного потока. Если нужно сделать быстрые расчеты и результатом пользоваться дальше - нужен параллелизм. Иначе лучше подойдет канкарренси. Почему количество ограничего логическими потоками процессора: потому что все что больше будет требовать лишнее время на смену контекстов и возрастет количество локов всякоразных мутексов, что тоже время.
parallelism - частный случай concurrency в отношении выполнения множества независимых задач. При одном ядре возможно только конкуретное (чередование задач при доступе к ядру) выполнение задач, при двух и более уже возможен параллелизм (одновременное выполнение)

Brooklyn
12.10.2018
21:33:05
У вас тоже здороваться нельзя ?

Anatoly
12.10.2018
21:34:28
У вас тоже здороваться нельзя ?
А ты ищешь, где можно? ;)

Brooklyn
12.10.2018
21:35:27
А ты ищешь, где можно? ;)
. Я в чате по Python поздоровался, мне сразу выдали инфу, что так делать нельзя. Поэтому уточняю

Ну просто тогда уж дайте пожалуйста правила чата или ещё что-то в этом духе.

Anatoly
12.10.2018
21:36:47
Хм, хотя, а кто его знает.... :)

Brooklyn
12.10.2018
21:37:52
Здесь тоже не принято, мы не клуб анонимных алкоголиков
Какое-то странное сравнение) Когда я вхожу в новое общество, первым делом здороваюсь. Ну это как-то в крови)

Anatoly
12.10.2018
21:37:54
Правила в описании чата.

Какое-то странное сравнение) Когда я вхожу в новое общество, первым делом здороваюсь. Ну это как-то в крови)
Это проекция социального поведения на чат, чат поток, здесь все движется непрерывно, но если хочется поздороваться, то ничего страшного

Google
Basil
13.10.2018
06:06:43
Здесь никто не знает, можно ли узнать точно размер функции в си коде? Например, я создал функцию void foo() { return; } Как мне понять сколько байт она будет занимать? Если брать указатель на функцию и итерировать до поиска команды RET то выдаются всегда разные значения почему-то.
я точно знаю, как узнать размер функции в си. но не под каждый компилятор, и не внутри программы. если компилятор содержит возможность объявления пользовательских секций, то помещаешь функцию внутрь этой секции. при этом надо помнить, что некоторые платформы размещают константы и код в разных секциях. распространённый пример такого объявления - ram_function для cortex m0. далее добавляете в генерацию линкеру map и смотрите размер функции в секции. собственно, вам для чего размер функции? может, есть другие решения?

Maxim
13.10.2018
06:10:45
Список компиляторов ограничен только gcc/g++ на Linux и MVC на винде соответственно

MVS*

Alex
13.10.2018
06:14:48
Список компиляторов ограничен только gcc/g++ на Linux и MVC на винде соответственно
Ну как минимум потенциальное присутствие clang на Linux и mingw на венде никто не отменял

Денис
13.10.2018
06:14:56
А потом на собеседования приходят и требуют зп 150++

Alex
13.10.2018
06:15:56
Я уже не говорю о специфичных компайлерах типа интеловского или ещё каких-либо других

Alex
13.10.2018
06:17:54
По-моему, странный вопрос

Basil
13.10.2018
06:18:50
Список компиляторов ограничен только gcc/g++ на Linux и MVC на винде соответственно
так, а список версий этих компиляторов определён? просто уточняю, чтобы понять принципиальную решаемость. в некоторых компиляторах, той же VS можно проверить её версию. делаем свич, с перебором этих версий, и выводим нужную строку.

Alex
13.10.2018
06:18:52
Может «тип» - имелось в виду название?

Maxim
13.10.2018
06:19:19
Со своими знаниями я до собеседования даже не дойду:)

А потом на собеседования приходят и требуют зп 150++

yuri
13.10.2018
06:19:19
Visual Studio _MSC_VER gcc _ _GNUC_ _ clang _ _clang_ _

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