Здравствуйте, eao197, Вы писали:

[]

E>Но, на двух ядрах оказывается, что стоимость переключения контекста между нитью-обработчиком и нитью ACE_Reactor-а слишком высока, чтобы передавать входящий/исходящий трафик через очереди сообщений.

При чем здесь это? Чем оно дороже чем на одноядерной машине?

E>Вопрос в том, как перепроектировать подобное приложение на два/четыре/восемь ядер сейчас так, чтобы при появлении 80(!) ядер приложение не пришлось перепроектировать с нуля заново.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, eao197, Вы писали:

E>>Но, на двух ядрах оказывается, что стоимость переключения контекста между нитью-обработчиком и нитью ACE_Reactor-а слишком высока, чтобы передавать входящий/исходящий трафик через очереди сообщений.
C>А почему тут происходят переключения контекстов?

Оно происходит, если оба треда сидят на одном ядре, как я понял. А вот к чему это я тоже не понял

Здравствуйте, remark, Вы писали:

R>К сожалению пока никто не придумал как приготовить этот рецепт в общем виде... Т.е. что бы программист был занят только прикладными задачами, а всё остальное происходило как-то само собой.

А как же array languages типа старый APL и новые J и K? Не уверен что их текущая реализация реально использует многоядерность (хотя за K не скажу, уж больно быстрый по слухам), Но принциально, в силу "нефоннеймовской" архитектуры, при правильной реализации и правильном стиле программирования (да, на J тоже циклами можно писать... но не нужно ), все теоретически должно работать...

Здравствуйте, сипласплас, Вы писали:

С>А разве каждое присваивание ссылки в c# не зовет что-то типа InterlockedExchangePointer?

1. нет, не зовет, и откуда у тебя такая странная мысль?
2. и вообще, какое это имеет отношение к моему вопросу?

Здравствуйте, Cyberax, Вы писали:

E>>Но, на двух ядрах оказывается, что стоимость переключения контекста между нитью-обработчиком и нитью ACE_Reactor-а слишком высока, чтобы передавать входящий/исходящий трафик через очереди сообщений.
C>А почему тут происходят переключения контекстов?

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

Совершенно забыл, что существует прослойка профи которая давно и успешно занимается распаралеливанием.

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

Здравствуйте, remark, Вы писали:

R>Шутка шуткой, а на форумах посвящённым многопоточности сейчас один из самых распространённых вопросов «Почему моя программа, которая делает Х, на 4-ёх ядерной машине работает медленнее, чем на 1-ядерной?»

Кстати, а где есть такие форумы?

Здравствуйте, remark, Вы писали:

Мой недавний анализ этой темы пришел почти к тем же выводам.

1. Алгоритмы разрабатываются для одного исполнителя. Есть огромная масса готовых алгоритмов, и все время создаются новые. Алгоритм для многих исполнителей — я о таком не слышал. Есть только алгоритм для одного, управляющий ходом других алгоритмов, которые опять же для одного.

2. Алгоритм для одного исполнителя нельзя автоматически исполнить многими. Одного контрпримера достаточно (типа сортировки)

R>Всё это я называю «многопоточность на одном ядре». Фактически система, построенная по таким принципам, образно является «однопоточной с кооперативной многозадачностью».

3. Параллельность делится вообще на две вещи — многопоточность и многоядерность. Многопоточность это когда в вашей программе должны работать паралелльные процессы просто по природе задачи (например, GUI работает дальше, а поток в фоне заливает файл). Многоядерность это когда вы хотите получить прирост до N раз при наличии N ядер (исполнителей). Вещи между собой вообще-то никак не связанные, кроме того единственного общего момента, что N ядер могут заняться одновременно вашими N (или 2N) потоками. Многопоточность это вообще не проблема, реализуется даже в рамках одного алгоритма с одним исполнителем, а при поддержке языка даже наличие потоков в ОС не особо имеет значение. Сегодняшняя проблема параллельности — в многоядерности.

