Здравствуйте, Кодёнок, Вы писали: Кё>ВремяВыполнения = X + Y + Z = ВремяПараллелящегосяКода/ЧислоЯдер + ВремяПодМьютексами + ПереключениеКонтекстов*ЧислоЯдер Кё>С ростом числа ядер, время X падает, Y — остается постоянным, а Z — растет.
Совершенно непонятно, почему Z должно неограниченно расти.
АФАИК, если у "лишних" ядер нет работы, то никаких дополнительных переключений контекстов происходить не будет.
Далее, время под мьютексами вовсе не обязано оставаться постоянным. В предельном случае однопоточной программы Y очевидно строго равно нулю.
Нулю оно также равно в случае идеально распараллеленного алгоритма, которому не нужны общие данные (но это экзотика).
Представим себе менее тривиальный случай. Например, мы считаем сумму чисел в массиве.
Делим массив размером M на N фрагментов; каждый поток считает сумму по своему фрагменту и шарашит ее в общую сумму.
Очевидно, что всего понадобится N обращений к сумме, которые потребуют мьютекса (забудем пока про интерлокед инкремент), и время простоя в каждом из них будет примерно пропорционально (N-1). То есть Y ~ N^2.
В общем, модель вышла какая-то неубедительная.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, remark, Вы писали:
R>>Y — это что такое? Время под мьютексами? Если да, значит программа не распараллелена, надо её соотв. образом переписать.
Кё>Это принципиально непараллелящаяся часть. Вроде сведения сумм в примере с суммированием массива.
parallel machines will "just" be implementing "embarrassingly parallel" programs— because we will be shifting to scalable algorithms
Кстати, сведение сумм прекрасно распараллеливается. Это делается на "обратном фронте" fork/join (conquer/divide) алгоритма, т.е. на join фазе, т.е. получается иерархическая агрегация данных.
R>>Так же ты не учитываешь, что это 100% легально, что бы одновременно выполнялся код под одним мьютексом и под другим. Представь множество из 10^6 объектов, каждый защищён своим мьютексом. 10^3 потоков вполне могут параллельно работать с этими объектами и никогда не ждать друг друга.
Кё>Только это не ты выбираешь, сколько у тебя мьютексов будет. Это специфика алгоритма. К тому же даже в таком же соотношении, один объект может быть по своей роли оказаться востребованным сразу всеми.
Значит надо просто взять другой алгоритм. Параллелизация и "поддержка многоядерности" не сводится просто к "добавлению потоков", она может включать и применению другого алгоритма.
Например, в однопоточном окружении часто используют хитрые быстродействующие алгоритмы сортировки. Но к сожалению они обычно не распарарллеливаются (потому что слишком хитрые). Распараллеливание такой сортировки будет заключаться в применении, допустим, менее эффективного, но зато отлично распараллеливаемого quick sort (тоже O(N*lgN)), при этом quick sort можно применить только на "верхнем" уровне, а когда массив уже достаточно побит на части (допустим до кусков по 1000 элементов), можно применить изначальный хитрый однопоточный алгоритм.
Таким образом, получаем и отличное распараллеливание и отличную производительность, и это при том, что в изначальной программе у нас вроде как была только не распараллеливамая часть.
Один мьютекс, востребованный сразу всеми, — это специфика алгоритма, или даже точнее — реализации алгоритма. В том то и дело. Это не врожденная специфика той задачи, которую требуется решить.
Безусловно, можно применить такой алгоритм и так его реализовать, что и на 2 ядра распараллеливаться не будет, тут даже о "росте числа ядер" и говорить не надо.
Суть не в том, что можно сделать не распараллеливаемо, суть в том, что можно сделать распараллеливаемо.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Кодёнок, Вы писали:
Кё>>Я правильно понимаю, что любой многопоточный код с ростом числа ядер достигнет числа, когда прирост остановится совсем, а при дальшейнем превышении — начнется замедление назад?
E>JFYI: Is the free lunch really over? Scalability in Many-core Systems: Part 1 in a Series E>
E>Figure 1-1. Amdahl’s Law curves for 8 cores, varying degrees of parallelism.
E>Figure 1-2. Amdahl’s Law curves for 216 cores, varying degrees of parallelism.
Помимо графиков, построенных на основании закона Амдала, дальше в статье написано про корректировку, которую предложил Густафсон:
The key flaw in Amdahl’s Law was pointed out as early as 1988, by John Gustafson: it assumes either a fixed computational workload, or a fixed scaling of serial and parallel portions as the problem size is increased.
The alternative, often referred to as Scaled Speedup, looks instead at increasing the problem size for a given amount of time.
То бишь, с ростом вычислительных ресурсов обычно растёт и доступный для вычисления размер задачи, тогда как строго последовательный код остаётся ограниченным. Так что масштабируемость с ростом числа ядер — вопрос не только кода, но и объёма данных, которые код обрабатывает.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я правильно понимаю, что любой многопоточный код с ростом числа ядер достигнет числа, когда прирост остановится совсем, а при дальшейнем превышении — начнется замедление назад?
Я правильно понимаю, что любой многопоточный код с ростом числа ядер достигнет числа, когда прирост остановится совсем, а при дальшейнем превышении — начнется замедление назад? Оцениваю так:
ВремяВыполнения = X + Y + Z = ВремяПараллелящегосяКода/ЧислоЯдер + ВремяПодМьютексами + ПереключениеКонтекстов*ЧислоЯдер
С ростом числа ядер, время X падает, Y — остается постоянным, а Z — растет.
Функция f(x) = a/x + b + cx при увеличении x рано или поздно начинает расти независимо от соотношения [положительных] констант a, b, c.
При соотношениях 0.98/x + 0.01 + 0.01*x где-то на сотне штук время сравнивается с одноядерником и неограниченно растет.
Может быть похуже, 0.88/x + 0.1 + 0.02*x — уже на 34.
Получается, что как не пыжься с оптимизацией, минимизируя время проведенное в мьютексах, затраты на конкуренцию все равно все погубят.
Интуитивно я согласен — для каждой задачи есть свой оптимум исполнителей, два человека забьют два гвоздя в 2 раза быстрее, чем один, но если это будут делать 16 человек — получится только замедление.
Выходит, идеально распараллеленый софт — не тот, который загрузит все ядра, а тот, который оценит нужное ему число и загрузит только их?
Здравствуйте, Sinclair, Вы писали:
S>АФАИК, если у "лишних" ядер нет работы, то никаких дополнительных переключений контекстов происходить не будет.
Ну это если нет. Неинтересно. Если у всех ядер нет работы, то и переключаться некому, разве что потокам прочих процессов
S>Далее, время под мьютексами вовсе не обязано оставаться постоянным. В предельном случае однопоточной программы Y очевидно строго равно нулю.
Это тоже тривиальный случай.
S>Нулю оно также равно в случае идеально распараллеленного алгоритма, которому не нужны общие данные (но это экзотика).
Это не такая уж экзотика. Если брать твой пример с суммированием массива, то в нем общие данные есть. А вот если взять мой любимый пример с суммированием двумерного массива по строкам или столбцам, то он прекрасно параллелится без каких-либо общих данных. Каждый поток совершенно сам по себе, а поток-инициатор ждет, когда они все закончатся. Если потоков столько, сколько ядер — идеальная распараллеленность (естественно, я не учитываю потоки прочих процессов и дела в ядре).
А если CUDA взять (я с ней сейчас разбираюсь), то там параллится на N аппаратных тредов, каждый из них занимается свои кусочком, а потом, если им надо, то вызывается syncthreads(), что заставляет их сойтись в этой точке. Переключений контекста нет вообще. "На старт! Внимание! Марш!" — и все побежали по своей дорожке. А на финише их ждет судья — syncthreads(), и когда он последнего дождется, можно новый забег организовать. И на обычном процессоре такое можно смоделировать (что я и сделал
Например, суммирование двух линейных массивов сводится к тому, что каждый тред находит сумму своей пары x[i] и y[i] и пишет в z[i] (ну я немного упростил). А syncthread вызывается, чтобы быть уверенным, что все треды свое действие выполнили.
S>Представим себе менее тривиальный случай. Например, мы считаем сумму чисел в массиве. S>Делим массив размером M на N фрагментов; каждый поток считает сумму по своему фрагменту и шарашит ее в общую сумму. S>Очевидно, что всего понадобится N обращений к сумме, которые потребуют мьютекса (забудем пока про интерлокед инкремент), и время простоя в каждом из них будет примерно пропорционально (N-1). То есть Y ~ N^2.
S>В общем, модель вышла какая-то неубедительная.
+1. В этой модели неявно предполагается, что потоки постоянно переключаются. Между тем переключение потоков — совсем не обязательная ситуация. Вот на одном ядре им точно придется переключаться
Здравствуйте, Кодёнок, Вы писали:
Кё>Я правильно понимаю, что любой многопоточный код с ростом числа ядер достигнет числа, когда прирост остановится совсем, а при дальшейнем превышении — начнется замедление назад? Оцениваю так:
Кё>ВремяВыполнения = X + Y + Z = ВремяПараллелящегосяКода/ЧислоЯдер + ВремяПодМьютексами + ПереключениеКонтекстов*ЧислоЯдер
Кё>С ростом числа ядер, время X падает, Y — остается постоянным, а Z — растет.
Теоретически это действительно так. Т.е. при бесконечном росте числа ядер ты не получишь бесконечного уменьшения времени работы. НО! В тоже время при росте числа ядер можно добиться того, что бы время работы приложения (не какой-то отдельной его части, а именно всего приложения) снизилось, допустим, до 100 мкс. Да, 1 нс не получим. Но надо ли?
Т.е. вывод такой, что при бесконечном росте числа ядер мы можем получить для любой задачи sub-user-visible время выполнения. Мне кажется этого вполне достаточно.
По поводу необходимого кол-ва ядер. На практике это не составляет проблемы и решается тривиально — ограничением гранулярности "задач". Т.е. допустим ограничили гранулярность задачи 10 мкс. Имеем работы на 1 с. Значит бьём эту работу на 100 000 задач. Если у нас будет больше ядер — они автоматически не будут использоваться.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я правильно понимаю, что любой многопоточный код с ростом числа ядер достигнет числа, когда прирост остановится совсем, а при дальшейнем превышении — начнется замедление назад? Оцениваю так:
Здравствуйте, Sinclair, Вы писали:
S>Делим массив размером M на N фрагментов; каждый поток считает сумму по своему фрагменту и шарашит ее в общую сумму. S>Очевидно, что всего понадобится N обращений к сумме, которые потребуют мьютекса (забудем пока про интерлокед инкремент), и время простоя в каждом из них будет примерно пропорционально (N-1). То есть Y ~ N^2.
Верно, но тогда тенденция все равно сохраняется. По большому счету ведь интересует, пойдет N в числитель или в знаменатель.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это не такая уж экзотика. Если брать твой пример с суммированием массива, то в нем общие данные есть. А вот если взять мой любимый пример с суммированием двумерного массива по строкам или столбцам, то он прекрасно параллелится без каких-либо общих данных. Каждый поток совершенно сам по себе, а поток-инициатор ждет, когда они все закончатся. Если потоков столько, сколько ядер — идеальная распараллеленность (естественно, я не учитываю потоки прочих процессов и дела в ядре).
Да, именно про это я и говорил. К сожалению, в жизни крайне редко встречаются случаи, когда можно полностью divide & konquer.
Для них можно просто считать количество мьютексов равным нулю, и получать линейное увеличение шустродействия.
Естественно, при условии отсутствия конфликтов кэширования. В противном случае опять окажется, что раскидывание суммирования по дополнительным ядрам будет только портить cache locality и ухудшать общую производительность.
PD>+1. В этой модели неявно предполагается, что потоки постоянно переключаются. Между тем переключение потоков — совсем не обязательная ситуация. Вот на одном ядре им точно придется переключаться
Это если их больше одного
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Для них можно просто считать количество мьютексов равным нулю, и получать линейное увеличение шустродействия. S>Естественно, при условии отсутствия конфликтов кэширования. В противном случае опять окажется, что раскидывание суммирования по дополнительным ядрам будет только портить cache locality и ухудшать общую производительность.
Увы. Именно это у меня и имеет место быть. В пределах терпимого, но избавиться полностью пока не смог. Так что не линейное, но близкое к нему. Хотя пробовал на 2 ядрах и на 4 (заказчик пробовал). Вообще говоря, если опять-таки мое любимое суммирование матрицы взять, то по строкам — все будет идеально (при достаточно большой длине строки, а тем более при выровненности на длину линейки кеша они друг другу не конкуренты), а по столбцам — можно ведь и до абсурда довести, когда каждое ядро своим столбцом занимается, тут их (ядер) кеши передерутся все
Так что не такое уж простое это дело — распараллеливать алгоритмы
В CUDA это чистый кошмар. Стоит хоть где-то нарушить правила выравнивания, и вместо параллельной обработки будет последовательная.
PD>>+1. В этой модели неявно предполагается, что потоки постоянно переключаются. Между тем переключение потоков — совсем не обязательная ситуация. Вот на одном ядре им точно придется переключаться S>Это если их больше одного
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>В общем, модель вышла какая-то неубедительная.
PD>+1. В этой модели неявно предполагается, что потоки постоянно переключаются. Между тем переключение потоков — совсем не обязательная ситуация. Вот на одном ядре им точно придется переключаться
Под X подразумевается параллелящийся код, под Y — последовательный, а под Z — издержки. Я конечно подразумеваю, что издержки всегда есть, и они зависят от числа ядер (и не сходятся к константе).
В Z так же входят затраты на конкуренцию, например, холостые обороты в спинлоках или переключение в kernel mode. Их может быть мало, но если начать прибавлять ядра не поштучно, а порядками, от 20 к 200, от 200 к 2000, то тенденция к деградации должна начаться именно из-за этого.
Еще другой процесс/модуль тоже может запустить свой тред-пул по числу ядер, и все, появились постоянные переключения.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тебе в MS-DOS захотелось ?
При чем тут MS-DOS? Я констатирую медицинский факт: вытесняющая многозадачность — штука дорогостоящая. Кооперативная многозадачность для однопоточных приложений куда как лучше. Об этом, кстати, нам лично Вирт рассказывал десять лет назад Почтил, тскать, личным присутствием.
Конечно, вытесняющая многозадачность удобнее — нет риска повесить всю систему неосторожным зацикливанием.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Тебе в MS-DOS захотелось ? S>При чем тут MS-DOS? Я констатирую медицинский факт: вытесняющая многозадачность — штука дорогостоящая. Кооперативная многозадачность для однопоточных приложений куда как лучше. Об этом, кстати, нам лично Вирт рассказывал десять лет назад Почтил, тскать, личным присутствием. S>Конечно, вытесняющая многозадачность удобнее — нет риска повесить всю систему неосторожным зацикливанием.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Ты совсем шутки разучился понимать
Ты просто данную шутку часто повторять стал. Я и не могу понять — то ли ты шутишь, то ли до сих пор так и не понял, как высокопроизводительные сервера на одноядерных машинах работают.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>При чем тут MS-DOS? Я констатирую медицинский факт: вытесняющая многозадачность — штука дорогостоящая.
Дорогостоящая? Насколько конкретно? Сколько процентов производительности она съедает (и соотв. сколько можно выгадать, если от неё избавиться)? Сколько занимает одно переключение?
Для контекста примем время кванта — 20мс, т.е. ~60 000 000 тактов.
Здравствуйте, eao197, Вы писали:
Кё>>Я правильно понимаю, что любой многопоточный код с ростом числа ядер достигнет числа, когда прирост остановится совсем, а при дальшейнем превышении — начнется замедление назад?
E>JFYI: Is the free lunch really over? Scalability in Many-core Systems: Part 1 in a Series E>[q] E>Figure 1-1. Amdahl’s Law curves for 8 cores, varying degrees of parallelism.
[красивые картинки поскипаны]
Ну если производительность остановится в такой точке, что любое приложение будет выполняться не более, допустим, 10 мкс. То меня бы это вполне устроило. Вас — нет?
Здравствуйте, remark, Вы писали:
R>Дорогостоящая? Насколько конкретно? Сколько процентов производительности она съедает (и соотв. сколько можно выгадать, если от неё избавиться)? Сколько занимает одно переключение?
Давай копнем архивы
Здравствуйте, remark, Вы писали:
R>Т.е. вывод такой, что при бесконечном росте числа ядер мы можем получить для любой задачи sub-user-visible время выполнения. Мне кажется этого вполне достаточно.
Почему оно обязательно будет sub-user-visible? Что если для комбинации алгоритм + данные минимум (Y) будет равняться 100 лет?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Дорогостоящая? Насколько конкретно? Сколько процентов производительности она съедает (и соотв. сколько можно выгадать, если от неё избавиться)? Сколько занимает одно переключение?
S>Давай копнем архивы
Для двухпроцессорной системы два потока в программе дают оптимальную и максимально возможную производительность программы. Однако увеличение количества потоков приводит к постоянному увеличению времени выполнения программы на десять и более процентов. С другой стороны, на однопроцессорной системе увеличение количества потоков до 32 практически не сказывается на времени выполнения программы,
Что и требовалось доказать. И это определенно не лучший пример программы, ну точнее он лучший для вскрытия оверхедов на переключения, и даже он не смог их вскрыть. И так же учтём, что последние версии ОС (Vista, Server2008) существенно улучшают механизм планирования потоков.
По моим подсчётам оверхед на переключения в нормальной программе должен быть ~0.01%. Считать ли его большим? Стоит ли гнаться за элиминацией этого оверхеда?
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, remark, Вы писали:
R>>Т.е. вывод такой, что при бесконечном росте числа ядер мы можем получить для любой задачи sub-user-visible время выполнения. Мне кажется этого вполне достаточно.
Кё>Почему оно обязательно будет sub-user-visible? Что если для комбинации алгоритм + данные минимум (Y) будет равняться 100 лет?
Y — это что такое? Время под мьютексами? Если да, значит программа не распараллелена, надо её соотв. образом переписать.
Так же ты не учитываешь, что это 100% легально, что бы одновременно выполнялся код под одним мьютексом и под другим. Представь множество из 10^6 объектов, каждый защищён своим мьютексом. 10^3 потоков вполне могут параллельно работать с этими объектами и никогда не ждать друг друга.
When we look at those software houses, however, aren't they still mainly coding "embarrassingly parallel" applications?
Like many people, I dislike the term "embarrassingly parallel," but it is used so often there seems to be no way to avoid it. The term "embarrassingly parallel" really means anything that scales well. There is really nothing embarrassing about scaling well.
The term "embarrassingly parallel" has been mostly used to refer to algorithms where the best known solutions are able to scale well on supercomputers.
All algorithms are getting a second look, to see if there are equivalent or better algorithms that are "embarrassingly parallel."
For example, it turns out ray tracing is a superior rendering method for visualization, but we haven't had enough horsepower to do ray tracing. So we'll been using other less compute intensive methods despite the superiority of ray tracing. Parallelism makes ray-tracing work. We'll move to preferring ray-tracing in the future, not because it is "embarrassingly parallel," but because it is better and parallelism offers the horsepower to adopt it.
The shift to replacing algorithms that cannot scale will mean all programs try to be "embarrassingly parallel." This will make your question a self-fulfilling prophecy. Yes, parallel machines will "just" be implementing "embarrassingly parallel" programs— because we will be shifting to scalable algorithms.
Здравствуйте, remark, Вы писали:
R>Y — это что такое? Время под мьютексами? Если да, значит программа не распараллелена, надо её соотв. образом переписать.
Это принципиально непараллелящаяся часть. Вроде сведения сумм в примере с суммированием массива.
R>Так же ты не учитываешь, что это 100% легально, что бы одновременно выполнялся код под одним мьютексом и под другим. Представь множество из 10^6 объектов, каждый защищён своим мьютексом. 10^3 потоков вполне могут параллельно работать с этими объектами и никогда не ждать друг друга.
Только это не ты выбираешь, сколько у тебя мьютексов будет. Это специфика алгоритма. К тому же даже в таком же соотношении, один объект может быть по своей роли оказаться востребованным сразу всеми.
Здравствуйте, remark, Вы писали: R>Что и требовалось доказать.
Избирательно копаете. Почему 32 потока? Кто-то предлагал ограничиться этим числом? >По моим подсчётам оверхед на переключения в нормальной программе должен быть ~0.01%. Считать ли его большим?
Такой — нет. Но я советую посмотреть на правую часть приведенного графика. Там всё не так весело.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали: R>>Что и требовалось доказать. S>Избирательно копаете. Почему 32 потока? Кто-то предлагал ограничиться этим числом?
32 потока в смысле, что система держит 32*число_процессоров потоков, т.е. на 32 ядерной системе будет нормально держаться 1024 потока. 32*число_процессоров потоков — это вполне нормальное число для построения системы на основе преемптивных потоков. Число потоков в такой системе не должно зависеть от пользователя/нагрузки/и т.д, оно должно определяться как раз аппаратной платформой.
>>По моим подсчётам оверхед на переключения в нормальной программе должен быть ~0.01%. Считать ли его большим?
S>Такой — нет. Но я советую посмотреть на правую часть приведенного графика. Там всё не так весело.
Правую в смысле где Windows 98 SE? Туда не стоит сейчас смотреть. Наоборот в последних ОС шедулер только улучшается.
S>>Избирательно копаете. Почему 32 потока? Кто-то предлагал ограничиться этим числом?
R>32 потока в смысле, что система держит 32*число_процессоров потоков, т.е. на 32 ядерной системе будет нормально держаться 1024 потока. 32*число_процессоров потоков — это вполне нормальное число для построения системы на основе преемптивных потоков. Число потоков в такой системе не должно зависеть от пользователя/нагрузки/и т.д, оно должно определяться как раз аппаратной платформой.
На одноядерной машине под виндой можно было и 256 потоков запустить без заметного влияния на быстродействие.
Поскольку ядро системы для таких машин вместо честного InterlockedXXX с префиксом LOCK использует обычные операции,
все мутексы, CS и т.д. тоже построены на том, что ядро проца _одно_.
Запустите 32 потока вместо одного на двухядерной машине, привязав все потоки к одному процессору -- это даст более реальный результат.
S>>>Избирательно копаете. Почему 32 потока? Кто-то предлагал ограничиться этим числом?
R>>32 потока в смысле, что система держит 32*число_процессоров потоков, т.е. на 32 ядерной системе будет нормально держаться 1024 потока. 32*число_процессоров потоков — это вполне нормальное число для построения системы на основе преемптивных потоков. Число потоков в такой системе не должно зависеть от пользователя/нагрузки/и т.д, оно должно определяться как раз аппаратной платформой.
K13>На одноядерной машине под виндой можно было и 256 потоков запустить без заметного влияния на быстродействие. K13>Поскольку ядро системы для таких машин вместо честного InterlockedXXX с префиксом LOCK использует обычные операции, K13>все мутексы, CS и т.д. тоже построены на том, что ядро проца _одно_.
K13>Запустите 32 потока вместо одного на двухядерной машине, привязав все потоки к одному процессору -- это даст более реальный результат.
Я не думаю, что на современных ОС (Windows Vista, Windows Server 2003) это сильно повлияет на результат. Не в префиксе lock суть, суть в том, что шедулеры теперь распределенные. Тем более, что LOCK как таковой сильно подешевел на последних процессорах.
Здравствуйте, remark, Вы писали:
R>По моим подсчётам оверхед на переключения в нормальной программе должен быть ~0.01%. Считать ли его большим? Стоит ли гнаться за элиминацией этого оверхеда?
Дело не только в переключении контекста... У вытесняющей многозадачности есть куча побочных эффектов типа convoy phenomenon, особенно, когда начинается борьба за ресурсы между потоками, в этом-то и есть главная засада.
Мы уже победили, просто это еще не так заметно...
