@Undisputed

Сабж. Есть ли смысл? Ведь одновременно одно ядро процессора не может выполнять более одной задачи (а поток это задача)

0

@Undisputed

Про это читал, но к какой составляющей именно ты клонишь не могу понять

Это вроде только в виртуальных машинах есть, а в си нет виртуальной машины (тема изначально была создан в разеделе Си)

Нашел информацию. Но эта технология только у intelовских процессоров и судя по всему логический процессор все равно не может параллельно выполнить 2 потока

Добавлено через 1 минуту
Выходит 1 ядро = 1 поток идеальный вариант

0

Evg

Если потоки работают с высоким темпом в память, то может получиться так, что они друг другу вышибают данные из кэша. Проблема может быть не только с кэшем, но и на более поздних стадиях подсистемы памяти. Например, когда физически установлена одна планка памяти, то при высоком темпе, идущем от нескольких потоков, она начнёт сдерживать потоки.

Вполне может получиться так, что 3 потока работают быстрее, чем 4. Такая ситуация будет скорее исключением, чем правилом, но при определённых раскладах она может случиться и при проектировании программы нужно иметь её в виду

0

@Undisputed

Кеш насколько мне известно вышибается при переключении контекста, что фактически неизбежно

0

Evg

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

Поведение кэша зависит исключительно от того, по каким адресам в память идут запросы. Чем больше покрытие по адресам (при суммарном объёме, превышающем размер кэша), тем чаще будет инвалидация. И проблема с потоками может в некотором пограничном случае. Допустим, у на 6 мегабайт кэша. Каждый их потоков активно использует память в количестве 2 мегабайт. При трёх работающих потоков постоянно активными должны быть 6 мегабайт и они уместятся в кэше. А при четырёх потоках активными должны быть 8 мегабайт, и при таком раскладе данные из кэша постоянно будут вытравливаться, что может весьма значительно повлиять на производительность

0

@ct0r

К тому, что если у тебя одно ядро, но нужно одновременно что-то считать, скачивать из интернета, отвечать на запросы пользователя, то как думаешь, "есть ли смысл создавать потоки количество которых больше чем количество ядер процессора?"

Логический не может, физический может.

0

@Undisputed

В плане расчета на их параллельное выполнение - думаю нет

Как так? Одно ядро ведь не может параллельно выполнять 2 потока

0

@ct0r

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

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

1

@Undisputed

Это да.

Это очевидно. Но не думаю что такое поведение проявляется всегда. Наверное зависит от того насколько эффективно задание использует процессорное время и у кого какие приоритеты

0

Evg

Сие возможно только для hyperthreading. Поэтому вам двоим прежде чем спорить, надо определиться с терминологией. sys_beginner под "ядром" понимает простое ядро, а ct0r - ядро с hyperthreading'ом

0

@Igor3D

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

Именно в этом все дело. Провозгласить идеальную архитектуру (число ниток = числу ядер + (может) 1) очень легко - но реализовать ее нередко столь же трудно, т.к. все заботы по "кормлению ниток задачами" ложатся на программиста. Если "любая нитка выполняет любую задачу", то надо предусмотреть что напр "задача 2" не должна выполняться до того как закончилась "задача 1". А если напр появилась "задача 10" то она должна быть выполнена как можно быстрее, ее приоритет максимальный и.т.д.

Распределение задач по ниткам часто резко упрощает логику, но увы, часто в ущерб производительности. А примитивное "заводим нитку на каждую задачу" быстро заводит в тупик и (справедливо) осуждается.

Вот собсно и все, вопрос простой, не надо искать пятый угол с "промахами кеша" и др.

1

Evg

Согласен с предыдущим оратором. 99% задач обладают свойством того, что подзадачи НЕ сбаллансированы. А потому простые варианты типа распихать каждую подзадачу в отдельный поток не дадут предельной производительности, т.к. потоки будут исполняться разное время. Но такие варианты будут быстрее последовательного исполнения при более-менее правильном разбитии на потоки. Т.е. если программист понимает, что 2+3 вычислять в отдельном потоке слишком накладно

0

@Shamil1

Я на вычислительных задачах типа перемножения матриц получал (почти) четырёхкратное ускорение на двух-ядерном процессоре с гипер-трейдингом.

0

Evg

Перемножение матриц - сбаллансированная задача. В том смысле, что при распараллеливании потоки получают одинаковую нагрузку. Но далеко не не все задачи обладают таким свойством. Двумя постами выше я сказал, что 99% задач не такие - тут я явно погорячился, написав цифру в 99%

Добавлено через 1 минуту
На двух нипердредных ядрах почти четырёхкратное ускорение может получиться только при перемножении больших матриц, когда процессор начинает активно лезть в память мимо кэша. В противном случае такого ускорения быть не может

Добавлено через 3 минуты


Добавлено через 1 минуту

1

@Undisputed

А в чем тупик? Можно создать тредпул куда помещать задачи и треды готовые их выполнить, не вижу никаких проблем. При наличии задачи, тред который освободился хватает следующую задачу. Что тут осудительного и что предлагается в замен?

Добавлено через 5 минут
В таком случае да, немного сложно. Но если нет ухищрений с приоритетами то думаю особых проблем возникать не должно

0

@Igor3D

Так это и не тот вариант что осуждается.

Проблемы найдут Вас сами Напр "схватила" нитка задачу - ну как минимум надо определить тип задачи и получить "контекст", т.е. связанные с задачей данные. При этом весьма вероятно что контекст используется и др нитками. Часто нужно приостановить выполнение какой-то задачи, потом продолжить или вообще отменить и.т.п. - все это "само по себе" не сделается. В общем, начнете делать - увидите

0

@Undisputed

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

0