4. Multithreading с общими данными (синхронизацией) — отстой. Языковая поддержка типа atomic {} не решает проблемы. Каждый наверное уже обжегся. Многие уже самостоятельно дошли до вывода, что чем меньше разделяемых данных — тем меньше багов. Синхронизации не дожно быть.

5. По причине п.1 и п.2 автоматическая многоядерность пока что мечта. Даже если изобретут другую науку об алгоритмах, создающую автоматически параллелящиеся алгоритмы, все равно нельзя просто взять всю массу накопленного софта и переписать.

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

7. Автоматическое распараллеливание, если оно возможно, имхо должно происходить по данным, а не по коду. Как только известно, что две последовательные функции в вашей программе гарантированно не работают с общими данными (и ресурсами), их можно параллелить не глядя на код вообще. От каждого куска кода надо только задействованные структуры данных. То есть анализировать надо данные, а не алгоритмы. Может, достаточно будет изменить способ декларации структур данных в языке, чтобы взаимосвязи между ними были легко отслеживаемыми, чтобы программы на нём стали параллелящимися во многих местах.

R>Если выразить это более кратко: *каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.
R>К сожалению пока никто не придумал как приготовить этот рецепт в общем виде... Т.е. что бы программист был занят только прикладными задачами, а всё остальное происходило как-то само собой.

Я думаю все уже придумано (Erlang). Программа делится на мелкие процессы. Чем мельче тем лучше — больше ядер смогут заняться параллельными процессами. Каждый из них ни с кем свои данные не делит в принципе. Для каждого общего ресурса создается процесс-контроллер, с работает с ресурсом только он. Процессы могут передавать друг другу владение над частями своих данных (без копирования памяти то есть). Шедулер создает нужное для текущей системы число потоков, и исполняет эти мелкие процессы в них.

Может такая архитектура, даже реализованная на уровне ОС (Singularity вспомнил ) и не загрузит 1000 ядер, но для нашего ближайшего будущего — 1-30 ядер — работает просто превосходно.

Здравствуйте, Кодёнок, Вы писали:

Кё>2. Алгоритм для одного исполнителя нельзя автоматически исполнить многими. Одного контрпримера достаточно (типа сортировки)

quicksort можно параллелить. При каждом делении массива пополам, каждую половину можно обрабатывать отдельным ядром. Вопрос только в том, что распределение задач по ядрам должно быть очень легковесным — а в рамках существующей архитектуры x86/64 такой возможности похоже нет

Здравствуйте, Andrei F., Вы писали:

Кё>>2. Алгоритм для одного исполнителя нельзя автоматически исполнить многими. Одного контрпримера достаточно (типа сортировки)

AF>quicksort можно параллелить. При каждом делении массива пополам, каждую половину можно обрабатывать отдельным ядром. Вопрос только в том, что распределение задач по ядрам должно быть очень легковесным — а в рамках существующей архитектуры x86/64 такой возможности похоже нет

Сортировку вставками или пузырьком нельзя. Многие алгоритмы на графе нельзя. Вопрос лишь в принципиальном существовании примера, чтобы показать, что чудес не будет.

Здравствуйте, remark, Вы писали:

R>Уже достаточно давно программисты экстенсивно применяют многопоточность при реализации систем. При этом многопоточность применялась в основном для таких вещей как упрощение модели программирования, маскирование латентности блокирующих операций и т.д. И так же это всё происходило в подавляющем большинстве в контексте одного ядра/процессора. Соотв. распространены следующие принципы и подходы:
R> — Можно завести любое кол-во потоков. Иимеется в виду любое в пределах сотни. Т.е. кол-во потоков определяется исключительно потребностью архитектуры, но не аппаратной платформой.
R> — Можно произвольным образом распределить работу по потокам. Т.к. всё равно всё выполняется на одном ядре, то это не имеет значения.
R> — Можно и нужно экстенсивно применять мьютексы для синхронизации. Т.к. всё выполняется на одном ядре, то это практически не влияет на производительность и масштабируемость.
R> — Можно произвольным образом разделять данные между потоками. Т.к. процессор один, то это никак не влияет на производительность и масштабируемость. Фактически система работает так, как будто поток один, просто он выполяет то одну функцию, то другую.

Мне кажется ты борешься с не очень хорошими программистами. С теми, кто использовал многопоточность для сокрытия собственной лени. Практически, это не многопоточность. Когда GUI крутится в одном потоке а ВСЕ тяжелые задачи в другом (одном) потоке — это НЕ многопоточность. И это сразу становится видно на любой старенькой SMP системке. Делом, как правило, занят один проц.
Если же человек смог разделить "тяжелую" задачу на составляющие, и запустить в отдельных потоках — он получает все выигрыши производительности и в SMP, и в HyperThreading, и в многоядерности. Но для такого человека все исходные ^^^^ (в посте) "принципы и подходы" не справедливы.
Так что, как всегда, все зависит от девелопера. "Шланги" останутся "шлангами", а для профи ничего не меняется.

Здравствуйте, Кодёнок, Вы писали:

Кё>1. Алгоритмы разрабатываются для одного исполнителя. Есть огромная масса готовых алгоритмов, и все время создаются новые. Алгоритм для многих исполнителей — я о таком не слышал. Есть только алгоритм для одного, управляющий ходом других алгоритмов, которые опять же для одного.
А вот сюдахотя бы посмотрите.

Здравствуйте, LaptevVV, Вы писали:

Кё>>1. Алгоритмы разрабатываются для одного исполнителя. Есть огромная масса готовых алгоритмов, и все время создаются новые. Алгоритм для многих исполнителей — я о таком не слышал. Есть только алгоритм для одного, управляющий ходом других алгоритмов, которые опять же для одного.
LVV>А вот сюдахотя бы посмотрите.

Там целый большой сайт Куда именно смотреть?

Здравствуйте, remark, Вы писали:

R>Так думали при появлении процессора 1 МГц.
R>Так думали при появлении процессора 10 МГц.
R>Так думали при появлении процессора 100 МГц.
R>Так думали при появлении процессора 500 МГц.
R>Так думали при появлении процессора 1 ГГц.
R>Так думали при появлении процессора 2 ГГц.
R>Так думали при появлении процессора 3 ГГц.
R>Так думают при появлении 4-ёх ядерного процессора 3 ГГц.
Двухядерный забыл. По двухядерному могу сказать что думал что будет лучше, а на деле оказалось что нет.

R>Если бы произошёл всемирный и вечный фича-фриз у производителей софта, то да, достаточно было бы выпустить ещё одно поколение процессоров и всё, его бы хватило бы на всегда.
Для подавляющего кол-ва десктопных приложений, по моему, достигнуто. Основное торможение диск, сеть и база данных. Я уже давно не видел проблем торможения(кроме некоторых специализированных приложений).

R>Но проблема, в том, что задачи, которые ставятся перед софтом постоянно растут с той же скоростью, с которой растёт производительность, даже быстрее. И конца этому не видно.
Для десктопов — нет.

R>Над чем сейчас работают — распознование голоса/видео на лету.
Во-первых, там алгоритмические проблемы. Двумя процессорами, можно выйграть по производительность максимум в 2 раза(если говорить идеалистично). Алгоритмами — на порядки. Да детерминизация алгоритмов оставляет желать лучшего. Во-вторых, там нужны не 80 процессоров по 3 гГц, а несколько тысяч с меньшей частотой, но с возможность общаться друг с другом. Ну а в третьих, зачем это делать на десктопе, а не на спец. апаратуре(или хотя бы спец. платку впихнуть).

R>О играх и серном ПО и говорить нечего.
Для игр — важна память+граф карта. Для серверного ПО, проблемы синхронизации не стоит. Фактически — на каждого пользователя по ядру, с разделением данных. Но я говорил именно о десктопах.

Здравствуйте, remark, Вы писали:

R>Меня лично на PIV3.0+1Гб не устраивает скорость компиляции,
У меня тормозит компиляция NET, только когда много сборок. Теже файлы но в одной сборке компилируются мухой. Соответсвенно вывод что проблема в диск+скорость кэша(то бишь доступа к озу).
Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции.
R>не устраивает скорость работы навороченных GUI типа Open Office/MS Visual Studio,
Основные проблемы память+диск.
R>не устраивает скорость запуска очень многих программ.
Основные проблемы память+диск.

Здравствуйте, Кодёнок, Вы писали:

Кё>Сортировку вставками или пузырьком нельзя. Многие алгоритмы на графе нельзя. Вопрос лишь в принципиальном существовании примера, чтобы показать, что чудес не будет.

"Если есть хоть один случай, когда нельзя — значит, нельзя вообще" — это только мне чудится, что в этой логике есть баааальшущий изъян?

Здравствуйте, GlebZ, Вы писали:

R>>Но проблема, в том, что задачи, которые ставятся перед софтом постоянно растут с той же скоростью, с которой растёт производительность, даже быстрее. И конца этому не видно.
GZ>Для десктопов — нет.
Компилятору надо больше гигагерц.

R>>Над чем сейчас работают — распознование голоса/видео на лету.
GZ>Во-первых, там алгоритмические проблемы. Двумя процессорами, можно выйграть по производительность максимум в 2 раза(если говорить идеалистично). Алгоритмами — на порядки. Да детерминизация алгоритмов оставляет желать лучшего. Во-вторых, там нужны не 80 процессоров по 3 гГц, а несколько тысяч с меньшей частотой, но с возможность общаться друг с другом. Ну а в третьих, зачем это делать на десктопе, а не на спец. апаратуре(или хотя бы спец. платку впихнуть).
Э нет, платка поможет только в очень немногих случаях. Те системы видеонаблюдения с десятком видеоканалов требуют ооочень больших ресурсов процессора.

R>>О играх и серном ПО и говорить нечего.
GZ>Для игр — важна память+граф карта. Для серверного ПО, проблемы синхронизации не стоит. Фактически — на каждого пользователя по ядру, с разделением данных. Но я говорил именно о десктопах.
AI в играх просчитывает именно процессор. Если поставить побольше умных ботов в каком-нибудь шутере — тормозить будет. И не из-за нехватки видео- или оперативной памяти.

Здравствуйте, Andrei F., Вы писали:

Кё>>Сортировку вставками или пузырьком нельзя. Многие алгоритмы на графе нельзя. Вопрос лишь в принципиальном существовании примера, чтобы показать, что чудес не будет.

AF>"Если есть хоть один случай, когда нельзя — значит, нельзя вообще" — это только мне чудится, что в этой логике есть баааальшущий изъян?

1. Есть случаи, когда нельзя.
2. Современные средства не могут различить случаи, когда можно и когда нельзя, без подсказок программиста.

1 + 2 = нельзя вообще
=> автоматического распараллеливания в ближайшее время не будет

Здравствуйте, Кодёнок, Вы писали:

Кё>1. Есть случаи, когда нельзя.
Кё>2. Современные средства не могут различить случаи, когда можно и когда нельзя, без подсказок программиста.

Кё>1 + 2 = нельзя вообще

Вычеркиваем "вообще", вписываем "сейчас"
Надо всё-таки следить за точностью формулировок

Здравствуйте, ddaa, Вы писали:
К сожалению, это красивая сказка.
а) судьба шлангов никого не интересует. Речь о людях, обеспечивающих требуемую функциональность в традиционной архитектуре.
б) судьба сферических идеальных разработчиков тоже никого не интересует. Просто потому, что таких нет. Речь о людях, обеспечивающих требуемую функциональность в
традиционной архитектуре.

В итоге, пост, в общем-то, о том, что в ситуации виноваты не программисты. Сейчас меняется среда выполнения программ; и она требует новых подходов, т.к. старые подходы не работают.
Много лет нас убеждали, что технологии, в общем-то, в порядке, "мы просто не умеем их готовить". Продолжающееся 100% отсутствие "правильных поваров" побуждает всё же повернуть обвиняющий перст в сторону технологий.