Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 10.10.07 11:28
Оценка: 568 (66)
Уже достаточно давно программисты экстенсивно применяют многопоточность при реализации систем. При этом многопоточность применялась в основном для таких вещей как упрощение модели программирования, маскирование латентности блокирующих операций и т.д. И так же это всё происходило в подавляющем большинстве в контексте одного ядра/процессора. Соотв. распространены следующие принципы и подходы:
— Можно завести любое кол-во потоков. Иимеется в виду любое в пределах сотни. Т.е. кол-во потоков определяется исключительно потребностью архитектуры, но не аппаратной платформой.
— Можно произвольным образом распределить работу по потокам. Т.к. всё равно всё выполняется на одном ядре, то это не имеет значения.
— Можно и нужно экстенсивно применять мьютексы для синхронизации. Т.к. всё выполняется на одном ядре, то это практически не влияет на производительность и масштабируемость.
— Можно произвольным образом разделять данные между потоками. Т.к. процессор один, то это никак не влияет на производительность и масштабируемость. Фактически система работает так, как будто поток один, просто он выполяет то одну функцию, то другую.

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

И всё это становится кардинально не верным с появлением массовых многоядерных процессоров. Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потоками: здесь
Автор: remark
Дата: 20.09.07

И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер». Под эффективностью я подразумеваю, что бы программа на 8 ядрах выполнялась хотя бы не медленнее, чем на одном. Шутка шуткой, а на форумах посвящённым многопоточности сейчас один из самых распространённых вопросов «Почему моя программа, которая делает Х, на 4-ёх ядерной машине работает медленнее, чем на 1-ядерной?»

Потому что старые принципы многопоточности патологически не работают в новом контексте! Я уверен, что значительная часть многопоточных систем «старой школы» будут быстрее работать на многоядерном процессоре, если банально привязать все потоки программы к одному ядру! Т.к. синхронизация всё равно убивает потенциальный параллелизм, а разделение данных вносит коллосальные пенальти.
Некоторое время назад я был свидетелем следующей ситуации. Серверное ПО запустили на двух-процессорной машине (в надежде, что оно будет работать в 2 раза быстрее. ха-ха). Оно стало работать в 10 (!) раз медленнее (как потом оказалось причиной было постоянное разделение модифицируемых данных между двумя потоками).

Сейчас наиболее общий рецепт выглядит примерно следующим образом:
— Создать кол-во потоков по кол-ву аппаратных потоков. Как следствие — кол-во потоков не должно быть «зашито» в программу, т.к. она может выполняться на разных платформах. И как второе следствие – управление кол-вом потоков не должно быть заботой прикладного программиста (ну по крайней мере того же программиста, но когда он играет роль прикладного ).
— Работа должна быть распределена по потокам [примерно] равномерно. Соотв. это тоже не получится зашивать в программу и поручать прикладному программисту, т.к. кол-во потоков и кол-во и содержание работы меняться.
— Нельзя экстенсивно применять мьютесы/синхронизацию/блокировки. Т.к. это фактически заставит систему сериализоваться и выполняться «на одном ядре». Ни о какой масштабируемости тут не может быть и речи.
— По возможности надо элиминировать разделяемые данные. Совместная работа над одними модифицируемыми данными сейчас работает ооочень медленно и становится одним из важнейших новых боттлнеков аппаратной платформы, на ряду с тактами ядра, шиной к памяти, диском, сетью. И никаких изменений в лучшую сторону тут не предвидится. Только в худшую. (Это не относится к константным данным, их можно и нужно разделять между потоками)

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

Естественно могут иметь место и частные случаи. Например, приложение по обработке изображений или CAD/CAM/CAE/CASE. Тут скорее всего имеет смысл эффективно распараллеливать только одну основную функцию, например, обработку изображения, или рассчёт параметров модели (все остальные функции — графический интерфейс, фоновые задачи — по прежнему могут быть реализованы по старым принципам). Тут сейчас ситуация обстоит немного лучше. Тут (и только тут) на помощь могут придти такие средства как OpenMP, RapidMind, Intel TBB, Java Fork/Join и тд.:
www.openmp.org
www.rapidmind.com
osstbb.intel.com
gee.cs.oswego.edu/dl/papers/fj.pdf
К сожалению все эти средства подходят для очень ограниченного круга задач, и не подходят для реализации более общих и не типовых задач. И всё равно они не снимают с программиста основной задачи — что конкретно и как конкретно должно быть распараллелено. Это по прежнему должен решать программист, и он по прежнему должен обеспечить достаточное кол-во потенциального параллелизма, возможность для независимой работы потоков без разделяемых данных и т.д.

Есть ещё 2 вещи стоящие упоминания в данном контексте: готовые высокооптимизированные библиотеки и автоматическое распараллеливание кода.

Для решения типовых задач имеется ряд высокооптимизированных библиотек. Например можно посмотреть на:
Intel Integrated Performance Primitives (IPP):
http://www.intel.com/cd/software/products/asmo-na/eng/219767.htm
И AMD Performance Library (APL):
http://developer.amd.com/apl.jsp
Задачи, которые они могут решать включают:
— обработка/кодирование/декодирование видео
— обработка/кодирование/декодирование изображений
— обработка/кодирование/декодирование аудио
— операции над матрицами/векторами/строками
и т.д.
Понятно, что на общее решение такие библиотеки не тянут. Однако, если решаемая задача укладывается в возможности библиотеки, то имеет большой смысл применять такую библиотеку (Intel — платная, AMD — бесплатная).

Автоматическое распараллеливание кода.
Здесь не на что смотреть! Проходите, не задерживаетесь!
Сейчас автоматические распараллеливатели могут очень мало и очень конкретного. И вам всё равно придётся убеждаться, что распараллелилось то, что надо, так, как надо, и оно не ломается при последующих модификациях кода (напоминает борьбу с оптимизатором БД ). Фактически правильнее считать, что автоматического распараллеливания кода *нет*. Сейчас и в ближайшую декаду. Если кто-то утверждает обратное, то он либо не разбирается в вопросе, либо хочет вам что-то продать
За подробностями смотрите интервью с Джеем Хоефлингером, который занимается автоматическим распараллеливанием с середины 80:
http://www.thinkingparallel.com/2007/08/14/an-interview-with-dr-jay-hoeflinger-about-automatic-parallelization/


Подытожу. Мы сейчас находимся на перегибе развития. Что бы поспеть за развитием, а не попасть в кювет, надо многое переосмыслить и смотреть на вещи по новому. Новые принципы и подходы только формируются, ни у кого пока нет *универсальных* решений. Всё, что сейчас выдают за таковые, за универсальные решения для многоядерности (OpenMP, RapidMind, Intel TBB) — маркетинг. Ну, возможно, это лишь строительные блоки, но ни как не решение. Сейчас всё зависит исключительно от компетентности конкретного программиста, разрабатывающего конкретную систему.


Дополнительные ссылки для интересующихся:

Фундаментальная работа на тему, почему процессоры *не* будут становится всё быстрее и быстрее, и что делать теперь:
The Landscape of Parallel Computing Research: A View from Berkeley

Если кто ещё не читал — популярные заметки Герба Саттера:
The Free Lunch Is Over
The Pillars of Concurrency
How Much Scalability Do You Have or Need?

OpenMP Does Not Scale — Or Does It?. В очень забавной форме показываются проблемы, связанные с написанием параллельных программ.

How-to Split a Problem into Tasks. Как выявлять параллелизм в системе (подходит в основном для HPC).

Ещё интересные заметки Michael Suess:
Is the Multi-Core Revolution a Hype?
Moore’s Law is Dead — Long Live Moore’s Law!
How Much of the Industry Will Go Parallel?
Parallel Programming is Entering the Mainstream — or isn’t it?



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.10.07 12:15
Оценка: 12 (2)
Здравствуйте, remark, Вы писали:

<...внимательно прочитано и поскипано...>

Так может пора возвращаться в Unix-way? Множество однопоточных программ, общающихся между собой по IPC?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 10.10.07 12:42
Оценка:
Здравствуйте, eao197, Вы писали:

E>Так может пора возвращаться в Unix-way? Множество однопоточных программ, общающихся между собой по IPC?



Это ничего не меняет. Такой дизайн можно тривиально переделать под использование потоков, и при этом использовать более дешёвые методы взаимодействия без лишних копирований данных, совместно использовать константные (или read-mostly) данные, упростить администрирование/настройку.
А если множество процессов будет общаться через shared memory, так вообще получаем то же самое многопоточное приложение с точностью до констант.
По большому счёту тут не принципиально, что использовать потоки или процессы (с разделяемой памятью). Все те же сложные вопросы остаются — как распределить работу между потоками/процессами, как разделять данные и как синхронизировать потоки/процессы, как организовать передачу данных/сообщений между потоками/процессами, как делать балансировку нагрузки между потоками/процессами.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Многопоточность сегодня
От: GlebZ Россия  
Дата: 10.10.07 12:45
Оценка: 19 (2) +1 -1
Здравствуйте, remark, Вы писали:

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

Мне больше нравится термин "квазимногопоточность". Кооперативная многозадачность — все таки просто термин невытесняющей многозадачности.

R>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

Хороший вопрос. Я задумался, а нужно ли иметь на десктопе более чем два ядра по 3 гГц. Может в своем развитии десктопы дошли до точки когда дальнейшее увеличение производительности уже не даст видимого эффекта для пользователя?
(дома стоит PIV2.4, на работе DUAL 3.0, кардинальной разницы в работе не вижу.)
Re: Библиотеки
От: remark Россия http://www.1024cores.net/
Дата: 10.10.07 12:49
Оценка: 1 (1)
Здравствуйте, remark, Вы писали:

R>Для решения типовых задач имеется ряд высокооптимизированных библиотек. Например можно посмотреть на:

R>Intel Integrated Performance Primitives (IPP):
R>http://www.intel.com/cd/software/products/asmo-na/eng/219767.htm
R>И AMD Performance Library (APL):
R>http://developer.amd.com/apl.jsp
R>Задачи, которые они могут решать включают:
R> — обработка/кодирование/декодирование видео
R> — обработка/кодирование/декодирование изображений
R> — обработка/кодирование/декодирование аудио
R>- операции над матрицами/векторами/строками
R>и т.д.
R>Понятно, что на общее решение такие библиотеки не тянут. Однако, если решаемая задача укладывается в возможности библиотеки, то имеет большой смысл применять такую библиотеку (Intel — платная, AMD — бесплатная).


С одной стороны библиотеки являются самым простым и автоматическим решением. Они не требую практически никакого приложения умственных усилий. Однако применение их в коммерческих продуктах для решения основных задач чревато, т.к. они имеют очень жёсткую "семантическую стену". Допустим разработано ПО жёстко зашитое на использование такой библиотеки. ПО выпущено быстро и качественно. Но теперь встаёт задача сделать "немного другую" обработку нежели предусматривает библиотека. Ууупс. Можно, конечно, купить премиум лицензию, подать фича-реквест и ждать...
Опен-сорц библиотеки в таком свете выглядят, конечно, более привликательно. Всегда можно подправить то, что необходимо... Ни та, ни другая *не* опен-сорц...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 10.10.07 13:10
Оценка: 1 (1) +2
Здравствуйте, GlebZ, Вы писали:

R>>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

GZ>Хороший вопрос. Я задумался, а нужно ли иметь на десктопе более чем два ядра по 3 гГц. Может в своем развитии десктопы дошли до точки когда дальнейшее увеличение производительности уже не даст видимого эффекта для пользователя?
GZ>(дома стоит PIV2.4, на работе DUAL 3.0, кардинальной разницы в работе не вижу.)

Так думали при появлении процессора 1 МГц.
Так думали при появлении процессора 10 МГц.
Так думали при появлении процессора 100 МГц.
Так думали при появлении процессора 500 МГц.
Так думали при появлении процессора 1 ГГц.
Так думали при появлении процессора 2 ГГц.
Так думали при появлении процессора 3 ГГц.
Так думают при появлении 4-ёх ядерного процессора 3 ГГц.

Если бы произошёл всемирный и вечный фича-фриз у производителей софта, то да, достаточно было бы выпустить ещё одно поколение процессоров и всё, его бы хватило бы на всегда.

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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Арифметика
От: remark Россия http://www.1024cores.net/
Дата: 10.10.07 13:20
Оценка: +2 :))) :)
Здравствуйте, remark, Вы писали:

R>И всё это становится кардинально не верным с появлением массовых многоядерных процессоров. Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потоками: здесь
Автор: remark
Дата: 20.09.07

R>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)


Позавчера однопоточная программа на одноядерном процессоре использовала 100% аппаратных ресурсов. Хорошо.
Вчера однопоточная программа на двухядерном процессоре использовала 50% аппаратных ресурсов. Допустим.
Сегодня однопоточная программа на четырёхядерном процессоре использует 25% аппаратных ресурсов. Хммм.
Завтра однопоточная программа на шестнадцатиядерном процессоре будет использовать 6.25% аппаратных ресурсов.
Послезавтра однопоточная программа на восьмидестиядерном процессоре будет использовать 1.25% аппаратных ресурсов.


Арифметика очень простая. Хотите быть автором программы, которая работает только на 1.25% от возможного?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 10.10.07 14:02
Оценка: 1 (1) +1 :)
Здравствуйте, remark, Вы писали:

R>>>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

GZ>>Хороший вопрос. Я задумался, а нужно ли иметь на десктопе более чем два ядра по 3 гГц. Может в своем развитии десктопы дошли до точки когда дальнейшее увеличение производительности уже не даст видимого эффекта для пользователя?
GZ>>(дома стоит PIV2.4, на работе DUAL 3.0, кардинальной разницы в работе не вижу.)

Меня лично на PIV3.0+1Гб не устраивает скорость компиляции, не устраивает скорость работы навороченных GUI типа Open Office/MS Visual Studio, не устраивает скорость запуска очень многих программ.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.10.07 14:30
Оценка: 3 (1)
Здравствуйте, remark, Вы писали:

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


E>>Так может пора возвращаться в Unix-way? Множество однопоточных программ, общающихся между собой по IPC?



R>Это ничего не меняет. Такой дизайн можно тривиально переделать под использование потоков, и при этом использовать более дешёвые методы взаимодействия без лишних копирований данных, совместно использовать константные (или read-mostly) данные, упростить администрирование/настройку.

R>А если множество процессов будет общаться через shared memory, так вообще получаем то же самое многопоточное приложение с точностью до констант.

С другой стороны, разделение приложения на однопоточные процессы может быть похоже на противостояние обмена сообщениями удаленному вызову подпрограмм. Обмен сообщениями заставляет разработчика проектировать места межпроцессового (межагентного) взаимодействия.

Однопоточность же для программы, по сравнению с многопоточностью, дает несколько преимуществ:
* простота (отсутствие гонок и тупиков в коде);
* скорость (отсутствие синхронизаций (даже в недрах стандартной библиотеки) и связанных с этим накладных расходов).

R>По большому счёту тут не принципиально, что использовать потоки или процессы (с разделяемой памятью). Все те же сложные вопросы остаются — как распределить работу между потоками/процессами, как разделять данные и как синхронизировать потоки/процессы, как организовать передачу данных/сообщений между потоками/процессами, как делать балансировку нагрузки между потоками/процессами.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 10.10.07 16:01
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


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


E>>>Так может пора возвращаться в Unix-way? Множество однопоточных программ, общающихся между собой по IPC?



R>>Это ничего не меняет. Такой дизайн можно тривиально переделать под использование потоков, и при этом использовать более дешёвые методы взаимодействия без лишних копирований данных, совместно использовать константные (или read-mostly) данные, упростить администрирование/настройку.

R>>А если множество процессов будет общаться через shared memory, так вообще получаем то же самое многопоточное приложение с точностью до констант.

E>С другой стороны, разделение приложения на однопоточные процессы может быть похоже на противостояние обмена сообщениями удаленному вызову подпрограмм. Обмен сообщениями заставляет разработчика проектировать места межпроцессового (межагентного) взаимодействия.


E>Однопоточность же для программы, по сравнению с многопоточностью, дает несколько преимуществ:

E>* простота (отсутствие гонок и тупиков в коде);
E>* скорость (отсутствие синхронизаций (даже в недрах стандартной библиотеки) и связанных с этим накладных расходов).

R>>По большому счёту тут не принципиально, что использовать потоки или процессы (с разделяемой памятью). Все те же сложные вопросы остаются — как распределить работу между потоками/процессами, как разделять данные и как синхронизировать потоки/процессы, как организовать передачу данных/сообщений между потоками/процессами, как делать балансировку нагрузки между потоками/процессами.


E>Я бы даже сказал, что эти вопросы сразу же выпячиваются на передний край. И потому требуют гораздо более пристального внимания, чем в случае многопоточных программ.



Такой момент есть. Но я бы назвал это организационным моментом, а не техническим. При написании многопоточного приложения ты не обязан заниматься половыми связями с разделяемыми структурами и мьютексами... хотя всегда очень тянет
Продумать структуру системы и структуру взимодействия можно всегда. Если делать многопоточное приложение на основе обмена сообщениями, то получается аналогично процессам — отсутствие гонок, чётко гранулированное и определенное взаимодействие и т.д. Ну в прочем не тебе это говорить.
Зато при использовании процессов ты гарантированно:
— Имеешь очень дорогое взаимодействие. Это скорее всего будет 2 системных вызова, 2 полных копирования данных, плюс ещё синхронизация и ещё куча непонятно чего. Более-менее не так ужасно тормозно это может быть только с IO-Lite:
http://www.usenix.org/publications/library/proceedings/osdi99/full_papers/pai/pai.pdf
Хотя его видимо никто не использует.
В случае же потоков это может действительно очень-очень-очень быстро. Порядка нескольких тактов.
— Имеешь копии read-mostly данных в памяти и каждого процесса. И в кэше.
— Имеешь сложность запуска/остановки/настройки приложения.

Единственное, что будет быстрее в случае процессов — это однопоточный рантайм в каждом процессе. Но это из-за тупого реплицирования всех данных. Я думаю, что основная проблема тут это — аллокация памяти. Но я надеюсь, что ты не используешь стандартный аллокатор памяти из crt в многопоточных программах?


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Многопоточность сегодня
От: Andrei F.  
Дата: 10.10.07 16:08
Оценка: 1 (1)
Здравствуйте, remark, Вы писали:

А какие сейчас есть средства для синхронизации работы ядер? Можно ли например передавать данные между ядрами, не затрагивая при этом основную память? А то если диспетчеру придется постоянно делать полную синхронизацию всех кэшей, то это на корню убьет преимущества от распараллеливания, когда фрагменты задачи невелики по времени выполнения....
Re[3]: Многопоточность сегодня
От: AVM Россия  
Дата: 10.10.07 18:11
Оценка: :)))
Здравствуйте, remark, Вы писали:

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


E>>Так может пора возвращаться в Unix-way? Множество однопоточных программ, общающихся между собой по IPC?



R>Это ничего не меняет. Такой дизайн можно тривиально переделать под использование потоков, и при этом использовать более дешёвые методы взаимодействия без лишних копирований данных, совместно использовать константные (или read-mostly) данные, упростить администрирование/настройку.

R>А если множество процессов будет общаться через shared memory, так вообще получаем то же самое многопоточное приложение с точностью до констант.
R>По большому счёту тут не принципиально, что использовать потоки или процессы (с разделяемой памятью). Все те же сложные вопросы остаются — как распределить работу между потоками/процессами, как разделять данные и как синхронизировать потоки/процессы, как организовать передачу данных/сообщений между потоками/процессами, как делать балансировку нагрузки между потоками/процессами.
IMHO самое основное, что мешает жить и что является первичной проблемой — как разделять данные.

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

Основной проблемой было как грамотно организовать распределение данных между потоками выполнения — это сильно затрагивает алгоритмы обработки данных.


К сожалению НИИ был настигнут молодым капитализмом с советским лицом и финансирование темы прикрыли. Работы через несколько лет продолжились и сейчас есть результаты — вот только люди, которые это делают рассказать ничего конкретного не могут — у них на работе интернета нет.
Re[2]: Многопоточность сегодня
От: сипласплас  
Дата: 10.10.07 18:39
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


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


А разве каждое присваивание ссылки в c# не зовет что-то типа InterlockedExchangePointer?
Re[5]: Многопоточность сегодня
От: сипласплас  
Дата: 10.10.07 18:40
Оценка: 4 (1) +2
Здравствуйте, remark, Вы писали:

[]

R>Единственное, что будет быстрее в случае процессов — это однопоточный рантайм в каждом процессе. Но это из-за тупого реплицирования всех данных. Я думаю, что основная проблема тут это — аллокация памяти. Но я надеюсь, что ты не используешь стандартный аллокатор памяти из crt в многопоточных программах?


А какой надо использовать?

R>
Re[2]: Арифметика
От: сипласплас  
Дата: 10.10.07 18:52
Оценка:
Здравствуйте, remark, Вы писали:

[]

btw, после прочтения введения в lock/wait free Александреску мне показалось, что они хорошо ложатся на GC
Re: Многопоточность сегодня
От: iZEN СССР  
Дата: 10.10.07 19:48
Оценка: 16 (2) +2 -4
Здравствуйте, remark, Вы писали:

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

R> — Можно завести любое кол-во потоков. Иимеется в виду любое в пределах сотни. Т.е. кол-во потоков определяется исключительно потребностью архитектуры, но не аппаратной платформой.

Спорная посылка.
Количество потоков научились оформлять в пул и обычно проводят тестироание производительности в зависимости от размера пула.

R> — Можно произвольным образом распределить работу по потокам. Т.к. всё равно всё выполняется на одном ядре, то это не имеет значения.


Спорная посылка.
Девять рожениц никогда не родят одного дитя за один месяц.

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


Никогда такого не было.
Блокировки всегда советовали применять, если по-другому нельзя. Избавление от блокировок где только можно -- одна из самых творческих и востребованных задач многопоточного программирования.
От GIANT_LOCK избавляются всеми доступными способами. Во FreeBSD, кстати, за минувший год проделана колоссальная работа по удалению глобальной блокировки в ядре.

R> — Можно произвольным образом разделять данные между потоками. Т.к. процессор один, то это никак не влияет на производительность и масштабируемость. Фактически система работает так, как будто поток один, просто он выполяет то одну функцию, то другую.


Спорная посылка.
Любая книжка по многопоточному программированию с 80-х годов ничего не говорит о том, что многопоточная программа будет выполнятся на одноядерном процессоре. Даже предположения приводятся противоположные: "А что будет, если ваша многопоточная программа будет выполняться на одном ядре -- будет велика вероятность взаимоблокировки на общих данных. Так что нужно делать так-то и так-то, чтобы этого не произошло.". У Таненбаума в книжках, кстати, есть масса примеров на этот счёт.
Так что ВСЕ_ВСЁ_ЗНАЛИ.

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


Да.

R>И всё это становится кардинально не верным с появлением массовых многоядерных процессоров. Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потоками: здесь
Автор: remark
Дата: 20.09.07

R>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

Это область инноваций в код Windows, так как другие операционные системы более-менее переболели "одноядерностью" (MacOS 9 -> MacOS X; FreeBSD 4.x,5.x,6.x -> FreeBSD 7.0).

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


Это уже изобрели в Sun.
откройте для себя процессор UltraSPARC T1 (в UMA-среде) и программную архитектуру управления многопоточностью в Solaris 10. Ключевые слова: CMT, ThreadLiblaries, Light-weight process (LWP), Kernel Level threads, Thread Local Storage (TLS).

R>Потому что старые принципы многопоточности патологически не работают в новом контексте!


Это из пресс-релизов Intel так следует?

R>Я уверен, что значительная часть многопоточных систем «старой школы» будут быстрее работать на многоядерном процессоре, если банально привязать все потоки программы к одному ядру! Т.к. синхронизация всё равно убивает потенциальный параллелизм, а разделение данных вносит коллосальные пенальти.


R>Некоторое время назад я был свидетелем следующей ситуации. Серверное ПО запустили на двух-процессорной машине (в надежде, что оно будет работать в 2 раза быстрее. ха-ха). Оно стало работать в 10 (!) раз медленнее (как потом оказалось причиной было постоянное разделение модифицируемых данных между двумя потоками).



Это целиком зависит от профессионального мастерства программиста, пишущего многопоточное приложение. Обучены далеко не многие.
Возможно, Intel предлагает библиотеки, облегчающие процесс написания хорошо масштабируемых по нескольким вычислительным ядрам приложения. Это полезно в первую очередь новичкам. Но не станут ли они "дельфистами" от того, что научились писать приложения "мышкой"?

R>Сейчас наиболее общий рецепт выглядит примерно следующим образом:

R> — Создать кол-во потоков по кол-ву аппаратных потоков. Как следствие — кол-во потоков не должно быть «зашито» в программу, т.к. она может выполняться на разных платформах. И как второе следствие – управление кол-вом потоков не должно быть заботой прикладного программиста (ну по крайней мере того же программиста, но когда он играет роль прикладного ).

В общем представлении да, но как всегда, досадные мелочи всё ставят на свои места. Жаль, на них редко обращают внимание.

R> — Работа должна быть распределена по потокам [примерно] равномерно. Соотв. это тоже не получится зашивать в программу и поручать прикладному программисту, т.к. кол-во потоков и кол-во и содержание работы меняться.


Да.

R> — Нельзя экстенсивно применять мьютесы/синхронизацию/блокировки. Т.к. это фактически заставит систему сериализоваться и выполняться «на одном ядре». Ни о какой масштабируемости тут не может быть и речи.


Да. Всё должно быть в меру.

R> — По возможности надо элиминировать разделяемые данные. Совместная работа над одними модифицируемыми данными сейчас работает ооочень медленно и становится одним из важнейших новых боттлнеков аппаратной платформы, на ряду с тактами ядра, шиной к памяти, диском, сетью. И никаких изменений в лучшую сторону тут не предвидится. Только в худшую. (Это не относится к константным данным, их можно и нужно разделять между потоками)


Да.

R>Если выразить это более кратко: *каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.

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

А как же прогресс в деле обSMPчивания MacOS? Ведь могут же на уровне операционки всё сделать красиво, а программисту-прикладнику оставить его работу!

<Остальное поскипано, так как говорить об том в рамках темы можно долго и нудно>
Re[2]: Многопоточность сегодня
От: сипласплас  
Дата: 10.10.07 20:00
Оценка:
Здравствуйте, iZEN, Вы писали:

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


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

R>> — Можно завести любое кол-во потоков. Иимеется в виду любое в пределах сотни. Т.е. кол-во потоков определяется исключительно потребностью архитектуры, но не аппаратной платформой.

ZEN>Спорная посылка.

ZEN>Количество потоков научились оформлять в пул и обычно проводят тестироание производительности в зависимости от размера пула.

При чем здесь это?

R>> — Можно произвольным образом распределить работу по потокам. Т.к. всё равно всё выполняется на одном ядре, то это не имеет значения.


ZEN>Спорная посылка.

ZEN>Девять рожениц никогда не родят одного дитя за один месяц.

???

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


ZEN>Никогда такого не было.

ZEN>Блокировки всегда советовали применять, если по-другому нельзя. Избавление от блокировок где только можно -- одна из самых творческих и востребованных задач многопоточного программирования.
ZEN>От GIANT_LOCK избавляются всеми доступными способами. Во FreeBSD, кстати, за минувший год проделана колоссальная работа по удалению глобальной блокировки в ядре.

Где не было? Прочтите внимательнее. Это он о том, как _сейчас_ принято рассуждать

R>> — Можно произвольным образом разделять данные между потоками. Т.к. процессор один, то это никак не влияет на производительность и масштабируемость. Фактически система работает так, как будто поток один, просто он выполяет то одну функцию, то другую.


ZEN>Спорная посылка.

ZEN>Любая книжка по многопоточному программированию с 80-х годов ничего не говорит о том, что многопоточная программа будет выполнятся на одноядерном процессоре. Даже предположения приводятся противоположные: "А что будет, если ваша многопоточная программа будет выполняться на одном ядре -- будет велика вероятность взаимоблокировки на общих данных. Так что нужно делать так-то и так-то, чтобы этого не произошло.". У Таненбаума в книжках, кстати, есть масса примеров на этот счёт.
ZEN>Так что ВСЕ_ВСЁ_ЗНАЛИ.

Опять же, читаем внимательно к чему это.

[]
R>>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

ZEN>Это область инноваций в код Windows, так как другие операционные системы более-менее переболели "одноядерностью" (MacOS 9 -> MacOS X; FreeBSD 4.x,5.x,6.x -> FreeBSD 7.0).


Что значит переболели? Они выкидывают мьютексы и за тебя вставляют lock-free?

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


ZEN>Это уже изобрели в Sun.

ZEN>откройте для себя процессор UltraSPARC T1 (в UMA-среде) и программную архитектуру управления многопоточностью в Solaris 10. Ключевые слова: CMT, ThreadLiblaries, Light-weight process (LWP), Kernel Level threads, Thread Local Storage (TLS).

И как это нам помогает писать быстрые мультитрэдные аппликухи?

[]

R>>Я уверен, что значительная часть многопоточных систем «старой школы» будут быстрее работать на многоядерном процессоре, если банально привязать все потоки программы к одному ядру! Т.к. синхронизация всё равно убивает потенциальный параллелизм, а разделение данных вносит коллосальные пенальти.


R>>Некоторое время назад я был свидетелем следующей ситуации. Серверное ПО запустили на двух-процессорной машине (в надежде, что оно будет работать в 2 раза быстрее. ха-ха). Оно стало работать в 10 (!) раз медленнее (как потом оказалось причиной было постоянное разделение модифицируемых данных между двумя потоками).


ZEN>Это целиком зависит от профессионального мастерства программиста, пишущего многопоточное приложение. Обучены далеко не многие.

ZEN>Возможно, Intel предлагает библиотеки, облегчающие процесс написания хорошо масштабируемых по нескольким вычислительным ядрам приложения. Это полезно в первую очередь новичкам. Но не станут ли они "дельфистами" от того, что научились писать приложения "мышкой"?

А что плохого, если они станут "дельфистами"?

[]

R>>Если выразить это более кратко: *каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.

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

ZEN>А как же прогресс в деле обSMPчивания MacOS? Ведь могут же на уровне операционки всё сделать красиво, а программисту-прикладнику оставить его работу!


Что-то ты путаешь. Единственное, что может делать ОС — пытаться хорошо шедулить треды. Пока все. Все остальное должен делать девелопер.

ZEN><Остальное поскипано, так как говорить об том в рамках темы можно долго и нудно>


Прости, но все мимо кассы
Re[2]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.10.07 20:16
Оценка: 16 (3)
Здравствуйте, iZEN

<...все саркастические комментарии к посту remark-а поскипаны...>

Remark писал не о том, насколько хорошо работает на многоядерных машинах ОС и насколько отшлифован в ней шедулер. А о том, как быть программисту, когда в его распоряжении оказывается несколько процессоров.

Например. В случае одного ядра выгодно было выделять отдельные нити для выполнения операций ввода-вывода. Скажем на отдельной нити работает ACE_Reactor, который прослушивает N сокетов и активирует M ACE_Event_Handler-ов. Event_Handler-ы вычитывают данные из сокета, оформляют их в сообщения и ставят в очередь сообщений другой нити для обработки. А так же извлекают из своих очередей сообщений сообщения с исходящими данными в своих методах handle_output (когда Reactor обнаруживает готовность сокета к записи). На одном ядре схема работает отлично.

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.10.07 20:21
Оценка: 12 (2)
Здравствуйте, remark, Вы писали:

R>Зато при использовании процессов ты гарантированно:

R> — Имеешь очень дорогое взаимодействие. Это скорее всего будет 2 системных вызова, 2 полных копирования данных, плюс ещё синхронизация и ещё куча непонятно чего. Более-менее не так ужасно тормозно это может быть только с IO-Lite:
R>http://www.usenix.org/publications/library/proceedings/osdi99/full_papers/pai/pai.pdf
R>Хотя его видимо никто не использует.
R>В случае же потоков это может действительно очень-очень-очень быстро. Порядка нескольких тактов.
R> — Имеешь копии read-mostly данных в памяти и каждого процесса. И в кэше.
R> — Имеешь сложность запуска/остановки/настройки приложения.

Зато имеешь возможно безболезненно килять сбойные процессы. Тогда как в многопоточном приложении придется убивать всех.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Многопоточность сегодня
От: Cyberax Марс  
Дата: 10.10.07 20:49
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

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

А почему тут происходят переключения контекстов?
Sapienti sat!
Re[3]: Многопоточность сегодня
От: сипласплас  
Дата: 10.10.07 20:53
Оценка:
Здравствуйте, eao197, Вы писали:

[]

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


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

E>Вопрос в том, как перепроектировать подобное приложение на два/четыре/восемь ядер сейчас так, чтобы при появлении 80(!) ядер приложение не пришлось перепроектировать с нуля заново.
Re[4]: Многопоточность сегодня
От: сипласплас  
Дата: 10.10.07 20:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

C>А почему тут происходят переключения контекстов?

Оно происходит, если оба треда сидят на одном ядре, как я понял. А вот к чему это я тоже не понял
Re: Многопоточность сегодня
От: RegisteredUser  
Дата: 11.10.07 01:22
Оценка:
Здравствуйте, remark, Вы писали:

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


А как же array languages типа старый APL и новые J и K? Не уверен что их текущая реализация реально использует многоядерность (хотя за K не скажу, уж больно быстрый по слухам), Но принциально, в силу "нефоннеймовской" архитектуры, при правильной реализации и правильном стиле программирования (да, на J тоже циклами можно писать... но не нужно ), все теоретически должно работать...
Re[3]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 02:17
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


1. нет, не зовет, и откуда у тебя такая странная мысль?
2. и вообще, какое это имеет отношение к моему вопросу?
Re[4]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 05:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>А почему тут происходят переключения контекстов?

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Многопоточность сегодня
От: minorlogic Украина  
Дата: 11.10.07 05:35
Оценка:
Совершенно забыл, что существует прослойка профи которая давно и успешно занимается распаралеливанием.

Это языки , програмисты, фреймворки для распределенных расчетах для суперкомпьютеров и распределенных вычислительных сетей. К сожалению инженеры для десктопов , не обращают на них должного внимания , и во многом пытаются изобрести велосипед.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 06:57
Оценка:
Здравствуйте, remark, Вы писали:

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


Кстати, а где есть такие форумы?
Re: Многопоточность сегодня
От: Кодёнок  
Дата: 11.10.07 07:06
Оценка: 24 (6) :)))
Здравствуйте, 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 ядер — работает просто превосходно.
Re[2]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 07:11
Оценка:
Здравствуйте, Кодёнок, Вы писали:

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


quicksort можно параллелить. При каждом делении массива пополам, каждую половину можно обрабатывать отдельным ядром. Вопрос только в том, что распределение задач по ядрам должно быть очень легковесным — а в рамках существующей архитектуры x86/64 такой возможности похоже нет
Re[3]: Многопоточность сегодня
От: Кодёнок  
Дата: 11.10.07 07:22
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


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


Сортировку вставками или пузырьком нельзя. Многие алгоритмы на графе нельзя. Вопрос лишь в принципиальном существовании примера, чтобы показать, что чудес не будет.
Re: Многопоточность сегодня
От: ddaa Россия  
Дата: 11.10.07 07:31
Оценка: -1 :)
Здравствуйте, remark, Вы писали:

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

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

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

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

А вот сюдахотя бы посмотрите.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Многопоточность сегодня
От: Кодёнок  
Дата: 11.10.07 07:53
Оценка:
Здравствуйте, LaptevVV, Вы писали:

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

LVV>А вот сюдахотя бы посмотрите.

Там целый большой сайт Куда именно смотреть?
Re[3]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 08:13
Оценка:
Здравствуйте, 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>О играх и серном ПО и говорить нечего.

Для игр — важна память+граф карта. Для серверного ПО, проблемы синхронизации не стоит. Фактически — на каждого пользователя по ядру, с разделением данных. Но я говорил именно о десктопах.
Re[4]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 08:20
Оценка: 8 (1) +1
Здравствуйте, remark, Вы писали:

R>Меня лично на PIV3.0+1Гб не устраивает скорость компиляции,

У меня тормозит компиляция NET, только когда много сборок. Теже файлы но в одной сборке компилируются мухой. Соответсвенно вывод что проблема в диск+скорость кэша(то бишь доступа к озу).
Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции.
R>не устраивает скорость работы навороченных GUI типа Open Office/MS Visual Studio,
Основные проблемы память+диск.
R>не устраивает скорость запуска очень многих программ.
Основные проблемы память+диск.
Re[4]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 08:23
Оценка: 2 (2) +1
Здравствуйте, Кодёнок, Вы писали:

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


"Если есть хоть один случай, когда нельзя — значит, нельзя вообще" — это только мне чудится, что в этой логике есть баааальшущий изъян?
Re[4]: Многопоточность сегодня
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 11.10.07 08:33
Оценка:
Здравствуйте, GlebZ, Вы писали:

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

GZ>Для десктопов — нет.
Компилятору надо больше гигагерц.

R>>Над чем сейчас работают — распознование голоса/видео на лету.

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

R>>О играх и серном ПО и говорить нечего.

GZ>Для игр — важна память+граф карта. Для серверного ПО, проблемы синхронизации не стоит. Фактически — на каждого пользователя по ядру, с разделением данных. Но я говорил именно о десктопах.
AI в играх просчитывает именно процессор. Если поставить побольше умных ботов в каком-нибудь шутере — тормозить будет. И не из-за нехватки видео- или оперативной памяти.
Re[5]: Многопоточность сегодня
От: Кодёнок  
Дата: 11.10.07 08:40
Оценка: -1
Здравствуйте, Andrei F., Вы писали:

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


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


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

1 + 2 = нельзя вообще
=> автоматического распараллеливания в ближайшее время не будет
Re[6]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 09:03
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>1. Есть случаи, когда нельзя.

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

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


Вычеркиваем "вообще", вписываем "сейчас"
Надо всё-таки следить за точностью формулировок
Re[2]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.10.07 09:09
Оценка: +4
Здравствуйте, ddaa, Вы писали:
К сожалению, это красивая сказка.
а) судьба шлангов никого не интересует. Речь о людях, обеспечивающих требуемую функциональность в традиционной архитектуре.
б) судьба сферических идеальных разработчиков тоже никого не интересует. Просто потому, что таких нет. Речь о людях, обеспечивающих требуемую функциональность в
традиционной архитектуре.

В итоге, пост, в общем-то, о том, что в ситуации виноваты не программисты. Сейчас меняется среда выполнения программ; и она требует новых подходов, т.к. старые подходы не работают.
Много лет нас убеждали, что технологии, в общем-то, в порядке, "мы просто не умеем их готовить". Продолжающееся 100% отсутствие "правильных поваров" побуждает всё же повернуть обвиняющий перст в сторону технологий.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 10:16
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


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


AF>1. нет, не зовет, и откуда у тебя такая странная мысль?


по моим сведениям присванивание ссылки в c# — атомарно. Кроме того, нужно делать memory barrier. А он делается с пом. InterlockedXXX — синхронизация кешей

AF>2. и вообще, какое это имеет отношение к моему вопросу?


Это имеет отношение к синхронизации кешей
Re[5]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 10:17
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Компилятору надо больше гигагерц.

Для чего? Лексический разбор работает на ура. Синтаксический тоже. Да и к тому же они плохо параллелятся. Оптимизация в основном на графах. А это рандомный доступ к памяти. Угадай кто-при этом тормозит?

N>Э нет, платка поможет только в очень немногих случаях. Те системы видеонаблюдения с десятком видеоканалов требуют ооочень больших ресурсов процессора.

Не совсем. Алгоритмы обнаружения достаточно просты(если не переводить в трехмерный вид). Проблема в том, что нужно перегнать большое кол-во информации, и опять упираемся в память.

R>>>О играх и серном ПО и говорить нечего.

GZ>>Для игр — важна память+граф карта. Для серверного ПО, проблемы синхронизации не стоит. Фактически — на каждого пользователя по ядру, с разделением данных. Но я говорил именно о десктопах.
N>AI в играх просчитывает именно процессор. Если поставить побольше умных ботов в каком-нибудь шутере — тормозить будет. И не из-за нехватки видео- или оперативной памяти.
Не эксперт в геймах, потому определенно сказать не могу — что является бутылочным горлышком в данном случае.
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 10:22
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


N>>Компилятору надо больше гигагерц.

GZ>Для чего? Лексический разбор работает на ура. Синтаксический тоже. Да и к тому же они плохо параллелятся. Оптимизация в основном на графах. А это рандомный доступ к памяти. Угадай кто-при этом тормозит?

Если граф read-mostly (например, уже построенное AST), то — ядро. Не память.
AST хорошо распараллеливается на функции, т.е. первое ядро оптимизирует первые 25% функций файла, второе — вторые 25% и т.д.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 10:26
Оценка: -1
Здравствуйте, сипласплас, Вы писали:

С>А он делается с пом. InterlockedXXX — синхронизация кешей

Interlocked — не относится к синхронизации кэшей. Кэш управляется чисто аппаратно. Interlocked используется для синхронизации доступа к обычной памяти.
Re[7]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 10:28
Оценка:
Здравствуйте, remark, Вы писали:

R>Если граф read-mostly (например, уже построенное AST), то — ядро. Не память.

R>AST хорошо распараллеливается на функции, т.е. первое ядро оптимизирует первые 25% функций файла, второе — вторые 25% и т.д.
Не забывай о стоимости доступа к основной памяти.
Re[5]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 10:28
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


AF>>1. нет, не зовет, и откуда у тебя такая странная мысль?


С>по моим сведениям присванивание ссылки в c# — атомарно. Кроме того, нужно делать memory barrier. А он делается с пом. InterlockedXXX — синхронизация кешей



Сам точно не в курсе. Меня тоже этот вопрос интересовал.
У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 10:31
Оценка:
Здравствуйте, remark, Вы писали:

[]

R>Сам точно не в курсе. Меня тоже этот вопрос интересовал.

R>У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.

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

R>
Re[6]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 10:32
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


С>>А он делается с пом. InterlockedXXX — синхронизация кешей

GZ>Interlocked — не относится к синхронизации кэшей. Кэш управляется чисто аппаратно. Interlocked используется для синхронизации доступа к обычной памяти.

Почитай Рихтера. Он "может" вести к синхронизации кешей.
Re[7]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 10:34
Оценка:
Здравствуйте, сипласплас, Вы писали:

R>>Сам точно не в курсе. Меня тоже этот вопрос интересовал.

R>>У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.

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


Я думаю, что это просто запрещено.
А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.

R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 10:35
Оценка: +2
Здравствуйте, Кодёнок, Вы писали:

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


Синхронизация -- это неотъемлимая часть окружающего нас мира. И, поскольку программы являются некоторым отражением этого мира, никуда от проблем синхронизации не деться. В той или иной форме синхронизация всегда будет присутствовать (ожидания на мутексах, событиях, условных переменных, механизмах рандеву или получения сообщения).

Мне не доводилось использовать Ada и ее механизм рандеву, но синхронизация на mutex-ах/cond_var-ах не слаще таковой на обмене сообщениями.

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


Erlang разрабатывался для достаточно специфических вещей, в которых за мелкими параллельными процессами ходить далеко не нужно было. Поэтому телефонные свитчи на Erlang-е программируются успешно, а вот попробуйте на Erlang-е Emacs или Vim написать -- откуда там взятся мелким процессам?

Задач, которые сейчас решаются с помощью компьютера, вагон и маленькая тележка. И со временем их число стабильно увеличиваться. Поэтому рачитывать на то, что какой-то один инструмент сможет успешно решать их все -- наивно.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 10:36
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


R>>Если граф read-mostly (например, уже построенное AST), то — ядро. Не память.

R>>AST хорошо распараллеливается на функции, т.е. первое ядро оптимизирует первые 25% функций файла, второе — вторые 25% и т.д.
GZ>Не забывай о стоимости доступа к основной памяти.

Просто считать один раз AST не дорого. Если, конечно, оно лежит в более-менее компактном виде, а не побито на биты и не разбросано хаотично по всему адресному пространству.
Обработка его будет значительно дольше.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 10:58
Оценка:
Здравствуйте, сипласплас, Вы писали:

С>Почитай Рихтера. Он "может" вести к синхронизации кешей.

Это уже побочно. Ссылка в Net атомарно, потому что GC перед сборкой мусора останавливает работу программы, собирает граф живых объектов (на который существуют ссылки хранящиеся в том числе в регистрах процессора) и перемещает требуемые объекты с переписыванием ссылок. Кэш тут вообще не причем. Interlocked при присваивании не делается.
Re[8]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 11:08
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


С>>Почитай Рихтера. Он "может" вести к синхронизации кешей.

GZ>Это уже побочно.

Ах значит вес-таки может вести к сбросу кеша? Уже лучше.

GZ>Ссылка в Net атомарно, потому что GC перед сборкой мусора останавливает работу программы, собирает граф живых объектов (на который существуют ссылки хранящиеся в том числе в регистрах процессора) и перемещает требуемые объекты с переписыванием ссылок. Кэш тут вообще не причем. Interlocked при присваивании не делается.


При чем здесь сборка мусора? А между ними что будем делать с изменением ссылок в разных потоках?
Re[3]: Многопоточность сегодня
От: Кодёнок  
Дата: 11.10.07 11:08
Оценка:
Здравствуйте, eao197, Вы писали:

E>а вот попробуйте на Erlang-е Emacs или Vim написать -- откуда там взятся мелким процессам?


Мелкие процессы нужны, что можно было параллелить. Если параллелить не надо, то и делить на подпроцессы не надо.

Если в Emacs или Vi есть что синхронизировать, значит там есть параллельные процессы. Если там есть параллельные процессы, то сериализацию доступа к общим данным можно сменить на посылку сообщения процессу-контроллеру над этими данными. Синхронизация остается, только её уже как минимум не надо делать вручную над каждым общим ресурсом, создавая возможность ошибки в каждом таком месте.

Я не могу придумать случая, когда многопоточность с ручной синхронизацией нельзя было бы заменить на обмен сообщениями.
Re[8]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 11:09
Оценка:
Здравствуйте, remark, Вы писали:

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


R>>>Сам точно не в курсе. Меня тоже этот вопрос интересовал.

R>>>У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.

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


R>Я думаю, что это просто запрещено.


нет.

R>А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.


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

R>>>

R>
Re[8]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 11:10
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


С>>Почитай Рихтера. Он "может" вести к синхронизации кешей.

GZ>Это уже побочно. Ссылка в Net атомарно, потому что GC перед сборкой мусора останавливает работу программы, собирает граф живых объектов (на который существуют ссылки хранящиеся в том числе в регистрах процессора) и перемещает требуемые объекты с переписыванием ссылок. Кэш тут вообще не причем. Interlocked при присваивании не делается.
Хотя нет, соврал. В нем нужна синхронизация ссылок из старых поколений в новые поколения в случае Concurrent режима. Но про interlocked там я не слышал.
Re[9]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 11:14
Оценка: +1 -1
Здравствуйте, сипласплас, Вы писали:

R>>А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.


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


На x86 да, а почему бы и нет? Это экстремально быстро.

R>>>>

R>>

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 11:19
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Я не могу придумать случая, когда многопоточность с ручной синхронизацией нельзя было бы заменить на обмен сообщениями.


Например, механизм producer/consumer с большими объемами данных. Скажем, видеопроигрыватель, где процесс подкачки данных с диска занимает очередной буфер и заполняет его, а процесс восспроизведения не может получить доступ к буферу до окончания закачки.

Какие выигрышы даст здесь обмен сообщениями по сравнению с ожиданием на cond_var/mutex-е?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[9]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 11:21
Оценка:
Здравствуйте, сипласплас, Вы писали:

С>При чем здесь сборка мусора? А между ними что будем делать с изменением ссылок в разных потоках?

А в чем проблема то? Адрес экземпляра объекта "неизменяемо". Единственный кто может его изменить — GC. Присваивание int — атомарно на аппаратном уровне. Так в чем дело?
Re[6]: Многопоточность сегодня
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 11.10.07 11:24
Оценка:
Здравствуйте, GlebZ, Вы писали:

N>>Э нет, платка поможет только в очень немногих случаях. Те системы видеонаблюдения с десятком видеоканалов требуют ооочень больших ресурсов процессора.

GZ>Не совсем. Алгоритмы обнаружения достаточно просты(если не переводить в трехмерный вид). Проблема в том, что нужно перегнать большое кол-во информации, и опять упираемся в память.

обнаружение движения — простая (вычислительная) задача, которая давным-давно решена. Сейчас главный вопрос — распознавание движущихся объектов, оставленных предметов. Т.е. не распознавание лиц или автомобильных номеров (что подразумевает поиск по базе данных), а просто определение класса объекта: человек, автомобиль и т.д. Даже самые быстрые на сегодняшний момент методы не позволяют это делать real-time на нескольких видеоканалах. А ведь их может быть очень много!
Re[10]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 11:27
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


С>>При чем здесь сборка мусора? А между ними что будем делать с изменением ссылок в разных потоках?

GZ>А в чем проблема то? Адрес экземпляра объекта "неизменяемо". Единственный кто может его изменить — GC. Присваивание int — атомарно на аппаратном уровне. Так в чем дело?

не забывай про необходимый memory barrier
Re[10]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 11:29
Оценка:
Здравствуйте, remark, Вы писали:

[]

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


R>На x86 да, а почему бы и нет? Это экстремально быстро.


remark, а memory barrier? Или это я один тут параноик?

R>>>>>

R>>>
R>
Re[5]: Многопоточность сегодня
От: Кодёнок  
Дата: 11.10.07 11:42
Оценка:
Здравствуйте, eao197, Вы писали:

E>Например, механизм producer/consumer с большими объемами данных. Скажем, видеопроигрыватель, где процесс подкачки данных с диска занимает очередной буфер и заполняет его, а процесс восспроизведения не может получить доступ к буферу до окончания закачки.


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

E>Какие выигрышы (жи/ши пиши через и, а жы/шы — через ы?) даст здесь обмен сообщениями по сравнению с ожиданием на cond_var/mutex-е?


Да никаких. Речь в изначальном посте вообще-то шла о том, как современной программе загрузить десятки процессоров. Описанная тобой задача в принципе не загрузит больше двух.

Речь не идет о том, чтобы Erlang автоматически за тебя что-то сделал. Речь о том, что то же самое делается удобнее. Параллелит-то всё еще программист. Только шанс допустить ошибку куда меньше, чем забыть захватить мьютекс или захватить его на излишне долгое время и тем самым затормозить программу.

Например, какие изменения тебе нужно внести в архитектуру, чтобы проигрыватель мог послать «напоминание» и получить частично заполненный буфер, чтобы пользователь не увидел подвисания картинки, в надежде что задержка чтения временная и вот-вот все нормализуется? Сменить блокирующее ожидание сокета на свой цикл проверки, чтобы был появился шанс проверить флаг?

В архитектуре изолированных процессов, producer получает сообщение от сокета о приеме данных, и добавляет в буфер, или получает сообщение от проигрывателя, и отдает частично заполненный. Расширение делается добавлением всего одного сообщения.
Re[11]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 11:59
Оценка:
Здравствуйте, сипласплас, Вы писали:

С>не забывай про необходимый memory barrier

А что memory barrier? Это всего лишь еще одна ссылка на тот же адрес. Даже если они будут различаться с хранящейся в OЗУ, после сборки выполнение продолжится, и будет присвоен корректный адрес. Атомарность не пострадает.
Re[6]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 12:05
Оценка:
Здравствуйте, Кодёнок, Вы писали:

E>>Например, механизм producer/consumer с большими объемами данных. Скажем, видеопроигрыватель, где процесс подкачки данных с диска занимает очередной буфер и заполняет его, а процесс восспроизведения не может получить доступ к буферу до окончания закачки.


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


Ожидание в любом случае придется делать вручную. Будет ли это mutex.acquire или receive->BUFFER_READY.

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

E>>Какие выигрышы (жи/ши пиши через и, а жы/шы — через ы?) даст здесь обмен сообщениями по сравнению с ожиданием на cond_var/mutex-е?


Кё>Да никаких. Речь в изначальном посте вообще-то шла о том, как современной программе загрузить десятки процессоров. Описанная тобой задача в принципе не загрузит больше двух.


Это уже придирки.

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


На основании какого опыта в Erlang вы делаете такие утверждения?

Кё>Например, какие изменения тебе нужно внести в архитектуру, чтобы проигрыватель мог послать «напоминание» и получить частично заполненный буфер, чтобы пользователь не увидел подвисания картинки, в надежде что задержка чтения временная и вот-вот все нормализуется? Сменить блокирующее ожидание сокета на свой цикл проверки, чтобы был появился шанс проверить флаг?


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


Если в архитектуре изолированных процессов producer выполняет блокирующие операции ввода-вывода, вы можете отсылать ему сообщения сколько угодно.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 12:16
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


С>>не забывай про необходимый memory barrier

GZ>А что memory barrier? Это всего лишь еще одна ссылка на тот же адрес. Даже если они будут различаться с хранящейся в OЗУ, после сборки выполнение продолжится, и будет присвоен корректный адрес. Атомарность не пострадает.

При чем здесь _сборка_? Я вот про что (как назло, где Wolfhound, где IT, где Vlad наконец? Неужели обязательно надо написать "с++ рулит!!!" что-бы они тут же подоспели?):


public class SharedResource{}

public class test
{
    SharedResource _shared = new SharedResource();
    Thread         _thread = null;

    void Start()
    {
          _thread = new Thread( new ThreadStartDelegate(this.ThreadProc) );
          Sleep(1000);
          _shared = null;
          Sleep(1000);
          _thread.Join();          
   }    

   private void ThreadProc()
   {
         //а тут мы вовсю юзаем _thread...
   }
}
Re[3]: Многопоточность сегодня
От: iZEN СССР  
Дата: 11.10.07 12:18
Оценка: :)))
Здравствуйте, eao197, Вы писали:

E>Remark писал не о том, насколько хорошо работает на многоядерных машинах ОС и насколько отшлифован в ней шедулер. А о том, как быть программисту, когда в его распоряжении оказывается несколько процессоров.


Ему надо было точно разграничить области: прикладная область программирования и системная область программирования. Иначе получился абстрактный призыв ко всем слоям населения, охваченным электрическими сетями.

E>Например. В случае одного ядра выгодно было выделять отдельные нити для выполнения операций ввода-вывода. Скажем на отдельной нити работает ACE_Reactor, который прослушивает N сокетов и активирует M ACE_Event_Handler-ов. Event_Handler-ы вычитывают данные из сокета, оформляют их в сообщения и ставят в очередь сообщений другой нити для обработки. А так же извлекают из своих очередей сообщений сообщения с исходящими данными в своих методах handle_output (когда Reactor обнаруживает готовность сокета к записи). На одном ядре схема работает отлично.


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


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


Я не знаю, что такое "ACE_Reactor" -- впервые слышу об этой идиоме программирования. И всё, что с ней связано, скорее всего, относится к практическому аспекту конкретной реализации какой-то сущности. Так что индуцировать на её основе принципы ДЛЯ_ВСЕХ не имеет смысла. Она может быть использована лишь как пример, но не эталон (не)применимости.
Re[4]: Многопоточность сегодня
От: LaptevVV Россия  
Дата: 11.10.07 12:21
Оценка:
Здравствуйте, Кодёнок, Вы писали:

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


Кё>>> Алгоритм для многих исполнителей — я о таком не слышал.

Кё>Там целый большой сайт Куда именно смотреть?
А там действительно много всего о параллельных алгоритмах.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[11]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 12:29
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


R>>На x86 да, а почему бы и нет? Это экстремально быстро.


С>remark, а memory barrier? Или это я один тут параноик?


Нет, я тоже параноик.
Но на x86 тут можно и нужно делать без барьеров.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[13]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 12:34
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


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


С>>>не забывай про необходимый memory barrier

GZ>>А что memory barrier? Это всего лишь еще одна ссылка на тот же адрес. Даже если они будут различаться с хранящейся в OЗУ, после сборки выполнение продолжится, и будет присвоен корректный адрес. Атомарность не пострадает.

С>При чем здесь _сборка_? Я вот про что (как назло, где Wolfhound, где IT, где Vlad наконец? Неужели обязательно надо написать "с++ рулит!!!" что-бы они тут же подоспели?):


С>

С>public class SharedResource{}

С>public class test
С>{
С>    SharedResource _shared = new SharedResource();
С>    Thread         _thread = null;

С>    void Start()
С>    {
С>          _thread = new Thread( new ThreadStartDelegate(this.ThreadProc) );
С>          Sleep(1000);
С>          _shared = null;
С>          Sleep(1000);
С>          _thread.Join();          
С>   }    

С>   private void ThreadProc()
С>   {
С>         //а тут мы вовсю юзаем _thread...
С>   }
С>}

С>



После "захвата" _shared в ThreadProc() надо просто проверить на null. InterlockedXXX здесь не нужен.
И это надо сделать в люом случае в такой ситуации, даже если обращения к _shared защищено мьютексами.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 12:36
Оценка:
Здравствуйте, iZEN, Вы писали:

E>>Remark писал не о том, насколько хорошо работает на многоядерных машинах ОС и насколько отшлифован в ней шедулер. А о том, как быть программисту, когда в его распоряжении оказывается несколько процессоров.


ZEN>Ему надо было точно разграничить области: прикладная область программирования и системная область программирования. Иначе получился абстрактный призыв ко всем слоям населения, охваченным электрическими сетями.


Я не помню, чтобы remark говорил что-нибудь о разработке ОС в условиях многоядерности.

Чтоже до деления на прикладное и системное программирование...
Вот, например, сервера БД и встраиваемые БД -- это системное или прикладное программирование?
А компиляторы?
А Web-сервера?

ZEN>Я не знаю, что такое "ACE_Reactor" -- впервые слышу об этой идиоме программирования. И всё, что с ней связано, скорее всего, относится к практическому аспекту конкретной реализации какой-то сущности. Так что индуцировать на её основе принципы ДЛЯ_ВСЕХ не имеет смысла. Она может быть использована лишь как пример, но не эталон (не)применимости.


Мне кажется, вам самому нужно определиться с тем, что вы хотели сказать. Судя по всему, многие читатели поняли, о чем говорил remark. Вы же насоветовали ему лучше ознакомиться с Solaris, LWP, TLS и пр. Хотя суть этого совета от меня ускользнула.

ACE_Reactor -- это C++ный фреймворк в составе библиотеки ACE. Он берет на себя задачу контроля за состоянием N дескрипторов каналов ввода/вывода (под Unix-ом это могут быть пайпы, сокеты, файлы, под Windows -- сокеты/пайпы). За каждый канал должен отвечать специальный объект-наследник ACE_Event_Handler. Т.е. ACE_Reactor работает в качестве мультиплексора (или демультиплексора -- путаюсь в этих терминах) событий.

В простейшем случае ACE_Reactor является оберткой над while{} c select-ом внутри. Когда канал переходит в состояние готовности к чтению, Reactor вызывает у соответствующего Event_Handler-а метод handle_input. Когда канал переходит в состояние готовности к записи -- вызывается метод handle_output. И т.д.

ACE_Reactor используется в качестве базового слоя при реализации различных реактивных (т.е. реагирующих на происходящие события) сетевых служб. А уже что это будут за службы -- служба синхронизации времени, Web-сервер, сервер БД, балансировщих нагрузки или еще что -- зависит от задачи.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Многопоточность сегодня
От: iZEN СССР  
Дата: 11.10.07 12:42
Оценка:
Здравствуйте, GlebZ, Вы писали:

R>>Меня лично на PIV3.0+1Гб не устраивает скорость компиляции,

GZ>У меня тормозит компиляция NET, только когда много сборок. Теже файлы но в одной сборке компилируются мухой. Соответсвенно вывод что проблема в диск+скорость кэша(то бишь доступа к озу).
GZ>Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции.

Вы сами проверяли?
А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).

R>>не устраивает скорость работы навороченных GUI типа Open Office/MS Visual Studio,

GZ>Основные проблемы память+диск.
R>>не устраивает скорость запуска очень многих программ.
GZ>Основные проблемы память+диск.
Для этого придумали различные QuickStart'ы. Для OpenOffice есть. Недавно анонсирован и для последней версии JRE:
http://www.linux.org.ru/jump-message.jsp?msgid=2192306

Но всё это костыли. Если всё рабочее окружение отправить в своп, а при загрузке компьютера оотуда всё доставать в оперативку... Но можно использовать энергонезависимое ОЗУ большой ёмкости (несколько гигабайт) и отказаться от винчестера вообще, тогда все установленые приложения и система фактически имеют включенную готовность, как радиоприёмник.
Re[5]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 12:44
Оценка:
Здравствуйте, сипласплас, Вы писали:

С>по моим сведениям присванивание ссылки в c# — атомарно. Кроме того, нужно делать memory barrier. А он делается с пом. InterlockedXXX — синхронизация кешей


Твои сведения сильно ошибочные. Если ты сохранишь значение ссылки в переменной, которая видна потоку на другом ядре и не сделаешь в явном виде барьер памяти — это будет очень большой ошибкой.
Ты хотя бы представляешь себе потери в производительности, если каждое присваивание ссылки будет сделано через InterlockedExchange, который является full fence?
Re[6]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 13:02
Оценка:
Здравствуйте, iZEN, Вы писали:

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


R>>>Меня лично на PIV3.0+1Гб не устраивает скорость компиляции,

GZ>>У меня тормозит компиляция NET, только когда много сборок. Теже файлы но в одной сборке компилируются мухой. Соответсвенно вывод что проблема в диск+скорость кэша(то бишь доступа к озу).
GZ>>Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции.

ZEN>Вы сами проверяли?

ZEN>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).

Дак и VS2005 это _умеет_. Вам неочевидно почему этого не умеет VS2003? Не из-за винды же...

[]
Re[6]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 13:06
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


С>>по моим сведениям присванивание ссылки в c# — атомарно. Кроме того, нужно делать memory barrier. А он делается с пом. InterlockedXXX — синхронизация кешей


AF>Твои сведения сильно ошибочные.


Ошибочные в том, что при любое присваивание ссылки ведет к full fence?

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


Спасибо

AF>Ты хотя бы представляешь себе потери в производительности, если каждое присваивание ссылки будет сделано через InterlockedExchange, который является full fence?


Вау! Какой слог!
Re[14]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 13:07
Оценка:
Здравствуйте, remark, Вы писали:

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


[]

R>После "захвата" _shared в ThreadProc() надо просто проверить на null. InterlockedXXX здесь не нужен.

R>И это надо сделать в люом случае в такой ситуации, даже если обращения к _shared защищено мьютексами.

А если заменить _shared = null на _shared = new SharedResource()? Ты понял о чем я?

R>
Re[12]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 13:09
Оценка:
Здравствуйте, remark, Вы писали:

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


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


R>>>На x86 да, а почему бы и нет? Это экстремально быстро.


С>>remark, а memory barrier? Или это я один тут параноик?


R>Нет, я тоже параноик.

R>Но на x86 тут можно и нужно делать без барьеров.

Почему?!

R>
Re[5]: Многопоточность сегодня
От: iZEN СССР  
Дата: 11.10.07 13:17
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>>>Remark писал не о том, насколько хорошо работает на многоядерных машинах ОС и насколько отшлифован в ней шедулер. А о том, как быть программисту, когда в его распоряжении оказывается несколько процессоров.


iZEN>>Ему надо было точно разграничить области: прикладная область программирования и системная область программирования. Иначе получился абстрактный призыв ко всем слоям населения, охваченным электрическими сетями.


E>Я не помню, чтобы remark говорил что-нибудь о разработке ОС в условиях многоядерности.


E>Чтоже до деления на прикладное и системное программирование...

E>Вот, например, сервера БД и встраиваемые БД -- это системное или прикладное программирование?

Это прикладное программирование.

E>А компиляторы?


Прикладное.

E>А Web-сервера?


Прикладное.

Что системное программирование: то, что работает в режиме ядра -- это прежде всего драйверы и шедулер аппаратных потоков исполнения.

iZEN>>Я не знаю, что такое "ACE_Reactor" -- впервые слышу об этой идиоме программирования. И всё, что с ней связано, скорее всего, относится к практическому аспекту конкретной реализации какой-то сущности. Так что индуцировать на её основе принципы ДЛЯ_ВСЕХ не имеет смысла. Она может быть использована лишь как пример, но не эталон (не)применимости.


E>Мне кажется, вам самому нужно определиться с тем, что вы хотели сказать. Судя по всему, многие читатели поняли, о чем говорил remark. Вы же насоветовали ему лучше ознакомиться с Solaris, LWP, TLS и пр. Хотя суть этого совета от меня ускользнула.


Да только что нашёл в Google, что такое ACE. Примочка на C++ для решения вдруг возникших проблем с управлением нагрузкой многоядерных процессоров.

E>ACE_Reactor -- это C++ный фреймворк в составе библиотеки ACE. Он берет на себя задачу контроля за состоянием N дескрипторов каналов ввода/вывода (под Unix-ом это могут быть пайпы, сокеты, файлы, под Windows -- сокеты/пайпы). За каждый канал должен отвечать специальный объект-наследник ACE_Event_Handler. Т.е. ACE_Reactor работает в качестве мультиплексора (или демультиплексора -- путаюсь в этих терминах) событий.


E>В простейшем случае ACE_Reactor является оберткой над while{} c select-ом внутри. Когда канал переходит в состояние готовности к чтению, Reactor вызывает у соответствующего Event_Handler-а метод handle_input. Когда канал переходит в состояние готовности к записи -- вызывается метод handle_output. И т.д.


E>ACE_Reactor используется в качестве базового слоя при реализации различных реактивных (т.е. реагирующих на происходящие события) сетевых служб. А уже что это будут за службы -- служба синхронизации времени, Web-сервер, сервер БД, балансировщих нагрузки или еще что -- зависит от задачи.



На его основе что-либо системное сделали (работающее в ядре ОС) или делают только приложения, так как на основе Pthreads и LWP? (Инетресуюсь, потому что хочу провести/или не провести черту применимости ACE между системным и прикладным использованием)
Re[5]: Многопоточность сегодня
От: Sergey Россия  
Дата: 11.10.07 13:18
Оценка:
> Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции.

Здрасте-приехали. А че у меня тогда инкредибилд пересобирает солюшен за 20-30 минут, в то время как локальная пересборка — более 2 часов?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[10]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 13:22
Оценка:
Здравствуйте, remark, Вы писали:

R>>>А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.


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


R>На x86 да, а почему бы и нет? Это экстремально быстро.


Тут будет возможна ситуация, когда на другом ядре обновленное значение указателя уже будет в кэше, а сами данные, на которые он указывает — нет. Поэтому на многоядерной системе так делать нельзя. На одноядерной можно, но тоже есть ограничение — переменная с указателем должна быть правильно выровнена.
Re[15]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 13:24
Оценка: -1
Здравствуйте, сипласплас, Вы писали:

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


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


С>[]


R>>После "захвата" _shared в ThreadProc() надо просто проверить на null. InterlockedXXX здесь не нужен.

R>>И это надо сделать в люом случае в такой ситуации, даже если обращения к _shared защищено мьютексами.

С>А если заменить _shared = null на _shared = new SharedResource()? Ты понял о чем я?


Тогда это можно сделать без InterlockedXXX. И без барьеров памяти вообще на x86.
Просто обычное сохранение/загрузка указателя.

R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 13:25
Оценка:
Здравствуйте, сипласплас, Вы писали:

С>Ошибочные в том, что при любое присваивание ссылки ведет к full fence?


Не ведет, конечно. Хотя меня интересовал другой вопрос — как обмениваться данными между ядрами, не залезая во внешнюю память. Ответ, боюсь — никак.

С>Вау! Какой слог!


Рад, что тебе нравится
Re[13]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 13:38
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


R>>>>На x86 да, а почему бы и нет? Это экстремально быстро.


С>>>remark, а memory barrier? Или это я один тут параноик?


R>>Нет, я тоже параноик.

R>>Но на x86 тут можно и нужно делать без барьеров.

С>Почему?!



Скетч кода примерно такой (в терминах С++):

std::atomic<int*> p;

void thread1()
{
  int* p2 = new int();
  p.store(p2, std::msync::ssb); // sink-store barrier -- release not affecting loads
}

void thread2()
{
  int p2 = p.load(std::msync::ddacq); // acquire with data dependency 
}



На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq.
На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.


R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 13:41
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Да только что нашёл в Google, что такое ACE. Примочка на C++ для решения вдруг возникших проблем с управлением нагрузкой многоядерных процессоров.




з.ы. ACE существует с 1993 года и является самой портируемой С++ библиотекой, и одной из самых распространённых. Для сведения.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 13:42
Оценка:
Здравствуйте, Andrei F., Вы писали:

R>>>>А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.


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


R>>На x86 да, а почему бы и нет? Это экстремально быстро.


AF>Тут будет возможна ситуация, когда на другом ядре обновленное значение указателя уже будет в кэше, а сами данные, на которые он указывает — нет. Поэтому на многоядерной системе так делать нельзя. На одноядерной можно, но тоже есть ограничение — переменная с указателем должна быть правильно выровнена.


http://www.rsdn.ru/forum/message/2690243.1.aspx
Автор: remark
Дата: 11.10.07



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[16]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 13:44
Оценка:
Здравствуйте, remark, Вы писали:

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


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


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


С>>[]


R>>>После "захвата" _shared в ThreadProc() надо просто проверить на null. InterlockedXXX здесь не нужен.

R>>>И это надо сделать в люом случае в такой ситуации, даже если обращения к _shared защищено мьютексами.

С>>А если заменить _shared = null на _shared = new SharedResource()? Ты понял о чем я?


R>Тогда это можно сделать без InterlockedXXX. И без барьеров памяти вообще на x86.

R>Просто обычное сохранение/загрузка указателя.

Учите матчасть:
http://www.rsdn.ru/forum/message/2690243.1.aspx
Автор: remark
Дата: 11.10.07

прежде чем ставить минусы. Или высказываетесь по существу.

R>>>

R>

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 13:49
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Что системное программирование: то, что работает в режиме ядра -- это прежде всего драйверы и шедулер аппаратных потоков исполнения.


Ok. Значит remark говорил о прикладном программировании.
(Хотя в начале 90-х в курсе по системному программированию в университеты мы изучали компиляторы. Ну да ладно, времена меняются).

ZEN>Да только что нашёл в Google, что такое ACE. Примочка на C++ для решения вдруг возникших проблем с управлением нагрузкой многоядерных процессоров.



Нужно Дугласу Шмидту написать о том, чем на самом деле является The ADAPTIVE Communication Environment. А то вот он чего понаписал:

The ADAPTIVE Communication Environment (ACE) is a freely available, open-source object-oriented (OO) framework that implements many core patterns for concurrent communication software. ACE provides a rich set of reusable C++ wrapper facades and framework components that perform common communication software tasks across a range of OS platforms. The communication software tasks provided by ACE include event demultiplexing and event handler dispatching, signal handling, service initialization, interprocess communication, shared memory management, message routing, dynamic (re)configuration of distributed services, concurrent execution and synchronization.

ACE is targeted for developers of high-performance and real-time communication services and applications. It simplifies the development of OO network applications and services that utilize interprocess communication, event demultiplexing, explicit dynamic linking, and concurrency. In addition, ACE automates system configuration and reconfiguration by dynamically linking services into applications at run-time and executing these services in one or more processes or threads.

(это я по поводу вашего "вдруг возникших проблем" прикалываюсь).

ZEN>На его основе что-либо системное сделали (работающее в ядре ОС) или делают только приложения, так как на основе Pthreads и LWP? (Инетресуюсь, потому что хочу провести/или не провести черту применимости ACE между системным и прикладным использованием)


ACE работает поверх имеющихся системных средств (т.е. поверх pthreads, LWP, WinThreads и т.д.).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 13:55
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Вы сами проверяли?

ZEN>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).
2,5 — не очень то линейно.
С GCС не работал. А он действительно компилирует многопоточно, или как VS2005 загружает по проекту на каждый проц?

ZEN>Но всё это костыли. Если всё рабочее окружение отправить в своп, а при загрузке компьютера оотуда всё доставать в оперативку... Но можно использовать энергонезависимое ОЗУ большой ёмкости (несколько гигабайт) и отказаться от винчестера вообще, тогда все установленые приложения и система фактически имеют включенную готовность, как радиоприёмник.

Очень похоже на Висту
Re[11]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 11.10.07 14:00
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Тут будет возможна ситуация, когда на другом ядре обновленное значение указателя уже будет в кэше, а сами данные, на которые он указывает — нет. Поэтому на многоядерной системе так делать нельзя. На одноядерной можно, но тоже есть ограничение — переменная с указателем должна быть правильно выровнена.

Это касается не только указателей, но и обычных данных. x86 берет на себя всю ответсвенность за кэш. Попробуй сделать тест — записывать в одну и ту же память двумя процами. А потом в разную (главное чтобы подальше, по крайней мере 256 байт от нее). Познаешь то, с чем в одном проекте мне приходится бороться.
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:07
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


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



Если ты имеешь в виду явный мессаджинг, то на Intel/AMD такого нет.
Но. Данные передавать между кэшами минуя основную память можно. Обычно так и происходит. Передача данных между ядрами обеспечивается протоколом когерентности кэшей. Сейчас обычно не происходит и блокировки шины памяти при InterlockedXXX операциях, обычно происходит блокировка строк кэша.
... правда передача данных между кэшами, без затрагивания основной памяти, медленнее, чем загрузка из основной памяти
Основная идея следующая — обращений к разделяемым структурам должно быть минимально необходимое кол-во. Совсем без них, естественно, не обойтись. Но если их мало, то это не ударит по производительности и масштабируемости.
Тут как с аллокацией памяти, например. Аллокация памяти относительно дорогая операция. Если их делать тысячи на транзакцию. А если их 10 на транзакцию, то сервер всё ещё способен обрабатывать десятки тысяч транзакций в секунду.
Про диспетчер не понял, о чём ты.
При распараллеливании, естестевенно, гранулярность должна быть не fine-grained, не coarse-grained, а fine-grained



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[12]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:16
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Это касается не только указателей, но и обычных данных. x86 берет на себя всю ответсвенность за кэш. Попробуй сделать тест — записывать в одну и ту же память двумя процами. А потом в разную (главное чтобы подальше, по крайней мере 256 байт от нее). Познаешь то, с чем в одном проекте мне приходится бороться.



Ну совсем всю ответственность он не берёт:

Initially x == y == 0

Processor 0
mov [ _x], 1 // M1
mov r1, [ _y] // M2

Processor 1
mov [ _y], 1 // M3
mov r2, [_x] // M4

r1 == 0 and r2 == 0 is allowed




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:20
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>IMHO самое основное, что мешает жить и что является первичной проблемой — как разделять данные.


Я это и говорю:

*каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.


AVM>Когда еще был студентом мой знакомый работал в одном НИИ который занимался разработкой многопроцессорных систем и знакомому (а он потом подключил меня к этой работе) предложили принять участие в разработке транслятора для многопроцессорных систем.

AVM>Основная идея которую туда пытались заложить — при написании кода можно было указать, может ли этот кусок код выполняться параллельно (если да — при каких условиях) и что является событием для запуска этого куска на выполнение.

AVM>Основной проблемой было как грамотно организовать распределение данных между потоками выполнения — это сильно затрагивает алгоритмы обработки данных.


AVM>К сожалению НИИ был настигнут молодым капитализмом с советским лицом и финансирование темы прикрыли. Работы через несколько лет продолжились и сейчас есть результаты — вот только люди, которые это делают рассказать ничего конкретного не могут — у них на работе интернета нет.



Скорее всего они занимаются распараллеливанием какого-то подмножества задач. Или вообще HPC.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: multicore -- напоминает переход на Win32
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 14:22
Оценка:
Что-то разговоры о проблемах программирования в условиях многоядерности напоминают мне шумиху вокруг перехода на Win32. Тогда так же было много шума. Многие выгоды сулили. Мол не будет для ваших данных барьеров в 64K, будут доступны файлы объемом свыше 2Gb и пр.

А в итоге -- многих ли этот переход действительно серьезно затронул? Я вот помню, что были некоторые проблемы у тех, кто писал приложения в чистом WinAPI и без распаковщиков сообщений. Тогда действительно превращение wParam в 32-х битовое значение из 16-ти битового и соответствующе изменение ряда Windows-сообщений требовало правки кода. Но те, кто пользовался объектными обертками вокруг WinAPI этого, возможно, даже и не заметили.

Так и сейчас. Что-то будет, а что не понятно. Неизвестность пугает. Хотя, подозреваю, для большинства из нас может вообще ничего не измениться.

Ну действительно, много кому приходится заниматься распределением работы приложения по десятку-другому потоков? Сейчас ведь столько всего упрятано в фреймворки, в сервера приложений, в сервера баз данных, что разработчику не так уж не сильно приходится заботится о распараллеливании чего-либо.

Да и ради чего это распараллеливание нужно? Для общей скорости работы ПО?
Во времена, когда под написанное на Ruby (!) web-приложение выделяются тысячи (!) серверов кто будет заботиться об увеличении скорости работы за счет усложнения разработки?

Конечно, кто-то занимается большими вычислениями. Типа прогнозов погоды или моделирования ядерных взрывов. Кто-то занимается кодированием видео/аудио (вот когда AutoGuardianKnot перекодирует фильмы, он запускает lame, а тот пишет, что мол используются ASM-модули и MMX, SSE расширения, в будущем будет писать -- running on 2/4/8/80 cores), кто-то еще чем-то ресурсоемким. Но ведь они уже давно используют специализированные инструменты (вроде PVM и MPI). Ну будут ими востребованны еще OpenMP, TBB и какая-нибудь другая специализированная хрень. Однако вопрос в том, сколько их, этих разработчиков, которые постоянно нуждаются в увеличении числа доступных им ядер?

А может быть все наоборот? Может быть осваивание большого количества ядер станет новой нишей, как в свое время Web? Сомнительно, однако.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:34
Оценка: 63 (5)
Здравствуйте, сипласплас, Вы писали:

R>>Единственное, что будет быстрее в случае процессов — это однопоточный рантайм в каждом процессе. Но это из-за тупого реплицирования всех данных. Я думаю, что основная проблема тут это — аллокация памяти. Но я надеюсь, что ты не используешь стандартный аллокатор памяти из crt в многопоточных программах?


С>А какой надо использовать?



hoard:
http://www.hoard.org/
(как раз на днях вышла новая версия 3.7)

jemalloc:
http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/BSDcan2006_slides.pdf

streamflow:
http://people.cs.vt.edu/~scschnei/papers/ismm06.pdf

dlmalloc:
http://gee.cs.oswego.edu/dl/html/malloc.html



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.10.07 14:35
Оценка:
Здравствуйте, remark, Вы писали:

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


К сожалению даже "фича фриз" не поможет. Многие программы работают не так качественно как могли бы если бы производительность не была бы проблемой. Например, те же игрушки. Сейчас говорят о почти полной фотореалистичности и т.п., но пройдет 10 лет и все равно конца и края совершенству не будет.

Кроме того есть проблема сложности. Одна и та же задача может быть решена совершенно с разными трудозатратами если выбирать более прямые методы решения. Ну, скажем у первых писюков была сегментная организация памяти и памяти явно было очень мало. Это вынуждало тратить тонну времени на то чтобы изобретать способы того как решить задачу в данных условиях. Сейчас у меня на машине 2Гб оперативки и я для многих задач могу выбрать весьма простые решения (скажем скачать 100 мегабайтный файл в память). Ранее я этого не мог. Далее, когда будет 1Тб пмяти я смогу, скажем использовать позиционную сортировку для int32. Сегодня это выглядит бредом. (в прочем может так будет и завтра ).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 14:37
Оценка:
Здравствуйте, remark, Вы писали:

R>Про диспетчер не понял, о чём ты.


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

В общем, не нравится мне архитектура. Ядер понапихали, а эффективных средств для координации не дали
Re[3]: Арифметика
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:37
Оценка:
Здравствуйте, сипласплас, Вы писали:

С>btw, после прочтения введения в lock/wait free Александреску мне показалось, что они хорошо ложатся на GC



Что значит "ложатся"? И что значит "хорошо"?
Определённо их можно реализовать в присутствии GC. Это даже немного легче.
Но их так же можно реализовать и без GC.
Моё личное мнение, что без GC будет быстрее и масштабируемее. Я не уверен, что какой-либо алгоритм GC может приблизиться к RCU.
Использование GC здесь (как в прочем и в остальных случаях) — это просто спихивание проблемы на другого, в надежде, что другой их как-то решит.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[14]: Многопоточность сегодня
От: Константин Л. Франция  
Дата: 11.10.07 14:39
Оценка:
Здравствуйте, remark, Вы писали:

[]

R>Скетч кода примерно такой (в терминах С++):


R>
R>std::atomic<int*> p;

R>void thread1()
R>{
R>  int* p2 = new int();
R>  p.store(p2, std::msync::ssb); // sink-store barrier -- release not affecting loads
R>}

R>void thread2()
R>{
R>  int p2 = p.load(std::msync::ddacq); // acquire with data dependency 
R>}
R>



R>На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq.

R>На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.

Что _это_? Это реальный код и мне пора на свалку? Откуда взялся этот std::atomic?


R>>>

R>
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:43
Оценка: 2 (1)
Здравствуйте, eao197, Вы писали:

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


R>>Зато при использовании процессов ты гарантированно:

R>> — Имеешь очень дорогое взаимодействие. Это скорее всего будет 2 системных вызова, 2 полных копирования данных, плюс ещё синхронизация и ещё куча непонятно чего. Более-менее не так ужасно тормозно это может быть только с IO-Lite:
R>>http://www.usenix.org/publications/library/proceedings/osdi99/full_papers/pai/pai.pdf
R>>Хотя его видимо никто не использует.
R>>В случае же потоков это может действительно очень-очень-очень быстро. Порядка нескольких тактов.
R>> — Имеешь копии read-mostly данных в памяти и каждого процесса. И в кэше.
R>> — Имеешь сложность запуска/остановки/настройки приложения.

E>Зато имеешь возможно безболезненно килять сбойные процессы. Тогда как в многопоточном приложении придется убивать всех.


В пределе можно сделать что-то типа такого:
Приложение реализовано на основе процессов, но для константных данных отводится отдельная разделяемая память, которой пользуются все процессы. А для обмена сообщениями используются отдельные "окна" разделяемой памяти, т.к. эти "окна" ограничены, то данные в них можно полностью верифицировать.
Т.о. образом получается лучшее от двух миров — в большинстве своём процессы изолированы и их можно убивать отдельно, с другой обмен идёт быстро и данные не дублируются.
... правда сбойный процесс может попортить разделяемую память, это не приведёт к падению остальных процессов, но работать они будут не корректно.
... в прочем это же может произойти и при полной изоляции, если сбойный процесс будет слать сообщения с некорректными данными...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[14]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 14:45
Оценка:
Здравствуйте, remark, Вы писали:

R>На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq.

R>На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.

Не верю! (С)
Ссылку на источник информации?
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:47
Оценка:
Здравствуйте, RegisteredUser, Вы писали:

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


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


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



Скорее всего ты говоришь о какой-то очень ограниченной области применения, либо вообще о HPC. К сожалению, этим сейчас страдают многие, которые кричат, что у них есть *решения для многоядерности*. Скорее всего их решения позволяют только "быстро перемножать матрицы неимоверных размеров" или что-нибудь такое. Как мне это поможет при написании сетевого сервера?! Или клиентского приложения? Ну нет у меня матриц на миллионы элементов и не надо мне ничего перемножать.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Арифметика
От: Константин Л. Франция  
Дата: 11.10.07 14:48
Оценка:
Здравствуйте, remark, Вы писали:

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


С>>btw, после прочтения введения в lock/wait free Александреску мне показалось, что они хорошо ложатся на GC



R>Что значит "ложатся"? И что значит "хорошо"?

R>Определённо их можно реализовать в присутствии GC. Это даже немного легче.
R>Но их так же можно реализовать и без GC.
R>Моё личное мнение, что без GC будет быстрее и масштабируемее. Я не уверен, что какой-либо алгоритм GC может приблизиться к RCU.

??? Либо я совсем не в теме, либо GC помогает забить на memory management в RCU

R>Использование GC здесь (как в прочем и в остальных случаях) — это просто спихивание проблемы на другого, в надежде, что другой их как-то решит.



R>
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:52
Оценка:
Здравствуйте, minorlogic, Вы писали:

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


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



Занимаются они этим долго, но дозанимались они только до того, как быстро перемножать матрицы неимоверного размера. Да, там у них действительно есть автоматическое распараллеливание и т.д.
Как мне это поможет при написании сетевого сервера?! Или развитого клиентского приложения?!
Дай этому профи, который давно занимается распараллеливанием, такую задачу и он войдёт в ступор. Скорее всего он начнёт у тебя спрашивать "ну где тут этот самый массив на миллиард элементов, который надо распараллелить?", или "над чём тут делать преобразование Фурье?"
А если задача что-нибудь посчитать, то есть средства типа OpenMP и иже с ним, их никто не игнорирует... если они всё-таки подходят.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность сегодня
От: alpha21264 СССР  
Дата: 11.10.07 14:55
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


ZEN>>Вы сами проверяли?

ZEN>>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).
GZ>2,5 — не очень то линейно.
GZ>С GCС не работал. А он действительно компилирует многопоточно, или как VS2005 загружает по проекту на каждый проц?

Кха... Юниксовый make много... параллельный короче.
Пишешь make -j 2 и он компилирует в два раза быстрее.
Даже если в машине ОДИН процессор.
А если в машине два процессора, то надо писать make -j 4.
Во как.
Разгадка простая — пока один экземпляр gcc занимает процессор, второй читает/пишет данные с диска.

Течёт вода Кубань-реки куда велят большевики.
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:56
Оценка: 6 (3)
Здравствуйте, Andrei F., Вы писали:

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


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


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



comp.programming.threads (USENET):
http://groups.google.com/group/comp.programming.threads/topics

Threading on Intel® Parallel Architectures:
http://softwarecommunity.intel.com/isn/Community/en-us/forums/1042/ShowForum.aspx

Parallel.ru:
http://hp.parallel.ru/parBB/index.php

Thinking Parallel (блог, но много интересного, в комментах бывает что-то типа форума):
http://www.thinkingparallel.com/



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:58
Оценка:
Здравствуйте, GlebZ, Вы писали:

R>>Так думали при появлении процессора 1 МГц.

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

А что ты на нём запускал?


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 14:59
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


С>>Ошибочные в том, что при любое присваивание ссылки ведет к full fence?


AF>Не ведет, конечно. Хотя меня интересовал другой вопрос — как обмениваться данными между ядрами, не залезая во внешнюю память. Ответ, боюсь — никак.


Обмен идёт через кэши.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 15:01
Оценка:
Здравствуйте, remark, Вы писали:

R>Обмен идёт через кэши.


Есть какие-то другие виды обмена кроме того, который иницируется явно при помощи барьера памяти?
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>К сожалению даже "фича фриз" не поможет. Многие программы работают не так качественно как могли бы если бы производительность не была бы проблемой. Например, те же игрушки. Сейчас говорят о почти полной фотореалистичности и т.п., но пройдет 10 лет и все равно конца и края совершенству не будет.


Я имею в виду *полный* фича фриз. Т.е. не увеличивается фотореалистичность игр и т.д.
Я надеюсь, все понимают, что я это говорю иронично. Ключевое слово "Если бы".


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 15:04
Оценка:
Здравствуйте, remark, Вы писали:

R>dlmalloc:

R>http://gee.cs.oswego.edu/dl/html/malloc.html

Кстати, сам Дуг Ли советует для многопоточных программ использовать ptmalloc, производный от dlmalloc. Но он только Unix-овый.

А dlmalloc, по слухам, в большинстве Linux-ов является частью libc и поэтому там он как раз штатный аллокатор.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:11
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>Про диспетчер не понял, о чём ты.


AF>Я имел в виду, что если нужно распределять между ядрами части задачи, то нужен какой-то диспетчер, который будет это делать. А в его работе без разделяемых данных никак не обойтись.


Не обязательно


AF>Поэтому получается, что нет смысла делить между ядрами поиск элемента в массиве не очень большого размера, к примеру — из-за существующей архитектуры затраты на работу диспетчера съедят больше, чем выполнение задачи целиком на одном ядре (я правда не уверен, где тут лежит граница, с которой начинается хоть какой-то прирост производительности)


Распараллеливать работу на уровне отдельных машинных инструкций определенно не стоит.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:12
Оценка: +1 :)))
Здравствуйте, Andrei F., Вы писали:

AF>В общем, не нравится мне архитектура. Ядер понапихали, а эффективных средств для координации не дали



Не слышу! Говори громче! В другое ухо мне очень громко кричит CEO из Intel, о том какое крутое они сделали новое поколение процессоров, и о том, какие все программисты тупые, что ни как не могут научиться эффективно их использовать, хотя уже прошёл целый год, и они написали целых 2 white paper, о том, что надо программировать как-то по-новому.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Многопоточность сегодня
От: Кодт Россия  
Дата: 11.10.07 15:12
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


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


Дороговизна не в переключениях, а в атомарных операциях.
Комплект функций синхронизации — атомарные операции, мьютексы-шмютексы — предоставляемый операционной системой приложению, различается для одно- и многоядерных систем.

На 1 ядре atomic_xxx — это
— запретить прерывания — чтобы планировщик не вломился и не вытеснил поток
— выполнить операцию
— разрешить прерывания

А на многоядерном — это
— запретить прерывания
— заблокировать память — чтобы остальные ядра туда не выстрелили
— выполнить операцию
— разблокировать память
— разрешить прерывания

То есть, во-первых, танец становится длиннее, а во-вторых, он становится сольным.
Атомарная операция как-бы выполняется сразу во всех ядрах (в родном — содержательно, в остальных — вхолостую).
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[14]: Многопоточность сегодня
От: Константин Л. Франция  
Дата: 11.10.07 15:13
Оценка:
Здравствуйте, remark, Вы писали:

[]

Этот std::atomic появится в C++0x? Что мне сейчас делать? Какая у меня сейчас есть альтернатива Interlocked?
Re[15]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:15
Оценка:
Здравствуйте, Константин Л., Вы писали:

R>>Скетч кода примерно такой (в терминах С++):


R>>
R>>std::atomic<int*> p;

R>>void thread1()
R>>{
R>>  int* p2 = new int();
R>>  p.store(p2, std::msync::ssb); // sink-store barrier -- release not affecting loads
R>>}

R>>void thread2()
R>>{
R>>  int p2 = p.load(std::msync::ddacq); // acquire with data dependency 
R>>}
R>>



КЛ>Что _это_? Это реальный код и мне пора на свалку? Откуда взялся этот std::atomic?



Сильно не напрягайся. Это примерный вариант реализации примитивов работы с памятью в C++0x.
Со слов Peter Dimov/Alexander Terekhov.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[15]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:20
Оценка:
Здравствуйте, Константин Л., Вы писали:

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


КЛ>[]


Хотя вот Hans-J. Boehm говорит по-другому:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2381.html


КЛ>Этот std::atomic появится в C++0x? Что мне сейчас делать? Какая у меня сейчас есть альтернатива Interlocked?



К сожалению, *никакой*!

Можно пошариться по готовым библиотекам. Базовые Interlocked скорее всего можно будет найти. Можно ACE посмотреть.
С портируемыми барьерами памяти всё значительно хуже. В ядре линукса можно найти жалкое подобие с убогим С интерфейсом.
Скорее всего писать самому.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность сегодня
От: Andrei F.  
Дата: 11.10.07 15:23
Оценка:
Здравствуйте, remark, Вы писали:

R>Не обязательно


И как ты себе это представляешь? На примере простой задачи поиска элемента в массиве простым перебором, например.

R>Распараллеливать работу на уровне отдельных машинных инструкций определенно не стоит.


см выше. У меня есть сомнения, что есть смысль параллелить эту задачу в рамках существующей архитектуры при размере массива < ~100 элементов. Может быть, даже 1000.
Re[16]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 15:24
Оценка:
Здравствуйте, remark, Вы писали:

[]

R>К сожалению, *никакой*!


R>Можно пошариться по готовым библиотекам. Базовые Interlocked скорее всего можно будет найти. Можно ACE посмотреть.

R>С портируемыми барьерами памяти всё значительно хуже. В ядре линукса можно найти жалкое подобие с убогим С интерфейсом.
R>Скорее всего писать самому.

Но почему ты не делаешь барьер памяти?

R>
Re[5]: Многопоточность сегодня
От: Константин Л. Франция  
Дата: 11.10.07 15:26
Оценка:
Здравствуйте, Кодт, Вы писали:

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


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


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


К>Дороговизна не в переключениях, а в атомарных операциях.


А я о чем?

К>Комплект функций синхронизации — атомарные операции, мьютексы-шмютексы — предоставляемый операционной системой приложению, различается для одно- и многоядерных систем.


[]
Re[15]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:27
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq.

R>>На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.

AF>Не верю! (С)

AF>Ссылку на источник информации?


http://developer.intel.com/products/processor/manuals/318147.pdf

Радуйтесь. Intel снизошла до публикации оффициальной модели памяти x86 около месяца назад. Видимо освободилось немного времени между горыди ударами в грудь, криками какие крутые новые процессоры они выпустили, и криками, что все программисты тупые, т.к. не могут научиться эффективно использовать их процессры, хотя прошёл уже год после выпуска, и они написали столько пресс-релизов, о том, что теперь надо программировать как-то но-другому.
Елси бы у них ещё освободилось немного времени на ответы на вопросы на их форуме посвящённым их процессорам, было совсем замечательно, и возможно бы тогда тупые программисты всё-таки немного бы поумнели.
Ну это так... о наболевшем...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: Кодт Россия  
Дата: 11.10.07 15:34
Оценка:
Здравствуйте, Константин Л., Вы писали:

К>>Дороговизна не в переключениях, а в атомарных операциях.


КЛ>А я о чем?


К>>Комплект функций синхронизации — атомарные операции, мьютексы-шмютексы — предоставляемый операционной системой приложению, различается для одно- и многоядерных систем.


Да в общем, всё о том же.

Вытесняющая многозадачность дороже кооперативной. Многоядерность дороже одноядерности. Хотя и удобнее, и эффективнее при разумном использовании.
О том ремарк и пишет: с помощью серебряной пули можно выстрелить себе в ногу
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[5]: Арифметика
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:39
Оценка:
Здравствуйте, Константин Л., Вы писали:

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


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


С>>>btw, после прочтения введения в lock/wait free Александреску мне показалось, что они хорошо ложатся на GC



R>>Что значит "ложатся"? И что значит "хорошо"?

R>>Определённо их можно реализовать в присутствии GC. Это даже немного легче.
R>>Но их так же можно реализовать и без GC.
R>>Моё личное мнение, что без GC будет быстрее и масштабируемее. Я не уверен, что какой-либо алгоритм GC может приблизиться к RCU.

КЛ>??? Либо я совсем не в теме, либо GC помогает забить на memory management в RCU


??? достаточно *либо* GC, *либо* RCU, иметь их вместе бессмысленно.


R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:42
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>Обмен идёт через кэши.


AF>Есть какие-то другие виды обмена кроме того, который иницируется явно при помощи барьера памяти?



Обмен инициируется не барьерами, а сохранениями/загрузками из памяти.
Других я не знаю.
Мессджинг... но тогда придётся в обязательном порядке делать *жёсткую* привязку *всех* потоков к ядрах. А иначе как? Какому ядру посылать сообщение? Это уже переведёт систему ближе к кластерам...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:44
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


R>>dlmalloc:

R>>http://gee.cs.oswego.edu/dl/html/malloc.html

E>Кстати, сам Дуг Ли советует для многопоточных программ использовать ptmalloc, производный от dlmalloc. Но он только Unix-овый.


E>А dlmalloc, по слухам, в большинстве Linux-ов является частью libc и поэтому там он как раз штатный аллокатор.


Главное не использовать виндовый


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[17]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:46
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


С>[]


R>>К сожалению, *никакой*!


R>>Можно пошариться по готовым библиотекам. Базовые Interlocked скорее всего можно будет найти. Можно ACE посмотреть.

R>>С портируемыми барьерами памяти всё значительно хуже. В ядре линукса можно найти жалкое подобие с убогим С интерфейсом.
R>>Скорее всего писать самому.

С>Но почему ты не делаешь барьер памяти?


http://www.rsdn.ru/forum/message/2690243.1.aspx
Автор: remark
Дата: 11.10.07


R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.10.07 15:48
Оценка:
Здравствуйте, remark, Вы писали:

R>>>dlmalloc:

R>>>http://gee.cs.oswego.edu/dl/html/malloc.html

E>>Кстати, сам Дуг Ли советует для многопоточных программ использовать ptmalloc, производный от dlmalloc. Но он только Unix-овый.


E>>А dlmalloc, по слухам, в большинстве Linux-ов является частью libc и поэтому там он как раз штатный аллокатор.


R>Главное не использовать виндовый


Все это хорошо пока ты стороние библиотеки в свой проект не подключаешь. А как возьмешь к себе ACE, PCRE, Crypto++, да еще в виде DLL, так и запаришься в них нестандартные аллокаторы запихивать.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Многопоточность сегодня
От: сипласплас  
Дата: 11.10.07 15:53
Оценка:
Здравствуйте, remark, Вы писали:

[]

С>>Но почему ты не делаешь барьер памяти?


R>http://www.rsdn.ru/forum/message/2690243.1.aspx
Автор: remark
Дата: 11.10.07


Но так _этого_ сейчас нигде нет?

Давай по порядку:

1. Interlocked
2. std::atomic
3. nothing

Ты мне говоришь
Автор: remark
Дата: 11.10.07
, что используешь nothing (т.е. вообще без какой-либо синхронизации кешей), тк *есть* std::atomic. Или ты используешь какой-то вариант std::atomic?

Я в конец запутался

R>>>

R>
Re[9]: Многопоточность сегодня
От: Константин Л. Франция  
Дата: 11.10.07 15:54
Оценка:
Здравствуйте, remark, Вы писали:

[]

R>Главное не использовать виндовый


А что ты делаешь с 3rd party libs?
Re[10]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 15:55
Оценка:
Здравствуйте, eao197, Вы писали:

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


R>>>>dlmalloc:

R>>>>http://gee.cs.oswego.edu/dl/html/malloc.html

E>>>Кстати, сам Дуг Ли советует для многопоточных программ использовать ptmalloc, производный от dlmalloc. Но он только Unix-овый.


E>>>А dlmalloc, по слухам, в большинстве Linux-ов является частью libc и поэтому там он как раз штатный аллокатор.


R>>Главное не использовать виндовый


E>Все это хорошо пока ты стороние библиотеки в свой проект не подключаешь. А как возьмешь к себе ACE, PCRE, Crypto++, да еще в виде DLL, так и запаришься в них нестандартные аллокаторы запихивать.



Да, этим грешит большинство библиотек.
Хотя вот насколько помню в OCI (Oracle call interface) в самую первую функцию инициализации можно передать указатели на функции аллокации/освобождения памяти. Приятно.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[19]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 16:08
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


С>[]


С>>>Но почему ты не делаешь барьер памяти?


R>>http://www.rsdn.ru/forum/message/2690243.1.aspx
Автор: remark
Дата: 11.10.07


С>Но так _этого_ сейчас нигде нет?


С>Давай по порядку:


С>1. Interlocked

С>2. std::atomic
С>3. nothing

С>Ты мне говоришь
Автор: remark
Дата: 11.10.07
, что используешь nothing (т.е. вообще без какой-либо синхронизации кешей), тк *есть* std::atomic. Или ты используешь какой-то вариант std::atomic?


С>Я в конец запутался


С использованием std::atomic я показал, как должна была бы выглядеть программа для сферического компьютера в вакууме. Т.е. где должны быть какие типы барьеров.
Потом я сказал, что те типы барьеров, которые тут должны быть на сферическом компьютере, на x86 не нужны, т.к. всегда присутствуют неявно.
Т.е., если я пишу под x86, то я ничего не использую.


R>>>>

R>>

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 16:08
Оценка:
Здравствуйте, Константин Л., Вы писали:

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


КЛ>[]


R>>Главное не использовать виндовый


КЛ>А что ты делаешь с 3rd party libs?


Я их


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность сегодня
От: AVM Россия  
Дата: 11.10.07 16:09
Оценка:
Здравствуйте, remark, Вы писали:

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


AVM>>IMHO самое основное, что мешает жить и что является первичной проблемой — как разделять данные.


R>Я это и говорю:

R>

R>*каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.

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

R>Скорее всего они занимаются распараллеливанием какого-то подмножества задач. Или вообще HPC.

Подмножество задач, но с закладыванием перспективы на будущее.
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 16:13
Оценка: 6 (1)
Здравствуйте, Andrei F., Вы писали:

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


R>>Не обязательно


AF>И как ты себе это представляешь? На примере простой задачи поиска элемента в массиве простым перебором, например.


Ключевое слово, по которому надо искать — work stealing.
Так же ищи — Cilk, Java Fork/Join, C# TPL, Intel TBB. Как это ни удивительно, но все эти вещи используют идентичный механизм.



R>>Распараллеливать работу на уровне отдельных машинных инструкций определенно не стоит.


AF>см выше. У меня есть сомнения, что есть смысль параллелить эту задачу в рамках существующей архитектуры при размере массива < ~100 элементов. Может быть, даже 1000.


Если *всё*, что надо сделать твоей программе — это обработать 100 элементов, то я не думаю, что у тебя есть проблемы вообще.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 16:16
Оценка:
Здравствуйте, AVM, Вы писали:

R>>Скорее всего они занимаются распараллеливанием какого-то подмножества задач. Или вообще HPC.

AVM>Подмножество задач, но с закладыванием перспективы на будущее.

По поводу подмножества охотно верю, а по поводу вообще:

За подробностями смотрите интервью с Джеем Хоефлингером, который занимается автоматическим распараллеливанием с середины 80:
http://www.thinkingparallel.com/2007/08/14/an-interview-with-dr-jay-hoeflinger-about-automatic-parallelization/


Их технология в перспективе сможет сделать мой врождённо однопоточный сетевой сервер или ядро БД линейно масштабируемым на N ядер? Можешь спросить у них... Или просто сам подумать


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[20]: Многопоточность сегодня
От: Константин Л. Франция  
Дата: 11.10.07 16:17
Оценка:
Здравствуйте, remark, Вы писали:

[]

R>С использованием std::atomic я показал, как должна была бы выглядеть программа для сферического компьютера в вакууме. Т.е. где должны быть какие типы барьеров.

R>Потом я сказал, что те типы барьеров, которые тут должны быть на сферическом компьютере, на x86 не нужны, т.к. всегда присутствуют неявно.
R>Т.е., если я пишу под x86, то я ничего не использую.



Т.е. ты хочешь сказать, что Interlocked _вообще_ никогда не нужен и все само собой синхронизируется? Для меня это большая новость. О чем же тогда пишет Рихтер в своей "Programming for Win2k"? Да ты Галилей получается, а мы средневековые узколобые создания (это типа не стеб, а попытка показать насколько твое "открытие" может меня шокировать)!

Правльно ли я понимаю, что:

1. Имеем переменную в кеше процессора1
2. Имеем ее значение в кеше проца2
3. При её изменеии в проце1 новое значение *автоматически" переезжает в кеш процессора 2, т.е. конструкия someptr = 0x00000000 выльется в нечто напоминающее InterlockedExchangePointer?

[]
Re[7]: Многопоточность сегодня
От: AVM Россия  
Дата: 11.10.07 16:57
Оценка: :)
Здравствуйте, remark, Вы писали:

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


R>>>Скорее всего они занимаются распараллеливанием какого-то подмножества задач. Или вообще HPC.

AVM>>Подмножество задач, но с закладыванием перспективы на будущее.

R>По поводу подмножества охотно верю, а по поводу вообще:

R>

R>За подробностями смотрите интервью с Джеем Хоефлингером, который занимается автоматическим распараллеливанием с середины 80:
R>http://www.thinkingparallel.com/2007/08/14/an-interview-with-dr-jay-hoeflinger-about-automatic-parallelization/


R>Их технология в перспективе сможет сделать мой врождённо однопоточный сетевой сервер или ядро БД линейно масштабируемым на N ядер? Можешь спросить у них... Или просто сам подумать


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

Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает, просто порождает кучу проблем и обсуждений на форумах.
С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр додключенный к обалденным устройствам ввода/вывода

R>

Re[6]: Арифметика
От: Константин Л. Франция  
Дата: 11.10.07 17:04
Оценка:
Здравствуйте, remark, Вы писали:

[]

R>??? достаточно *либо* GC, *либо* RCU, иметь их вместе бессмысленно.


Ну, честно признаюсь, дальше этого я не ходил:


Without a garbage collector, things get harder. Much harder, actually, and it turns out that deterministic memory freeing is quite a fundamental problem in lock-free data structures.


А вот про то, что GC поможет RCU, я похоже, погорячился

R>>>

R>
Re[8]: Многопоточность сегодня
От: Стэн http://stanonwork.blogspot.com/
Дата: 11.10.07 17:08
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр додключенный к обалденным устройствам ввода/вывода

А с какой скоростью и с какой точностью сможешь перемножить две матрицы 100x100 действительных чисел в уме?
Re[6]: Арифметика
От: WolfHound  
Дата: 11.10.07 17:14
Оценка:
Здравствуйте, remark, Вы писали:

R>??? достаточно *либо* GC, *либо* RCU, иметь их вместе бессмысленно.

Главная идея RCU (http://en.wikipedia.org/wiki/Read-copy-update оно?) это неизменение разделяемых данных, а изменеие ссылки по которой эти данные получают на ссылку на обновленные данные.
Те GC не отменяет RCU. Но делает реализацию данного паттерна тривиальной.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 17:21
Оценка: 35 (3)
Здравствуйте, Кодт, Вы писали:

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


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


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


К>Дороговизна не в переключениях, а в атомарных операциях.

К>Комплект функций синхронизации — атомарные операции, мьютексы-шмютексы — предоставляемый операционной системой приложению, различается для одно- и многоядерных систем.

К>На 1 ядре atomic_xxx — это

К>- запретить прерывания — чтобы планировщик не вломился и не вытеснил поток
К>- выполнить операцию
К>- разрешить прерывания

Не могу не вмешаться
Скажу за x86.

На 1 ядре atomic_xxx — это
— запрещать прерывания не надо — т.к. операции, которые выполняются как атомарные, всегда состоят из одной машинной команды, а прерывания не действуют на уровне микрокоманд
— выполнить операцию

Хотя тут некоторая загвоздка. Т.к. что бы добиться такого эффекта надо либо компилировать свою программу исключительно под одно ядро, либо делать как в ACE — при старте программы смотрим сколько ядер в системе и устанавливаем соотв. обрабом глобальные указатели на правильные функции atomic_xxx.

Итого это занимает порядка тактов.

Если использоват "честные" atomic_xxx, то даже на одноядерном процессоре Intel это выливается в 100 тактов.


К>А на многоядерном — это

К>- запретить прерывания
К>- заблокировать память — чтобы остальные ядра туда не выстрелили
К>- выполнить операцию
К>- разблокировать память
К>- разрешить прерывания

А на многоядерном — это
— запретить прерывания — опять не надо
— заблокировать память/или строку кэша, что немного дешевле и масштабируемее
— выполнить операцию
— разблокировать память/строку кэша


Итого это занимает порядка 100 — 450 тактов (в зависимости от статуса кэш линии)


Но основная беда даже не в этом.

(опустим пока такие тривиальные вещи как сериализация на мьютексах)

Передача кэш-линии занимает порядка 150-350 тактов. Даже без всяких атомарных операций и пр.
Т.е. скорость работы снижается до 100 (!) раз. Т.о. тривиальный producer-consumer может стать ботлнеком, если данные просто переходят из одного кэша в другой (без всяких atomic, мьютексов, евентов, вызовов я ядро для пробуждения consumer).
Плюс шина межпроцессорного/межядерного взаимодействия может стать боттлнеком, так что приложение просто не будет масштабироваться вообще при добавлении ядер, даже если потоков/работы достаточно, и нет сериализации на мьютексах, ядра не загружены и шина памяти не загружена.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Многопоточность сегодня
От: WolfHound  
Дата: 11.10.07 17:32
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает, просто порождает кучу проблем и обсуждений на форумах.

AVM>С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр додключенный к обалденным устройствам ввода/вывода
Вобще говоря эти машинки обладают принципиально разными свойствами и ИМХО то что хорошо делает одна другая будет делать плохо. Обратоное тоже верно.
Те они не будут заменять друг друга. Они будут друг друга дополнять.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Многопоточность сегодня
От: Кодт Россия  
Дата: 11.10.07 17:53
Оценка: +1
Здравствуйте, remark, Вы писали:

R>Но основная беда даже не в этом.


R>(опустим пока такие тривиальные вещи как сериализация на мьютексах)


R>Передача кэш-линии занимает порядка 150-350 тактов. Даже без всяких атомарных операций и пр.

R>Т.е. скорость работы снижается до 100 (!) раз. Т.о. тривиальный producer-consumer может стать ботлнеком, если данные просто переходят из одного кэша в другой (без всяких atomic, мьютексов, евентов, вызовов я ядро для пробуждения consumer).
R>Плюс шина межпроцессорного/межядерного взаимодействия может стать боттлнеком, так что приложение просто не будет масштабироваться вообще при добавлении ядер, даже если потоков/работы достаточно, и нет сериализации на мьютексах, ядра не загружены и шина памяти не загружена.

Получается, что нужно сосредоточиться не только на стычках потоков вокруг общих данных (что всегда было предметом уважения), но и на стычках ядер вокруг линеек кеша.

Это означает, что
— чем больше взаимодействие между потоками основано на пакетной обработке, тем лучше (впрочем, это и для одноядерных справедливо — в том плане, чтоб минимизировать переключения потоков)
— для очередей, не предполагающих пакетную обработку — нужно разбрасывать элементы по разным линейкам
Правильно?

На моей памяти это уже второй виток хардверно-специфических оптимизаций. Первый был, когда стали очень уважать попадание/промахивание в кэш своего ядра
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 17:57
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает,


А качественного скачка и раньше никогда в истории не было. Было 10МГц, потом 20МГц, потом 50МГц, потом 100МГц, потом 200МГц, потом 500МГц, потом 1ГГц.
Просто умножается на 2. И это всех устраивало. И будет устраивать.

R>>

AVM>

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[21]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 17:59
Оценка:
Здравствуйте, Константин Л., Вы писали:


R>>С использованием std::atomic я показал, как должна была бы выглядеть программа для сферического компьютера в вакууме. Т.е. где должны быть какие типы барьеров.

R>>Потом я сказал, что те типы барьеров, которые тут должны быть на сферическом компьютере, на x86 не нужны, т.к. всегда присутствуют неявно.
R>>Т.е., если я пишу под x86, то я ничего не использую.

КЛ>


КЛ>Т.е. ты хочешь сказать, что Interlocked _вообще_ никогда не нужен и все само собой синхронизируется?


Где я это сказал?!

[дальнейшие фантазии поскипаны]


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Арифметика
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 17:59
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Ну, честно признаюсь, дальше этого я не ходил:


КЛ>

КЛ>Without a garbage collector, things get harder. Much harder, actually, and it turns out that deterministic memory freeing is quite a fundamental problem in lock-free data structures.



Тогда было проблемой. Но развитие не стоит на месте


R>>>>

R>>

1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность сегодня
От: Cyberax Марс  
Дата: 11.10.07 18:15
Оценка:
Здравствуйте, eao197, Вы писали:

C>>А почему тут происходят переключения контекстов?

E>Если нить ввода-вывода и нить обработки находятся на разных ядрах, то передача сообщений между ними оказывается дороже, чем при работе обоих нитей на одном ядре. По крайней мере, по моим впечатлениям.
У меня впечатления обратные — передача данных через неблокирующуюся очередь (java.util.concurrent.ConcurrentNavigableMap, если кому интересно) у меня работает абсолютно с одинаковой скоростью на любом количестве процессоров (масштабируется почти линейно).
Sapienti sat!
Re[7]: Арифметика
От: remark Россия http://www.1024cores.net/
Дата: 11.10.07 18:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


R>>??? достаточно *либо* GC, *либо* RCU, иметь их вместе бессмысленно.

WH>Главная идея RCU (http://en.wikipedia.org/wiki/Read-copy-update оно?) это неизменение разделяемых данных, а изменеие ссылки по которой эти данные получают на ссылку на обновленные данные.
WH>Те GC не отменяет RCU. Но делает реализацию данного паттерна тривиальной.

Я бы так не сказал. "неизменение разделяемых данных" это основа практически всех lock-free алгоритмов.
RCU тут как раз решает задачу отложенного выполнения действий. Т.н. PDR, partial-copy-on-write deferred reclamation.
И в принципе теоретически можно произвольно выбрать какой-либо алгоритм, основанный на partial-copy-on-write. И произвольную технику deferred reclamation (GC, RCU, SMP/ROP, DRC, vZOOM). И соединить их воедино. И это будет работать. Т.е. они независимы.
И RCU это фактически понятие того же порядка, что и GC.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Многопоточность сегодня
От: iZEN СССР  
Дата: 11.10.07 19:04
Оценка:
Здравствуйте, alpha21264, Вы писали:

iZEN>>>Вы сами проверяли?

iZEN>>>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).
GZ>>2,5 — не очень то линейно.
GZ>>С GCС не работал. А он действительно компилирует многопоточно, или как VS2005 загружает по проекту на каждый проц?

A>Кха... Юниксовый make много... параллельный короче.

A>Пишешь make -j 2 и он компилирует в два раза быстрее.
A>Даже если в машине ОДИН процессор.
A>А если в машине два процессора, то надо писать make -j 4.
A>Во как.
A>Разгадка простая — пока один экземпляр gcc занимает процессор, второй читает/пишет данные с диска.

Я раньше тоже так думал, но разгадка оказалась не так проста.
На двуядерном процессоре команда make -j4 ровным счётом ничего не дала в плане уменьшения времени компиляции -- времени затратилось ровно столько же (с точностью до 5 минут), как-будто компиляция проводилась в однопоточном режиме на одном ядре.
А вот команда make -j2 действительно увеличила скорость компиляции 2,5 раза.
Re[22]: Многопоточность сегодня
От: Константин Л. Франция  
Дата: 11.10.07 19:59
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, Константин Л., Вы писали:



R>>>С использованием std::atomic я показал, как должна была бы выглядеть программа для сферического компьютера в вакууме. Т.е. где должны быть какие типы барьеров.

R>>>Потом я сказал, что те типы барьеров, которые тут должны быть на сферическом компьютере, на x86 не нужны, т.к. всегда присутствуют неявно.
R>>>Т.е., если я пишу под x86, то я ничего не использую.

КЛ>>


КЛ>>Т.е. ты хочешь сказать, что Interlocked _вообще_ никогда не нужен и все само собой синхронизируется?


R>Где я это сказал?!


Начинаем читать отсюда
Автор: сипласплас
Дата: 11.10.07
:

1. Привели пример, когда значение поинтеров меняется из разных тредов без-каких либо Interlocked/atomic. Будем считать что каждый тред сразу должен увидеть эти изменения (актуально для refcounting, не правда-ли?)
2. Ты говоришь —

На x86 да, а почему бы и нет? Это экстремально быстро.

3. Тебе говорят — тут нужен memory barrier.
4. Ты в ответ — "Не нужен, на x86 все и так путем. Они там присутствуют неявно".
5. Тебя спрашивают — "За каким хреном нам тогда вообще Interlocked на x86"
6. Ты — "Где я это сказал"?

Я просто искренне хочу понять, что я упустил


R>[дальнейшие фантазии поскипаны]


R>
Re[23]: Многопоточность сегодня
От: WolfHound  
Дата: 11.10.07 20:07
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

КЛ>1. Привели пример, когда значение поинтеров меняется из разных тредов без-каких либо Interlocked/atomic. Будем считать что каждый тред сразу должен увидеть эти изменения (актуально для refcounting, не правда-ли?)

Не путай запись из регистра в память (это одна атомарная операция) и чтение из памяти в регистр, изменение регистра, запись из регистра в память (это 3 атомарные операции) но вся последовательность не атомарна.
Интерлокеды нужны для того чтобы выполнять подобные последовательности атомарно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Многопоточность сегодня
От: AVM Россия  
Дата: 11.10.07 20:21
Оценка: +2 :))
Здравствуйте, Стэн, Вы писали:

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


AVM>>С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр подключенный к обалденным устройствам ввода/вывода

С>А с какой скоростью и с какой точностью сможешь перемножить две матрицы 100x100 действительных чисел в уме?
Это вопрос к Человеку дождя, если ты догадываешься о чем я — Мы не знаем всех возможностей мозга.
Можно задать и встречный вопрос? — с какой скоростью японский робот-пылесос сможет найти (если вообще сможет) грязные носки в углу? Да ладно носки — с какой скоростью он сможет найти угол
Re[9]: Многопоточность сегодня
От: AVM Россия  
Дата: 11.10.07 20:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


AVM>>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает, просто порождает кучу проблем и обсуждений на форумах.

AVM>>С другой стороны у каждого из нас в голове содержится нехреновый такой вычислительный центр додключенный к обалденным устройствам ввода/вывода
WH>Вобще говоря эти машинки обладают принципиально разными свойствами и ИМХО то что хорошо делает одна другая будет делать плохо. Обратоное тоже верно.
WH>Те они не будут заменять друг друга. Они будут друг друга дополнять.
Отчасти согласен, но думаю что со временем биомасса вытеснит кремний.
Re[9]: Многопоточность сегодня
От: AVM Россия  
Дата: 11.10.07 20:24
Оценка: +1
Здравствуйте, remark, Вы писали:

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


AVM>>Ну а если уж сваливаться на философию, то мое мнение начинает сдвигаться в сторону что развитие современных кремниевых процессоров — тупиковая ветвь. Какая разница 4 или 80 или 8000 ядер. Качественный скачек это не дает,


R>А качественного скачка и раньше никогда в истории не было. Было 10МГц, потом 20МГц, потом 50МГц, потом 100МГц, потом 200МГц, потом 500МГц, потом 1ГГц.

R>Просто умножается на 2. И это всех устраивало. И будет устраивать.
Был, переход от механики к электричеству.

R>>>

AVM>>
R>
Re[3]: Многопоточность сегодня
От: RegisteredUser  
Дата: 12.10.07 00:11
Оценка:
Здравствуйте, remark, Вы писали:

R>Скорее всего ты говоришь о какой-то очень ограниченной области применения, либо вообще о HPC.


Нет, я говорю о языках общего назначения. Общеизвестный пример: на К написала большая часть kdb (говорят лидер рынка БД по производительности), набор трейдерских (то бишь зачастую очень real-time-овских) и других околофинансовых приложений (kx.com). Порылся на форумах JSoftware — нет, к сожалению текущая реализация J 601 никак не использует многоядерность, но принципиальных проблем с её использованием нет (ввиду implicit parallelism).
Просто эти языки и платформы предлагают иную (векторную сиречь _параллельную_) парадигму программирования (что не означает кстати, что они подходят лишь для перемножения матриц — обычные повседневные задачи тоже зачастую легко "векторизуются").
Это был всего лишь мой пример существующего решения проблемы означенной в заглавии этой дискуссии. Продолжайте ломать копия о memory barrier-ы и прочие низкоуровневые детали реализации взгромождаемые традиционными постфортрановскими средствами разработки на плечи прикладного программиста
Re[10]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 04:31
Оценка: +1
Здравствуйте, AVM, Вы писали:
AVM>Отчасти согласен, но думаю что со временем биомасса вытеснит кремний.
Там проблема не в структуре кристалла. Если мы хакнем алгоритмическую базу, то прошить ее можно будет хоть в кремнии, хоть в германии. См.тж. Тезис Черча.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: multicore -- напоминает переход на Win32
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 04:49
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Что-то разговоры о проблемах программирования в условиях многоядерности напоминают мне шумиху вокруг перехода на Win32. Тогда так же было много шума. Многие выгоды сулили. Мол не будет для ваших данных барьеров в 64K, будут доступны файлы объемом свыше 2Gb и пр.


E>А в итоге -- многих ли этот переход действительно серьезно затронул?

Вообще-то этот переход серъезно затронул практически всех.
Проблема-то не в перекомпиляции приложения. Эти приложения к 2005 году практически вымерли совсем.
Проблема в том, что требования пользователя изменились. На win16 не было принято писать многопоточные приложения. У всех вся работа делалась прямо в цикле выборки сообщений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Многопоточность сегодня
От: Стэн http://stanonwork.blogspot.com/
Дата: 12.10.07 05:56
Оценка:
Здравствуйте, AVM, Вы писали:

С>>А с какой скоростью и с какой точностью сможешь перемножить две матрицы 100x100 действительных чисел в уме?

AVM>Это вопрос к Человеку дождя, если ты догадываешься о чем я — Мы не знаем всех возможностей мозга.
Зато я читал о парочке случаев, из клинической психологии, когда человек мог запомнить и процетировать дословно несколько десятков страниц книжного текста, но при этом совершенно не мог объяснить о чем текст.
На самом деле мы знаем о возможностях мозга гораздо больше чем думают многие, и известно, что чудес не бывает, просто хочется в это верить...

AVM>Можно задать и встречный вопрос? — с какой скоростью японский робот-пылесос сможет найти (если вообще сможет) грязные носки в углу? Да ладно носки — с какой скоростью он сможет найти угол

Хороший вопрос. Вообщем-то о том и речь, что если задача искать носки, то забудь о перемножении матриц, если матрицы, то стоит забыть о носках...
Возьми какую-нибудь программную реализацию нейросетевого алгоритма. Нейронную сеть на его основе можно научить перемножать два числа, но для этого "умножения" ему придется несколько десятков тысяч внутренних коэффициентов перемножить! Спрашивается: а зачем такие сложности?

Сразу предвижу утверждение, что компьютер одной частью своего "мозга" может быстро искать носки, а другой быстро перемножать матрицы... Компьютер (ИИ), который пользуется компьютером... Вернемся тудаже откуда начали.
Re[11]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 06:10
Оценка: 14 (2) -2
Здравствуйте, Sinclair, Вы писали:

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

AVM>>Отчасти согласен, но думаю что со временем биомасса вытеснит кремний.
S>Там проблема не в структуре кристалла. Если мы хакнем алгоритмическую базу, то прошить ее можно будет хоть в кремнии, хоть в германии. См.тж. Тезис Черча.
IMHO хакнуть — это только пол дела, потом его надо заимплементить. Ну хакнул ты алгоритм генерации запаха. Как ты имплементируешь скунса в игрушках на железе которое сделано по сути песка? На кремнии в рантайме химии нет, там голая физика.

Тут задавали вопрос про скорость перемножения матриц. А какая скорость принятия решения у хищной птицы, который в пикировании ловит добычу? И сколько фотодиодов должна иметь каменная оптика, чтобы различить мышь в траве c высоты птичьего полета?

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

Пишут супер навигационные системы, запускают спутники, создают GPS и ГЛОНАС, чтобы самолеты и корабли не заблудились. А птицы просто летят на зимовку и возвращаются с нее. Гарбуша просто идет на нерест.

Бъемся над распознаванием голоса, наворотили кучу железа и софта, защитили кучу диссертаций и получили вагон премий, а кутенок уже через пол часа уже узнает колос хозяина.

Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.
Re[11]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 06:13
Оценка:
Здравствуйте, Стэн, Вы писали:

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

Можно еще один хороший вопрос? Зачем нам вообще перемножать матрицы? Может быть только для того, чтобы сделать компьютер умеющий их перемножать?
Re[12]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 06:45
Оценка:
Здравствуйте, AVM, Вы писали:
С>>Хороший вопрос. Вообщем-то о том и речь, что если задача искать носки, то забудь о перемножении матриц, если матрицы, то стоит забыть о носках...
AVM>Можно еще один хороший вопрос?
Ничего хорошего в этом вопросе нету.
AVM>Зачем нам вообще перемножать матрицы?
AVM>Может быть только для того, чтобы сделать компьютер умеющий их перемножать?
Перемножение матриц имеет невероятно широкий спектр прикладных применений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 06:45
Оценка:
Здравствуйте, AVM, Вы писали:

S>>Там проблема не в структуре кристалла. Если мы хакнем алгоритмическую базу, то прошить ее можно будет хоть в кремнии, хоть в германии. См.тж. Тезис Черча.

AVM>IMHO хакнуть — это только пол дела, потом его надо заимплементить.
AVM>Ну хакнул ты алгоритм генерации запаха.
Что такое "генерация запаха"? Я знаю массу приборов, которые генерируют запах — только в путь, причем безо всякого интеллекта.
AVM>Как ты имплементируешь скунса в игрушках на железе которое сделано по сути песка? На кремнии в рантайме химии нет, там голая физика
Ничего не понимаю. О каких игрушках речь? При чем тут песок?

AVM>Тут задавали вопрос про скорость перемножения матриц. А какая скорость принятия решения у хищной птицы, который в пикировании ловит добычу? И сколько фотодиодов должна иметь каменная оптика, чтобы различить мышь в траве c высоты птичьего полета?

Почему фотодиодов? Почему каменная? Птичий глаз распознает около миллиарда пикселов. В современной мыльнице их всего в 100 раз меньше. Для того, чтобы соорудить аналог птичьего глаза, нужно уменьшить линейный размер элемента в 10 раз. Еще десять лет назад типичные площади фотоматриц были около 0.1 MP. Я не уверен, что для достижения следующего этапа в зрении потребуется использовать все эти трансретиналы, родопсины и прочее.

Глаз не обязан быть построен по той же технологии, что и мозг. И

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

И что?


AVM>Пишут супер навигационные системы, запускают спутники, создают GPS и ГЛОНАС, чтобы самолеты и корабли не заблудились. А птицы просто летят на зимовку и возвращаются с нее. Гарбуша просто идет на нерест.

И что?

AVM>Бъемся над распознаванием голоса, наворотили кучу железа и софта, защитили кучу диссертаций и получили вагон премий, а кутенок уже через пол часа уже узнает колос хозяина.

И что?

AVM>Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.

А на чем еще? Неужто на воле божьей?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 06:54
Оценка: :))) :))
Здравствуйте, Sinclair, Вы писали:

AVM>>Может быть только для того, чтобы сделать компьютер умеющий их перемножать?

S>Перемножение матриц имеет невероятно широкий спектр прикладных применений.
Например?
Re[13]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 07:23
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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


S>>>Там проблема не в структуре кристалла. Если мы хакнем алгоритмическую базу, то прошить ее можно будет хоть в кремнии, хоть в германии. См.тж. Тезис Черча.

AVM>>IMHO хакнуть — это только пол дела, потом его надо заимплементить.
AVM>>Ну хакнул ты алгоритм генерации запаха.
S>Что такое "генерация запаха"? Я знаю массу приборов, которые генерируют запах — только в путь, причем безо всякого интеллекта.
AVM>>Как ты имплементируешь скунса в игрушках на железе которое сделано по сути песка? На кремнии в рантайме химии нет, там голая физика
S>Ничего не понимаю. О каких игрушках речь? При чем тут песок?
Это я про аля виртуальная реальность. Шлемы делать более-менее научились. Объемныое изображение есть. Но достижения в передачи тактильных ощущений и запахов — почти полный ноль.
При чем тут песок? А что есть первый транзистор, на котором были построены первые ПК знаешь?

AVM>>Тут задавали вопрос про скорость перемножения матриц. А какая скорость принятия решения у хищной птицы, который в пикировании ловит добычу? И сколько фотодиодов должна иметь каменная оптика, чтобы различить мышь в траве c высоты птичьего полета?

S>Почему фотодиодов? Почему каменная? Птичий глаз распознает около миллиарда пикселов. В современной мыльнице их всего в 100 раз меньше. Для того, чтобы соорудить аналог птичьего глаза, нужно уменьшить линейный размер элемента в 10 раз. Еще десять лет назад типичные площади фотоматриц были около 0.1 MP. Я не уверен, что для достижения следующего этапа в зрении потребуется использовать все эти трансретиналы, родопсины и прочее.
Матрицу то сделают в конце концов и потом упруться в проблему правильной и быстрой обработки поступающего сигнала. Прикрутят эту матрицу к 512 разрядной шине данных, подключат Intel СуперПиперон с 80 ядрами, а программисты так и будут продолжать обсуждение на форумах "какую функцию вызвать для эффективного выделения памяти" на всем этом двоичном железе. IMHO это тупиковая ветвь.

S>Глаз не обязан быть построен по той же технологии, что и мозг. И

Глаз это устройство ввода, которое очень хорошо сопряжено с блоком обработки. Интуиция мне подсказывает, что достаточно легко сопрягать модули, которые построены на общих принципах. И очень сложно добиться сопряжения, если модули основаны на совершенно разных принципах работы.
Понимаешь о чем я?

AVM>>Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.

S>А на чем еще? Неужто на воле божьей?
Да я вообще то материалист Это я к тому что многие прикладные задачи, которые сейчас пытаются решать люди уже давно решены в окружающем нас мире и их решение базируется на совершенно других технологиях.

Сорри если раздражаю своей философией.
Re[14]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 08:45
Оценка: +1
Здравствуйте, AVM, Вы писали:
AVM>Это я про аля виртуальная реальность. Шлемы делать более-менее научились. Объемныое изображение есть. Но достижения в передачи тактильных ощущений и запахов — почти полный ноль.
При чем тут виртуальная реальность? Выйди из нее. Ты обсуждал применение "биомассы" для компьютеров. Компьютер — это вычислитель, а не телевизор.
AVM>При чем тут песок? А что есть первый транзистор, на котором были построены первые ПК знаешь?
Я знаю. Я не понимаю, почему нужно делать запах из песка.

AVM>Матрицу то сделают в конце концов и потом упруться в проблему правильной и быстрой обработки поступающего сигнала. Прикрутят эту матрицу к 512 разрядной шине данных, подключат Intel СуперПиперон с 80 ядрами, а программисты так и будут продолжать обсуждение на форумах "какую функцию вызвать для эффективного выделения памяти" на всем этом двоичном железе. IMHO это тупиковая ветвь.

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

AVM>Глаз это устройство ввода, которое очень хорошо сопряжено с блоком обработки. Интуиция мне подсказывает, что достаточно легко сопрягать модули, которые построены на общих принципах. И очень сложно добиться сопряжения, если модули основаны на совершенно разных принципах работы.


AVM>Понимаешь о чем я?
Понимаю. Ты говоришь о том, что у тебя некачественная интуиция. Пока что сопряжение модулей на разных принципах работы удается прямо-таки на ура.

AVM>>>Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.

S>>А на чем еще? Неужто на воле божьей?
AVM>Да я вообще то материалист Это я к тому что многие прикладные задачи, которые сейчас пытаются решать люди уже давно решены в окружающем нас мире и их решение базируется на совершенно других технологиях.
Я говорю не о технологиях, а об алгоритмах. Нет никакой принципиальной разницы, применять электромеханические реле, вакуумные лампы, или кремний. Технологии — вторичны.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 09:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

AVM>>Это я про аля виртуальная реальность. Шлемы делать более-менее научились. Объемныое изображение есть. Но достижения в передачи тактильных ощущений и запахов — почти полный ноль.
S>При чем тут виртуальная реальность?
Создание правильных моделей — одна из задач, которую пытаются решать при помощи компьютеров.

S>Компьютер — это вычислитель, а не телевизор.

IMHO очень примитивно.

AVM>>При чем тут песок? А что есть первый транзистор, на котором были построены первые ПК знаешь?

S>Я знаю. Я не понимаю, почему нужно делать запах из песка.
Не делать запах из песка, а использовать систему управления генерацией запаха, построенную из песка и основанную на дискретной обработке сигналов.

AVM>>Матрицу то сделают в конце концов и потом упруться в проблему правильной и быстрой обработки поступающего сигнала. Прикрутят эту матрицу к 512 разрядной шине данных, подключат Intel СуперПиперон с 80 ядрами, а программисты так и будут продолжать обсуждение на форумах "какую функцию вызвать для эффективного выделения памяти" на всем этом двоичном железе. IMHO это тупиковая ветвь.

S>Проблеа правильной и быстрой обработки — в алгоритмах. Мы не знаем, какими алгоритмами пользуется глаз. А когда узнаем — сможем воспроизвести их хоть на реле.
AVM>>Глаз это устройство ввода, которое очень хорошо сопряжено с блоком обработки. Интуиция мне подсказывает, что достаточно легко сопрягать модули, которые построены на общих принципах. И очень сложно добиться сопряжения, если модули основаны на совершенно разных принципах работы.
S>
AVM>>Понимаешь о чем я?
S>Понимаю...
Не, не понимаешь. На реле ты сможешь воспроизвести только дискретные алгоритмы обработки. Невозможно сделать преобразование "аналог -> цифра -> аналог" без потерь. Эти потери заложены в алгоритмы. Скорее всего, когда ты узнаешь как работает глаз, то сразу поймешь что эти потери очень критичны и дискретные алгоритмы обработки не позволяют добиться тех же результатов.

AVM>>>>Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.

S>>>А на чем еще? Неужто на воле божьей?
AVM>>Да я вообще то материалист Это я к тому что многие прикладные задачи, которые сейчас пытаются решать люди уже давно решены в окружающем нас мире и их решение базируется на совершенно других технологиях.
S>Я говорю не о технологиях, а об алгоритмах. Нет никакой принципиальной разницы, применять электромеханические реле, вакуумные лампы, или кремний. Технологии — вторичны.
Ты ставишь реле и лампу в один ряд, потому что используешь дискретные методы обработки данных, но между ними есть принципиальная разница.
Лампа основана на технологии неприрывной обработки сигнала, реле на — дискретной. Разница принципиальная.

PS: И ни одной попытки перейти на личности с моей стороны. Надеюсь на взаимное понимание.
Re[4]: Многопоточность сегодня
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 12.10.07 10:06
Оценка: 7 (1)
RegisteredUser,

R>>Скорее всего ты говоришь о какой-то очень ограниченной области применения, либо вообще о HPC.


RU>Просто эти языки и платформы предлагают иную (векторную сиречь _параллельную_) парадигму программирования (что не означает кстати, что они подходят лишь для перемножения матриц — обычные повседневные задачи тоже зачастую легко "векторизуются").

RU>Это был всего лишь мой пример существующего решения проблемы означенной в заглавии этой дискуссии. Продолжайте ломать копия о memory barrier-ы и прочие низкоуровневые детали реализации взгромождаемые традиционными постфортрановскими средствами разработки на плечи прикладного программиста

У меня возникли сомнения насчёт "лёгкой векторизации". Перевести программу в "векторную" форму примерно так же легко, как и программу, написанную императивно в функциональную. Суть переписать заново, то есть.

Ещё меня давно интересует вопрос, есть ли полный базис операций над массивами. В J операций много, обычно хватает, но кто сказал, что набор эквивалентен МТ? Видать, не смог Кен Иверсон доказать это, вот и оставили там обычный for & while...
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[16]: Многопоточность сегодня
От: cl-user  
Дата: 12.10.07 10:12
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>На реле ты сможешь воспроизвести только дискретные алгоритмы обработки.


Информация дискретна. Вернее — "недискретированная информация" плохо поддаётся обработке.

А если нужна повторяемость эксперимента...

С теми-же запахами: если бы парфюмеры не умели пользоваться массовыми долями...

А на клеточном уровне всё равно идёт обмен сигналами.
Re[16]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 10:37
Оценка:
Здравствуйте, AVM, Вы писали:
S>>При чем тут виртуальная реальность?
AVM>Создание правильных моделей — одна из задач, которую пытаются решать при помощи компьютеров.
Совершенно верно, но я всё равно не понимаю, в чем проблема. Моделирование химии развивается вполне успешно.

AVM>IMHO очень примитивно.

IMHO это верно.

AVM>Не делать запах из песка, а использовать систему управления генерацией запаха,

Я по-прежнему настаиваю на вопросе "что такое генерация запаха?".
AVM>построенную из песка и основанную на дискретной обработке сигналов.
А в чем проблема с дискретной обработкой? Пока что у нас нет никакой математики, принципиально не сводимой к дискретной. Более того, "биомасса" не дает никакой новой математики.

AVM>Не, не понимаешь. На реле ты сможешь воспроизвести только дискретные алгоритмы обработки. Невозможно сделать преобразование "аналог -> цифра -> аналог" без потерь. Эти потери заложены в алгоритмы. Скорее всего, когда ты узнаешь как работает глаз, то сразу поймешь что эти потери очень критичны и дискретные алгоритмы обработки не позволяют добиться тех же результатов.

Скорее всего, ты сильно ошибаешься. Поскольку глаз работает как раз с дискретным сигналом. Скорее всего, когда ты узнаешь, как работает глаз, то сразу поймешь, что проблема не в потерях. Особенно заметно это в том, что глаз прекрасно воспринимает картинку с такими потерями, что погрешность АЦП бесконечно мала по сравнению с ними.


S>>Я говорю не о технологиях, а об алгоритмах. Нет никакой принципиальной разницы, применять электромеханические реле, вакуумные лампы, или кремний. Технологии — вторичны.

AVM>Ты ставишь реле и лампу в один ряд, потому что используешь дискретные методы обработки данных, но между ними есть принципиальная разница.
AVM>Лампа основана на технологии неприрывной обработки сигнала, реле на — дискретной. Разница принципиальная.
Лампа основана на технологии дискретной обработки сигнала. Речь не о ламповом усилителе, а об логических элементах.

AVM>PS: И ни одной попытки перейти на личности с моей стороны. Надеюсь на взаимное понимание.

Ок, хорошо. Но мне тяжело обсуждать такие вещи с человеком, который игнорирует элементарные знания, накопленные человечеством.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 10:37
Оценка:
Здравствуйте, AVM, Вы писали:
AVM>>>Понимаешь о чем я?
S>>Понимаю...
AVM>Не, не понимаешь. На реле ты сможешь воспроизвести только дискретные алгоритмы обработки.
Еще раз подчеркну: нет никаких "недискретных" алгоритмов обработки. По крайней мере, до сих пор таких алгоритмов обнаружено не было. См. тезис Черча. Нет никакой специальной математики для аналоговых величин, которая не была бы сводима к дискретной.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 10:45
Оценка:
Здравствуйте, cl-user, Вы писали:

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


AVM>>На реле ты сможешь воспроизвести только дискретные алгоритмы обработки.


CU>Информация дискретна. Вернее — "недискретированная информация" плохо поддаётся обработке.

Именно, неприрывная информация не поддается обработке в дискретной системе без потерь. Весь вопрос "можно ли использовать дискретную систему для обработки аналогового сигнала?" сводится к вопросу "какая нужна точность?"

CU>А если нужна повторяемость эксперимента...

Нельзя войти в одну реку дважды.

CU>С теми-же запахами: если бы парфюмеры не умели пользоваться массовыми долями...

Они просто умеют хорошо перемешивать и при этом хороший "нюхачь" может почувствовать разницу.

CU>А на клеточном уровне всё равно идёт обмен сигналами.

Вопрос "какими сигналами?" Ответа естественно не жду, т.к. это пока тайна за семью печатями.
Но есть тема для размышления: в клетке хранится геном — огромное количество информации о владельце. Современные вычислительные системы хранят информацию на магнитных дисках. Технологии принципиально разные, функциональные возможности — несопоставимы. Для копирования 1Т данных требуются часы, для копирования генома — минуты. IMHO очень шустрая реализация интерфейса Clonable
Re[16]: Многопоточность сегодня
От: Кодёнок  
Дата: 12.10.07 10:52
Оценка: :))) :))) :))) :)))
Здравствуйте, AVM, Вы писали:

AVM>>>Понимаешь о чем я?

S>>Понимаю...
AVM>Не, не понимаешь.

Тренировка телепатов
Re[18]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 11:16
Оценка:
Здравствуйте, AVM, Вы писали:

CU>>Информация дискретна. Вернее — "недискретированная информация" плохо поддаётся обработке.

AVM>Именно, неприрывная информация не поддается обработке в дискретной системе без потерь. Весь вопрос "можно ли использовать дискретную систему для обработки аналогового сигнала?" сводится к вопросу "какая нужна точность?"
В аналоговом случае, при передаче информации потери больше чем в дискретном. Точно так же, доля ошибок значительно больше. (ведь человеку свойственно ошибаться ) Надо еще сказать, что аналогового сигнала как такого не существует. Неплохо помнить о существование кванта, и даже земля вращается вокруг земли дискретно. За аналоговый сигнал мы принимаем изменяемую величину где точность шага изменений нас не волнует.
Re[17]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 11:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>>>При чем тут виртуальная реальность?
AVM>>Создание правильных моделей — одна из задач, которую пытаются решать при помощи компьютеров.
S>Совершенно верно, но я всё равно не понимаю, в чем проблема. Моделирование химии развивается вполне успешно.

AVM>>Не делать запах из песка, а использовать систему управления генерацией запаха,

S>Я по-прежнему настаиваю на вопросе "что такое генерация запаха?".
Идешь ты по первому уровню DOOM, и чувствуешь что пахнет розами, а потом опа — наступил в дерьмо

AVM>>построенную из песка и основанную на дискретной обработке сигналов.

S>А в чем проблема с дискретной обработкой? Пока что у нас нет никакой математики, принципиально не сводимой к дискретной.
А может не надо сводить всю математику только к дискретной математике?


AVM>>Не, не понимаешь. На реле ты сможешь воспроизвести только дискретные алгоритмы обработки. Невозможно сделать преобразование "аналог -> цифра -> аналог" без потерь. Эти потери заложены в алгоритмы. Скорее всего, когда ты узнаешь как работает глаз, то сразу поймешь что эти потери очень критичны и дискретные алгоритмы обработки не позволяют добиться тех же результатов.

S>Скорее всего, ты сильно ошибаешься. Поскольку глаз работает как раз с дискретным сигналом. Скорее всего, когда ты узнаешь, как работает глаз, то сразу поймешь, что проблема не в потерях.
Ты хочешь прилепить ярлык и сказать что точно знаешь как работает механизм восприятие видеообразов у живых организмов. Судя по тому что ты не конкретизируешь какой глаз — ты прекрасно знаешь способы обработки видео всеми живыми организмами.
Сдаюсь, и снимаю шляпу
S>Особенно заметно это в том, что глаз прекрасно воспринимает картинку с такими потерями, что погрешность АЦП бесконечно мала по сравнению с ними.
Я честно говоря не понял что ты хотел сказать, может быть имелось ввиду "мозг прекрасно воспринимает картинку с такими потерями"?
ИМНО все в кучу и ЦП и переферию


S>>>Я говорю не о технологиях, а об алгоритмах. Нет никакой принципиальной разницы, применять электромеханические реле, вакуумные лампы, или кремний. Технологии — вторичны.

AVM>>Ты ставишь реле и лампу в один ряд, потому что используешь дискретные методы обработки данных, но между ними есть принципиальная разница.
AVM>>Лампа основана на технологии неприрывной обработки сигнала, реле на — дискретной. Разница принципиальная.
S>Лампа основана на технологии дискретной обработки сигнала. Речь не о ламповом усилителе, а об логических элементах.
Принцип работы электронной лампы основан на эмиссии электронов из катода и их пролете через управляющую сетку к аноду. А огонек который там светиться это нить нагрева для того, чтобы электроны пошустрее вылетали из катода. И придумал это Джон Амброз Флеминг в начале прошлого века.
Я про эти лампы говорю и честно признаюсь ничего не слышал про про лампы "основанные на технологии дискретной обработки сигнала".

AVM>>PS: И ни одной попытки перейти на личности с моей стороны. Надеюсь на взаимное понимание.

S>Ок, хорошо. Но мне тяжело обсуждать такие вещи с человеком, который игнорирует элементарные знания, накопленные человечеством.
Соррии если мой ответ покажется тебе резким. Если очень тяжело — давай просто прекратим это обсуждение. Я заранее готов согласиться что 80 ядер в пластиковом корпусе и 20G RAM уделают по производительности сбора меда улей пчел и в соответствии тезисом Черча сможет координировать работу муравейника.
Re[9]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 11:20
Оценка:
Здравствуйте, iZEN, Вы писали:


A>>Разгадка простая — пока один экземпляр gcc занимает процессор, второй читает/пишет данные с диска.


ZEN>Я раньше тоже так думал, но разгадка оказалась не так проста.

ZEN>На двуядерном процессоре команда make -j4 ровным счётом ничего не дала в плане уменьшения времени компиляции -- времени затратилось ровно столько же (с точностью до 5 минут), как-будто компиляция проводилась в однопоточном режиме на одном ядре.
ZEN>А вот команда make -j2 действительно увеличила скорость компиляции 2,5 раза.
Теперь я уже запутался, кто дал выйгрыш. Двухпроцессорность, или двухпоточность.
Re[18]: Многопоточность сегодня
От: cl-user  
Дата: 12.10.07 11:24
Оценка: +1
Здравствуйте, AVM, Вы писали:

CU>>Информация дискретна. Вернее — "недискретированная информация" плохо поддаётся обработке.

AVM>Именно, неприрывная информация не поддается обработке в дискретной системе без потерь. Весь вопрос "можно ли использовать дискретную систему для обработки аналогового сигнала?" сводится к вопросу "какая нужна точность?"

Необходимо и достаточно.

"Чистую непрерывную информацию" невозможно обрабатывать (сравнивать, хранить, изменять — без потери этой самой информации) вообще (если ты не введёшь ту-же самую точность, _дискретную_ точность). И что ты с ней будешь делать? Запись концерта на плёнку — это не повторение концерта — это получение "нечто", что может напомнить концерт или дать приблизительное (степень приближения?) представление о нём. Копия этой плёнки — это _другое_ "нечто", которое _объективно_ и не дискретно даже сравнить ни с чем нельзя. Люди даже дискретную информацию умудряются по-разному интерпретировать. Что уж по аналоговую говорить?...

CU>>А если нужна повторяемость эксперимента...

AVM>Нельзя войти в одну реку дважды.

Без унификации всего и вся... ню-ню. Нечёткие алгоритмы и наноэлектроника армейским строем покажутся по сравнению с таким бардаком.

CU>>С теми-же запахами: если бы парфюмеры не умели пользоваться массовыми долями...

AVM>Они просто умеют хорошо перемешивать и при этом хороший "нюхачь" может почувствовать разницу.

Что значит "хорошо перемешивать"? Т.е. составлять (повторять) запахи не _зная_ долей составляющих? А поставить дело на поток (опять же без долей)?

CU>>А на клеточном уровне всё равно идёт обмен сигналами.

AVM>Вопрос "какими сигналами?" Ответа естественно не жду, т.к. это пока тайна за семью печатями.

Вам перечислить _все_ сигналы? Так это и о написанных программах уже не скажешь. А перечислить характер "сигналов" — запросто. Хотя да — алгоритмы реакции пока не ясны.

AVM>Но есть тема для размышления: в клетке хранится геном — огромное количество информации о владельце. Современные вычислительные системы хранят информацию на магнитных дисках. Технологии принципиально разные, функциональные возможности — несопоставимы. Для копирования 1Т данных требуются часы, для копирования генома — минуты. IMHO очень шустрая реализация интерфейса Clonable


Хм, скорость штамповки DVD по матрице? Не прожиг в DVD-ROM, а именно штамповка.

Короче — заканчивайте с аналогиями. Принципиальную невозможность математически доказать можете?
Re[19]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 11:29
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


CU>>>Информация дискретна. Вернее — "недискретированная информация" плохо поддаётся обработке.

AVM>>Именно, неприрывная информация не поддается обработке в дискретной системе без потерь. Весь вопрос "можно ли использовать дискретную систему для обработки аналогового сигнала?" сводится к вопросу "какая нужна точность?"
GZ>В аналоговом случае, при передаче информации потери больше чем в дискретном. Точно так же, доля ошибок значительно больше. (ведь человеку свойственно ошибаться )
Полностью согласен — нет ничего совершенного в этом мире. Странно только одно, наш цифровой подход не может "оцифровать" некоторые явления этого мира. Я только высказал гипотезу, что надо изменить подход.
GZ>Надо еще сказать, что аналогового сигнала как такого не существует. Неплохо помнить о существование кванта, и даже земля вращается вокруг земли дискретно. За аналоговый сигнал мы принимаем изменяемую величину где точность шага изменений нас не волнует.
Честно тебе признаюсь, не я разработал эту систему и не знаю как конкретно она вращается.
Кстати интересная мысль — а время дискретно???
Re[5]: Многопоточность сегодня
От: RegisteredUser  
Дата: 12.10.07 11:32
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>У меня возникли сомнения насчёт "лёгкой векторизации". Перевести программу в "векторную" форму примерно так же легко, как и программу, написанную императивно в функциональную. Суть переписать заново, то есть.


Я имел ввиду "имплементация привычных задач в векторном стиле" — проще говоря, там где среднестатистический С# программист напихает for-ов и, в лучшем случае foreach-ев (автоматическое распараллеливание коих на текущий момент, как я слышал, большая проблема), среднестатистический J-ст будет применять стандартные и свои глаголы сразу на весь набор данных задумываясь только о правильном сопряжении ранков (параллельное исполнение которых на машинном уровне особых затруднений вызвать не должно).

LCR>Ещё меня давно интересует вопрос, есть ли полный базис операций над массивами. В J операций много, обычно хватает, но кто сказал, что набор эквивалентен МТ? Видать, не смог Кен Иверсон доказать это, вот и оставили там обычный for & while...


А что такое МТ? Мне кажется for. оставлен потому что, в конце-то концов, не все ж можно считать параллельно Тот же FoldR который здесь причастие "/" — его ж не распараллелишь? Лично я ни разу for. явно не использовал, хотя его тацидный эквивалент "^:" — сплошь и рядом — там где нужна именно итеративная обработка, а она очень часто нужна. Часто, но не всегда
Re[9]: Многопоточность сегодня
От: alpha21264 СССР  
Дата: 12.10.07 11:33
Оценка:
Здравствуйте, iZEN, Вы писали:

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


iZEN>>>>Вы сами проверяли?

iZEN>>>>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).
GZ>>>2,5 — не очень то линейно.
GZ>>>С GCС не работал. А он действительно компилирует многопоточно, или как VS2005 загружает по проекту на каждый проц?

A>>Кха... Юниксовый make много... параллельный короче.

A>>Пишешь make -j 2 и он компилирует в два раза быстрее.
A>>Даже если в машине ОДИН процессор.
A>>А если в машине два процессора, то надо писать make -j 4.
A>>Во как.
A>>Разгадка простая — пока один экземпляр gcc занимает процессор, второй читает/пишет данные с диска.

ZEN>Я раньше тоже так думал, но разгадка оказалась не так проста.

ZEN>На двуядерном процессоре команда make -j4 ровным счётом ничего не дала в плане уменьшения времени компиляции -- времени затратилось ровно столько же (с точностью до 5 минут), как-будто компиляция проводилась в однопоточном режиме на одном ядре.
ZEN>А вот команда make -j2 действительно увеличила скорость компиляции 2,5 раза.

Всяко бывает. Они ведь еще и кеш могут друг у друга отбирать. А... после j пробел стоял?

Течёт вода Кубань-реки куда велят большевики.
Re[18]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 11:47
Оценка:
Здравствуйте, AVM, Вы писали:
AVM>Идешь ты по первому уровню DOOM, и чувствуешь что пахнет розами, а потом опа — наступил в дерьмо
Ну, значит нужен картридж с запахами розы и дерьма.

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

AVM>А может не надо сводить всю математику только к дискретной математике?

Примеры несводимых к дискретной математике алгоритмов в студию.

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

AVM>Ты хочешь прилепить ярлык и сказать что точно знаешь как работает механизм восприятие видеообразов у живых организмов.
Ну уж на таком уровне, как дискретный/недискретный — знаю. Так, для справки: восприятие зрительного образа начинается с попадания фотона в светочувствительную клетку. Сие есть факт существенно дискретный.
AVM>Судя по тому что ты не конкретизируешь какой глаз — ты прекрасно знаешь способы обработки видео всеми живыми организмами.
Ну, способов не так уж и много. Глаза отличаются в основном инженерным устройством: ну там, оптика разная; всякие оптимизации типа переменной плотности элементов; разное подключение считывающих элементов (спереди/сзади), встраивание клеток предварительной обработки и т.п.
AVM>Сдаюсь, и снимаю шляпу
Ну, неплохой обзор технологий зрения приведен, к примеру, здесь.

S>>Особенно заметно это в том, что глаз прекрасно воспринимает картинку с такими потерями, что погрешность АЦП бесконечно мала по сравнению с ними.

AVM>Я честно говоря не понял что ты хотел сказать, может быть имелось ввиду "мозг прекрасно воспринимает картинку с такими потерями"?
AVM>ИМНО все в кучу и ЦП и переферию
А там нет четкого разделения. Ты же не думаешь, что глаз тупо гонит в мозг MPEG-68? Проблема как раз в частности в том, что не очень хорошо известно, как обрабатывается картинка. Глаза неспроста расположены поближе к мозгу. У некоторых организмов вообще чуть ли не половина работы по выделению образов сделана прямо в глазу.
Если мы не теряем узнаваемость картинки даже после внесения в нее существенных искажений, я не вижу повода настаивать на сверхъестественной точности передачи входных данных для работоспособности используемых в природе алгоритмов. Элементарная логика не дает мне это сделать.

AVM>Принцип работы электронной лампы основан на эмиссии электронов из катода и их пролете через управляющую сетку к аноду. А огонек который там светиться это нить нагрева для того, чтобы электроны пошустрее вылетали из катода. И придумал это Джон Амброз Флеминг в начале прошлого века.

AVM>Я про эти лампы говорю и честно признаюсь ничего не слышал про про лампы "основанные на технологии дискретной обработки сигнала".
Я имел в виду ламповые цифровые компьютеры.

AVM>Соррии если мой ответ покажется тебе резким. Если очень тяжело — давай просто прекратим это обсуждение. Я заранее готов согласиться что 80 ядер в пластиковом корпусе и 20G RAM уделают по производительности сбора меда улей пчел

А при чем тут сбор меда?
AVM>и в соответствии тезисом Черча сможет координировать работу муравейника.
Я совершенно не уверен, что координирование работы муравейника требует белковых решений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Многопоточность сегодня
От: cl-user  
Дата: 12.10.07 11:50
Оценка: :))) :))
Здравствуйте, AVM, Вы писали:

AVM>Кстати интересная мысль — а время дискретно???


Ну что за....

А бутылка кефира полна по Тьюрингу?
Re[19]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 12:04
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>"Чистую непрерывную информацию" невозможно обрабатывать (сравнивать, хранить, изменять — без потери этой самой информации) вообще (если ты не введёшь ту-же самую точность, _дискретную_ точность).

Невозможно или не умеем?

CU>>>С теми-же запахами: если бы парфюмеры не умели пользоваться массовыми долями...

AVM>>Они просто умеют хорошо перемешивать и при этом хороший "нюхачь" может почувствовать разницу.

CU>Что значит "хорошо перемешивать"?

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

CU>>>А на клеточном уровне всё равно идёт обмен сигналами.

AVM>>Вопрос "какими сигналами?" Ответа естественно не жду, т.к. это пока тайна за семью печатями.
CU>Вам перечислить _все_ сигналы? Так это и о написанных программах уже не скажешь. А перечислить характер "сигналов" — запросто. Хотя да — алгоритмы реакции пока не ясны.
Не надо перечислять. Я не уверен что известны даже все характеры сигналов.

AVM>>Но есть тема для размышления: в клетке хранится геном — огромное количество информации о владельце. Современные вычислительные системы хранят информацию на магнитных дисках. Технологии принципиально разные, функциональные возможности — несопоставимы. Для копирования 1Т данных требуются часы, для копирования генома — минуты. IMHO очень шустрая реализация интерфейса Clonable

CU>Хм, скорость штамповки DVD по матрице? Не прожиг в DVD-ROM, а именно штамповка.
Штамповку и получим, а толку от нее?
Если серьезно, то на базе этого механизма (хранение генома в клетке) в перспективе можно строить очень хорошие хранилища информации: отношение емкость/размер — огромное, энергопотребление — низкое, защита информации от потерь — великолепная. Есть правда и куча минусов, основной — мы до сих пор не знаем как оно работает

CU>Короче — заканчивайте с аналогиями.

Не нравятся?

CU>Принципиальную невозможность математически доказать можете?

Знал бы прикуп, жил бы в Сочи
Re[20]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.07 12:06
Оценка:
Здравствуйте, AVM, Вы писали:
AVM>Кстати интересная мысль — а время дискретно???
Нет, пространство и время не квантуются — флеймер ошибается.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 12:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

AVM>>Кстати интересная мысль — а время дискретно???
S>Нет, пространство и время не квантуются — флеймер ошибается.
Не квантуется — это да. Вопрос дискретно или нет время — пока считают открытым. Пока берется что время (а точнее пространство-время по теории относительности) непрерывно.
Re[6]: Многопоточность сегодня
От: Left2 Украина  
Дата: 12.10.07 12:28
Оценка:
>> Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции.
S>Здрасте-приехали. А че у меня тогда инкредибилд пересобирает солюшен за 20-30 минут, в то время как локальная пересборка — более 2 часов?
Потому что инкредибилд — это не только много процессоров, это ещё и много памяти и многократно увеличенная скорость чтения-записи на диск.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[21]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 12:49
Оценка:
Здравствуйте, cl-user, Вы писали:

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


AVM>>Кстати интересная мысль — а время дискретно???


CU>Ну что за....


CU>А бутылка кефира полна по Тьюрингу?

Зависит от того, оптимист вы или пессимист
Re[20]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 12:49
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>Полностью согласен — нет ничего совершенного в этом мире. Странно только одно, наш цифровой подход не может "оцифровать" некоторые явления этого мира. Я только высказал гипотезу, что надо изменить подход.

Зато многое уже может. Например, мы можем дискретно генерировать звук с большей точностью чем слышит человек. Только остается вопрос в том, что восприятие человека очень нелинейно. И звук при разных частотах слышится более четко или менее четко или громко. Восприятие цвета и интенсивности света тоже нелинейнно. Мы же можем дискретно обрабатывать все линейно.


AVM>Честно тебе признаюсь, не я разработал эту систему и не знаю как конкретно она вращается.

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

Вообще же, что лучше аналоговый или дискретный сигнал — это большой вопрос. Аналоговый сигнал несет больше информации. Дискретный сигнал менее подтвержен искажениям. Как заметил Sinclair они легко трансформируются друг в друга.

AVM>Кстати интересная мысль — а время дискретно???

Точно неизвестно.
Занятно следующее. Есть такой преобразователь — называется матрица от фотоаппарата. Когда световая интенсивность мала, уже заметно что свет является дискретной величиной. Фактически измеряется количество фотонов попавших(зарегистрированных) на ту или иную ячейку и вероятностным способом(распределение Пуассона) досчитывается нормальной, визуальной картинки. А это уже преобразователь из дискретного в дискретный вид. Человеческий глаз переобразовывает информацию из дискретный в аналоговый. И становится непонятно — что лучше. Дискретный в дискретный или дискретный в аналоговый.

ЗЫ. Нейроны общаются — с аналогово частотной модуляцией. То есть что-то дискретное в этом есть. здесь
Re[20]: Многопоточность сегодня
От: cl-user  
Дата: 12.10.07 12:51
Оценка:
Здравствуйте, AVM, Вы писали:

CU>>"Чистую непрерывную информацию" невозможно обрабатывать (сравнивать, хранить, изменять — без потери этой самой информации) вообще (если ты не введёшь ту-же самую точность, _дискретную_ точность).

AVM>Невозможно или не умеем?

Ты же сам говорил про воду... Можно получить некое подобие. Точную копию — нельзя.

CU>>Что значит "хорошо перемешивать"?

AVM>Брать большие по размеру доли и смешивать их, чтобы можно было пренебречь погрешностью отмеривания долей.

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

CU>>>>А на клеточном уровне всё равно идёт обмен сигналами.

AVM>>>Вопрос "какими сигналами?" Ответа естественно не жду, т.к. это пока тайна за семью печатями.
CU>>Вам перечислить _все_ сигналы? Так это и о написанных программах уже не скажешь. А перечислить характер "сигналов" — запросто. Хотя да — алгоритмы реакции пока не ясны.
AVM>Не надо перечислять. Я не уверен что известны даже все характеры сигналов.

Физика? (электро-магнитные) Химия (органическая и неорганическая)? Что ещё?

CU>>Хм, скорость штамповки DVD по матрице? Не прожиг в DVD-ROM, а именно штамповка.

AVM>Штамповку и получим, а толку от нее?

_ТОЧНАЯ_ копия.

AVM>Если серьезно, то на базе этого механизма (хранение генома в клетке) в перспективе можно строить очень хорошие хранилища информации: отношение емкость/размер — огромное, энергопотребление — низкое, защита информации от потерь — великолепная. Есть правда и куча минусов, основной — мы до сих пор не знаем как оно работает


Скорее всего произвольную последовательность хранить не получится...

CU>>Короче — заканчивайте с аналогиями.

AVM>Не нравятся?

"Они есть зло" и в лучшем случае могут служить для пояснения, но никак не для доказательства.
Re[22]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 12:55
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


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

AVM>>>Кстати интересная мысль — а время дискретно???
S>>Нет, пространство и время не квантуются — флеймер ошибается.
GZ>Не квантуется — это да. Вопрос дискретно или нет время — пока считают открытым. Пока берется что время (а точнее пространство-время по теории относительности) непрерывно.
Вот блин и приплыли. В соответствии с Тезисом Чёрча—Тьюринга все можно посчитать с помошью машины Тьюринга. (Про допущения в этом тезисе я скромно молчу). А блин в соответствии с теорией Энштейна пространство и время непрерывные.
Куда катиться этот мир
Re[23]: Многопоточность сегодня
От: cl-user  
Дата: 12.10.07 13:15
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>А блин в соответствии с теорией Энштейна пространство и время непрерывные.


На макро уровне. А если опустимся до элементарных частиц или, тем паче, струн — будет ли вообще вопрос иметь смысл?
Re[6]: Многопоточность сегодня
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.10.07 13:34
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Но всё это костыли. Если всё рабочее окружение отправить в своп, а при загрузке компьютера оотуда всё доставать в оперативку...


В Windows это называется hibernate. К сожалению, при современных объемах оперативки и скоростях винтов это не очень быстро.

ZEN> Но можно использовать энергонезависимое ОЗУ большой ёмкости (несколько гигабайт) и отказаться от винчестера вообще, тогда все установленые приложения и система фактически имеют включенную готовность, как радиоприёмник.


Угу, именно так работает Windows Mobile начиная с версии 5.0. А еще, если сделать отдельное независимое питание на оперативку, может полагаться, что это питание не отключается. Называется это suspend to ram и поддерживается любым современным писюком.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[5]: Многопоточность сегодня
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.10.07 13:39
Оценка: -1
Здравствуйте, remark, Вы писали:

R>Я имею в виду *полный* фича фриз. Т.е. не увеличивается фотореалистичность игр и т.д.

R>Я надеюсь, все понимают, что я это говорю иронично. Ключевое слово "Если бы".

Дык фотореалистичность не является фичей. Тогда уж надо говорить о заморозке разработки какиго бы то ни было нового софта.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Многопоточность сегодня
От: Mikl Kurkov Россия  
Дата: 12.10.07 13:43
Оценка: 2 (2)
Здравствуйте, eao197, Вы писали:

...
E>Erlang разрабатывался для достаточно специфических вещей, в которых за мелкими параллельными процессами ходить далеко не нужно было. Поэтому телефонные свитчи на Erlang-е программируются успешно, а вот попробуйте на Erlang-е Emacs или Vim написать -- откуда там взятся мелким процессам?
...

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

Будешь смеяться, но Emacs на Erlang таки разрабатывался. Ermacs проект назывался. Есть еще трехмерный графический редактор Wings, вполне юзабельная штука, люди с ее помощью довольно сложные модели делают.

--
Mikl
Re[7]: Многопоточность сегодня
От: Sergey Россия  
Дата: 12.10.07 13:44
Оценка:
>>> Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции.
> S>Здрасте-приехали. А че у меня тогда инкредибилд пересобирает солюшен за 20-30 минут, в то время как локальная пересборка — более 2 часов?
> Потому что инкредибилд — это не только много процессоров, это ещё и много памяти и многократно увеличенная скорость чтения-записи на диск.

1) даже без инкредибилда на 2 процессорах собирается сильно быстрей чем на одном.
2) скорость чтения-записи на диск с инкредибилдом не увеличивается, поскольку все читается/пишется с моего диска и до кучи гоняется по сети (распределенная линковка выключена, ибо нефиг).

Памяти действительно больше, это да — ну так оно ведь и не в объем памяти упирается. В диск оно у меня упирается только при линковке, а вовсе не при компилляции. Хотя, возможно, если из кода повыкидывать все шаблоны, то картина сильнее бы походила на описанную GlebZ.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[18]: Многопоточность сегодня
От: Hobot Bobot США  
Дата: 12.10.07 13:50
Оценка: :)))
Здравствуйте, AVM, Вы писали:

AVM>Идешь ты по первому уровню DOOM, и чувствуешь что пахнет розами, а потом опа — наступил в дерьмо


Знаем мы, к чему это приводит.

– Тогда я видел, – сказал Малышев. – Нет, почему же, фильм неплохой. Музыка хорошая. И гамма запахов хороша. Помнишь, когда они у моря?

– Может быть, – сказал Панин. – Только у меня смелфидер испорчен. Все время разит копченой рыбой. Это было особенно здорово, когда она там заходит в цветочный магазин и нюхает розы.

– Вах! – сказал Гургенидзе. – Почему ты не починишь, Борька?

Малышев задумчиво сказал:

– Было бы здорово разработать для кино методы передачи осязательных ощущений. Представляешь, Борька, на экране кто-то кого-то целует, а ты испытываешь удар по морде...

– Представляю, – сказал Панин. – У меня уже так было однажды. Без всякого кино.


Аркадий и Борис Стругацкие, "Полдень, XXII век"
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Re: Многопоточность сегодня
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.10.07 13:56
Оценка:
Оптоп...

Сори, мы (редакторы RSDN) тедбе на мыло указанное в профайле написали, но ты так и не ответил.

Ты его читашь?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 14:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

AVM>>Идешь ты по первому уровню DOOM, и чувствуешь что пахнет розами, а потом опа — наступил в дерьмо
S>Ну, значит нужен картридж с запахами розы и дерьма.
S>Эта проблема к компьютерам не очень относится. Точно так же, как проблема стимуляции осязательных ощущений. Если мы сделаем генератор запахов, то он будет совершенно одинаково управляться и из кремния, и из биомассы.
Что то похожее я уже раньше читал. "Дайте нам 1 Мгц тактовой частоты и мы сможем управлять плазмой (или термоядом)" точно сейчас не помню, кажется это называлось проблемой 3-х М или 3-х Г.
Я конечно понимаю, что абстрактная теоретическая машина Тьюринга в соответствии с тезисом Черча, может посчитать любого сферического кона в вакууме. Только какая польза от этого коня?

AVM>>А может не надо сводить всю математику только к дискретной математике?

S>Примеры несводимых к дискретной математике алгоритмов в студию.
Приведи пожалуйста доказательство тезиса Черча-Тюнинга.
Сразу скажу что опровергнуть я его тоже не смогу, хотя в соответствии с тем же тезисом машина Тьюринга это должна уметь делать. Вся проблема — найти правильный алгоритм. И еще поищи "алгоритмически неразрешимые массовые проблемы".

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

AVM>>Ты хочешь прилепить ярлык и сказать что точно знаешь как работает механизм восприятие видеообразов у живых организмов.
S>Ну уж на таком уровне, как дискретный/недискретный — знаю. Так, для справки: восприятие зрительного образа начинается с попадания фотона в светочувствительную клетку. Сие есть факт существенно дискретный.
AVM>>Судя по тому что ты не конкретизируешь какой глаз — ты прекрасно знаешь способы обработки видео всеми живыми организмами.
S>Ну, способов не так уж и много. Глаза отличаются в основном инженерным устройством: ну там, оптика разная; всякие оптимизации типа переменной плотности элементов; разное подключение считывающих элементов (спереди/сзади), встраивание клеток предварительной обработки и т.п.
AVM>>Сдаюсь, и снимаю шляпу
S>Ну, неплохой обзор технологий зрения приведен, к примеру, здесь.

Это оттуда:

Таким образом, эволюционисты остались с аргументом о дефектах дизайна – доказательством, которое основывается на предполагаемом понимании идентичности, мотивов, возможностей дизайнера. Такие аргументы доводят не что иное, как высокомерие тех, кто использует эти аргументы, особенно когда тот, кто выдвигает такие аргументы не может создать ничего, что хотя бы издалека походило на объект исследования.

Если ты действительно это все внимательно прочитал и понял — уважаю!!!

S>>>Особенно заметно это в том, что глаз прекрасно воспринимает картинку с такими потерями, что погрешность АЦП бесконечно мала по сравнению с ними.

AVM>>Я честно говоря не понял что ты хотел сказать, может быть имелось ввиду "мозг прекрасно воспринимает картинку с такими потерями"?
AVM>>ИМНО все в кучу и ЦП и переферию
S>А там нет четкого разделения. Ты же не думаешь, что глаз тупо гонит в мозг MPEG-68? Проблема как раз в частности в том, что не очень хорошо известно, как обрабатывается картинка. Глаза неспроста расположены поближе к мозгу. У некоторых организмов вообще чуть ли не половина работы по выделению образов сделана прямо в глазу.
S>Если мы не теряем узнаваемость картинки даже после внесения в нее существенных искажений, я не вижу повода настаивать на сверхъестественной точности передачи входных данных для работоспособности используемых в природе алгоритмов. Элементарная логика не дает мне это сделать.
Я не знаю как обрабатывается картинка живым организмом. Просто знаю что пренебрегать мелочами не всегда верно, даже если логика подсказывает ими пренебречь.

AVM>>Принцип работы электронной лампы основан на эмиссии электронов из катода и их пролете через управляющую сетку к аноду. А огонек который там светиться это нить нагрева для того, чтобы электроны пошустрее вылетали из катода. И придумал это Джон Амброз Флеминг в начале прошлого века.

AVM>>Я про эти лампы говорю и честно признаюсь ничего не слышал про про лампы "основанные на технологии дискретной обработки сигнала".
S>Я имел в виду ламповые цифровые компьютеры.
Ок, т.е. ты согласен, что в реле и лампу заложены абсолютно разные возможности по обработки сигнала?

AVM>>Соррии если мой ответ покажется тебе резким. Если очень тяжело — давай просто прекратим это обсуждение. Я заранее готов согласиться что 80 ядер в пластиковом корпусе и 20G RAM уделают по производительности сбора меда улей пчел

S>А при чем тут сбор меда?
К тому что не все можно вычислить.
AVM>>и в соответствии тезисом Черча сможет координировать работу муравейника.
S>Я совершенно не уверен, что координирование работы муравейника требует белковых решений.
Кстати и тема для кандидатской диссертации. Эффективное управление работой муравейника на основании тезиса Черча-Тюнинга для повышения собираемости муравьиной кислоты.
Пошутил просто чтобы разрядиться.
Re[6]: Многопоточность сегодня
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 12.10.07 14:01
Оценка:
RegisteredUser,

LCR>>У меня возникли сомнения насчёт "лёгкой векторизации". Перевести программу в "векторную" форму примерно так же легко, как и программу, написанную императивно в функциональную. Суть переписать заново, то есть.


RU>Я имел ввиду "имплементация привычных задач в векторном стиле" — проще говоря, там где среднестатистический С# программист напихает for-ов и, в лучшем случае foreach-ев (автоматическое распараллеливание коих на текущий момент, как я слышал, большая проблема), среднестатистический J-ст будет применять стандартные и свои глаголы сразу на весь набор данных задумываясь только о правильном сопряжении ранков (параллельное исполнение которых на машинном уровне особых затруднений вызвать не должно).


В случае for-each-ей (фурычей ) — согласен, легко "векторизовать". А когда обработка элемента требует знания о случайном уже обработанном элементе? Как это векторизовать? Или там деревья какие-нибудь приплести, графы там...

LCR>>Ещё меня давно интересует вопрос, есть ли полный базис операций над массивами. В J операций много, обычно хватает, но кто сказал, что набор эквивалентен МТ? Видать, не смог Кен Иверсон доказать это, вот и оставили там обычный for & while...


RU>А что такое МТ? Мне кажется for. оставлен потому что, в конце-то концов, не все ж можно считать параллельно Тот же FoldR который здесь причастие "/" — его ж не распараллелишь? Лично я ни разу for. явно не использовал, хотя его тацидный эквивалент "^:" — сплошь и рядом — там где нужна именно итеративная обработка, а она очень часто нужна. Часто, но не всегда


МТ = Машина Тьюринга. Вот про лямбда-исчисление доказано, что да, оно эквивалентно МТ, поэтому в лямбда-исчислении нет никаких форов, а вот в J — увы. То есть, имхо, причина — не параллельность, а полнота.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[8]: Многопоточность сегодня
От: Left2 Украина  
Дата: 12.10.07 14:11
Оценка:
>> Потому что инкредибилд — это не только много процессоров, это ещё и много памяти и многократно увеличенная скорость чтения-записи на диск.

S>1) даже без инкредибилда на 2 процессорах собирается сильно быстрей чем на одном.

А есть результаты замеров?
S>2) скорость чтения-записи на диск с инкредибилдом не увеличивается, поскольку все читается/пишется с моего диска и до кучи гоняется по сети (распределенная линковка выключена, ибо нефиг).
Разве? Я всегда считал что Incredibuild держит кэш файлов на каждой машине. Иначе бы за счёт одновременного обращения к одному единственному диску с разных машин скорость билда вместо возрастания упала бы на порядки (и кэш на твоей машине не помог бы, временные файлы при билде C++ проектов огромные и в дисковый кэш они не влезут).

S>Памяти действительно больше, это да — ну так оно ведь и не в объем памяти упирается.

Больше памяти == больше дискового кэша

S>В диск оно у меня упирается только при линковке, а вовсе не при компилляции. Хотя, возможно, если из кода повыкидывать все шаблоны, то картина сильнее бы походила на описанную GlebZ.

Согласен с тем что критичные места (проц/память/диск) должны сильно зависеть от стиля написания кода. Лично я например, когда выбираю между run-time и compile-time полиморфизмом, во многих случаях готов смириться с копеешной потерей производительности в run-time если это даст существенный прирост скорости билда проекта.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[9]: Многопоточность сегодня
От: Sergey Россия  
Дата: 12.10.07 14:29
Оценка:
>>> Потому что инкредибилд — это не только много процессоров, это ещё и много памяти и многократно увеличенная скорость чтения-записи на диск.
>
> S>1) даже без инкредибилда на 2 процессорах собирается сильно быстрей чем на одном.
> А есть результаты замеров?
> S>2) скорость чтения-записи на диск с инкредибилдом не увеличивается, поскольку все читается/пишется с моего диска и до кучи гоняется по сети (распределенная линковка выключена, ибо нефиг).
> Разве? Я всегда считал что Incredibuild держит кэш файлов на каждой машине. Иначе бы за счёт одновременного обращения к одному единственному диску с разных машин скорость билда вместо возрастания упала бы на порядки (и кэш на твоей машине не помог бы, временные файлы при билде C++ проектов огромные и в дисковый кэш они не влезут).

Как именно инкредибилд использует дисковый кэш, мне не известно. Но размер самого большого объектника у меня в проекте меньше 32 Мб, pch — меньше 20 Mb, инкредибилдовские куски pdb тоже не особо здоровые. Все вполне влазит в ОЗУ.

> S>Памяти действительно больше, это да — ну так оно ведь и не в объем памяти упирается.

> Больше памяти == больше дискового кэша

А сильно много дискового кэша и не надо.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[23]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 14:29
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>Вот блин и приплыли. В соответствии с Тезисом Чёрча—Тьюринга все можно посчитать с помошью машины Тьюринга.

Не понял??? В соответсвии с этим тезисом любая вычислимая функция может быть частично вычислена машиной Тьюринга. То есть с достаточном приближением. Вычислимость функции предполагает ее измеримость. То есть, ее можно вычислить данной машиной до определенной степени точности. Если у тебя величина бесконечность, то почему бы бесконечность не принять за некоторое значение обладающее соответвующими свойствами (есть же такое значение как null или NaN).
Re[21]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 14:32
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>>>Что значит "хорошо перемешивать"?

AVM>>Брать большие по размеру доли и смешивать их, чтобы можно было пренебречь погрешностью отмеривания долей.
CU>Тогда будет как с винами: такой-то год, такой-то берег такой-то реки... Алхимия в средневековье, а не наука и промышленность века нашего.
Лет 500 назад алхимия была ого-го наукой. Лет через 500 про нас тоже скажут — алхимия

CU>>>>>А на клеточном уровне всё равно идёт обмен сигналами.

AVM>>>>Вопрос "какими сигналами?" Ответа естественно не жду, т.к. это пока тайна за семью печатями.
CU>>>Вам перечислить _все_ сигналы? Так это и о написанных программах уже не скажешь. А перечислить характер "сигналов" — запросто. Хотя да — алгоритмы реакции пока не ясны.
AVM>>Не надо перечислять. Я не уверен что известны даже все характеры сигналов.
CU>Физика? (электро-магнитные) Химия (органическая и неорганическая)? Что ещё?
Я не знаю. Просто думаю, что есть что-то еще. Нет не высший разум. Просто есть вещи, которые современной наукой до конца не изучены. Уверен, что появятся новые науки и что современная физика будет значительно расширена и обновлена.

CU>>>Хм, скорость штамповки DVD по матрице? Не прожиг в DVD-ROM, а именно штамповка.

AVM>>Штамповку и получим, а толку от нее?

CU>_ТОЧНАЯ_ копия.


AVM>>Если серьезно, то на базе этого механизма (хранение генома в клетке) в перспективе можно строить очень хорошие хранилища информации: отношение емкость/размер — огромное, энергопотребление — низкое, защита информации от потерь — великолепная. Есть правда и куча минусов, основной — мы до сих пор не знаем как оно работает


CU>Скорее всего произвольную последовательность хранить не получится...

Не знаю. Знаю только что сейчас там хранение организовано намного эффективнее чем хранение 0 и 1 на магнитном диске.
Re[5]: Многопоточность сегодня
От: Left2 Украина  
Дата: 12.10.07 14:43
Оценка:
E>Т.е. ACE_Reactor работает в качестве мультиплексора (или демультиплексора -- путаюсь в этих терминах) событий.
демультиплексора
из одной точки программы у нас могут вылазить разные события, и соотв. разные пути исполнения. Если нарисовать это на блок-схеме — получится что-то подобное демультиплексору из схемотехники

E>В простейшем случае ACE_Reactor является оберткой над while{} c select-ом внутри.

Или WaitForMultiplyObjects, если iZEN Windows ближе чем Linux или BSD-шные сокеты

А вообще, паттерн так и называется — Reactor, гуглом можно найти массу внятных описАний.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[10]: Многопоточность сегодня
От: Left2 Украина  
Дата: 12.10.07 14:49
Оценка:
S>Как именно инкредибилд использует дисковый кэш, мне не известно. Но размер самого большого объектника у меня в проекте меньше 32 Мб, pch — меньше 20 Mb, инкредибилдовские куски pdb тоже не особо здоровые. Все вполне влазит в ОЗУ.
Для случая билда одного файла в одном проекте. Перемножь это на кол-во машин, которое использует IncrediBuild. Ну и опять же — размер ОЗУ != размеру файлового кэша.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[10]: Многопоточность сегодня
От: Left2 Украина  
Дата: 12.10.07 14:56
Оценка:
S>Как именно инкредибилд использует дисковый кэш, мне не известно.
Если очень интересно узнать читает ли он ВСЕ файлы или только те которые билдятся на этой машине — можно довольно просто посмотреть ProcessMonitor-ом.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[24]: Многопоточность сегодня
От: AVM Россия  
Дата: 12.10.07 14:57
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


AVM>>Вот блин и приплыли. В соответствии с Тезисом Чёрча—Тьюринга все можно посчитать с помошью машины Тьюринга.

GZ>Не понял??? В соответсвии с этим тезисом любая вычислимая функция может быть частично вычислена машиной Тьюринга. То есть с достаточном приближением. Вычислимость функции предполагает ее измеримость. То есть, ее можно вычислить данной машиной до определенной степени точности. Если у тебя величина бесконечность, то почему бы бесконечность не принять за некоторое значение обладающее соответвующими свойствами (есть же такое значение как null или NaN).
В соответствии с тезисом "интуитивно вычислимая функция является частично вычислимой. Частично вычислимая может быть посчитана на машине Тьюринга". (Доказать или опровергнуть это не возможно, т.к. не совсем понятно что есть интуитивно вычислимая функция).
Я не уверен, что пространство и время можно описать интуитивно вычислимой функцией. Следовательно я не уверен, что можно "обсчитать" пространство и время на машине Тьюринга.
Это можно развивать дальше, но IMHO продолжать смысла нет.
Re[11]: Многопоточность сегодня
От: Sergey Россия  
Дата: 12.10.07 15:00
Оценка:
"Left2" <13414@users.rsdn.ru> wrote in message news:2691870@news.rsdn.ru...
>S>Как именно инкредибилд использует дисковый кэш, мне не известно. Но размер самого большого объектника у меня в проекте меньше 32 Мб, pch — меньше 20 Mb, инкредибилдовские куски pdb тоже не особо здоровые. Все вполне влазит в ОЗУ.
> Для случая билда одного файла в одном проекте. Перемножь это на кол-во машин, которое использует IncrediBuild.

10 машин — все равно временное барахло в озу влазит.

> Ну и опять же — размер ОЗУ != размеру файлового кэша.


Ну и каким образом все это может сделать утверждение "Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции" справедливым? Пока у нас отнюдь не 80 процессоров, а 1-2-4, и дополнительный проц весьма сильно влияет на скорость компилляции. А когда ядер будет 80, так и памяти наверняка прибавится, и многоканальной ее скорее всего сделают (если, конечно, маркетинг в очередной раз не восторжествует над разумом)).
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[11]: Многопоточность сегодня
От: Sergey Россия  
Дата: 12.10.07 15:15
Оценка:
"Left2" <13414@users.rsdn.ru> wrote in message news:2691879@news.rsdn.ru...
>S>Как именно инкредибилд использует дисковый кэш, мне не известно.
> Если очень интересно узнать читает ли он ВСЕ файлы или только те которые билдятся на этой машине — можно довольно просто посмотреть ProcessMonitor-ом.

Казнить нельзя помиловать. Ничего не понял. Кстати, файлы в кэше у него лежат мелкие, больше мегабайта только индекс.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[7]: Многопоточность сегодня
От: CreatorCray  
Дата: 12.10.07 15:23
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ZEN>>Но всё это костыли. Если всё рабочее окружение отправить в своп, а при загрузке компьютера оотуда всё доставать в оперативку...

AVK>В Windows это называется hibernate. К сожалению, при современных объемах оперативки и скоростях винтов это не очень быстро.
На 3 гб и обычном SATA2 венике hibernate занимает секунд 5
ВСЯ память будет записана только если она ВСЯ занята.
Обычно пишется только реально занятые участки минус кэш
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Многопоточность сегодня
От: Left2 Украина  
Дата: 12.10.07 15:35
Оценка:
S>10 машин — все равно временное барахло в озу влазит.
Что говорит о том, что Incredibuild не читает его постоянно с твоей машины, а хранит на чужих билд-машинах.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[25]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 15:41
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>В соответствии с тезисом "интуитивно вычислимая функция является частично вычислимой. Частично вычислимая может быть посчитана на машине Тьюринга". (Доказать или опровергнуть это не возможно, т.к. не совсем понятно что есть интуитивно вычислимая функция).

Ты их недооцениваешь. То что и Тьюринг, и лямбда Черча вычислимо полные машины — уже доказано (по моему ими же). Существует также такой раздел математики как "теория вычислимости", где описывается вычислимость той или иной модели.


AVM>Я не уверен, что пространство и время можно описать интуитивно вычислимой функцией. Следовательно я не уверен, что можно "обсчитать" пространство и время на машине Тьюринга.

А вот вопрос "обсчитать пространство и время" — уже непонятно.

AVM>Это можно развивать дальше, но IMHO продолжать смысла нет.

Согласен.
Re[13]: Многопоточность сегодня
От: Sergey Россия  
Дата: 12.10.07 15:50
Оценка:
>S>10 машин — все равно временное барахло в озу влазит.
> Что говорит о том, что Incredibuild не читает его постоянно с твоей машины, а хранит на чужих билд-машинах.

Ясное дело, что Incredibuild не читает объектники постоянно с моей машины, а сам их генерирует Я немного о другом говорю — работа с диском при компилляции у меня узким местом не является, скорость упирается в процессор. Собственно, даже по загрузке процессора это видно. А об винт оно тормозит при линковке и склеивании pdb.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[4]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 16:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кроме того есть проблема сложности. Одна и та же задача может быть решена совершенно с разными трудозатратами если выбирать более прямые методы решения. Ну, скажем у первых писюков была сегментная организация памяти и памяти явно было очень мало. Это вынуждало тратить тонну времени на то чтобы изобретать способы того как решить задачу в данных условиях. Сейчас у меня на машине 2Гб оперативки и я для многих задач могу выбрать весьма простые решения (скажем скачать 100 мегабайтный файл в память). Ранее я этого не мог. Далее, когда будет 1Тб пмяти я смогу, скажем использовать позиционную сортировку для int32. Сегодня это выглядит бредом. (в прочем может так будет и завтра ).

Если ты поставишь 1Тб и 80 ядерный процессор к себе на компьютер, то использовать позиционную сортировку ты все равно не сможешь. Сейчас мне пришлось заняться тиковыжимательством, и я пришел к выводу, что в нынешней архитектуре x86 нужно что-то менять. Проблема оказалась не в самом процессоре как таковом, он все успевает. Проблема оказалась в random доступе к памяти. Кэш проца в этом случае не спасает. Приходится сильно пере... алгоритмы чтобы запись была последовательна. Была еще проблема доступа к близким участкам памяти с нескольких процессоров. Но это достаточно легко решилось, хотя тоже через одно место.

ЗЫ. Что касается Desktop, то для большинства бизнес-приложений, ресурсы процессора избыточен. Меня пока в этом не переубедили.
Re[12]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 12.10.07 16:08
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Ну и каким образом все это может сделать утверждение "Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции" справедливым? Пока у нас отнюдь не 80 процессоров, а 1-2-4, и дополнительный проц весьма сильно влияет на скорость компилляции. А когда ядер будет 80, так и памяти наверняка прибавится, и многоканальной ее скорее всего сделают (если, конечно, маркетинг в очередной раз не восторжествует над разумом)).

А ты внимательно прочитал мое сообщение? У тебя 10 машин. Значит 10 шин памяти между процессором и OЗУ. Пока противоречия с моим утверждением — не вижу.
Re[4]: Многопоточность сегодня
От: Left2 Украина  
Дата: 12.10.07 17:08
Оценка:
VD> Далее, когда будет 1Тб пмяти я смогу, скажем использовать позиционную сортировку для int32. Сегодня это выглядит бредом. (в прочем может так будет и завтра ).
Почему бредом, кстати? На 64-битных системах (а современные десктопные системы 64-битную адресацию тянут аппаратно) вроде бы всё должно быть нормально, даже 4 гб оперативной памяти иметь не надо — достаточно 4 гб виртуальной, и то — в самом худшем случае
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[10]: Многопоточность сегодня
От: iZEN СССР  
Дата: 12.10.07 17:10
Оценка:
Здравствуйте, alpha21264, Вы писали:

iZEN>>А вот команда make -j2 действительно увеличила скорость компиляции 2,5 раза.


A>Всяко бывает. Они ведь еще и кеш могут друг у друга отбирать. А... после j пробел стоял?


Пробел не нужен.
Re[13]: Многопоточность сегодня
От: Sergey Россия  
Дата: 12.10.07 18:18
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


S>>Ну и каким образом все это может сделать утверждение "Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции" справедливым? Пока у нас отнюдь не 80 процессоров, а 1-2-4, и дополнительный проц весьма сильно влияет на скорость компилляции. А когда ядер будет 80, так и памяти наверняка прибавится, и многоканальной ее скорее всего сделают (если, конечно, маркетинг в очередной раз не восторжествует над разумом)).

GZ>А ты внимательно прочитал мое сообщение? У тебя 10 машин. Значит 10 шин памяти между процессором и OЗУ. Пока противоречия с моим утверждением — не вижу.

Ага, значит тезис о тормозах диска при компилляции откидываем. Замечательно. Однако у меня и без инкредибилда в 2 потока солюшен собирается гораздо быстрее, чем в 1.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[24]: Многопоточность сегодня
От: сипласплас  
Дата: 12.10.07 20:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Константин Л., Вы писали:


[]

Ты хочешь сказать, что я могу не использовать Interlocked для изменения 32 битных чисел из разных трэдов и при этом _каждый_ трэд будет видеть их без задержек?
Re[16]: Многопоточность сегодня
От: Andrei F.  
Дата: 13.10.07 03:04
Оценка:
Здравствуйте, remark, Вы писали:

R>http://developer.intel.com/products/processor/manuals/318147.pdf


И где там про неявные барьеры памяти?
Re[7]: Многопоточность сегодня
От: GlebZ Россия  
Дата: 13.10.07 06:06
Оценка:
Здравствуйте, Кодт, Вы писали:

В этом смысле Cell интересно сделан.
Re[7]: Многопоточность сегодня
От: RegisteredUser  
Дата: 13.10.07 09:04
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>В случае for-each-ей (фурычей ) — согласен, легко "векторизовать". А когда обработка элемента требует знания о случайном уже обработанном элементе? Как это векторизовать? Или там деревья какие-нибудь приплести, графы там...


J (не K) есть function-level язык (см. известную лекцию Бэкуса) — язык, выражения которого поддаются алгебраической трансформации куда лучше "классических" языков (что включает в себя, например, доказательство _эквивалентности_ выражений/конструкций). Это, как мне видится облегчает _выделение_ тех участков программы которые теоретически могут быть исполнены параллельно. Т.е. чуда же здесь нет — если для следующего шага требуются знания результата предыдущего — то это на любой архитектуре будет, в конечном итоге, исполнено последовательно. Но если что-то теоретически может быть вычислено параллельно, то, как мне видится, транслятор векторных языков имеет куда более высокие шансы _выявить_ эти самые параллельные моменты. Только и всего.

LCR>МТ = Машина Тьюринга. Вот про лямбда-исчисление доказано, что да, оно эквивалентно МТ, поэтому в лямбда-исчислении нет никаких форов, а вот в J — увы. То есть, имхо, причина — не параллельность, а полнота.


Насколько я понимаю, на сегодняшний день считается, что а) любая вычислительная система может быть промоделированная МТ, б) как следствие, любая существующая вычислительная система не мощнее (а значит _слабее_) МТ (хотя и возможно и даже скорее всего, превосходит МТ по оптимальности на некоторых задачах) и значит для теоретических нужд может быть сведена к МТ (в частности релевантная данной теме "многоленточная МТ" тоже сводится к простейшей МТ), в) лямбда-калькулис эквивалентен МТ и может быть использован как замена для теоретических выкладок.
Форов в лямбде нет, но есть рекурсия через Y-combinator, так что фор имплементируется элементарно... Так что я не вполне понимаю ваши опасения по поводу полноты: в любом случае любая из существующих реальных вычислительных систем-языков слабее МТ в силу "небесконечности" реальной ленты, но каждая из систем слабее с разной степенью удобства для программиста и возможного параллельного транслятора
Re[8]: Многопоточность сегодня
От: deniok Россия  
Дата: 13.10.07 09:21
Оценка: +1
Здравствуйте, RegisteredUser, Вы писали:


RU>Насколько я понимаю, на сегодняшний день считается, что а) любая вычислительная система может быть промоделированная МТ, б) как следствие, любая существующая вычислительная система не мощнее (а значит _слабее_) МТ (хотя и возможно и даже скорее всего, превосходит МТ по оптимальности на некоторых задачах) и значит для теоретических нужд может быть сведена к МТ (в частности релевантная данной теме "многоленточная МТ" тоже сводится к простейшей МТ), в) лямбда-калькулис эквивалентен МТ и может быть использован как замена для теоретических выкладок.

RU>Форов в лямбде нет, но есть рекурсия через Y-combinator, так что фор имплементируется элементарно... Так что я не вполне понимаю ваши опасения по поводу полноты: в любом случае любая из существующих реальных вычислительных систем-языков слабее МТ в силу "небесконечности" реальной ленты, но каждая из систем слабее с разной степенью удобства для программиста и возможного параллельного транслятора

Насчёт "слабее" — совсем не уверен. Точнее, эта проблема не кажется мне принципиальной; ясно что реальный вычислитель тратит ещё и время на каждый шаг. ИМХО, временная сложность порождает существенно больше проблем, чем пространственная. Обычно мы не можем посчитать какие-то вещи, потому что это слишком долго, а не потому, что у нас не хватает ячеек памяти для хранения кода/данных.
Re[17]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 10:01
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>http://developer.intel.com/products/processor/manuals/318147.pdf


AF>И где там про неявные барьеры памяти?


Если отталкиваться от полностью расслабленной модели памяти, то модель памяти x86 ведёт себя так, как будто в ней имеется ряд неявных барьеров памяти.

Но если ты хочешь формализма, то правильнее сказать, что в x86 некоторые виды барьеров в некоторых местах просто не нужны, а не неявные. Что имхо тождественно с практической точки зрения.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[25]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 10:05
Оценка:
Здравствуйте, сипласплас, Вы писали:

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


WH>>Здравствуйте, Константин Л., Вы писали:


С>[]


С>Ты хочешь сказать, что я могу не использовать Interlocked для изменения 32 битных чисел из разных трэдов и при этом _каждый_ трэд будет видеть их без задержек?



Это распростарённая ошибка касательно барьеров памяти. Барьеры памяти не имеют отношения к задержкам. Они не об этом.
С практической т.з. они скорее даже увеличивают задержки и время работы. Это как QоS против best-effort.
Если бы имелось какое-то средство, которое уменьшает задержки, то почему бы его не сделать неявным везде?!



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 10:12
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


GZ>В этом смысле Cell интересно сделан.



Многие специалисты пророчат будущее именно для таких систем. Ну или по крайней мере, что Cell сильно повлияет на дальнейшее развитие...
Правда, модель Cell ещё на порядок сложнее в использовании сегодняшнего SMP/multicore? т.е. имеется одно центральное ядро "общего назначения", и ряд вспомогательных ядер, которые могут "перемножать матрицы". При этом общение этих ядер идёт не через shared memory, а через подобие DMA. Т.е. центральное ядро заливает во вспомогательное ядро данные, заливает программу, и командует действовать. Вспомогательное ядро выполняет обработку и сигнализирует центральное, что работа сделана. Далее через DMA данные выливаются из вспомогательного ядра.
Модель, определённо требующая специального и изначального дазайна программы именно под неё!



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 12:19
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>А почему тут происходят переключения контекстов?

E>>Если нить ввода-вывода и нить обработки находятся на разных ядрах, то передача сообщений между ними оказывается дороже, чем при работе обоих нитей на одном ядре. По крайней мере, по моим впечатлениям.
C>У меня впечатления обратные — передача данных через неблокирующуюся очередь (java.util.concurrent.ConcurrentNavigableMap, если кому интересно) у меня работает абсолютно с одинаковой скоростью на любом количестве процессоров (масштабируется почти линейно).

А на скольких процессорах ты тестировал?


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 13:22
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Оптоп...


VD>Сори, мы (редакторы RSDN) тедбе на мыло указанное в профайле написали, но ты так и не ответил.


А ну да, вот теперь нашёл его в спаме gmail'а


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность сегодня
От: minorlogic Украина  
Дата: 13.10.07 15:06
Оценка:
Здравствуйте, remark, Вы писали:

R>Не слышу! Говори громче! В другое ухо мне очень громко кричит CEO из Intel, о том какое крутое они сделали новое поколение процессоров, и о том, какие все программисты тупые, что ни как не могут научиться эффективно их использовать, хотя уже прошёл целый год, и они написали целых 2 white paper, о том, что надо программировать как-то по-новому.


Может выжидают , может ждуть пока кто то дельное предложит?

P.S. Практично посмотреть как монстры эти проблемы решают , как Эпик распаралеливает свои движки , как Havok свои и т.п.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 15:28
Оценка:
Здравствуйте, RegisteredUser, Вы писали:

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


R>>Скорее всего ты говоришь о какой-то очень ограниченной области применения, либо вообще о HPC.


RU>Нет, я говорю о языках общего назначения. Общеизвестный пример: на К написала большая часть kdb (говорят лидер рынка БД по производительности), набор трейдерских (то бишь зачастую очень real-time-овских) и других околофинансовых приложений (kx.com). Порылся на форумах JSoftware — нет, к сожалению текущая реализация J 601 никак не использует многоядерность, но принципиальных проблем с её использованием нет (ввиду implicit parallelism).

RU>Просто эти языки и платформы предлагают иную (векторную сиречь _параллельную_) парадигму программирования (что не означает кстати, что они подходят лишь для перемножения матриц — обычные повседневные задачи тоже зачастую легко "векторизуются").


Я не спорю, что такие языки есть. За примерами далеко ходить не надо — OpenMP.
Единственная проблема, что такие языки ооооочень "ограниченные" в возможностях, которые они предоставляют программисту. Иначе они работать *не могут*! Они не могут просто так дать в руки программисту указатель и тому подобное.
И ещё вторая проблема, такие языки работают на 100% только при решении той самой задачи, которая была в голове у автора, когда он разрабатывал язык. В других случаях они работают процентов на 80-90. А если попытаешься добавить что-то, что плохо вписывается в модель, то можешь получить и 10%. А ведь никогда не знаешь, что может потребоваться завтра...


RU>Это был всего лишь мой пример существующего решения проблемы означенной в заглавии этой дискуссии. Продолжайте ломать копия о memory barrier-ы и прочие низкоуровневые детали реализации взгромождаемые традиционными постфортрановскими средствами разработки на плечи прикладного программиста



Во-первых, *никгода* не помешает хорошо разбираться во всех деталях используемой технологии. Хорошему Java/C# программисту не помешает разбираться, что такое указатель и стек. Не смотря на то, что язык полностью прячет это от него.
Во-вторых, а при чём тут прикладной программист. Если я делаю, допустим, кастомный движок для сервера, это не значит, что я потом пишу в прикладном коде: (1) увеличить баланс л/с. (2) выполнить барьер памяти. (3) проверить данные персоны.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 15:34
Оценка:
Здравствуйте, minorlogic, Вы писали:

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


R>>Не слышу! Говори громче! В другое ухо мне очень громко кричит CEO из Intel, о том какое крутое они сделали новое поколение процессоров, и о том, какие все программисты тупые, что ни как не могут научиться эффективно их использовать, хотя уже прошёл целый год, и они написали целых 2 white paper, о том, что надо программировать как-то по-новому.


M>Может выжидают , может ждуть пока кто то дельное предложит?


Пускай молча ждут!

M>P.S. Практично посмотреть как монстры эти проблемы решают , как Эпик распаралеливает свои движки , как Havok свои и т.п.


У всех кастомные движки.
У Valve, например, смесь разделяемых структур и распараллеливания на основе задач.
На разделяемых структурах в частности сделана модель мира. Полностью lock-free. Причём разделена на 2 части: статическая (read-mostly) и динамическая. Видимо применяют что-то типа RCU.
Задачи сделаны достаточно традиционно. Прикладной программист просто выделяет некую задачу в выполняемый объект, который отдаётся шедулеру.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 15:52
Оценка: 33 (4)
Здравствуйте, Кодт, Вы писали:

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


R>>Но основная беда даже не в этом.


R>>(опустим пока такие тривиальные вещи как сериализация на мьютексах)


R>>Передача кэш-линии занимает порядка 150-350 тактов. Даже без всяких атомарных операций и пр.

R>>Т.е. скорость работы снижается до 100 (!) раз. Т.о. тривиальный producer-consumer может стать ботлнеком, если данные просто переходят из одного кэша в другой (без всяких atomic, мьютексов, евентов, вызовов я ядро для пробуждения consumer).
R>>Плюс шина межпроцессорного/межядерного взаимодействия может стать боттлнеком, так что приложение просто не будет масштабироваться вообще при добавлении ядер, даже если потоков/работы достаточно, и нет сериализации на мьютексах, ядра не загружены и шина памяти не загружена.

К>Получается, что нужно сосредоточиться не только на стычках потоков вокруг общих данных (что всегда было предметом уважения), но и на стычках ядер вокруг линеек кеша.


К>Это означает, что

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

К>На моей памяти это уже второй виток хардверно-специфических оптимизаций. Первый был, когда стали очень уважать попадание/промахивание в кэш своего ядра



Абсолютно правильно. Соперничество за линейки кэша даже более дорогое, чем промахивание мимо L2 (130 тактов).

В принципе, если на вскидку, попробовать оценить "стоимость" разделяемой структуры данных, то получается примерно так:
1. Кол-во атомарных операций (atomic rmw, InterlockedXXX). Это порядка 100 тактов. Плюс складывается со следующими пунктами.
2. Кол-во считываемых линеек кэша, которые модифицируются другими потоками. Перекачка строки из кэша в кэш порядка 150-350 тактов.
3. Кол-во линеек кэша, в которые производится запись. Не уверен вносит ли это дополнительное пенальти по сравнению с 2, но должно влиять на масштабируемость, т.к. все перекачки строк кэша вызваны тем, что в неё записал кто-то другой.

По моим представлениям, кол-во "потроганных" строк кэша — основной параметр влияющий на производительность.
Т.е. да, олучается, что если уж трогаешь вместе какие-то данные в разделяемой структуре, то лучше что бы они были в одной кэш-линии (пакетная обработка).
И да, если уж данные трогаются разными потоками несвязанно (нет пакетной обработки), то крайне противопоказано располагать их в одной кэш-линии. Это называется false sharing, когда данные как-бы не разделяются, но из-за того, что лежат в одной кэш-линии, получается, что разделяются.
В принципе multicore-aware аллокаторы специально выделяют каждый элемент выровненным по началу кэш-линии и занимают им всю линию. Правда кэш-линия сейчас в последних Intel 64/128 байт.
Категорически противопоказано выделять таблицы мьютектов подряд в памяти — каждый должен быть в своих 128 байтах — тут ещё примешивается т.н. cache line locking. Ну или если маленький объект содержит в себе мьютекс, то тоже самое.

з.ы. цифры по памяти для Intel Core.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[23]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 13.10.07 15:54
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>Я просто искренне хочу понять, что я упустил


Тут так просто за 5 минут не опишешь. Если будет время, постараюсь в ближайшие дни ответить...

R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[25]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.10.07 05:26
Оценка:
Здравствуйте, AVM, Вы писали:

AVM>>>Вот блин и приплыли. В соответствии с Тезисом Чёрча—Тьюринга все можно посчитать с помошью машины Тьюринга.

GZ>>Не понял??? В соответсвии с этим тезисом любая вычислимая функция может быть частично вычислена машиной Тьюринга. То есть с достаточном приближением. Вычислимость функции предполагает ее измеримость. То есть, ее можно вычислить данной машиной до определенной степени точности. Если у тебя величина бесконечность, то почему бы бесконечность не принять за некоторое значение обладающее соответвующими свойствами (есть же такое значение как null или NaN).
AVM>В соответствии с тезисом "интуитивно вычислимая функция является частично вычислимой. Частично вычислимая может быть посчитана на машине Тьюринга". (Доказать или опровергнуть это не возможно, т.к. не совсем понятно что есть интуитивно вычислимая функция).
Совершенно верно. Поэтому это и называется тезисом, а не теоремой. Тезис Черча — про то, что наше интуитивное определение вычислимости сводимо к формальному определению алгоритма. Тезис был косвенно подтвержден строгими доказательствами эквивалентности различных определений алгоритма и вычислимости.
AVM>Я не уверен, что пространство и время можно описать интуитивно вычислимой функцией.
Я не очень понимаю смысл выражения "описать пространство и время функцией". Пространство и время не описывают; они служат как бы холстом, на котором написана картина нашего мира. Физикам известно довольно много про пространство и время; в частности, однородность и анизотропность пространства хорошо подтверждены экспериментально, так же, как и равномерность времени.
Физики говорят о вычислимости применительно к алгоритмическому моделированию результатов эксперимента. Как в классической механике: дайте мне все координаты, массы и скорости, и я рассчитаю их значения в любой будущий или прошлый момент.
В квантовой механике оказалось, что прямо так координаты и скорости рассчитать нельзя; но это не из-за слабости нашей математики, а из-за устройства мира.

AVM>Следовательно я не уверен, что можно "обсчитать" пространство и время на машине Тьюринга.

Вот с этого и надо было начинать. Подвергать сомнению тезис Черча можно и нужно — на критике стоит весь научный метод познания.
Но пока что никаких симптомов его опровержения на горизонте не видно. Например, квантовые компьютеры никак не повлияли на трактовку понятия вычислимости.
AVM>Это можно развивать дальше, но IMHO продолжать смысла нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Многопоточность сегодня
От: minorlogic Украина  
Дата: 14.10.07 09:54
Оценка:
Здравствуйте, remark, Вы писали:

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

R>Как мне это поможет при написании сетевого сервера?! Или развитого клиентского приложения?!
R>Дай этому профи, который давно занимается распараллеливанием, такую задачу и он войдёт в ступор. Скорее всего он начнёт у тебя спрашивать "ну где тут этот самый массив на миллиард элементов, который надо распараллелить?", или "над чём тут делать преобразование Фурье?"
R>А если задача что-нибудь посчитать, то есть средства типа OpenMP и иже с ним, их никто не игнорирует... если они всё-таки подходят.

Ну вот еще вопрос , а есть ли необходимость паралелить ВСЕ что можно ? Мы же слышали что тормозят только 15 — 20 процентов программы. Может как раз и стоит выделять критические куски и трансформировать их на стандартные алгоритмы ?

А обычные серверные приложения типа обработать N запросов... Тут можно банально запускать некое к-во процессов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[26]: Многопоточность сегодня
От: Константин Л. Франция  
Дата: 14.10.07 18:05
Оценка:
Здравствуйте, remark, Вы писали:

[]

R>Это распростарённая ошибка касательно барьеров памяти. Барьеры памяти не имеют отношения к задержкам. Они не об этом.

R>С практической т.з. они скорее даже увеличивают задержки и время работы. Это как QоS против best-effort.
R>Если бы имелось какое-то средство, которое уменьшает задержки, то почему бы его не сделать неявным везде?!

Что ты тут понимаешь под задержками? Я то, что изменение в одном трэде сразу видны в другом.

R>
Re[5]: Многопоточность сегодня
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.10.07 06:01
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Если ты поставишь 1Тб и 80 ядерный процессор к себе на компьютер, то использовать позиционную сортировку ты все равно не сможешь. Сейчас мне пришлось заняться тиковыжимательством, и я пришел к выводу, что в нынешней архитектуре x86 нужно что-то менять. Проблема оказалась не в самом процессоре как таковом, он все успевает. Проблема оказалась в random доступе к памяти. Кэш проца в этом случае не спасает. Приходится сильно пере... алгоритмы чтобы запись была последовательна. Была еще проблема доступа к близким участкам памяти с нескольких процессоров. Но это достаточно легко решилось, хотя тоже через одно место.


+1

GZ>ЗЫ. Что касается Desktop, то для большинства бизнес-приложений, ресурсы процессора избыточен. Меня пока в этом не переубедили.


-1
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Многопоточность сегодня
От: Andrei F.  
Дата: 15.10.07 08:32
Оценка:
Здравствуйте, сипласплас, Вы писали:

С>Ты хочешь сказать, что я могу не использовать Interlocked для изменения 32 битных чисел из разных трэдов и при этом _каждый_ трэд будет видеть их без задержек?


Судя по этой статье, действительно так и есть.

For systems with multiple processors, hardware vendors need to ensure data coherency across all processors. Data coherency ensures that the data in all processor caches are updated when a single processor writes to the back up memory. This implies that there is a memory protocol that prevents one processor from overwriting data that another processor is using in its cache. Intel multiprocessor systems use the Modified — Exclusive — Shared — Invalid (MESI) protocol. This protocol ensures cache coherency of the internal cache lines of each processor.

When you first load the program data into a processor’s cache line, MESI requires the processor to mark the cache line with Exclusive (E) access, which gives that processor unlimited load/store access to the data on the cache line. However, if another processor requires access to the same data that already resides in another processor’s cache, MESI requires the processor to mark this line as Shared (S). For all subsequent stores to that cache line from any processor, the cache line is marked as Modified (M), which causes all processors with that cache line to Invalidate (I) the cache line and reload it from system memory.

Re[10]: Многопоточность сегодня
От: vdimas Россия  
Дата: 16.10.07 09:38
Оценка:
Здравствуйте, eao197, Вы писали:


E>Все это хорошо пока ты стороние библиотеки в свой проект не подключаешь. А как возьмешь к себе ACE, PCRE, Crypto++, да еще в виде DLL, так и запаришься в них нестандартные аллокаторы запихивать.


Так они же в исходниках идут, и у всех есть подключаемый конфигурационный h-заголовок, который инклюдится первым для любого cxx-файла. В этом конфигурационном заголовке прописал глобальные операторы new/delete и усё.
Re[27]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 16.10.07 10:05
Оценка:
Здравствуйте, Константин Л., Вы писали:

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


КЛ>[]


R>>Это распростарённая ошибка касательно барьеров памяти. Барьеры памяти не имеют отношения к задержкам. Они не об этом.

R>>С практической т.з. они скорее даже увеличивают задержки и время работы. Это как QоS против best-effort.
R>>Если бы имелось какое-то средство, которое уменьшает задержки, то почему бы его не сделать неявным везде?!

КЛ>Что ты тут понимаешь под задержками? Я то, что изменение в одном трэде сразу видны в другом.


Я тоже. Видимость сразу ничто не может обеспечить.

R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[20]: Многопоточность сегодня
От: Klapaucius  
Дата: 16.10.07 12:19
Оценка: 6 (1)
Здравствуйте, AVM, Вы писали:

AVM>Если серьезно, то на базе этого механизма (хранение генома в клетке) в перспективе можно строить очень хорошие хранилища информации: отношение емкость/размер — огромное, энергопотребление — низкое, защита информации от потерь — великолепная.


Если бы защита информации от потерь и вправду была бы великолепной, то никакой дивергенции (видообразования) вообще небыло бы.

AVM>Есть правда и куча минусов, основной — мы до сих пор не знаем как оно работает


А. Ну ну. Восхищение от природных решений чаще всего неосведомленностью и объясняется. Ну или ореолом некоей исключительности вокруг этих решений. Посмотрел бы я, что вы сказали бы о творениях инженера, который во-первых, полностью ограничен в выборе материала, во-вторых, не имеет возможности повторного использования предидущих решений и поэтому каждый день изобретает велосипед, в-третих, не может думать даже на пару ходов вперед (на самом деле, вообще не может думать) а решает все проблемы по мере возникновения, и так, как будто любое отдельно взятое решение — последнее. Ну а матушке-природе не то что все сойдет с рук — рукоплескания обеспечены.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 17.10.07 08:00
Оценка:
Здравствуйте, minorlogic, Вы писали:

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


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

R>>Как мне это поможет при написании сетевого сервера?! Или развитого клиентского приложения?!
R>>Дай этому профи, который давно занимается распараллеливанием, такую задачу и он войдёт в ступор. Скорее всего он начнёт у тебя спрашивать "ну где тут этот самый массив на миллиард элементов, который надо распараллелить?", или "над чём тут делать преобразование Фурье?"
R>>А если задача что-нибудь посчитать, то есть средства типа OpenMP и иже с ним, их никто не игнорирует... если они всё-таки подходят.

M>Ну вот еще вопрос , а есть ли необходимость паралелить ВСЕ что можно ? Мы же слышали что тормозят только 15 — 20 процентов программы. Может как раз и стоит выделять критические куски и трансформировать их на стандартные алгоритмы ?


M>А обычные серверные приложения типа обработать N запросов... Тут можно банально запускать некое к-во процессов.


Ну да, банально. Только надо обеспечить, что бы они могли принимать сообщения с одного активного сокета. Разделять read-mostly данные, балансировать между собой нагрузку и т.д.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность сегодня
От: iZEN СССР  
Дата: 18.10.07 14:19
Оценка:
Здравствуйте, eao197, Вы писали:

E>ACE работает поверх имеющихся системных средств (т.е. поверх pthreads, LWP, WinThreads и т.д.).


А правда, что не все проблемы с многопоточностью в C++ решены?
Threads and memory model for C++
Re[8]: Многопоточность сегодня
От: Курилка Россия http://kirya.narod.ru/
Дата: 18.10.07 16:21
Оценка:
Здравствуйте, iZEN, Вы писали:

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


E>>ACE работает поверх имеющихся системных средств (т.е. поверх pthreads, LWP, WinThreads и т.д.).


ZEN>А правда, что не все проблемы с многопоточностью в C++ решены?

ZEN>Threads and memory model for C++

Извини, но что ты хотел сказать такой ссылкой?
Re[8]: Многопоточность сегодня
От: Стэн http://stanonwork.blogspot.com/
Дата: 28.10.07 19:47
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>А правда, что не все проблемы с многопоточностью в C++ решены?

ZEN>Threads and memory model for C++

Имелось ввиду это?
Re[13]: Многопоточность сегодня
От: Ka3a4oK  
Дата: 28.10.07 23:29
Оценка:
AVM>>Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.
S>А на чем еще? Неужто на воле божьей?

Очень интересная книга Р.Пенроуза "Новый ум короля". Основная мысль произведения — моделирование разума невозможно с помощью машины тьюрнга.
Автор приводил примеры задач принципиально не решаемых алгоритмически. Одна из них: замощение плоскости плитками различной формы. Однако, разные люди, в т.ч. сам Пенроуз, решали эту задачу для различного количества плиток.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[14]: Многопоточность сегодня
От: deniok Россия  
Дата: 29.10.07 00:10
Оценка:
Здравствуйте, Ka3a4oK, Вы писали:

KK>Очень интересная книга Р.Пенроуза "Новый ум короля". Основная мысль произведения — моделирование разума невозможно с помощью машины тьюрнга.

KK>Автор приводил примеры задач принципиально не решаемых алгоритмически. Одна из них: замощение плоскости плитками различной формы. Однако, разные люди, в т.ч. сам Пенроуз, решали эту задачу для различного количества плиток.

Аккуратнее. В задаче замощения невозможен универсальный алгоритм выяснения того возможно оно или нет при произвольном, хотя и конечном наборе плиток. Для каждого конкретного набора можно либо построить алгоритм, дибо доказывать что его не существует. Правда имеются ещё невычислимые покрытия (то есть доказано, что данным набором покрыть можно, но алгоритма не существует). Но даже Пенроуз не достиг ещё такой силы мысли, чтобы при доказанном отсутствии алгоритма предложить готовое покрытие.
Re[14]: Многопоточность сегодня
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.10.07 02:50
Оценка:
Здравствуйте, Ka3a4oK, Вы писали:

AVM>>>Таких примеров вагон и маленькая тележка. Не верю я что все это можно реализовать из мертвого камня на одной только физике.

S>>А на чем еще? Неужто на воле божьей?

KK>Очень интересная книга Р.Пенроуза "Новый ум короля". Основная мысль произведения — моделирование разума невозможно с помощью машины тьюрнга.

Гм. Поясню немного более развернуто:
В настоящий момент существует две взаимоисключающие гипотезы — тезис Черча и его опровержение. Пока что не представляется возможным даже придумать эксперимент, который мог бы убедительно проверить статус этих гипотез. Пенроуз фактически манипулирует недоказанностью ТЧ.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Многопоточность сегодня
От: BulatZiganshin  
Дата: 29.10.07 12:52
Оценка:
Здравствуйте, Ka3a4oK, Вы писали:

KK>Очень интересная книга Р.Пенроуза "Новый ум короля". Основная мысль произведения — моделирование разума невозможно с помощью машины тьюрнга.


из чего следует, что законов физики не существует (или человек им не подчиняется)

меня в этой книге больше заинтересовали объяснения квантовой физики и энтропии
Люди, я люблю вас! Будьте бдительны!!!
Re[9]: Многопоточность сегодня
От: Pavel Dvorkin Россия  
Дата: 30.10.07 03:18
Оценка:
Здравствуйте, remark, Вы писали:

R>Главное не использовать виндовый


Хм... Насчет malloc — вполне согласен, а как насчет HeapCreate/HeapAlloc с HEAP_NO_SERIALIZE ?
With best regards
Pavel Dvorkin
Re[10]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 30.10.07 08:25
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


R>>Главное не использовать виндовый


PD>Хм... Насчет malloc — вполне согласен, а как насчет HeapCreate/HeapAlloc с HEAP_NO_SERIALIZE ?


A vot eto poprobu'te


http://gzip.rsdn.ru/forum/message/2605709.1.aspx
Автор: remark
Дата: 31.07.07

http://gzip.rsdn.ru/forum/message/2605738.1.aspx
Автор: remark
Дата: 01.08.07

http://gzip.rsdn.ru/forum/message/2605709.1.aspx
Автор: remark
Дата: 31.07.07



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[26]: Многопоточность сегодня
От: . Великобритания  
Дата: 30.10.07 08:35
Оценка:
Sinclair wrote:
> Совершенно верно. Поэтому это и называется тезисом, а не теоремой. Тезис
> Черча — про то, что наше интуитивное определение вычислимости сводимо к
> формальному определению алгоритма. Тезис был косвенно подтвержден
> строгими доказательствами эквивалентности различных определений
> алгоритма и вычислимости.
А вообще говоря, проблема в том, что ещё не доказано, что всё что делает человек — алгоритмизируемо. И проблема не в аналоговости/цифровости.
Скажем, проблема останова — алгоритмически неразрешима, доказано, однако, студенты на первом курсе только так щёлкают такие задачки.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[27]: Многопоточность сегодня
От: deniok Россия  
Дата: 30.10.07 08:40
Оценка: +2
Здравствуйте, ., Вы писали:

.>Sinclair wrote:

>> Совершенно верно. Поэтому это и называется тезисом, а не теоремой. Тезис
>> Черча — про то, что наше интуитивное определение вычислимости сводимо к
>> формальному определению алгоритма. Тезис был косвенно подтвержден
>> строгими доказательствами эквивалентности различных определений
>> алгоритма и вычислимости.
.>А вообще говоря, проблема в том, что ещё не доказано, что всё что делает человек — алгоритмизируемо. И проблема не в аналоговости/цифровости.
.>Скажем, проблема останова — алгоритмически неразрешима, доказано, однако, студенты на первом курсе только так щёлкают такие задачки.
Те задачки, которые студенты щелкают на первом курсе — для них проблема останова решается на раз. Неразрешимость доказана для общего случая — нет универсального алгоритма, который для произвольного алгоритма решал бы эту проблему.
Re[4]: Многопоточность сегодня
От: igna Россия  
Дата: 01.11.07 12:57
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Сортировку вставками или пузырьком нельзя. Многие алгоритмы на графе нельзя.

Значит на многоядерных процессорах будут использоваться те алгоритмы, которые распараллелить можно.

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

Нет уж. Недостаточно найти один алгоритм, который распараллелить нельзя; нужно доказать, что не существует алгоритма, который распараллелить можно.
Re[5]: Многопоточность сегодня
От: Кодёнок  
Дата: 01.11.07 17:54
Оценка:
Здравствуйте, igna, Вы писали:

Кё>>Сортировку вставками или пузырьком нельзя. Многие алгоритмы на графе нельзя.

I>Значит на многоядерных процессорах будут использоваться те алгоритмы, которые распараллелить можно.

Не раньше чем появится «Исскусство программирования» для параллельного программирования Проблема в том, что десятки ядер — уже здесь, а истинное (тру ) параллельное программирование — еще далеко-далеко «там». А то что сейчас под ним подразумевают (multithreading), на практике показывает немасштабируемость, даже на 8 ядер.

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

I>Нет уж. Недостаточно найти один алгоритм, который распараллелить нельзя; нужно доказать, что не существует алгоритма, который распараллелить можно.

Извини, не уловил логики.
Re[28]: Многопоточность сегодня
От: . Великобритания  
Дата: 01.11.07 21:05
Оценка: +1
deniok wrote:

> .>А вообще говоря, проблема в том, что ещё не доказано, что всё что

> делает человек — алгоритмизируемо. И проблема не в аналоговости/цифровости.
> .>Скажем, проблема останова — алгоритмически неразрешима, доказано,
> однако, студенты на первом курсе только так щёлкают такие задачки.
> Те задачки, которые студенты щелкают на первом курсе — для них проблема
> останова решается на раз. Неразрешимость доказана для общего случая —
> нет универсального алгоритма, который для произвольного алгоритма решал
> бы эту проблему.
Так да, проблема в том, что нет лишь _алгоритма_ (как математического объекта). Не доказано, что человек думает, решает задачи только в соответсвтии с каким-то, пусть безумно большим и сложным, но всё же алгоритом. Вполне вероятно, существуют процессы, которые позволяют отыскивать решения неалгоритмическим способом, иначе бы человечество не прогрессировало. Но, по правде говоря, это философская проблема (т.е. не оффтопик ).
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[29]: Многопоточность сегодня
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.11.07 21:13
Оценка: 6 (1)
Здравствуйте, ., Вы писали:

.>Так да, проблема в том, что нет лишь _алгоритма_ (как математического объекта). Не доказано, что человек думает, решает задачи только в соответсвтии с каким-то, пусть безумно большим и сложным, но всё же алгоритом. Вполне вероятно, существуют процессы, которые позволяют отыскивать решения неалгоритмическим способом, иначе бы человечество не прогрессировало. Но, по правде говоря, это философская проблема (т.е. не оффтопик ).


Кстати вот на LtU очень понравилась статья, там чувак как одним из пунктов предлагает открытую аксиоматическую систему, т.е. фактически мы получем не строгий алгоритм, т.е. чётко конечную систему, и в результате не получаем по сути противоречия с теоремой Гёделя. Но это дело заставило задуматься — а есть ли какие-либо системы, которые были бы мощнее чем машина Тьюринга и лямбда-исчисление? Как простроить строгую систему исходя из этой открытой аксиоматики очень непонятно...
Re[7]: Многопоточность сегодня
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 13.11.07 07:40
Оценка:
Здравствуйте, remark, Вы писали:

R>hoard:

R>http://www.hoard.org/
R>(как раз на днях вышла новая версия 3.7)

вопрос. можно ли собрать Hoard при помощи VC6? у меня создается впечатление что он и под виндой только GCC собирается
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 14.11.07 09:28
Оценка:
Здравствуйте, kaa.python, Вы писали:

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


R>>hoard:

R>>http://www.hoard.org/
R>>(как раз на днях вышла новая версия 3.7)

KP>вопрос. можно ли собрать Hoard при помощи VC6? у меня создается впечатление что он и под виндой только GCC собирается


Там же написано: "...после сборки доработать напильником."


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[29]: Многопоточность сегодня
От: BulatZiganshin  
Дата: 19.11.07 16:51
Оценка:
Здравствуйте, ., Вы писали:

>> останова решается на раз. Неразрешимость доказана для общего случая —

>> нет универсального алгоритма, который для произвольного алгоритма решал
>> бы эту проблему.
.>Так да, проблема в том, что нет лишь _алгоритма_ (как математического объекта). Не доказано, что человек думает, решает задачи только в соответсвтии с каким-то, пусть безумно большим и сложным, но всё же алгоритом. Вполне вероятно, существуют процессы, которые позволяют отыскивать решения неалгоритмическим способом, иначе бы человечество не прогрессировало. Но, по правде говоря, это философская проблема (т.е. не оффтопик ).

во-первых, если говорить о любом конкретно взятом человеке, то он не может гарантироваванно решить произвольно взятую проблему, т.е. ничем не отличается от компа. во-вторых, животный мир точно так жде прогрессировал миллиарды лет. это всего лишь следствие процесса ест. отбора, который обладает некоторыми "сверхъественными" свойствами — например, уменьшает энтропию и решает проблемы не путём действия по алгоритму, а путём случайного перебора в некоем пространстве возможных решений — соотвественно, и вероятность успешного решения меньше 100%
Люди, я люблю вас! Будьте бдительны!!!
Re[30]: Многопоточность сегодня
От: . Великобритания  
Дата: 19.11.07 17:54
Оценка:
BulatZiganshin wrote:

> во-первых, если говорить о любом конкретно взятом человеке, то он не

> может гарантироваванно решить произвольно взятую проблему, т.е. ничем не
> отличается от компа. во-вторых, животный мир точно так жде
А вот это не и доказано.. А вдруг может? Экспериментально не проверить, по-моему. Может для каких-то проблем ему потребуется миллиард лет и тонны "бумаги". А теоретического доказательства я не слышал.
Ведь и компьютер, которому дано только 100 лет не может решить произвольно взятый алгоритм, это мало о чём говорит.

> прогрессировал миллиарды лет. это всего лишь следствие процесса ест.

> отбора, который обладает некоторыми "сверхъественными" свойствами —
> например, уменьшает энтропию и решает проблемы не путём действия по
> алгоритму, а путём случайного перебора в некоем пространстве возможных
> решений — соотвественно, и вероятность успешного решения меньше 100%
Возможно... но реальна ли возможность это алгоритмизировать? Или там возникают другие эффекты и существуют неалгоритмизируемые процессы?..
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Многопоточность сегодня
От: Maxim S. Shatskih Россия  
Дата: 23.11.07 00:20
Оценка:
Для системных программистов никакого перегиба развития нету. Ядро полноценной ОС и все прибамбасы к нему должны быть SMP-совместимы, потому в системном программировании тестирование на SMP было обязательно и в 90ые годы.

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

Только вот нити используются не только для задействования всех CPU, но и для той же отвязки от ожидания на вводе-выводе, к примеру.

Мутексы должны быть "маленькими", под ними должны исполняться очень короткие пути кода.

Пачкание кэша — далеко не единственная причина тормозов на MT, есть еще и инверсии приоритетов, и голодания, и прочие радости.
Занимайтесь LoveCraftом, а не WarCraftом!
Re: Многопоточность сегодня - не от хорошей жизни
От: Pavel Dvorkin Россия  
Дата: 26.11.07 11:44
Оценка:
Здравствуйте, remark, Вы писали:

Как-то все думал, стоит ли говорить то, что скажу. Нестандартно это очень...

А не кажется ли вам, господа, что многопоточность (а точнее, многоядерность) — не от хорошей жизни. Иными словами, это перекладывание проблем с аппаратуры на программистов ?

>Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потокамию. И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)


А зададимся-ка таким вопросом. Представьте себе. что через 5 лет будет выпущен одноядерный процессор с быстродействием в 80 раз больше нынешнего. Вы его предпочтете или это многоядерное чудовище ?

Я в свое время голосование устроил

http://www.rsdn.ru/poll/1851.aspx
Автор: Pavel Dvorkin
Дата: 25.06.07
Вопрос: Какую машину бы Вы предпочли


Как видите, хоть и незначительное, но все же большинство предпочитает одноядерный процессор паре двухядерных с той же суммарной частотой. И это неудивительно — про распараллеливание много сказано, а попробуйте обратную задачу решить — заставить один поток исполняться на двух процессорах, дабы полностью использовать мощность компьютера. Именно так — на остальные процессы наплевать, им ничего не дадим (насколько сможем), а вот этому процессу — всю мощь PC. А он однопоточный по характеру самого алгоритма. Ну и как ?


Если же ситуация иная, и потоков много, то на этом жутком 80x скоростном процессоре время переключения потоков будет настолько ничтожным по сравнению с суммарным временем, что им просто можно будет пренебречь (разумеется, в предположении, что и скорость работы памяти увеличится так же) . И можете теперь рассматривать как один 80x скоростной процессор или , если хотите, как 80 1x-скоростных процессоров или как-то еще иначе.

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

Я уж не говорю о том. что при этом применяются решения, которые совсем не очевидны. Тут много о кэше памяти говорилось. А ведь кэш-память — это кэш ОП, а не процессора. И быть ей надо бы ИМХО именно кэш-памятью на самой ОП, а не у каждого процессора, тогда бы и проблем с синхронизацией кэша не было бы. Если процессор == поток, то получаем кэш у потока, вместо того, чтобы иметь его у процесса, отсюда и все проблемы. Но сделать иначе — технически невозможно, а точнее, не заложено в архитектуру.

Вот такие пироги...

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

P.S. Лично мое мнение о многопоточности очень простое. Если по характеру алгоритма распараллеливания нет — не надо ее насильно туда совать. Если оно может быть, но можно обойтись без него — тоже лучше не надо. Вот только если обойтись нельзя, то есть алгоритм по своей сути параллельный — тогда да.
With best regards
Pavel Dvorkin
Re[2]: Многопоточность сегодня - не от хорошей жизни
От: Hobot Bobot США  
Дата: 26.11.07 12:12
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И это неудивительно — про распараллеливание много сказано, а попробуйте обратную задачу решить — заставить один поток исполняться на двух процессорах, дабы полностью использовать мощность компьютера. Именно так — на остальные процессы наплевать, им ничего не дадим (насколько сможем), а вот этому процессу — всю мощь PC. А он однопоточный по характеру самого алгоритма. Ну и как ?


Чего-то я запутался... Во-первых, занять одним потоком два процессора (если мы говорим о чем-то подобном threads в Windows) вроде как невозможно по определению. А если речь идет о процессе, а не о потоке, то это вроде и есть задача по распареллеливанию — замена "однопоточных" алгоритмов "многопоточными". Или я где-то ошибаюсь?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: Pavel Dvorkin Россия  
Дата: 26.11.07 12:19
Оценка:
Здравствуйте, Hobot Bobot, Вы писали:

HB>Чего-то я запутался... Во-первых, занять одним потоком два процессора (если мы говорим о чем-то подобном threads в Windows) вроде как невозможно по определению.


Я именно об этом и говорю. Если программа однопоточная, то на двухядерном процессоре она может использовать только половину его мощности. В то время как на одноядерном процессоре — либо она все 100%, либо две программы по 50% — тоже все 100, либо четыре по 25% и т.д. А вот одна однопоточная 100% — не может.

У меня как раз задача — взять от процессора всю его мощность. А задача не является по своей сути распараллеливаемой, по крайней мере на первый взгляд. Так что придется ее распараллеливать искусственно...
With best regards
Pavel Dvorkin
Re[4]: Многопоточность сегодня - не от хорошей жизни
От: Hobot Bobot США  
Дата: 26.11.07 12:33
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я именно об этом и говорю. Если программа однопоточная, то на двухядерном процессоре она может использовать только половину его мощности. В то время как на одноядерном процессоре — либо она все 100%, либо две программы по 50% — тоже все 100, либо четыре по 25% и т.д. А вот одна однопоточная 100% — не может.


PD>У меня как раз задача — взять от процессора всю его мощность. А задача не является по своей сути распараллеливаемой, по крайней мере на первый взгляд. Так что придется ее распараллеливать искусственно...


А, ну так это, ИМХО, довольно общее место — то, что многоядерные системы хорошо подходят для распараллеливаемых задач, и плохо — для нераспараллеливаемых. Вряд ли кто-то с этим не согласится.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Re[5]: Многопоточность сегодня - не от хорошей жизни
От: Pavel Dvorkin Россия  
Дата: 26.11.07 12:45
Оценка:
Здравствуйте, Hobot Bobot, Вы писали:

HB>А, ну так это, ИМХО, довольно общее место — то, что многоядерные системы хорошо подходят для распараллеливаемых задач, и плохо — для нераспараллеливаемых. Вряд ли кто-то с этим не согласится.


А вот потенциальный одноядерный с быстродействием, равным сумме быстродействий ядер, хорошо бы подошел для задач обоих типов. Но с этим не уверен, что все согласятся
With best regards
Pavel Dvorkin
Re[6]: Многопоточность сегодня - не от хорошей жизни
От: deniok Россия  
Дата: 26.11.07 12:54
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


HB>>А, ну так это, ИМХО, довольно общее место — то, что многоядерные системы хорошо подходят для распараллеливаемых задач, и плохо — для нераспараллеливаемых. Вряд ли кто-то с этим не согласится.


PD>А вот потенциальный одноядерный с быстродействием, равным сумме быстродействий ядер, хорошо бы подошел для задач обоих типов. Но с этим не уверен, что все согласятся


То-то и оно, что потенциальный. Если мы научились делать одно ядро в 80 раз быстрее, то мы вскоре сможем сделать 80-ядерник из таких в 80 раз более быстрых. Проблема же в том, что закон Мура вроде закончился. А быстродействия дополнительного хочется
Re[6]: Многопоточность сегодня - не от хорошей жизни
От: Hobot Bobot США  
Дата: 26.11.07 12:55
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

HB>>А, ну так это, ИМХО, довольно общее место — то, что многоядерные системы хорошо подходят для распараллеливаемых задач, и плохо — для нераспараллеливаемых. Вряд ли кто-то с этим не согласится.


PD>А вот потенциальный одноядерный с быстродействием, равным сумме быстродействий ядер, хорошо бы подошел для задач обоих типов. Но с этим не уверен, что все согласятся


А вот если построить из этих "потенциальных и сверх-быстрых" ядер многоядерную систему...
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Re[7]: Многопоточность сегодня - не от хорошей жизни
От: Pavel Dvorkin Россия  
Дата: 26.11.07 13:15
Оценка:
Здравствуйте, Hobot Bobot, Вы писали:

HB>А вот если построить из этих "потенциальных и сверх-быстрых" ядер многоядерную систему...


А вот если заменить эту многоядерную систему из "потенциальных и сверх-быстрых" на один "потенциальный и сверх-сверх-быстрый"

Предлагаю рекурсию прекратить
With best regards
Pavel Dvorkin
Re[2]: Многопоточность сегодня - не от хорошей жизни
От: Кодёнок  
Дата: 26.11.07 13:16
Оценка: +3
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Жить нам, конечно, с этими многоядерными монстрами придется, и проблемы решать — тоже. Но, похоже, многие из них не фундаментальные проблемы, а проблемы, которые на нас изготовители оборудования переложили.


Железо последние годы развивалось значительно быстрее софта, и просто дошло до своего предела. Теперь оно пошло в другую сторону — туда, где еще свободно.

PD>P.S. Лично мое мнение о многопоточности очень простое. Если по характеру алгоритма распараллеливания нет — не надо ее насильно туда совать. Если оно может быть, но можно обойтись без него — тоже лучше не надо. Вот только если обойтись нельзя, то есть алгоритм по своей сути параллельный — тогда да.


Моё мнение о многопоточности: it sucks. Лучшая многопоточность — это множество однопоточных алгоритмов, взаимодействующих между собой в небольшом и явно выделенном числе точек соприкосновения. Чем меньше точек соприкосновения, тем лучше. Множество потоков не проблема, проблема — их взаимодействие.

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

Может ты хочешь невозможного — N ядер не могут дать N-кратного прироста скорости на взаимосвязанных процессах, предел скорости есть у всего.

И ещё, далеко не всем алгоритмам для приемлемой скорости работы нужно хотя бы 50% мощности современных ядер. Так что наличие непараллелящихся алгоритмов не есть аргумент в пользу одноядерности. Сколько компьютеров в мире заняты обсчитыванием графов размером 4 Гб? Остальные 99.9999% обсчитывают данные размером 100 Кб, которые даже непараллелящимся алгоритмом приемлемо быстро выполнятся на одном 200 Мгц-ядре.
Re[7]: Многопоточность сегодня - не от хорошей жизни
От: Pavel Dvorkin Россия  
Дата: 26.11.07 13:16
Оценка:
Здравствуйте, deniok, Вы писали:

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


Видимо, да.

>А быстродействия дополнительного хочется


Хочется. Но будет оно за счет нашей головной боли.
With best regards
Pavel Dvorkin
Re[8]: Многопоточность сегодня - не от хорошей жизни
От: deniok Россия  
Дата: 26.11.07 14:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

>>А быстродействия дополнительного хочется


PD>Хочется. Но будет оно за счет нашей головной боли.


Зато того, кто придумает лучшие таблетки, ждёт большой кусок пирога
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 26.11.07 14:52
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Для системных программистов никакого перегиба развития нету. Ядро полноценной ОС и все прибамбасы к нему должны быть SMP-совместимы, потому в системном программировании тестирование на SMP было обязательно и в 90ые годы.


Возможно разработчики ОС. Некоторых. Windows — нет.
Разработчики драйверов — нет.
Разработчики tcp-стеков и web-серверов — нет.


MSS>Только вот нити используются не только для задействования всех CPU, но и для той же отвязки от ожидания на вводе-выводе, к примеру.


Это отдельный разговор. Тут всё определяется тем, что и как предоставляет ОС. Windows, например, предоставляет очень хорошее API — IOCP. Linux — NBIO и AIO.


MSS>Мутексы должны быть "маленькими", под ними должны исполняться очень короткие пути кода.


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


MSS>Пачкание кэша — далеко не единственная причина тормозов на MT, есть еще и инверсии приоритетов, и голодания, и прочие радости.


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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: The Lex Украина  
Дата: 26.11.07 15:24
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Железо последние годы развивалось значительно быстрее софта, и просто дошло до своего предела. Теперь оно пошло в другую сторону — туда, где еще свободно.


+1!

Кё>Моё мнение о многопоточности: it sucks.


Как и в случае с демократией, "это лучшее из того, что мы имеем на сей момент" (к)

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


+1!

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


Реальный мир это уже прошел — равно аналогичный (имхо) этап развития в производстве: какое-то время тому назад всякий предмет делал один человек — ремесленник. Да, подмастерья были — банально потому что удобнее делать многие технологические операции "в четыре руки". Но потом данная технология производства совершенствовалась и достигла своего предела: один мастер просто физически не может делать больше. Выход напрашивается сам собой: посадить кучу мастеров и пусть они делают сразу много предметов — каждый свой — параллельно. А есть еще один, который был реализован исторически в современном промышленном производстве: разбить процесс производства предмета на отдельные составляющие и посадить кучу людей делать каждую отдельную составляющую, но параллельно — конвейер называется. Да, для реализации такого нужна дополнительная работа: разработка технологического процесса (читай: алгоритма?), подходящего для работы на конвейере. Для "железного", "материального" мира этот вопрос успешно решен.

Но тут действительно есть еще один вопрос...

Кё>И ещё, далеко не всем алгоритмам для приемлемой скорости работы нужно хотя бы 50% мощности современных ядер. Так что наличие непараллелящихся алгоритмов не есть аргумент в пользу одноядерности. Сколько компьютеров в мире заняты обсчитыванием графов размером 4 Гб? Остальные 99.9999% обсчитывают данные размером 100 Кб, которые даже непараллелящимся алгоритмом приемлемо быстро выполнятся на одном 200 Мгц-ядре.


Вот-вот. Однако же подобный "спор" я помню еще со времен классического "ни одной программе не понадобится более 640 килобайт ОЗУ" (к) (по памяти — возможно переврал), а потом еще один такой же этап на переходе с 16 бит разрядности на 32: "32 бита могут понадобиться лишь каким-то крайне требовательным к ресурсами приложениям, вроде СУБД и прочих, а рядовые вполне обойдуть 16-ю..." Но как-то вот сейчас по гигабайту памяти — обычный объем — а вопрос "почему я не могу 4 ГБ?" тоже перешел в разряд "боянов" — значит таки нужны?

Какие вообще исторические двигатели ИТ-прогресса произвотельности ПК имели место быть и есть сейчас? Игры. Сейчас — видео высокой четкости. Что еще?
Голь на выдумку хитра, однако...
Re[2]: Многопоточность сегодня - не от хорошей жизни
От: remark Россия http://www.1024cores.net/
Дата: 26.11.07 17:08
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>Как-то все думал, стоит ли говорить то, что скажу. Нестандартно это очень...


PD>А не кажется ли вам, господа, что многопоточность (а точнее, многоядерность) — не от хорошей жизни. Иными словами, это перекладывание проблем с аппаратуры на программистов ?


Именно так и есть!


>>Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потокамию. И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)


PD>А зададимся-ка таким вопросом. Представьте себе. что через 5 лет будет выпущен одноядерный процессор с быстродействием в 80 раз больше нынешнего. Вы его предпочтете или это многоядерное чудовище ?


К сожалению, мы перед таким выбором не стоим...



PD>Как видите, хоть и незначительное, но все же большинство предпочитает одноядерный процессор паре двухядерных с той же суммарной частотой. И это неудивительно — про распараллеливание много сказано, а попробуйте обратную задачу решить — заставить один поток исполняться на двух процессорах, дабы полностью использовать мощность компьютера. Именно так — на остальные процессы наплевать, им ничего не дадим (насколько сможем), а вот этому процессу — всю мощь PC. А он однопоточный по характеру самого алгоритма. Ну и как ?


Так же как и алгоритму, который упирается в пропускную способность памяти, или в пропускную способность сети. Они все не будут использовать процессор на полную мощность.



PD>Иными словами, не сумев решить задачу повышения быстродействия одного ядра, разработчики процессоров пошли по экстенсивному пути, начав наращивать число ядер. Возникающие проблемы при этом перекладываются на программистов, пусть они решают.


Так и есть.

PD>Я уж не говорю о том. что при этом применяются решения, которые совсем не очевидны. Тут много о кэше памяти говорилось. А ведь кэш-память — это кэш ОП, а не процессора. И быть ей надо бы ИМХО именно кэш-памятью на самой ОП, а не у каждого процессора, тогда бы и проблем с синхронизацией кэша не было бы. Если процессор == поток, то получаем кэш у потока, вместо того, чтобы иметь его у процесса, отсюда и все проблемы. Но сделать иначе — технически невозможно, а точнее, не заложено в архитектуру.



кэш-памятью на самой ОП — бессмысленно. ОП — и есть свой кэш.



PD>Жить нам, конечно, с этими многоядерными монстрами придется, и проблемы решать — тоже. Но, похоже, многие из них не фундаментальные проблемы, а проблемы, которые на нас изготовители оборудования переложили.


Так же как и IOCP, интерфейс которого переложили на нас изготовители ОС. Так же как и MMX/SSE/SSE2/SSE3/SSE4, которое на нас переложили изготовители процессора. И т.д. и т.п.


PD>P.S. Лично мое мнение о многопоточности очень простое. Если по характеру алгоритма распараллеливания нет — не надо ее насильно туда совать. Если оно может быть, но можно обойтись без него — тоже лучше не надо. Вот только если обойтись нельзя, то есть алгоритм по своей сути параллельный — тогда да.


Например, всё серверное ПО замечательно распараллеливается — на уровне транзацкий сам бог велел распараллеливать.
Что такое "по своей сути" — сложно сказать...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: Pavel Dvorkin Россия  
Дата: 27.11.07 02:23
Оценка:
Здравствуйте, remark, Вы писали:

R>кэш-памятью на самой ОП — бессмысленно. ОП — и есть свой кэш.


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



R>Например, всё серверное ПО замечательно распараллеливается — на уровне транзацкий сам бог велел распараллеливать.


+1

R>Что такое "по своей сути" — сложно сказать...


Что такое компьютер — тоже сложно сказать , но когда мы его видим перед собой, мы сразу понимаем, что это он. Дать определение нераспараллеливаемому алгоритму я так сразу не берусь, но для конкретного алгоритма порой вполне ясно, что распараллелить его можно только с помощью грубой силы. Итерационные алгоритмы, к примеру...
With best regards
Pavel Dvorkin
Re[4]: Многопоточность сегодня - не от хорошей жизни
От: remark Россия http://www.1024cores.net/
Дата: 27.11.07 08:01
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


R>>кэш-памятью на самой ОП — бессмысленно. ОП — и есть свой кэш.


PD>Я имел в виду, что та кэш-память, которая сейчас у процессора (и у каждого своя, откуда проблемы ее синхронизации), должна быть одной на все процессоры. Аналогично тому, что все потоки процесса иимеют программно-реализованный кэш (к примеру, данных из БД ), а не каждый поток имеет этот кэш.


Это не возможно, т.к. во-первых, всё равно нужна будет синхронизация при работе с этим кэшем. Ты же защищаешь мьютексом свой кэш, который общий на все потоки. Т.е. возвращаемся туда, откуда вышли. Во-вторых, кэш *обязан* быть близко к процессору, в этом его первостипенное предназначение. А как разместить общий кэш близко ко всем ядрам — не понятно.
В принципе, кэш второго уровня зачастую как раз и делают разделяемым между всеми ядрами. Но кэш первого уровня остаётся приватным для ядра.



R>>Что такое "по своей сути" — сложно сказать...


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


А чем "грубая сила" плоха? Взяли матрицу и подели по строкам (по столбцам, по блокам, в шахматном порядке), и рассчитываем параллельно.
Итерационный — это алгоритм, а в конечном итоге нам всегда надо решить задачу, а не алгоритм. А у задачи может быть несколько алгоритмов решения. Например, есть алгоритмы сортировки, наиболее оптимальные для последовательного вычисления, но при распараллеливании обычно берут немного более плохой с т.з. вычислительной сложности алгоритм, но который зато легко и "естественно" разделяется на независимые подзадачи.

Кстати, если интересно, пример *задачи*, которая не поддаётся распараллеливанию (текущими математическими методами) — посчитать:
(2^(2^t)) (mod n*p)
где n и p — произвольные большие простые числа, t — произвольное число
(т.н. MIT LCS35 Time Capsule Crypto-Puzzle)



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность сегодня
От: Andrei F.  
Дата: 27.11.07 11:16
Оценка:
Здравствуйте, remark, Вы писали:

R>Ключевое слово, по которому надо искать — work stealing.

R>Так же ищи — Cilk, Java Fork/Join, C# TPL, Intel TBB. Как это ни удивительно, но все эти вещи используют идентичный механизм.

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

R>Если *всё*, что надо сделать твоей программе — это обработать 100 элементов, то я не думаю, что у тебя есть проблемы вообще.


Это просто упрощенный пример.
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 27.11.07 12:32
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>Ключевое слово, по которому надо искать — work stealing.

R>>Так же ищи — Cilk, Java Fork/Join, C# TPL, Intel TBB. Как это ни удивительно, но все эти вещи используют идентичный механизм.

AF>Неважно, когда нужно будет агрегировать результаты обработки частей — без разделяемой памяти все равно не обойтись.


Агрегации либо вообще не бывает. Например, параллельная обработка транзакций на сервере, обработка изображений строго по частям.
Либо она на порядок меньше "основной работы". Например, "досортировка" массива. "Складывание" изображения из слоёв.


AF>Кстати, а когда TPL обещают в публичном доступе, неизвестно?


Вместе с .NET 4.0 видимо...



R>>Если *всё*, что надо сделать твоей программе — это обработать 100 элементов, то я не думаю, что у тебя есть проблемы вообще.


AF>Это просто упрощенный пример.


Значит, он не адекватный...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Многопоточность сегодня
От: Andrei F.  
Дата: 27.11.07 13:16
Оценка:
Здравствуйте, remark, Вы писали:

R>Либо она на порядок меньше "основной работы". Например, "досортировка" массива. "Складывание" изображения из слоёв.


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

R>Значит, он не адекватный...


Почему?
Re[10]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 27.11.07 14:21
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>Либо она на порядок меньше "основной работы". Например, "досортировка" массива. "Складывание" изображения из слоёв.


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



При распараллеливании гранулярность должна быть не fine-grained, не coarse-grained, а right-grained



R>>Значит, он не адекватный...


AF>Почему?


Потому что предполагает тривиальное решение...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Многопоточность сегодня
От: Andrei F.  
Дата: 27.11.07 14:28
Оценка:
Здравствуйте, remark, Вы писали:

R>

R>При распараллеливании гранулярность должна быть не fine-grained, не coarse-grained, а right-grained


right-grained — это понятие растяжимое, и очень зависит от величины накладных расходов

R>Потому что предполагает тривиальное решение...


Не понял мысли.
Re[4]: Многопоточность сегодня - не от хорошей жизни
От: GlebZ Россия  
Дата: 27.11.07 15:06
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я имел в виду, что та кэш-память, которая сейчас у процессора (и у каждого своя, откуда проблемы ее синхронизации), должна быть одной на все процессоры. Аналогично тому, что все потоки процесса иимеют программно-реализованный кэш (к примеру, данных из БД ), а не каждый поток имеет этот кэш.

Эдак мы то совместных регистров дойдем. Иначе их придется синхронизировать между процессорами.
Re[12]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 27.11.07 15:15
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>

R>>При распараллеливании гранулярность должна быть не fine-grained, не coarse-grained, а right-grained


AF>right-grained — это понятие растяжимое, и очень зависит от величины накладных расходов


Так точно!


R>>Потому что предполагает тривиальное решение...


AF>Не понял мысли.


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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[13]: Многопоточность сегодня
От: Andrei F.  
Дата: 28.11.07 03:47
Оценка:
Здравствуйте, remark, Вы писали:

R>На таком примере нельзя ничего показать, и нельзя ничему научиться, т.к. я могу просто выдать ответ "делай всё в одном потоке", и это будет наилучшее решение для данной задачи. При приведении примеров надо отбрасывать второстипенные детали, а не существенные...


Ладно, давай тогда по другому. Это я правильно понял, что операция записи в разделяемую ячейку памяти стоит порядка 500-1000 тактов простоя, причем для каждого ядра, у которого в кэше загружена линия с этой ячейкой памяти?
Re[14]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 28.11.07 09:08
Оценка:
Здравствуйте, Andrei F., Вы писали:

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


R>>На таком примере нельзя ничего показать, и нельзя ничему научиться, т.к. я могу просто выдать ответ "делай всё в одном потоке", и это будет наилучшее решение для данной задачи. При приведении примеров надо отбрасывать второстипенные детали, а не существенные...


AF>Ладно, давай тогда по другому. Это я правильно понял, что операция записи в разделяемую ячейку памяти стоит порядка 500-1000 тактов простоя, причем для каждого ядра, у которого в кэше загружена линия с этой ячейкой памяти?



Ну не всё так плохо
Я думаю, ситуация всё же немного лучше. Но во-первых, надо понимать, что цифры в некоторой степени референсные. Во-вторых, цифры могут сильно зависеть от модели процессора (Pentium 4 vs Pentium Core), не говоря о производителе (Intel vs AMD).
По моим представлениям примерно так: захват/освобождение мьютекса стоит примерно 500 тактов. На Intel x86. При условии, что память, в которой расположен мьютекс находится в кэше другого ядра. Если память уже находится в кэше текущего ядра и другое ядро не пытается захватить мьютекс, то это может быть 200 тактов. Если это ещё спин-мьютекс, то это может быть 100 тактов.
То, что это пенальти для всех ядер, скорее мне кажется, что нет. Т.е. пенальти только для текущего ядра. Т.к. кэши и протокол когерентности работает асинхронно с вычислительным ядром. Хотя может наступить конкуренция или насыщение шины когерентности, тогда скорее всего будет неявное пенальти и для других ядер.
Но опять же, всё это достаточно сложно и архитектурно-зависимо. Поэтому единственный более-менее реалистичный способ судить об этом, это — просто измерять.

Если говорить о записе в разделяемую память. Тут зависит от состояния, в котором находится кэш линия (Modified, Owner, Shared, Invalidated). В хорошем случае это просто запись в кэш, т.е. несколько тактов. В плохом случае — 150-350 тактов. (Опять же это всё относится к Intel x86)



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.11.07 12:09
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>>>Сортировку вставками или пузырьком нельзя.


Зато сортировка Бэтчера (см. Кнут, том 3) — отлично параллелится. Многие исполнения внешней сортировки — тоже.
Кстати, почему это пузырёк по-Вашему не параллелится? При надлежащей синхронизации (следующая волна не может обогнать предыдущую) — полная;) параллельность (хотя у Бэтчера всё равно лучше).

Кё>>> Многие алгоритмы на графе нельзя.

I>>Значит на многоядерных процессорах будут использоваться те алгоритмы, которые распараллелить можно.
Кё>Не раньше чем появится «Исскусство программирования» для параллельного программирования :)

Ну вот почти с ходу:

http://www.ozon.ru/context/detail/id/1372271/
Автор(ы): Грегори Р. Эндрюс
Издательство: Вильямс
Цена: 229р.

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


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

А кому надо чего-то менее современного — пусть читает Хоара:)

Кё> Проблема в том, что десятки ядер — уже здесь, а истинное (тру :) ) параллельное программирование — еще далеко-далеко «там». А то что сейчас под ним подразумевают (multithreading), на практике показывает немасштабируемость, даже на 8 ядер.


Я не думаю, что здесь народ настолько туп;), чтобы не заметить существование того же Erlang, у которого совсем не многопоточность и который освоит любое количество ядер (лишь бы работа была).

Вот промежуточных подходов практически нет, и это именно то, что вызывает резкий разрыв между двумя подходами. Или многонитевость на общей памяти — или полная независимость и обмен сообщениями (неважно, Erlang или MPI). Построения же в духе "вот тут 8 процессоров объединим на общей шине памяти, она может быть связана ещё с 15 такими же блоками, но уже через спецшины (получается NUMA), а такие блоки на 128 процессоров общаются между собой уже только сообщениями" — существуют только в узких нишах, снабжаемых 2-3 вендорами (типа Sun).
The God is real, unless declared integer.
Re[2]: Многопоточность сегодня - не от хорошей жизни
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.11.07 12:14
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А не кажется ли вам, господа, что многопоточность (а точнее, многоядерность) — не от хорошей жизни. Иными словами, это перекладывание проблем с аппаратуры на программистов ?


Какая альтернатива? Опровергнуть законы физики?

PD>Иными словами, не сумев решить задачу повышения быстродействия одного ядра, разработчики процессоров пошли по экстенсивному пути, начав наращивать число ядер. Возникающие проблемы при этом перекладываются на программистов, пусть они решают.


Только перекладывают проблемы не они. А те, кому нужна мощность несмотря на аппаратные проблемы.
The God is real, unless declared integer.
Re[7]: Многопоточность сегодня - не от хорошей жизни
От: Алексей.  
Дата: 28.11.07 12:23
Оценка: +1
Здравствуйте, deniok, Вы писали:

D>Проблема же в том, что закон Мура вроде закончился.


Закон Мура говорит об удвоении числа транзисторов на кристалле. О быстродействии он ничего не говорит.
Так что закон Мура будет еще действовать ближайшие 15-30 лет, пока современная технология производства чипов не упрется в физические пределы.
Re[7]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 28.11.07 13:29
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ну вот почти с ходу:


N>http://www.ozon.ru/context/detail/id/1372271/
Автор(ы): Грегори Р. Эндрюс
Издательство: Вильямс
Цена: 229р.

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


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



Вот именно, что *теоретические*. Очень много общих вещей, типа "Разделяемые данные нужно защищать критическими секциями бла-бла-бла бла-бла-бла ...". Материал в основном от второй половины 80 до второй половины 90.
Имхо, книга замечательно подходит для студента, который хочет вникнуть в тему. Но профессиональному разработчику, который хочет изучить что-то реальное, книга практически бесполезна...
Появилось бы что-нибудь с материалом хотя бы 2002-2004 годов...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Supra-linear scaling
От: remark Россия http://www.1024cores.net/
Дата: 29.11.07 14:38
Оценка: 2 (2)
Здравствуйте, Кодёнок, Вы писали:

Кё>Может ты хочешь невозможного — N ядер не могут дать N-кратного прироста скорости на взаимосвязанных процессах, предел скорости есть у всего.



Занятный момент — N ядер могут дать даже более чем N-кратный прирост скорости. Этот феномен называется Supra-linear scaling.

Хороший пример можно поглядеть здесь: Supra-linear Packet Processing Performance with Intel® Multi-core Processors

На 4-ёх ядерном процессоре авторы получили ускорение в 6,27 раза. Причём на вполне реалистичном приложении — сетевой сервер для фильтрации TCP соединений.
И в ряде других источников я встречался с упоминаниями этого феномена, правда с более скромными результатами (ссылки сейчас будет трудно найти).

Основная причина этого феномена — размер кэша первого и второго уровней. Если рабочий набор (и данных и команд) начинает не влезать в кэш первого уровня, то появляется скачкообразное падение производительности до 10-15 раз. И аналогично для не влезания в кэш второго уровня. На многоядерных процессорах кэши больше (пропорционально числу ядер), соотв. рабочий набор может начать влезать в кэш, в который он раньше не влезал. В этом и кроется причина Supra-linear scaling.
Хотя возможно тут есть и ещё какие-то менее очевидные факторы.

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

Вот Вам и многопоточность.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 07:54
Оценка:
MSS>>Для системных программистов никакого перегиба развития нету. Ядро полноценной ОС и все прибамбасы к нему должны быть SMP-совместимы, потому в системном программировании тестирование на SMP было обязательно и в 90ые годы.

R>Возможно разработчики ОС. Некоторых. Windows — нет.


SMP в Windows сделана полноценно с самого начала, в отличие от обоих популярных юниксов, где она была сделана как хак сбоку.

R>Разработчики драйверов — нет.


Разработчики драйверов — да.

R>Разработчики tcp-стеков и web-серверов — нет.


Разработчики tcp-стеков — да, web-серверов — нет, ибо в юзер моде нет разницы (кроме производительности в особо наворочанных местах) между многонитевостью на одном ядре и SMP.

R>Вот про это и я говорю. Подход "многопоточности на одном ядре". Короткие, не короткие, а пенальти в 500 тактов будь добр заплати. И насыщение шины когерентности кэшей.


500 тактов есть ерунда, например, для любой IO-bound задачи — IO все равно медленнее, да и послать IRP (и дождаться завершения) поболе 500 тактов стоит.

Что касается CPU-bound задач, то они как правило делятся на макро-операции, каждая из которых работает эдак с мегабайтом данных. Данные нарезаются на порции вот этого размера, потом на каждой порции бежит CPU-bound задача _уже без любых локов_. Снова 500 тактов — фигня по сравнению с переработкой мегабайта данных.

MSS>>Пачкание кэша — далеко не единственная причина тормозов на MT, есть еще и инверсии приоритетов, и голодания, и прочие радости.


R>Благодаря использованию хороших алгоритмов, меня, к счастью, такие проблемы не касаются


Я бы не зарекался вот именно вот тут.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 30.11.07 11:14
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>Для системных программистов никакого перегиба развития нету. Ядро полноценной ОС и все прибамбасы к нему должны быть SMP-совместимы, потому в системном программировании тестирование на SMP было обязательно и в 90ые годы.


R>>Возможно разработчики ОС. Некоторых. Windows — нет.


MSS>SMP в Windows сделана полноценно с самого начала, в отличие от обоих популярных юниксов, где она была сделана как хак сбоку.



Ну давай посмотрим.
Какие функции доступны с какой версии:
Обязательное условие сделать что-то стоящее — GetLogicalProcessorInformation() — Windows Vista or Windows XP Professional x64 Edition, Windows Server "Longhorn" or Windows Server 2003
Единственая возможность сделать что-то нормальное на NUMA и современных многоядерных процессорах — VirtualAllocExNuma() — Windows Vista, Windows Server "Longhorn"
Первый стоящий примитив синхронизации — InitializeSListHead() — Windows Vista or Windows XP, Windows Server "Longhorn" or Windows Server 2003
Второй стоящий примитив синхронизации — InitializeSRWLock() — Windows Vista, Windows Server "Longhorn".
Ну и так далее. Это говорит о том, когда они только *начали* задумываться об этом.



MSS>>>Пачкание кэша — далеко не единственная причина тормозов на MT, есть еще и инверсии приоритетов, и голодания, и прочие радости.


R>>Благодаря использованию хороших алгоритмов, меня, к счастью, такие проблемы не касаются


MSS>Я бы не зарекался вот именно вот тут.


Ну пожалуйста, не зарекайся.
Мои алгоритмы не подвержены инверсиям приоритетов, голоданиям, дедлокам и т.д.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность сегодня
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 12:33
Оценка: :)
MSS>>SMP в Windows сделана полноценно с самого начала, в отличие от обоих популярных юниксов, где она была сделана как хак сбоку.

R>

R>Ну давай посмотрим.

А что там смотреть? код кернела изначально мог выполняться на многих процессорах, и для локинга всегда использовались fine-grained спинлоки (вплоть до того, что в каждом драйвере по нескольку), вместо одного могучего lock_kernel() в начале тела сисколла, как в линуксе.

Код кернела всегда был преемптивным, в отличие от почти всех юниксов, даже, кажется, от SunOS 5, которая ровесница Windows NT.

R>Какие функции доступны с какой версии:

R>Обязательное условие сделать что-то стоящее — GetLogicalProcessorInformation() —

Да это просто пустяк. Все главное — см. выше.

R>Единственая возможность сделать что-то нормальное на NUMA и современных многоядерных процессорах — VirtualAllocExNuma() — Windows Vista, Windows Server "Longhorn"


При чем тут NUMA? мы про SMP, а не про NUMA.

NUMA да, совсем недавно стала поддерживаться вообще.

R>Первый стоящий примитив синхронизации — InitializeSListHead() — Windows Vista or Windows XP, Windows Server "Longhorn" or Windows Server 2003


Первые стоящие примитивы синхронизации — KeAcquireSpinLock, ExAcquireFastMutex, EnterCriticalSection — Windows NT 3.1

R>Ну и так далее. Это говорит о том, когда они только *начали* задумываться об этом.


В конце 80х и начали, сделав код ядра а) преемптивным б) способным выполняться на любом числе процессоров. Когда это в Линуксе появилось, к примеру? году в 2002?

Приведенные вами мелкие фенечки — это так, пустячки.

R>Ну пожалуйста, не зарекайся.

R>Мои алгоритмы не подвержены инверсиям приоритетов, голоданиям, дедлокам и т.д.

Можно, я не поверю? в подфоруме по Си++ вы в коде "lock-free контейнера данных" сделали две смешные баги, говорящие о ваших навыках в многонитевом программировании.

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

На этот скатывание во флейм можно остановить.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[2]: Многопоточность сегодня - не от хорошей жизни
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 12:38
Оценка: +1
PD>А зададимся-ка таким вопросом. Представьте себе. что через 5 лет будет выпущен одноядерный процессор с быстродействием в 80 раз больше нынешнего. Вы его предпочтете или это многоядерное чудовище ?

Конечно же, однопроцессор лучше SMP при той же общей производительности. Лучше 1 процессор в 2 раза быстрее, чем SMP из двух.

Причин целый ряд: а) пачканье кэшей б) contention на общей шине в) выжимание максимума из SMP требует определенного программирования приложений, а максимум из однопроцессора выжмется и без этого.

Просто мощность однопроцессора ограничена технически (а когда около 2002 умер закон Мура, стало ясно, что и физикой тоже ограничена). Мощность же SMP может наращиваться примерно до 8 CPU на существующей технологической базе (у Сана были и 32процессорный СпаркЦентры, но они вроде как были NUMA).
Занимайтесь LoveCraftом, а не WarCraftом!
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: Cyberax Марс  
Дата: 30.11.07 12:43
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Просто мощность однопроцессора ограничена технически (а когда около 2002 умер закон Мура, стало ясно, что и физикой тоже ограничена). Мощность же SMP может наращиваться примерно до 8 CPU на существующей технологической базе (у Сана были и 32процессорный СпаркЦентры, но они вроде как были NUMA).

Не умер закон Мура!!

Hint: в нем ничего не сказано про тактовые частоты.
Sapienti sat!
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 12:44
Оценка:
R>Например, всё серверное ПО замечательно распараллеливается — на уровне транзацкий сам бог велел распараллеливать.

...и даже на уровне микро-операций, из которых состоит транзакция — по крайней мере из них можно выделить IO bound и гонять CPU bound в параллель с IO bound.

Например, рендеринг трехмерной сцены. Экран режется на полосы по числу процессоров — и каждый процессор рендерит свое.

Вообще любые алгоритмы над независимыми друг от друга порциями данных легко параллелятся.

R>Что такое "по своей сути" — сложно сказать...
Занимайтесь LoveCraftом, а не WarCraftом!
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 12:50
Оценка:
Кё>Моё мнение о многопоточности: it sucks. Лучшая многопоточность — это множество однопоточных алгоритмов, взаимодействующих между собой в небольшом и явно выделенном числе точек соприкосновения.

Именно так нормальную многопоточность и делают.

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


Ага, и эти проблемы (голодания, инверсии приоритетов) — как правило, значительно хуже, чем то же загрязнение кэшей. Например, если CPU bound задача ждет завершения IO bound задачи, а процессор при этом стоит — то это может уменьшить общую производительность втрое. Загрязнение кэшей же... ну вряд ли втрое.

Про дедлоки я и не говорю — это просто баг. Обвинять в них многопоточность — это все равно что обвинять Windows в том, что при наличии на машине 30 наименований хренти какого софта она иногда показыает AV faults.

Кё>И ещё, далеко не всем алгоритмам для приемлемой скорости работы нужно хотя бы 50% мощности современных ядер. Так что наличие непараллелящихся алгоритмов не есть аргумент в пользу одноядерности. Сколько компьютеров в мире заняты обсчитыванием графов размером 4 Гб? Остальные 99.9999% обсчитывают данные размером 100 Кб, которые даже непараллелящимся алгоритмом приемлемо быстро выполнятся на одном 200 Мгц-ядре.


Ага. Значительная часть типовых современных задач прекрасно делается на компьютере 2000 года выпуска.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 13:00
Оценка:
HB>Чего-то я запутался... Во-первых, занять одним потоком два процессора (если мы говорим о чем-то подобном threads в Windows) вроде как невозможно по определению. А если речь идет о процессе, а не о потоке, то это вроде и есть задача по распареллеливанию — замена "однопоточных" алгоритмов "многопоточными". Или я где-то ошибаюсь?

Забудьте о тредах. Это не более чем механизм ОС, предназначенный для задействования всех процессоров (а также для отвязки от блокирующего ожидания каких-то событий, IO completion в том числе).

Это не "железо".

А на уровне "железа" у нас вот что — исполнение задачи требует столько-то памяти, столько то операций ввода/вывода, и столько-то тактов процессора. И все равно, один это процессор или несколько.

Интересует — выполнить задачу быстрее. Число тактов процессора известно. Значит, есть только два выхода: а) повышать частоту б) поставить несколько независимых процессоров.

Так вот, подход б) хуже. Потому как процессора не есть 100% независимые, по чисто "железным" причинам. Потому как не все операции хорошо параллелятся. Скажем, компрессия фильма параллелится на ура — AVI файл все равно состоит из независимо закодированных фреймов (или групп фреймов), вот и выдать каждому процессору по фрейму, пусть кодирует. Но таковы не все задачи. Плохо параллелится то, где неизбежно есть крупные shared данные, для примера.

remark тут приводил в пример извратную ситуацию, когда 4 ядра дают выигрыш в 6 раз — но совершенно явно не мэйнстрим, и вообще похоже на интеловский маркетинг.

Правильный подход — это а).

Что же касается нитей, то они есть вспомогательная сущность, которая нужна для того, чтобы в рамках ОС задействовать процессор. Если процессор один — то просто отпадает нужда в нитях в некоторых случаев. Например, в предполагаемом компрессоре фильмов просто тупо компрессится кадр за кадром. Одной нитью (чтение и запись я оставляю за кадром). А на SMP надо будет — по нити на процессор (да еще и affinity раздать).
Занимайтесь LoveCraftом, а не WarCraftом!
Re[4]: Многопоточность сегодня - не от хорошей жизни
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 13:01
Оценка:
C>Не умер закон Мура!!
C>Hint: в нем ничего не сказано про тактовые частоты.

А, т.е. теперь вместо роста частоты повышается количество ядер?
Занимайтесь LoveCraftом, а не WarCraftом!
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 30.11.07 13:03
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>SMP в Windows сделана полноценно с самого начала, в отличие от обоих популярных юниксов, где она была сделана как хак сбоку.


R>>

R>>Ну давай посмотрим.

MSS>А что там смотреть? код кернела изначально мог выполняться на многих процессорах, и для локинга всегда использовались fine-grained спинлоки (вплоть до того, что в каждом драйвере по нескольку), вместо одного могучего lock_kernel() в начале тела сисколла, как в линуксе.


MSS>Код кернела всегда был преемптивным, в отличие от почти всех юниксов, даже, кажется, от SunOS 5, которая ровесница Windows NT.



А ну если поддержкой многоядерности считать только возможность выполняться на нескольких аппаратных потоках и много локов, а не один. То пожалуйста. Я имел в виду, не теоритетическую возможность выполняться на нескольких аппаратных потоках, а *эффективную* работу.



R>>Первый стоящий примитив синхронизации — InitializeSListHead() — Windows Vista or Windows XP, Windows Server "Longhorn" or Windows Server 2003


MSS>Первые стоящие примитивы синхронизации — KeAcquireSpinLock, ExAcquireFastMutex, EnterCriticalSection — Windows NT 3.1



Этот треш из 70-ых годов меня не интересует. Хотя, да, он позволяет работать на нескольких аппаратных потоках.





R>>Ну пожалуйста, не зарекайся.

R>>Мои алгоритмы не подвержены инверсиям приоритетов, голоданиям, дедлокам и т.д.

MSS>Можно, я не поверю? в подфоруме по Си++ вы в коде "lock-free контейнера данных" сделали две смешные баги, говорящие о ваших навыках в многонитевом программировании.


Я отвечу там.

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




MSS>На этот скатывание во флейм можно остановить.




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 30.11.07 13:05
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>Единственая возможность сделать что-то нормальное на NUMA и современных многоядерных процессорах — VirtualAllocExNuma() — Windows Vista, Windows Server "Longhorn"


MSS>При чем тут NUMA? мы про SMP, а не про NUMA.



Все современные процессоры *будут* NUMA. Не в том плане, как суперкомпьютеры, а внутри одного процессора. Смотри последние процессоры от AMD. И новые разработки по северным мостам от Intel и AMD.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: multicore -- напоминает переход на Win32
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 13:07
Оценка:
Ну что я могу сказать... кто-то занимается разработкой, стыкуя готовые кусочки и обвешивая их скриптами типа Ruby.

А кто-то разрабатывает сами эти кусочки.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[3]: multicore -- напоминает переход на Win32
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.11.07 13:35
Оценка: -1
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Ну что я могу сказать... кто-то занимается разработкой, стыкуя готовые кусочки и обвешивая их скриптами типа Ruby.


MSS>А кто-то разрабатывает сами эти кусочки.


Вы повторили в точности мою мысль -- переход от Win16 к Win32 больше всего затронул тех, кто писал кусочки, из которых остальные стыковали что-то прикладное.
Переход от одноядерных процессоров к многоядерным приведет к тому же самому, т.е. реально заниматься многоядерностью будет совсем небольшой процент разработчиков, а остальные будут обвешивать готовые кусочки какими-то скриптами (и хорошо, если бы это был Ruby). Зато шуму от многоядерности столько, как будто программировать 80 ядер придется каждому второму.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Многопоточность сегодня - не от хорошей жизни
От: Трурль  
Дата: 30.11.07 13:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не умер закон Мура!!


А что будет, когда он умрет?
Re[4]: multicore -- напоминает переход на Win32
От: Кодёнок  
Дата: 30.11.07 13:55
Оценка:
Здравствуйте, eao197, Вы писали:

E>Вы повторили в точности мою мысль -- переход от Win16 к Win32 больше всего затронул тех, кто писал кусочки, из которых остальные стыковали что-то прикладное.

E>Переход от одноядерных процессоров к многоядерным приведет к тому же самому

Это с какой стати? Win16->Win32 это те же самые принципы, те же самые приемы, те же самые архитектурные решения (паттерны). А параллельное программирование — другое во всём.
Re[5]: multicore -- напоминает переход на Win32
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.11.07 14:10
Оценка:
Здравствуйте, Кодёнок, Вы писали:

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


E>>Вы повторили в точности мою мысль -- переход от Win16 к Win32 больше всего затронул тех, кто писал кусочки, из которых остальные стыковали что-то прикладное.

E>>Переход от одноядерных процессоров к многоядерным приведет к тому же самому

Кё>Это с какой стати? Win16->Win32 это те же самые принципы, те же самые приемы, те же самые архитектурные решения (паттерны). А параллельное программирование — другое во всём.


Параллельное программирование существует давно и успешно. OpenMP не сегодня появился, PVM и MPI уже очень давно используются в вычислительных задачах, решаемых на кластерах в сотни и тысячи машин, Erlang находится в промышленном использовании с середины 90-х годов. Web-приложения, в которых запросы обрабатываются тысячами параллельно работающих процессов -- уже давно не диковинка. Так что те, кому параллельное программирование было надо, давно им пользовались. И умели пользоваться, что характерно.

Не важно, насколько параллельное программирование отличается, важно какому проценту разработчиков оно реально нужно. Может быть здесь так же сработает закон потребления пива -- 80% разработчиков потребовуется всего лишь 20% возможностей новых многоядерных процессоров.

Тем более, что для массового потребления всю эту многоядерность завернут в какие-нибудь непрозрачные одежды, типа LINQ или параллельных модификаций STL. Станет в одночасье в C++ной программе std::sort или std::transform распараллеливаться на свободные ядра, а программист этого и не заметит.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Многопоточность сегодня
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 14:28
Оценка:
R>А ну если поддержкой многоядерности считать только возможность выполняться на нескольких аппаратных потоках и много локов, а не один. То пожалуйста. Я имел в виду, не теоритетическую возможность выполняться на нескольких аппаратных потоках, а *эффективную* работу.

Мой пойнт был в том, что в Windows NT было умение работать SMP с самого первого релиза, и по этому умению она в течение многих лет опережала (да и опережает поди) Linux и FreeBSD. Вполне возможно, что она и SunOS 5 опережала.

Весь мой пойнт подтвердился.

Что же касается эффективности — ну, не было до Висты вызовов, которые позволяли сделать финальную "полировочную" оптимизацию и выбрать последние 5%. Но базовые вещи — были, и зачастую их хватало.

R>Этот треш из 70-ых годов меня не интересует. Хотя, да, он позволяет работать на нескольких аппаратных потоках.


В огромном количестве случаев спинлок (который, кажется, еще и 60х годов, у Дейтела он описан, а Дейтел вроде как начало 70х) — лучше, чем наворочанные lock-free алгоритмы.

Причина проста. Практически любой lock-free — это 2 interlocked операции. Спинлок — они же. Есть, кстати, еще и queued spinlock, чуть умнее, и ничто не мешало его сделать в своем коде и до XP. Это по большому счету библиотечный объект "в себе", от ОС ему надо только KeRaiseIrql.

Недостаток спинлока только в пустопорожней растрате процессора в случае возникновения конкуренции. Недостаток lock-free — в некоторых случаях придется делать значительно больше, чем 2 interlocked операции. Lock-free не универсален, нет единого способа решения всех задач в стиле lock-free, и там придется пользоваться тем же спинлоком или мутексом.

FAST_MUTEX вырождается в спинлок при отсутствии конкуренции (что на "маленьком" локе, защищающем коротенький кусок кода, реально). Опять же всего 2 interlocked операции.

Так что я не думаю, что эти объекты есть треш.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[7]: Многопоточность сегодня
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 14:29
Оценка:
R>Все современные процессоры *будут* NUMA. Не в том плане, как суперкомпьютеры, а внутри одного процессора. Смотри последние процессоры от AMD. И новые разработки по северным мостам от Intel и AMD.

Верю. Только мое утверждение "SMP сделана в Windows полноценно с самого начала" — таки истинно.

Про NUMA на этих машинах тогда и не думал никто.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 30.11.07 15:05
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>А ну если поддержкой многоядерности считать только возможность выполняться на нескольких аппаратных потоках и много локов, а не один. То пожалуйста. Я имел в виду, не теоритетическую возможность выполняться на нескольких аппаратных потоках, а *эффективную* работу.


MSS>Мой пойнт был в том, что в Windows NT было умение работать SMP с самого первого релиза, и по этому умению она в течение многих лет опережала (да и опережает поди) Linux и FreeBSD. Вполне возможно, что она и SunOS 5 опережала.


MSS>Весь мой пойнт подтвердился.


Меня не очень интересует "номинальная возможность работать на SMP". Возможно, что я слишком молодой, что бы удивляться и радоваться таким вещам. Для меня такая номинальная поддержка кажется очевидной. Видимо поэтому мы и говорим о разном...



MSS>Что же касается эффективности — ну, не было до Висты вызовов, которые позволяли сделать финальную "полировочную" оптимизацию и выбрать последние 5%. Но базовые вещи — были, и зачастую их хватало.


Распределение памяти по узлам NUMA и эффективные примитивы синхронизации — 5%... если в программе не устранены боттлнеки в других местах, то и 5% может не набежать...


R>>Этот треш из 70-ых годов меня не интересует. Хотя, да, он позволяет работать на нескольких аппаратных потоках.


MSS>В огромном количестве случаев спинлок (который, кажется, еще и 60х годов, у Дейтела он описан, а Дейтел вроде как начало 70х) — лучше, чем наворочанные lock-free алгоритмы.


MSS>Причина проста. Практически любой lock-free — это 2 interlocked операции.


Ты говоришь о том, чего не знаешь.
Вопрос не в том, какое максимальное кол-во interlocked операций можно запихать в алгоритм. Я думаю, что достаточно легко написать lock-free алгоритм и с 100 interlocked операциями. Вопрос в том, какое *минимальное* кол-во interlocked операций может быть в том или ином алгоритме.
А минимальное кол-во interlocked операций обычно бывает от 2 до 0 (прописью: ноль). Ещё раз повторю: ноль interlocked операций в примитиве синхронизации.




MSS>Спинлок — они же. Есть, кстати, еще и queued spinlock, чуть умнее, и ничто не мешало его сделать в своем коде и до XP. Это по большому счету библиотечный объект "в себе", от ОС ему надо только KeRaiseIrql.


Если цель использования queued spinlock — уменьшить конкуренцию за кэш, то это не более чем затыкание дыр в кривом примитиве. Класс Wait-free алгоритмов создаёт минимально необходимую нагрузку на кэш и больше уменьшать или затыкать нечего.

Если цель использования queued spinlock — обеспечить честный порядок захвата, то это опять же затыкание дыр в кривом примитиве. Класс Lock-free алгоритмов всегда обеспечивает честный порядок.



MSS>Недостаток спинлока только в пустопорожней растрате процессора в случае возникновения конкуренции. Недостаток lock-free — в некоторых случаях придется делать значительно больше, чем 2 interlocked операции. Lock-free не универсален, нет единого способа решения всех задач в стиле lock-free, и там придется пользоваться тем же спинлоком или мутексом.


Так же как нет единого и универсального способа делать производительные сетевые сервера, организовывать структуру базы данных и т.д. и т.п.


MSS>FAST_MUTEX вырождается в спинлок при отсутствии конкуренции (что на "маленьком" локе, защищающем коротенький кусок кода, реально). Опять же всего 2 interlocked операции.


Если у тебя маленький кусочек кода, то лучше используй спин-мьютекс — это всего 1 interlocked операция. Можно добиться существенного повышения производительности. (и не в коем случае не используй reader-writer мьютекс)


MSS>Так что я не думаю, что эти объекты есть треш.


Так многие думают...




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 30.11.07 15:10
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>Все современные процессоры *будут* NUMA. Не в том плане, как суперкомпьютеры, а внутри одного процессора. Смотри последние процессоры от AMD. И новые разработки по северным мостам от Intel и AMD.


MSS>Верю. Только мое утверждение "SMP сделана в Windows полноценно с самого начала" — таки истинно.

MSS>Про NUMA на этих машинах тогда и не думал никто.


Я тебя не понял, т.к. ты отвечал на мой пост, который был совсем о другом.
Но тогда становится неверно твоё другое утверждение, что "Для системных программистов никакого перегиба развития нету", т.к. теперь об этих вещах *надо* думать. И только несколько лет назад некоторые разработчики Windows о них задумались.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: multicore -- напоминает переход на Win32
От: Maxim S. Shatskih Россия  
Дата: 30.11.07 15:11
Оценка:
E>Переход от одноядерных процессоров к многоядерным приведет к тому же самому, т.е. реально заниматься многоядерностью будет совсем небольшой процент разработчиков, а остальные будут обвешивать готовые кусочки какими-то скриптами (и хорошо, если бы это был Ruby). Зато шуму от многоядерности столько, как будто программировать 80 ядер придется каждому второму.

А кто шум-то разводит? только маркетологи Интела.

Системные программисты знали SMP еще в 90ые годы, и для них это не новость.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[5]: multicore -- напоминает переход на Win32
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.11.07 15:13
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

E>>Переход от одноядерных процессоров к многоядерным приведет к тому же самому, т.е. реально заниматься многоядерностью будет совсем небольшой процент разработчиков, а остальные будут обвешивать готовые кусочки какими-то скриптами (и хорошо, если бы это был Ruby). Зато шуму от многоядерности столько, как будто программировать 80 ядер придется каждому второму.


MSS>А кто шум-то разводит? только маркетологи Интела.


И участники Интернет-форумов. Смотрите, например, сколько людей только в этой теме засветилась. А ведь это и не первая тема про многоядерность только в Философии Программирования на RSDN.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Кстати
От: remark Россия http://www.1024cores.net/
Дата: 30.11.07 15:34
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>Все современные процессоры *будут* NUMA. Не в том плане, как суперкомпьютеры, а внутри одного процессора. Смотри последние процессоры от AMD. И новые разработки по северным мостам от Intel и AMD.


MSS>Верю. Только мое утверждение "SMP сделана в Windows полноценно с самого начала" — таки истинно.

MSS>Про NUMA на этих машинах тогда и не думал никто.


Я некоторое время назад попытался выяснить один вопрос на форуме MSDN:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2346495&amp;SiteID=1

За полтора месяца так никто ничего и не ответил и, видимо, уже не ответит. У тебя в профиле написано "Windows DDK MVP", может быть ты можешь пролить какой-то свет на этот вопрос, или посоветовать кого-нибудь, кто может пролить. А то я уж совсем обезнадёжился...

Судя по тому, что ты часто упоминаешь функции, начинающиеся с Ke, ты разбираешься в ядре.
Правильно ли я понимаю, что с портом завершения связана *одна* очередь сообщений, и с этими сообщениями не связан идентификатор процессора, с которого поступило данное сообщение? Т.е. при вызове GetQueuedCompletionStatus() ОС не может автоматически стараться распределять обработку сообщения на те же процессоры, на которых они были сгенерированы?

И в обратную сторону. Связан ли с IRP идентификатор процессора, на котором он был сгенерирован? И старается ли ОС распределять IRP на тот процессор, на котором он был сгенерирован? Там есть IRP.Tail.Overlay.Thread, но я так понимаю, что он для других целей.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 30.11.07 16:48
Оценка:
Здравствуйте, remark, Вы писали:

MSS>>Причина проста. Практически любой lock-free — это 2 interlocked операции.


R>Ты говоришь о том, чего не знаешь.

R>Вопрос не в том, какое максимальное кол-во interlocked операций можно запихать в алгоритм. Я думаю, что достаточно легко написать lock-free алгоритм и с 100 interlocked операциями. Вопрос в том, какое *минимальное* кол-во interlocked операций может быть в том или ином алгоритме.
R>А минимальное кол-во interlocked операций обычно бывает от 2 до 0 (прописью: ноль). Ещё раз повторю: ноль interlocked операций в примитиве синхронизации.


Как раз любой мьютекс — "это 2 interlocked операции". Одно из основных отличий lock-free алгоритмов — это то, что есть "непаханное поле" для различных "амортизаций", "оптимизаций" и т.д. lock-based алгоритмы нет смысла оптимизировать каким-либо образом, точнее нет возможности. Т.к. что бы что-либо сделать, надо вначале захватить мьютекс, а раз он уже всё равно захвачен, то далее нет смысла что-либо оптимизировать — надо просто быстрее "доделать работу" и отпускать мьютекс. Это — принципиальная ограниченность подхода.
При использовании lock-free подхода нет никакой "обязательной части", которую надо выполнить. Помимо всего прочего можно делать "что-то" не каждый раз, можно делать "что-то" только когда возведён какой-либо флаг, а что бы проверять флаг не надо никакой синхронизации и т.д. и т.п.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Кстати
От: Maxim S. Shatskih Россия  
Дата: 02.12.07 16:38
Оценка: 30 (1)
Выскажу несколько косвенных соображений, потому как актуальной информации (скажем, по Висте) о том, как это сделано внутри, у меня нет.

Если у нити не задана affinity, то все это суть бессмыслица. Ее перекинут на другой CPU между практически любыми двумя опкодами (на < DISPATCH_LEVEL, понятно).

Таким образом, любое понятие current CPU в этом случае суть эдакая гейзенберговщина, значение, которое можно померять, но оно через микросекунду может измениться, и потому бессмысленно.

Я вообще не припоминаю в Win32 вызова "получить номер текущего процессора". В ядре он есть, но в ядре и DISPATCH_LEVEL есть, т.е. временный запрет преемптивности на текущем CPU. В Win32 этого нет.

Таким образом, чтобы сделать такую привязку к процессору, нужно в IRPе тащить за собой affinity нити, которая его создала. В принципе можно вместо этого использовать affinity нити напрямую через Tail.Overlay.Thread, но ассоциация, заданная этим полем, рвется в момент помещения IRPа в очередь IOCP при его завершении, т.е. с этого момента Tail.Overlay.Thread есть junk.

Я не помню в IRPе поля affinity. Структура — публичная. Можете посмотреть и сделать вывод о том, есть ли оно там.

Также я не помню ничего связанного с affinity в параметрах создания IOCP или file object.

Похоже, что этого нет. То есть — если вам нужна привязка завершения IRPа к CPU, то либо используйте другие механизмы завершения — OVERLAPPED::hEvent или Read/WriteFileEx и user APC, либо же _создайте по одному IOCP на процессор_ (и, конечно, по одному file object га процессор). Сделать последнее не так и сложно.

R>Правильно ли я понимаю, что с портом завершения связана *одна* очередь сообщений, и с этими сообщениями не связан идентификатор процессора, с которого поступило данное сообщение?


В NT4 точно была одна, дальше не знаю.

В очереди IOCP лежат именно IRPs (зацеплены за Tail.Overlay.ListEntry), а я не припоминаю такого поля (CpuId или Affinity) в IRPе.

R>Т.е. при вызове GetQueuedCompletionStatus() ОС не может автоматически стараться распределять обработку сообщения на те же процессоры, на которых они были сгенерированы?


Если в IRPе нет идентификатора CPU, и также его нет в параметрах создания IOCP — то это, понятно, невозможно.

R>И в обратную сторону. Связан ли с IRP идентификатор процессора, на котором он был сгенерирован?


А где? структура-то публичная. Где он там, в каком поле?

R>И старается ли ОС распределять IRP на тот процессор, на котором он был сгенерирован?


Если нет поля — то, значит, невозможно это.

R>Там есть IRP.Tail.Overlay.Thread, но я так понимаю, что он для других целей.


Ага. Кстати, когда IRP попал в IOCP, оно уже junk — т.е. нет гарантии, что эта нить не умерла сразу после.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[3]: Многопоточность сегодня - не от хорошей жизни
От: minorlogic Украина  
Дата: 06.12.07 07:38
Оценка:
Закон мура в любом случае упрется в скорость света. Разве что в физике будет прорыв значительный.

Посему наращивание паралельности нас ждет полюбому.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[9]: [ANN] Task Parallel Library (Parallel Extensions to .
От: remark Россия http://www.1024cores.net/
Дата: 06.12.07 08:33
Оценка:
Здравствуйте, remark, Вы писали:

AF>>Кстати, а когда TPL обещают в публичном доступе, неизвестно?


R>Вместе с .NET 4.0 видимо...



[ANN] Task Parallel Library (Parallel Extensions to .NET)
Автор: remark
Дата: 06.12.07



R>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: Кстати
От: remark Россия http://www.1024cores.net/
Дата: 06.12.07 14:13
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Выскажу несколько косвенных соображений, потому как актуальной информации (скажем, по Висте) о том, как это сделано внутри, у меня нет.


MSS>Если у нити не задана affinity, то все это суть бессмыслица. Ее перекинут на другой CPU между практически любыми двумя опкодами (на < DISPATCH_LEVEL, понятно).


MSS>Таким образом, любое понятие current CPU в этом случае суть эдакая гейзенберговщина, значение, которое можно померять, но оно через микросекунду может измениться, и потому бессмысленно.


MSS>Я вообще не припоминаю в Win32 вызова "получить номер текущего процессора". В ядре он есть, но в ядре и DISPATCH_LEVEL есть, т.е. временный запрет преемптивности на текущем CPU. В Win32 этого нет.



В Win32 это GetCurrentProcessorNumber(). В Linux это numa_node_id(), либо ещё какой-то вызов в юзер спейс недавно сделали — не помню точно.
Ну в целом, да, это "гейзенберговщина". Но тем не менее используется относительно широко для различных оптимизаций. Например можно структуру данных партицировать по процессорам и защитить таблицей из мьютексов, и блокировать мьютексом всегда ту, которая = GetCurrentProcessorNumber(). В подавляющем большинстве случаев всё будет замечательно — с каждым мьютексом работают только с одного процессора. Ну а если произошло переключение — не страшно — всё равно это мьютекс.

В данном случае с сокетом такая оптимизация тоже бы подошла — т.е. стараемся работать с локальными данными, но если и произошло переключение контекста — не страшно. Но далее предположим, что даже есть строгая affinity. Т.е. всегда можно точно сказать на каком процессоре работаем.



MSS>Таким образом, чтобы сделать такую привязку к процессору, нужно в IRPе тащить за собой affinity нити, которая его создала. В принципе можно вместо этого использовать affinity нити напрямую через Tail.Overlay.Thread, но ассоциация, заданная этим полем, рвется в момент помещения IRPа в очередь IOCP при его завершении, т.е. с этого момента Tail.Overlay.Thread есть junk.


MSS>Я не помню в IRPе поля affinity. Структура — публичная. Можете посмотреть и сделать вывод о том, есть ли оно там.


MSS>Также я не помню ничего связанного с affinity в параметрах создания IOCP или file object.


MSS>Похоже, что этого нет. То есть — если вам нужна привязка завершения IRPа к CPU, то либо используйте другие механизмы завершения — OVERLAPPED::hEvent или Read/WriteFileEx и user APC, либо же _создайте по одному IOCP на процессор_ (и, конечно, по одному file object га процессор). Сделать последнее не так и сложно.


R>>Правильно ли я понимаю, что с портом завершения связана *одна* очередь сообщений, и с этими сообщениями не связан идентификатор процессора, с которого поступило данное сообщение?


MSS>В NT4 точно была одна, дальше не знаю.


MSS>В очереди IOCP лежат именно IRPs (зацеплены за Tail.Overlay.ListEntry), а я не припоминаю такого поля (CpuId или Affinity) в IRPе.


R>>Т.е. при вызове GetQueuedCompletionStatus() ОС не может автоматически стараться распределять обработку сообщения на те же процессоры, на которых они были сгенерированы?


MSS>Если в IRPе нет идентификатора CPU, и также его нет в параметрах создания IOCP — то это, понятно, невозможно.


R>>И в обратную сторону. Связан ли с IRP идентификатор процессора, на котором он был сгенерирован?


MSS>А где? структура-то публичная. Где он там, в каком поле?


R>>И старается ли ОС распределять IRP на тот процессор, на котором он был сгенерирован?


MSS>Если нет поля — то, значит, невозможно это.


R>>Там есть IRP.Tail.Overlay.Thread, но я так понимаю, что он для других целей.


MSS>Ага. Кстати, когда IRP попал в IOCP, оно уже junk — т.е. нет гарантии, что эта нить не умерла сразу после.



Так хорошо. Первый вывод такой, что автоматически Win32 такого сделать просто не может.

По поводу "OVERLAPPED::hEvent или Read/WriteFileEx и user APC, либо же _создайте по одному IOCP на процессор_ (и, конечно, по одному file object га процессор)".

OVERLAPPED::hEvent и Read/WriteFileEx+APC позволят работать с одним сокетом из разных потоков, но при этом направлять Completion Notification на тот же процессор, откуда был инициирован запрос. Но основной вопрос — будет ли ОС стараться обрабатывать запрос на том же процессоре? Если она не будет это делать, то пропадает смысл и обрабатывать завершение там же, откуда был запрос...

Один IOCP на процессор + один file object на процессор в принципе тоже приемлимый вариант, в том плане, что наврядли всё равно надо работать с одним сокетом из разных потоков. Если на запись ещё можно сообщения "сливать", то на чтение получится мешанина.
Но тот же вопрос остаётся — а имеет ли это какой-то смысл? Т.е. как заставить ОС сделать "аффинити сокета/порта завершения на процессор"?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Кстати
От: Maxim S. Shatskih Россия  
Дата: 06.12.07 18:26
Оценка: 20 (1)
R>OVERLAPPED::hEvent и Read/WriteFileEx+APC позволят работать с одним сокетом из разных потоков, но при этом направлять Completion Notification на тот же процессор, откуда был инициирован запрос. Но основной вопрос — будет ли ОС стараться обрабатывать запрос на том же процессоре? Если она не будет это делать, то пропадает смысл и обрабатывать завершение там же, откуда был запрос...

Dispatch routine в AFD.SYS исполняется в контексте юзер нити, если у нее стоит affinity — то да, есть гарантия процессора.

IopCompleteRequest опять исполняется в той же нити, опять гарантия процессора.

Все остальное, что между — это bottom half, говоря языком Линукса. Это вызовы, инициированные снизу из TCPIP — типа ClientEventReceive. Контекст этих вызовов прослеживается аж до ndisMDpc, которая зовется на том же CPU, что и прерывание от сетевой карты. А вот это может быть совсем не тот процессор, что у юзерской нити.

R> Если на запись ещё можно сообщения "сливать", то на чтение получится мешанина.


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

Но а) socket read совсем не обязательно полностью заполняет весь запрошенный размер, что делает слияние таких данных тяжелой задачей б) про несколько нитей вы правы, неизвестно, какая первой добежит до лока, защищающего очередь в AFD.

R>Но тот же вопрос остаётся — а имеет ли это какой-то смысл? Т.е. как заставить ОС сделать "аффинити сокета/порта завершения на процессор"?


Можно только об аффинити нити говорить.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[12]: Кстати
От: remark Россия http://www.1024cores.net/
Дата: 10.12.07 10:07
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>OVERLAPPED::hEvent и Read/WriteFileEx+APC позволят работать с одним сокетом из разных потоков, но при этом направлять Completion Notification на тот же процессор, откуда был инициирован запрос. Но основной вопрос — будет ли ОС стараться обрабатывать запрос на том же процессоре? Если она не будет это делать, то пропадает смысл и обрабатывать завершение там же, откуда был запрос...


MSS>Dispatch routine в AFD.SYS исполняется в контексте юзер нити, если у нее стоит affinity — то да, есть гарантия процессора.


MSS>IopCompleteRequest опять исполняется в той же нити, опять гарантия процессора.


MSS>Все остальное, что между — это bottom half, говоря языком Линукса. Это вызовы, инициированные снизу из TCPIP — типа ClientEventReceive. Контекст этих вызовов прослеживается аж до ndisMDpc, которая зовется на том же CPU, что и прерывание от сетевой карты. А вот это может быть совсем не тот процессор, что у юзерской нити.



Т.е. облом
Интересна как раз "нижняя половина", которая непосредственно "трогает" данные, а не "верхняя половина", которая просто передаёт указатель.




R>>Но тот же вопрос остаётся — а имеет ли это какой-то смысл? Т.е. как заставить ОС сделать "аффинити сокета/порта завершения на процессор"?


MSS>Можно только об аффинити нити говорить.



Это я условно так обозвал то, чего я хочу добиться.

Кстати, Intel в пресс-релизе по Nehalem здесь говорит:

Improved addressing for interrupts with xAPIC capability

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


Слушай, а может ответ даст старое доброе блокирующее АПИ (send/recv)?
На recv, правда, всё равно надежды нет, т.к. прерывание от сетевой карты не сможет обработаться на нужном ядре.
А вот на блокирующий send есть некоторая надежда. Я тут вижу 2 возможных варианта реализации:
Хороший: ОС сделает всю работу, включая копирование/отправку непосредственно в сетевую карту, на пользовательской нити.
Плохой: на пользовательской нити ОС только создаст и положит в очередь IRP, а далее заблокирует этот поток, пока IRP не будет обработан. Реальную же работу будет делать рабочий поток ОС, возможно на другом ядре.
Ты не в курсе, как это происходит в реальности при блокирующем send()?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность сегодня - не от хорошей жизни
От: Pavel Dvorkin Россия  
Дата: 11.12.07 05:39
Оценка:
Здравствуйте, remark, Вы писали:

Извини, что не ответил вовремя. Забыл...

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


Начал над этим замечанием думать, и вот что мне не совсем ясно.

Предположим, два процессора строго одновременно пытаются модифицировать одну и ту же ячейку ОП. Для простоты будем считать, что кэша нет вообще. Что будет ?
Насколько я понимаю (поправьте, если я не прав), память в любой момент может изменять только одно значение. Т.е. эти запросы от процессоров как-то сериализуются на памяти (на шине ?) В итоге будет вначале выполнено одно присваивание, а потом второе. Результат, конечно, непредсказуем. Так или нет ? Во всяком случае, об аппаратных мютексах на память я ничего не слышал

Если так, то при наличии кэша ничего не меняется. Процессор A пытается записать в память. Это приведет либо к изменению значения в кэше (если там этот адрес уже был), либо к изгнанию кого-то из кэша и записи нового (если не было). Процессор B делает то же самое. Кэш-память (в моем варианте, то есть одна на все процессоры) сериализует эти запросы, результат непредсказуем, ну и что ? Забота синхронизации хоть на ОП. хоть на кэше — дело софта, а не процессора.


>Во-вторых, кэш *обязан* быть близко к процессору, в этом его первостипенное предназначение. А как разместить общий кэш близко ко всем ядрам — не понятно.


Близко — в чем ? В миллиметрах ? Так вроде скорости света пока что хватает ...




R>>>Что такое "по своей сути" — сложно сказать...


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


R>А чем "грубая сила" плоха? Взяли матрицу и подели по строкам (по столбцам, по блокам, в шахматном порядке), и рассчитываем параллельно.

R>Итерационный — это алгоритм, а в конечном итоге нам всегда надо решить задачу, а не алгоритм. А у задачи может быть несколько алгоритмов решения. Например, есть алгоритмы сортировки, наиболее оптимальные для последовательного вычисления, но при распараллеливании обычно берут немного более плохой с т.з. вычислительной сложности алгоритм, но который зато легко и "естественно" разделяется на независимые подзадачи.

R>Кстати, если интересно, пример *задачи*, которая не поддаётся распараллеливанию (текущими математическими методами) — посчитать:

R>(2^(2^t)) (mod n*p)
R>где n и p — произвольные большие простые числа, t — произвольное число
R>(т.н. MIT LCS35 Time Capsule Crypto-Puzzle)


R>
With best regards
Pavel Dvorkin
Re[6]: Многопоточность сегодня - не от хорошей жизни
От: Left2 Украина  
Дата: 11.12.07 12:51
Оценка: 1 (1)
>>Во-вторых, кэш *обязан* быть близко к процессору, в этом его первостипенное предназначение. А как разместить общий кэш близко ко всем ядрам — не понятно.
PD>Близко — в чем ? В миллиметрах ? Так вроде скорости света пока что хватает ...
Не хватает. Несложный подсчёт показывает что за 1 такт 3-гц процессора свет проходит расстояние в 10 см. Это свет и это в вакууме. В реальных условиях скорость распространения сигналов внутри микросхем на порядок меньше скорости света. Так что даже вынесение кэш памяти на несколько миллиметров от процессора очень существенно влияет на тайминги.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[13]: Кстати
От: Maxim S. Shatskih Россия  
Дата: 11.12.07 17:15
Оценка:
R>Интересна как раз "нижняя половина", которая непосредственно "трогает" данные, а не "верхняя половина", которая просто передаёт указатель.

Что значит "трогает данные"? в современном TCP стеке данные вообще никто не трогает, кроме копирования в буфера AFD при ненулевом значении SO_SNDBUF.

Данные трогает только чип сетевой карты, он же и контрольные суммы считает.

R>Возможно, это как раз даст возможность более правильно направлять прерывания по нужным ядрам. Правда, что конкретно это значит — непонятно. И на уровне TCP соединений, всё равно эта штука не сможет разруливать прерывания от сетевой карты...


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

R>Хороший: ОС сделает всю работу, включая копирование/отправку непосредственно в сетевую карту, на пользовательской нити.


Копировать уже ничего не надо, если SO_SNDBUF в нуле стоит. В этой ситуации send() есть то же самое, что TDI_SEND, а TDI_SEND при правильном состоянии TCP позовет из себя NdisSend и далее MiniportSend.

R>Ты не в курсе, как это происходит в реальности при блокирующем send()?


SO_SNDBUF в виндах реализован (в AFD) вот как:
— есть счетчик числа байт, ныне находящихся внутри TDI транспорта, и еще не переданных.
— перед каждым TDI_SEND счетчик увеличивается, в send completion — уменьшается.
— если этот счетчик меньше значению SO_SNDBUF, то при приходе сверху send IRP аллоцируется временный буфер, копируются туда данные, этот временный буфер уезжает вниз в TDI_SEND со вторым IRPом, а send завершается немедленно. Send completion для TDI_SEND уменьшает счетчик и убивает буфер. Все.
— если же счетчик >= SO_SNDBUF, то тогда никаких временных буферов не делается, и каждый send исполняется как TDI_SEND, не помню только, на этом же IRPе или второй аллоцируется.

TDI_SEND у нас верхний край к TCP, между TCP и AFD. Внутри TCP никакие данные никогда никуда не копируются. Если учесть это в сочетании с тем, что могут потребоваться ретрансмиты — то становится ясно, что TDI_SEND может быть завершен только тогда, когда на эту порцию данных пришли все ACKи (ретрансмиты делаются из буфера в самом же TDI_SEND IRP). Что и делается.

Мы получаем вот что: если поставить SO_SNDBUF в нуль, то каждый send() есть TDI_SEND, и возвращает управление только после того, как придут все ACKи на эту порцию. Это накладывает связанные с производительностью ограничения на то, как можно звать send() при этом, но зато нет ни одного копирования данных от user buffer до DMA сетевой карты.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[14]: Кстати
От: remark Россия http://www.1024cores.net/
Дата: 11.12.07 22:33
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>Интересна как раз "нижняя половина", которая непосредственно "трогает" данные, а не "верхняя половина", которая просто передаёт указатель.


MSS>Что значит "трогает данные"? в современном TCP стеке данные вообще никто не трогает, кроме копирования в буфера AFD при ненулевом значении SO_SNDBUF.


MSS>Данные трогает только чип сетевой карты, он же и контрольные суммы считает.



А если отвлечься от всяких IRP и SNDBUF, мой вопрос вообще имеет смысл?
Сейчас насколько распространена поддержка полного tcp offloading включая подсчёт/проверку контрольной суммы? Я, честно говоря, считал, что сейчас лишь небольшой процент (из не дешёвых) сетевых карт поддерживает полный tcp offloading. А если он сейчас является нормой, и процессор не трогает данные, то может и нет смысла думать, о чём я думаю?

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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[15]: Кстати
От: Maxim S. Shatskih Россия  
Дата: 12.12.07 12:08
Оценка:
R>Сейчас насколько распространена поддержка полного tcp offloading включая подсчёт/проверку контрольной суммы?

Контрольные суммы — это далеко не полный TCP offloading, это как раз его простейшая версия.

R>Я, честно говоря, считал, что сейчас лишь небольшой процент (из не дешёвых) сетевых карт поддерживает полный tcp offloading.


Контрольные суммы умеют считать любые гигабитные чипы, даже интеловская карточка образца 2005 года за 850 рублей

Вот полный оффлоадинг, который есть оффлоадинг стейт-машин — это у нас Chimney, это у нас только появилось в Висте.

R>А если он сейчас является нормой, и процессор не трогает данные, то может и нет смысла думать, о чём я думаю?


Не знаю.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[6]: Многопоточность сегодня - не от хорошей жизни
От: remark Россия http://www.1024cores.net/
Дата: 13.12.07 14:28
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>Извини, что не ответил вовремя. Забыл...


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


PD>Начал над этим замечанием думать, и вот что мне не совсем ясно.


PD>Предположим, два процессора строго одновременно пытаются модифицировать одну и ту же ячейку ОП. Для простоты будем считать, что кэша нет вообще. Что будет ?

PD>Насколько я понимаю (поправьте, если я не прав), память в любой момент может изменять только одно значение. Т.е. эти запросы от процессоров как-то сериализуются на памяти (на шине ?) В итоге будет вначале выполнено одно присваивание, а потом второе. Результат, конечно, непредсказуем. Так или нет ? Во всяком случае, об аппаратных мютексах на память я ничего не слышал


Да. Всё правильно. Шина доступа к памяти сериализует все запросы. Т.к. в один момент времени по ней может быть передан только один запрос.


PD>Если так, то при наличии кэша ничего не меняется. Процессор A пытается записать в память. Это приведет либо к изменению значения в кэше (если там этот адрес уже был), либо к изгнанию кого-то из кэша и записи нового (если не было). Процессор B делает то же самое. Кэш-память (в моем варианте, то есть одна на все процессоры) сериализует эти запросы, результат непредсказуем, ну и что ? Забота синхронизации хоть на ОП. хоть на кэше — дело софта, а не процессора.



Ключевые слова — "сериализует" и "синхронизации". Это очень плохие слова для производительности и масштабируемости.
В целом такой подход имеет смысл и место. Кэш третьего уровня зачастую так и делают — один на все процессоры/ядра. В скором будущем можно ожидать появления кэшей третьего уровня, встроенных в массовые процессоры. В них тоже скорее всего будет применяться тот же подход.
Однако с кэшем второго уровня ситуация становится сложнее. Для него уже полная централизация и синхронизация могут быть губительными. Сейчас кэш второго уровня делают либо один на ядро, либо один на два ядра. В принципе в полуэкспериментальных процессорах, типа Tile64, применяют следующий подход. Каждое ядро имеет свой физический кэш второго уровня, но все они объединены в один большой логический кэш, который доступен всем ядрам. Но опять же это не отменяет необходимости в протоколах когерентности кэшей и on-chip network.
Касательно кэша первого уровня нет никаких намёков и желаний объединять их. Кэш первого уровня остаётся полностью приватным для ядра. Благодаря этому он обеспечивает латентность доступа порядка нескольких тактов.
Не упускай из вида так же тот момент, что работу с разделяемыми переменными всё же можно назвать не основной работой для ядра. Основная работа всё же остаётся работа с локальными данными. И именно тут надо обеспечивать максимальную производительность. Разделяемый кэш как раз и даёт эту ассиметрию. Работа с локальными данными быстрее на порядок, но работа с разделяемыми данными становится медленнее.
Если тебе интересна эта тема, то за более детальной можешь обращаться сюда: comp.arch


>>Во-вторых, кэш *обязан* быть близко к процессору, в этом его первостипенное предназначение. А как разместить общий кэш близко ко всем ядрам — не понятно.


PD>Близко — в чем ? В миллиметрах ? Так вроде скорости света пока что хватает ...



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


R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Многопоточность сегодня
От: kirilloid *nick*.ru
Дата: 17.12.07 11:07
Оценка:
Здравствуйте, remark, Вы писали:

R>Да, этим грешит большинство библиотек.

R>Хотя вот насколько помню в OCI (Oracle call interface) в самую первую функцию инициализации можно передать указатели на функции аллокации/освобождения памяти. Приятно.

Такие монолитные монстры, как Oracle могут себе это позволить.
"Поэт витиеватых алгоритмов" © ZAMUNDA
Re: Fork/Join
От: remark Россия http://www.1024cores.net/
Дата: 16.02.08 13:33
Оценка: 65 (9)
Здравствуйте, remark, Вы писали:

R>Естественно могут иметь место и частные случаи. Например, приложение по обработке изображений или CAD/CAM/CAE/CASE. Тут скорее всего имеет смысл эффективно распараллеливать только одну основную функцию, например, обработку изображения, или рассчёт параметров модели (все остальные функции — графический интерфейс, фоновые задачи — по прежнему могут быть реализованы по старым принципам). Тут сейчас ситуация обстоит немного лучше. Тут (и только тут) на помощь могут придти такие средства как OpenMP, RapidMind, Intel TBB, Java Fork/Join и тд.:

R>www.openmp.org
R>www.rapidmind.com
R>osstbb.intel.com
R>gee.cs.oswego.edu/dl/papers/fj.pdf


[изначально я запостил это в cpp.applied, но думаю, что место этому здесь]


Что такое Fork/Join. И с чем его едят.


Fork/Join сейчас является одной из самых распространённых методик для построения параллельных алгоритмов. Так же его называют параллельным Divide&Conquer (разделяй и властвуй).
Идея следующая. Большая задача разделяется на несколько меньших. Потом эти ещё деляться на меньшие. И так до тех пор, пока задача не становится тривиальной, тогда она решается последовательным методом. Этот этап называется Fork. Далее [опционально] идёт процесс "свёртки", когда решения маленьких задач объединяются некоторым образом пока не получится решение самой верхней задачи. Этот этап называется Join. Решения всех подзадач (в т.ч. и разбиений на меньшие задачи) происходит параллельно. В принципе для решения некоторых задач этап Join не требуется. Например, для параллельного QuickSort — тут мы просто рекурсивно делим массив на всё меньшие и меньшие диапазоны, пока не дойдём до тривиального случая из 1 элемента. Хотя в некотором смысле Join нужен и тут, т.к. нам всё равно надо дождаться пока не закончится обработка всех подзадач.

Что поглядеть. Не буду ходить очень далеко в прошлое или вдаваться в теорию.

Cilk

Расширение для языка С. Реализовано в виде препроцессора и небольшого ран-тайм. Появилось в первой половине 90-х, активно развивалось до 2000, сейчас находится в стабильной версии. Одна из самых эффективных библиотек для параллельного программирования.
Самый любимый алгоритм, который реализовывают и на котором меряются пиписьками, создатели параллельных систем — рассчёт N-ого числа Фибоначи методом грубой силы. Вот пример на Cilk:

cilk int fib (int n)
{
 if (n<2)
  return n;
 else
 {
  int x, y;
  x = spawn fib (n-1); // fork
  y = spawn fib (n-2); // fork
  sync;  // join
  return (x+y);
 }
}

cilk int main (int argc, char *argv[])
{
 int n, result;
 n = atoi(argv[1]);
 result = spawn fib(n); // fork
 sync; // join
 printf ("Result: %d\n", result);
 return 0;
}


Собственно Fork/Join схема — это единственная схема, возможная в Cilk. Т.е. авторы сделали ставку исключительно на эту модель.

Подроднее здесь:
The Cilk Project
Cilk Papers
Cilk 5.4.6 Reference Manual
Качать здесь:
http://supertech.csail.mit.edu/cilk/cilk-5.4.6.tar.gz

Сейчас на основе Cilk разработан JCilk (соотв. для Java) и Cilk++ (для С++).
JCilk


Java Fork/Join Framework

Разработана Doug Lea (который сделал dlmalloc). АФАИК Является пропоузалом для включения в спецификацию Ява (возможно уже включён — не слежу). Единственный вид параллелизма — тоже только Fork/Join.

Подроднее здесь:
Java Fork/Join Framework
Качать здесь:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/current/concurrent.tar.gz
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/current/concurrent.zip

Пример Фибоначи:

class Fib extends FJTask {
 static final int threshold = 13;
 volatile int number; // arg/result
 Fib(int n) { number = n; }
 int getAnswer() {
  if (!isDone())
  throw new IllegalStateException();
  return number;
 }
 public void run() {
  int n = number;
  if (n <= threshold) // granularity ctl
   number = seqFib(n);
  else {
   Fib f1 = new Fib(n − 1); // fork
   Fib f2 = new Fib(n − 2); // fork
   coInvoke(f1, f2);
   number = f1.number + f2.number; // join
  }
 }

 public static void main(String[] args) {
  try {
   int groupSize = 2; // for example
   FJTaskRunnerGroup group =
    new FJTaskRunnerGroup(groupSize);
   Fib f = new Fib(35); // for example
   group.invoke(f);
   int result = f.getAnswer();
   System.out.println("Answer: " + result);
  }
  catch (InterruptedException ex) {}
 }

 int seqFib(int n) {
  if (n <= 1) return n;
  else return seqFib(n−1) + seqFib(n−2);
 }
}



Task Parallel Library (Parallel Extensions to .NET)

Это соотв. параллельные расширения для .NET. Тут уже возможена не только Fork/Join схема, но параллельность по данным и общая параллельность по задачам.

Подроднее здесь:
Optimize Managed Code For Multi-Core Machines
[ANN] Task Parallel Library (Parallel Extensions to .NET)
Автор: remark
Дата: 06.12.07

Качать здесь:
http://www.microsoft.com/downloads/details.aspx?FamilyID=e848dc1d-5be3-4941-8705-024bc7f180ba&amp;displaylang=en

К сожалению примера Фибаначи не прилагается, но выглядел бы он примерно так же. Вот коротенький пример:
override int Sum()
{   
   if (depth < 10) return SeqSum();
 
   Task<int> l = new Task<int>( left.Sum );  // fork
   int r         = right.Sum();
   return (r + l.Value);  // join
}



Intel Threading Building Blocks

Опять библиотека для С++. Опен сорц. Так же как и Task Parallel Library помимо Fork/Join так же предоставляет параллельность по данным и общая параллельность по задачам.

Подроднее здесь:
TBB Home
TBB Overview
TBB Code Samples
Качать здесь:
http://threadingbuildingblocks.org/file.php?fid=77

Вот пример суммирования значений в дереве с помощью Fork/Join:

class SimpleSumTask: public tbb::task {
    Value* const sum;
    TreeNode* root;
public:
    SimpleSumTask( TreeNode* root_, Value* sum_ ) : root(root_), sum(sum_) {}
    task* execute() {
        if( root->node_count<1000 ) { // trivial case
            *sum = SerialSumTree(root);
        } else {
            Value x, y;
            int count = 1; 
            tbb::task_list list;
            if( root->left ) {
                ++count;
                list.push_back( *new( allocate_child() ) SimpleSumTask(root->left,&x) );
            }
            if( root->right ) {
                ++count;
                list.push_back( *new( allocate_child() ) SimpleSumTask(root->right,&y) );
            }
            // Argument to set_ref_count is one more than size of the list,
            // because spawn_and_wait_for_all expects an augmented ref_count.
            set_ref_count(count);
            spawn_and_wait_for_all(list); // fork&join
            *sum = root->value;
            if( root->left ) *sum += x;
            if( root->right ) *sum += y;
        }
        return NULL;
    }
};

Value SimpleParallelSumTree( TreeNode* root ) {
    Value sum;
    SimpleSumTask& a = *new(tbb::task::allocate_root()) SimpleSumTask(root,&sum);
    tbb::task::spawn_root_and_wait(a); // fork&join
    return sum;
}




Несмотря на то, что Task Parallel Library и Intel Threading Building Blocks предоставляют так же возможность создания алгоритмов с параллелизмом по данным и с общим параллелизмом по задачам, фактически это просто надстройки над Fork/Join. Параллелизм по данным реализуется как одноразовый неявный Fork нескольких подзадач и потом неявный Join. Параллельность по задачам — это просто Fork без Join.


Надеюсь вопросов, что такое Fork/Join больше не осталось


R>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Fork/Join
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.02.08 15:16
Оценка: 25 (2)
Здравствуйте, remark, Вы писали:

R>Cilk

R>Java Fork/Join Framework
R>Task Parallel Library (Parallel Extensions to .NET)
R>Intel Threading Building Blocks

Складывается впечатление, что JoCaml из этой же оперы.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Fork/Join
От: remark Россия http://www.1024cores.net/
Дата: 16.02.08 16:06
Оценка:
Здравствуйте, eao197, Вы писали:

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


R>>Cilk

R>>Java Fork/Join Framework
R>>Task Parallel Library (Parallel Extensions to .NET)
R>>Intel Threading Building Blocks

E>Складывается впечатление, что JoCaml из этой же оперы.



Вообще, ты знаешь, у меня складывается впечатление, что есть 2 разные вещи. Первая — то, что я назвал Fork/Join. Вторая — Join-calculus.
Первая — это Cilk и все его последователи. Что формально он из себя представляет хорошо описал Doug Lea:

...problems are solved by
(recursively) splitting them into subtasks that are solved in
parallel, waiting for them to complete, and then composing
results.
...
Fork/join algorithms are parallel versions of familiar divide−
and−conquer algorithms, taking the typical form:
Result solve(Problem problem) {
if (problem is small)
directly solve problem
else {
split problem into independent parts
fork new subtasks to solve each part
join all subtasks
compose result from subresults
}
}

Отсюда

Вторая — это "Си Омега", Jo&Caml и иже с ними.
Проблема в том, что я, как инженер, очень туго понимаю такие вещи:
http://moscova.inria.fr/~maranget/papers/pat/pat002.html
Возможно они говоят о и том же, я просто не могу понять о чём они вообще говорят. Но что-то мне подсказывает, что это немного другое.
Что то в таком духе. Описываем функцию. Описываем для неё условия "срабатывания" (т.е. когда она должна быть вызвана). Условия записываются в виде набора сообщений, которые должны поступить, сообщения можно объединять по "и", по "или", по "вслед за", по "перед" и т.д. Когда приходит заданная "последовательность" сообщений автоматически вызывается функция, в которую передаются пришедшие сообщения.

Т.е. первый вариант — это параллельный divide-and-conquer, второй — параллельный pattern-matching.
Первый — больше подходит для описания вычислительных алгоритмов. Второй — для описания асинхронных распределенных систем.
У меня пока складывается такое впечатление. Присутствие слова "Join" и там и там, конечно, немного путает...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Многопоточность сегодня
От: VEAPUK  
Дата: 17.02.08 17:44
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


ZEN>>>Но всё это костыли. Если всё рабочее окружение отправить в своп, а при загрузке компьютера оотуда всё доставать в оперативку...

AVK>>В Windows это называется hibernate. К сожалению, при современных объемах оперативки и скоростях винтов это не очень быстро.
CC>На 3 гб и обычном SATA2 венике hibernate занимает секунд 5
600 МБ/сек
CC>ВСЯ память будет записана только если она ВСЯ занята.
CC>Обычно пишется только реально занятые участки минус кэш
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Многопоточность сегодня
От: CreatorCray  
Дата: 17.02.08 20:32
Оценка:
Здравствуйте, VEAPUK, Вы писали:

CC>>На 3 гб и обычном SATA2 венике hibernate занимает секунд 5

VEA>600 МБ/сек
Читаем внимательно:
CC>>ВСЯ память будет записана только если она ВСЯ занята.
CC>>Обычно пишется только реально занятые участки минус кэш
Все 3 гига будут записаны только если они все заняты
Поэтому в большинстве случаев получается быстрее
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Многопоточность сегодня
От: Cyberax Марс  
Дата: 17.02.08 20:39
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

CC>На 3 гб и обычном SATA2 венике hibernate занимает секунд 5

CC>ВСЯ память будет записана только если она ВСЯ занята.
CC>Обычно пишется только реально занятые участки минус кэш
И еще, вдобавок, сжимают при записи. А дампы памяти сжимаются весьма неплохо.
Sapienti sat!
Re[10]: Многопоточность сегодня
От: VEAPUK  
Дата: 17.02.08 21:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


CC>>>На 3 гб и обычном SATA2 венике hibernate занимает секунд 5

VEA>>600 МБ/сек
CC>Читаем внимательно:
CC>CC>>ВСЯ память будет записана только если она ВСЯ занята.
CC>CC>>Обычно пишется только реально занятые участки минус кэш
CC>Все 3 гига будут записаны только если они все заняты
CC>Поэтому в большинстве случаев получается быстрее
Я прекрасно вижу, но реальная скорость записи на блины 150Мб/сек — предел для САТА2 7200, если ошибаюсь, то поправьте.
Итого, в среднем, из 3 гб занято 750 Мб — денег девать не куда?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Многопоточность сегодня
От: CreatorCray  
Дата: 18.02.08 08:55
Оценка:
Здравствуйте, VEAPUK, Вы писали:

VEA>Я прекрасно вижу, но реальная скорость записи на блины 150Мб/сек — предел для САТА2 7200, если ошибаюсь, то поправьте.

VEA>Итого, в среднем, из 3 гб занято 750 Мб — денег девать не куда?
Вопрос не понятен.
Впрочем могу предположить...
Ты имел в виду зачем 3 гига если занято на момент хибернейта около 750?
Элементарно!
3 гига нужно для быстрой работы тяжелых прог, которые память хавают как бесплатную. Существенную часть времени эта память не используется на 100%. Но и брался такой объем именно для ускорения тяжелых процессов.
у меня на компе такие процессы запускаются где то на 40-50% активного времени. Т.е. запустили — отработало — закрыли. Отрабатывать должно достаточно быстро не теряя время на своппинг.
В хибернейт рабочий комп я выпихиваю обычно с открытыми MSVC и проч девелоперскими тулами. которые хавают уже не так много + там Janus, Maxthon с кучкой открытых страниц и т.п.
Так что обычная ситуация.

естественно сервера, на которых крутятся подобные прожорливые проги (живой пример: Sharepoint2007 + MSSQL2005 — 3 гига им схавать это как семечки, даже тесновато бывает) вообще почти никогда в хибернейт не уходят — у них режим работы 24/7

в дополнение: еще к тому же все замапленные секции (например образы EXE и DLL) тоже не будут писаться в хиберфайл
пишется грубо говоря "working set" и "private bytes" процессов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Многопоточность сегодня
От: sharcUs Беларусь http://sharcus.blogspot.com/
Дата: 24.02.08 12:02
Оценка: 2 (1)
Джеймс Рейндерс, автор книги «Intel Threading Building Blocks: Outfitting C++ for Multi-core Processor Parallelism» сформулировал восемь ключевых правил программирования для многоядерных процессоров, которые окажутся очень кстати на пути к увеличению эффективности программ, разрабатываемых для multicore.

Правило 1.
Думайте параллельно. Решение всех проблем ищите в параллелизме. Обретите понимание того, где действительно есть параллелизм и организуйте свое мышление таким образом, что бы смогли без труда выявить такие фрагменты системы. Прежде чем использовать другие приемы и реализации, склоняйтесь к максимально эффективному решению, основанному на параллельном видении проблемы. Учитесь «думать параллельно».

Правило 2.
Программируйте, используя абстракции. При написании исходного кода сфокусируйтесь на параллельности выполнения процессов, но избегайте непосредственного управления потоками или ядрами процессора. Такие библиотеки, как OpenMP и Intel Threading Building Blocks это все примеры использования абстракций. Не используйте объекты потоков напрямую (pthreads, Windows Threads, Boost threads и пр.) Потоки и MPI это механизмы параллелизма языков программирования. Они предлагают максимум гибкости, однако требуют чрезвычайно много времени для написания, отладки и поддержания. Ваше внимание должно быть сосредоточено на более высоком уровне видения решаемой проблемы, чем уровень управления ядрами и потоками.

Правило 3.
Программируйте в терминах задач, а не потоков вычисления. Оставьте вопрос привязывания задач к потокам или ядрам процессоров как отдельную изолированную операцию в вашей программе, абстрагируя механизм управления вычислительными потоками. Создавайте максимально обособленные реализации решаемых в вашей программе задач, которые потенциально могут автоматически выполняться на различных ядрах процессора (как, к примеру, цикл OpenMP). В процессе формулирования реализуемых в программе отдельных подзадач, создавайте их ровно столько, сколько вам действительно нужно, избегая, разумеется, избыточного разделения.

Правило 4.
Проектируйте вашу систему таким образом, чтобы была возможность не использовать параллелизм вовсе. Для того, что бы проще выполнять отладку, создавайте программу, которую можно было бы запустить без параллельного выполнения задач. В таком случае у вас будет возможность при отладке программы сначала запустить ее с параллельными вычислениями, а затем без таковых и проверить результаты обоих запусков на наличие ошибок и слабых мест. Отладка отдельных частей программы проще, когда в ней нет параллельно работающих фрагментов. Это связано с тем, что основная масса существующих инструментов отладки в большей степени не ориентированы на работу с многопоточным кодом. Когда вам известно, что проблемы возникают только в том случае, когда части системы выполняются параллельно, то наверняка выявить причину этого вам будет проще. Если проигнорировать данное правило и не предусмотреть возможности работы программы в однопоточном режиме, вы можете потратить очень много вермени на выявление причины существующих в программе ошибок. После этого у вас наверняка появится желание добавить в программу возможность ее выполнения в однопоточном режиме, но это уже не принесет такой эффективности, как если бы такая возможность присутствовала изначально. Вам просто необходимо избегать создание параллельных программ, которые для работы обязательно требуют параллельности выполнения. MPI программы часто нарушают это правило, что отчасти является причиной того, что подобные программы сложно отладить.

Правило 5.
Избегайте использования блокировок (lock). Просто скажите блокировкам «нет». Блокировки замедляют программы, снижают их масштабируемость и являются источниками ошибок в параллельном программировании. Делайте неявную синхронизацию решения для вашей программы. Когда вам все-таки требуется явная синхронизация, используйте атомарные операции. Используйте блокировки только как последнее средство. Тщательно спроектируйте вашу систему таким образом, что бы использование блокировок в вашей программе не понадобилось.

Правило 6.
Используйте средства и библиотеки, предназначенные для того, что бы помочь реализации параллельных вычислений. Даже не прикасайтесь к устаревшему инструментарию. Будьте критичны к тому, поддерживает ли данное средство параллелизм и если да, то насколько хорошо. Большинство существующих подобных инструментов достаточно слабы в этом вопросе и не полностью поддерживают параллельные процессы. Ищите потокобезопасные библиотеки или же такие, которые спроектированы специально для применения в многопоточной среде.

Правило 7.
Используйте масштабируемые механизмы выделения памяти. Поточные программы требуют использования масштабируемых механизмов выделения памяти. Точка. Существует много решений, которые лучше чем malloc(). Использование таких механимов увеличивает скорость работы программы, устраняя узкие места, связанные с перераспределением памяти и способствуют лучшему использованию системного кеша.

Правило 8.
Проектируйте масштабируемость программы с учетом увеличения нагрузки. Со временем количество выполняемой вашей программой работы, возможно, потребуется увеличить. Учтите это на этапе проектирования. Уделите большое внимание вопросам масшабируемости еще на начальном этапе, и ваша программа сможет делать больше работы при увеличении числа ядер процессора. Каждый год мы вынуждаем компьютеры делать все больше и больше работы. Затратив больше времени вопросам масштабируемости на начальном этапе, вы получите огромную выгоду при возрастании нагрузок в будущем.
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 24.02.08 17:56
Оценка: 2 (1)
Здравствуйте, sharcUs, Вы писали:

U>Джеймс Рейндерс, автор книги «Intel Threading Building Blocks: Outfitting C++ for Multi-core Processor Parallelism» сформулировал восемь ключевых правил программирования для многоядерных процессоров, которые окажутся очень кстати на пути к увеличению эффективности программ, разрабатываемых для multicore.



Да, было такое в DDJ в прошлом сентябре:
http://www.ddj.com/hpc-high-performance-computing/201804248
Статья, конечно, больше в стиле вопросов, нежели ответов. Т.к. после каждого пункта хочется спросить "А как?"

В вот ещё один вариант "8-ми правил" от Клея Брешерса (тоже из Интел):
8 Simple Rules for Designing Threaded Applications
Немного более развёрнуто и детально. Частично советы пересекаются, что и логично.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня
От: AndrewJD США  
Дата: 25.02.08 12:33
Оценка: +1
Здравствуйте, remark, Вы писали:

R>Да, было такое в DDJ в прошлом сентябре:

R>http://www.ddj.com/hpc-high-performance-computing/201804248
R>Статья, конечно, больше в стиле вопросов, нежели ответов. Т.к. после каждого пункта хочется спросить "А как?"

Особенно хочется спросить, "А как?" на совет

Avoid using locks. Simply say "no" to locks. Locks slow programs, reduce their scalability, and are the source of bugs in parallel programs

"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.04.08 08:50
Оценка: 31 (6)
Здравствуйте, remark

Прошу прощения за подъем старой темы, но наткнулся на интересный пост одного из разработчиков JRuby. В нем описывается, как на небольшом бенчмарке обнаружилось, что приложение с двумя нитями на Java 5 работает значительно быстрее, чем оно же на Java 6. Проявляется это на двухядерном процессоре из-за эффекта "Cache Line Ping-Pong":

...Это ведет нас к причине плохой производительности на упомянутом выше бенчмарке. Джон Роуз помог мне с помощью дизассемблирования результирующего нативного кода этого бенчмарка для Java 5 и Java 6. Оказалось, что Java 5 размещает два статических поля в разных quadword-ах (16 байтах), а Java 6 -- в одном quadword-е. Эта оптимизация позволяет лучше использовать кэш, т.к. расположенные сразу одно за другим поля почти наверняка будут разделять одну cache line (eao197: здесь у меня не хватило знаний для подходящего русскоязычного термина). Но это так же имеет и другой эффект.

"Cache line ping-pong" проявляется, когда две нити, работающие с разными кешами, нуждаются в чтении и записи одной и той же области памяти. Поскольку две нити должны видеть изменения друг друга, cache line оказывается занятой переключениями между двумя кешами, что обычно ведет к сбросу кеша или обновлению кеша из основной памяти.

Основная память медленная, помните? Поэтому из-за "cache line ping-pong" добавление нитей в этом бенчмарке в действительности приводит к замедлению...


В качестве выводов автор в очередной раз говорит, что нельзя использовать статические данные в многопоточных программах, так же как плохо вообще разделять какие-либо данные между потоками. Ну это и понятно (не понятно, однако, насколько та же Java приспособлена к другим подходам в многопоточности). Интересен другой вывод:

One man's optimization is another man's deoptimization — Java 6 is significantly faster than Java 5, presumably because of optimizations like this. But every optimization has a tradeoff, and this one caught me by surprise.

Как раз этот-то эффект и заинтересовал меня в упомянутом посте.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 04.04.08 12:27
Оценка: 101 (6)
Здравствуйте, eao197, Вы писали:

E>Прошу прощения за подъем старой темы, но наткнулся на интересный пост одного из разработчиков JRuby. В нем описывается, как на небольшом бенчмарке обнаружилось, что приложение с двумя нитями на Java 5 работает значительно быстрее, чем оно же на Java 6. Проявляется это на двухядерном процессоре из-за эффекта "Cache Line Ping-Pong":

[...]
E>В качестве выводов автор в очередной раз говорит, что нельзя использовать статические данные в многопоточных программах, так же как плохо вообще разделять какие-либо данные между потоками. Ну это и понятно (не понятно, однако, насколько та же Java приспособлена к другим подходам в многопоточности). Интересен другой вывод:
E>

E>One man's optimization is another man's deoptimization — Java 6 is significantly faster than Java 5, presumably because of optimizations like this. But every optimization has a tradeoff, and this one caught me by surprise.

E>Как раз этот-то эффект и заинтересовал меня в упомянутом посте.


Не слушай его, он ламер... по крайней мере, что касается многопоточности

Don't use statics — Gilad Bracha probably said it best in his article "Cutting out Static":
Static variables are bad for for concurrency. Of course, any shared state is bad for concurrency, but static state is one more subtle time bomb that can catch you by surprise.


Не верно. Статические переменные не имеют никакого отношения к делу. За задницу может поймать абсолютно любая переменная, даже переменная самого-самого маленького класса, если не уделять этому вопросу внимания. Значение имеет только то, какие потоки и как используют эту переменную. В приведённом примере, насколько я вижу, статическая переменная используется исключительно, что бы упростить доступ к ней из функции потока. Если бы она была не статическая, а переменная-член класса, и ссылка на этот класс передавалась бы в потоки, это ну ровным счётом ничего бы не изменило.
Значительно большее влияние может иметь, например, неаккуратно размешённая переменная-член producer-consumer очереди, чем статическая переменная центрального класса приложения. Эти вопросы совершенно перпендикулярны.


One man's optimization is another man's deoptimization — Java 6 is significantly faster than Java 5, presumably because of optimizations like this. But every optimization has a tradeoff, and this one caught me by surprise.


Совершенно не верно. Все компиляторы оптимизируют под однопоточное выполнение. Это известно. Это традиционно. Это по-умолчанию.
Видимо они работают с процессорами SUN, что у них кэш линия всего 16 байт. А что будет если мы работаем на процессоре Pentium4, где кэш линия на чтение 128 байт? Компилятор должен размещать каждую переменную в своих 128 байтах, тем самым увеличивая потребление памяти в 32 раза? Верно? Нет, конечно не верно. Компилятор пакует все данные максимально плотно, *пока пользователь явно не укажет иного*.
Фактически в программе изначально была допушена ошибка (я думаю, что в контексте разговора о производительности, законно называть это ошибкой). На одном компиляторе это "работало", на другом перестало работать. Попытка как-то приплести сюда компилятор, и свалить вину на него, это просто ламерство. Никакой ошибки и никакого трейдоффа в компиляторе нет.
Это всё равно что возмущаться, что на одном компиляторе С++ этот код работал, а на другом "плохом" компиляторе неожиданно сломался:
i = i++ + ++i;

И назвать это трейдоффом оптимизируещего компилятора.

Компилятору надо явно сказать, если ты надеешься на какое-то конкретное размещение данных. Например, как я организую размещение данных в С++:
class producer_consumer_fifo_queue
{
  //...

  // producer data
  node* volatile head;

  char cacheline_pad [128];

  // consumer data
  node* tail;
};


Или даже так:
class producer_part_of_fifo_queue
{
  //...

  node* volatile head;
};

class consumer_part_of_fifo_queue
{
  //...

  node* tail;

  void connect_producer(producer_part_of_fifo_queue& producer);
};


Это — всегда корректное, контролируемое мной размещение данных. Я уверен, что если не первый, то второй вариант точно можно сделать и в Java.

То, что автора это застало врасплох... ну что ж... все мы учимся... в следующий раз не застанет...


2. Don't share state unless you absolutely have to — This is perhaps a lesson we all believe we know, but until you're bitten by something sneaky like this you may not realize the what bad habits you have.


Это, в принципе, верно. Точнее так, это может быть и верно и не верно. В зависимости от того, что вкладывал в эти слова автор, и как мы его поняли.
Я бы выразил это так: всегда явно контролируйте и продумывайте — где, как и какие данные разделяются. Само по себе разделение может быть даже полезным.
Чем отличается одна система из N компонентов, то N раздельных систем? Тем, что одна система всегда должна разделять каким-либо образом какие-то данные внутри себя. Иначе она распадается на N раздельных систем. Чем отличается многопоточная программа от программы, состоящей из нескольких процессов, объединенных сокетами/пайпами/файлами? Тем, что в многопоточной программе можно эффективно разделять данные. Я не говорю, что это разделение всегда само сабой окажется эффективным, скорее даже наоборот, но тем не менее добиться этого можно.
Тут надо рассмотреть 2 типа данных: неизменяемые (или редко-изменяемые данные) и часто изменяемые данные.
Что касается неизменяемых (или редко-изменяемых) данных, то тут мы в шоколаде. Подумай, например, о кэше данных из БД размером в несколько сот МБ. Его разделять не только можно, но и нужно. И такое разделение очень эффективно и с т.з. временной сложности, т.е. никаких дополнительных пенальти по времени. Для редко изменяемых данных необходим какой-то механизм, позволяющий платить только во время изменения, а всё остальное время работать с данными как с неизменяемыми.
С часто-изменяемыми данными сложнее. В принципе, да, лучше минимизировать их разделение. Но сильно мало, всё равно не получится, т.к. в любом случае это будет подсистема аллокации памяти, подсистема контроля времени-жизни объектов, очереди для передачи сообщений, либо разделяемые коллекции данных. А так же такие врожденно центролизованные подсистемы, как, например, логирование. Поэтому тут более правильно было бы сказать, не минимизируйте разделение данных, а грамотно, аккуратно и эффективно организуйте это разделение (после того как Вы убрали заведомо ненужное разделение).


з.ы. cache line обычно передоится как... кэш линия, ну или строка кэша


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 04.04.08 12:31
Оценка:
Здравствуйте, AndrewJD, Вы писали:

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


R>>Да, было такое в DDJ в прошлом сентябре:

R>>http://www.ddj.com/hpc-high-performance-computing/201804248
R>>Статья, конечно, больше в стиле вопросов, нежели ответов. Т.к. после каждого пункта хочется спросить "А как?"

AJD>Особенно хочется спросить, "А как?" на совет


AJD>

AJD>Avoid using locks. Simply say "no" to locks. Locks slow programs, reduce their scalability, and are the source of bugs in parallel programs



На этот вопрос сразу хочется ответить вопросом "А где?"

Т.е. вариантов-то много. Всё зависит от конкретной ситуации и деталей.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 04.04.08 12:48
Оценка: 1 (1) :)
Здравствуйте, eao197, Вы писали:

E>В качестве выводов автор в очередной раз говорит, что нельзя использовать статические данные в многопоточных программах, так же как плохо вообще разделять какие-либо данные между потоками. Ну это и понятно (не понятно, однако, насколько та же Java приспособлена к другим подходам в многопоточности)



Пока не добавят встроенный ассемблер — нисколько не приспособлена

Пока будьте любезны обходится мейнстримом, который встроен в язык/библиотеку/ран-тайм



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Многопоточность сегодня
От: рыбак  
Дата: 04.04.08 17:25
Оценка:
Здравствуйте, remark, Вы писали:

Как сказал какой-то умный тип: многопоточность придумали те, кто не понимают конечных автоматов.
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 04.04.08 18:17
Оценка: 1 (1)
Здравствуйте, рыбак, Вы писали:

Р>Как сказал какой-то умный тип: многопоточность придумали те, кто не понимают конечных автоматов.



Что касается "многопоточности на одном процессоре", то в принципе, наверное, да.
Что касается "многопоточности на множестве процессоров", то это совсем о другом, это перпендикулярные вещи.


Р>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Арифметика
От: Alex Alexandrov США  
Дата: 04.04.08 19:40
Оценка: -2
Здравствуйте, remark, Вы писали:

R>Позавчера однопоточная программа на одноядерном процессоре использовала 100% аппаратных ресурсов. Хорошо.

R>Вчера однопоточная программа на двухядерном процессоре использовала 50% аппаратных ресурсов. Допустим.
R>Сегодня однопоточная программа на четырёхядерном процессоре использует 25% аппаратных ресурсов. Хммм.
R>Завтра однопоточная программа на шестнадцатиядерном процессоре будет использовать 6.25% аппаратных ресурсов.
R>Послезавтра однопоточная программа на восьмидестиядерном процессоре будет использовать 1.25% аппаратных ресурсов.

R>Арифметика очень простая. Хотите быть автором программы, которая работает только на 1.25% от возможного?


Говорят, мы используем возможности нашего мозга только на 2 процента. Видимо, Творец так и не смог это безобразие по-нормальному распараллелить...
It's kind of fun to do the impossible (Walt Disney)
Re: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.04.08 10:04
Оценка: 55 (3)
Здравствуйте, remark, Вы писали:

R>Дополнительные ссылки для интересующихся:


Ct: C for Throughput Computing -- какая-то новая штука от Intel-а (как я понял, пока находящаяся в стадии разработки).

How does it work?

In principal, Ct works with any standard C++ compiler because it is a standards-compliant C++ library (with a lot of runtime behind the scenes). When one initializes the Ct library, one loads a runtime that includes the compiler, threading runtime, memory manager — essentially all the components one needs for threaded and/or vectorized code generation. Ct code is dynamically compiled, so the runtime tries to aggregate as many smaller tasks or data parallel work quanta so that it can minimize threading overhead and control the granularity according to run-time conditions. With the Ct dynamic engine, one gets precise inter-procedural traces to compile, which is extremely useful in the highly modularized and indirect world of object-oriented programming.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 10.04.08 16:43
Оценка:
Здравствуйте, eao197, Вы писали:

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


R>>Дополнительные ссылки для интересующихся:


E>Ct: C for Throughput Computing -- какая-то новая штука от Intel-а (как я понял, пока находящаяся в стадии разработки).

E>

E>How does it work?

E>In principal, Ct works with any standard C++ compiler because it is a standards-compliant C++ library (with a lot of runtime behind the scenes). When one initializes the Ct library, one loads a runtime that includes the compiler, threading runtime, memory manager — essentially all the components one needs for threaded and/or vectorized code generation. Ct code is dynamically compiled, so the runtime tries to aggregate as many smaller tasks or data parallel work quanta so that it can minimize threading overhead and control the granularity according to run-time conditions. With the Ct dynamic engine, one gets precise inter-procedural traces to compile, which is extremely useful in the highly modularized and indirect world of object-oriented programming.



Спасибо. Погляжу.

На первый взгляд это что-то типа гибрида RapidMind и Cilk.

RapidMind:
http://www.rapidmind.com/product.php
http://www.rapidmind.com/pdfs/WP_RapidMindPlatform.pdf

При использовании RapidMind вычислительная программа описывается на смеси шаблонов с макросами, и потом тоже в ран-тайме компилируется в нативный оптимизированный код, под конкретную платформу.


А из Cilk спёрли "spawn" и "task parallelism".


Огорчает то, что это всё, и всё то, и то тоже, всё это рассчитано исключительно для вычислительных задач. Т.е. пока тебе не надо перемножать матрицы в миллион элементов, или обрабатывать видео, или считать САПР какой-нибудь, пользы от этого мало... Не то, что от SObjectizer



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность сегодня
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.04.08 17:05
Оценка:
Здравствуйте, remark, Вы писали:

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


Тут вот народ выход Fortress 1.0 обсуждает, так в обсуждении какие-то прям зубры HPC затесались. Оказывается, очень восстребованная штука это нонче. Если разработки Intel-а им жизнь облегчат, так это же хорошо.

Примечательно так же, что подобные штуки для неуправляемых C/C++ делают. Что-то managed среды типа Java/C# у Intel-а не котируются

R>Не то, что от SObjectizer


А то!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Многопоточность сегодня
От: Michael7 Россия  
Дата: 10.04.08 20:18
Оценка:
Здравствуйте, remark, Вы писали:

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


Многопроцессорные системы и кластеры вовсе не новое явление, новое только в том, что они добрались до массового рынка для которого просто оказалось недостаточно квалифицированных специалистов, притом и среди преподавателей тоже.

Разумеется, проблемы написания программ с по-настоящему, параллельными вычислениями были и есть, но сдаётся мне, что 99% программистов, которым хочется эффективно задействовать несколько ядер достаточно использовать давно уже известные приёмы, методики и библиотеки. Ещё конечно проблема, что в системах, в которых до недавнего времени использовали многопроцессорность, Windows с одной стороны была не очень популярна, с другой — она сама не слишком на них рассчитывалась, несмотря на поддержку мультипроцессорности.
Re[4]: Многопоточность сегодня
От: Хитрик Денис Россия RSDN
Дата: 11.04.08 04:34
Оценка:
Здравствуйте, eao197, Вы писали:

E>Примечательно так же, что подобные штуки для неуправляемых C/C++ делают. Что-то managed среды типа Java/C# у Intel-а не котируются


Так управляемая же среда должна и на процессорах AMD работать
Правила нашего с вами форума.
Как правильно задавать вопросы. © 2001 by Eric S. Raymond; перевод: © 2002 Валерий Кравчук.
Re[5]: Многопоточность сегодня
От: CreatorCray  
Дата: 11.04.08 08:02
Оценка: :)
Здравствуйте, Хитрик Денис, Вы писали:

E>>Примечательно так же, что подобные штуки для неуправляемых C/C++ делают. Что-то managed среды типа Java/C# у Intel-а не котируются

Потому как в управляемой среде производительность программы зависит от кучи внешних факторов.
Какой смысл устраивать гонки на скоростных болидах по трассе, где придется часто тормозить на каждом гаишнике для проверки бардачка.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Многопоточность сегодня
От: LaPerouse  
Дата: 11.04.08 14:47
Оценка:
Здравствуйте, AVM, Вы писали:

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


AVM>>>Может быть только для того, чтобы сделать компьютер умеющий их перемножать?

S>>Перемножение матриц имеет невероятно широкий спектр прикладных применений.
AVM>Например?

Любая из современных игр. Правда, там все происходит на гпу.
По твоему зря оптимизацию векторных вычислений в процессоры встраивают?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[4]: Многопоточность сегодня
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.04.08 21:00
Оценка:
Здравствуйте, eao197, Вы писали:

E>Что-то managed среды типа Java/C# у Intel-а не котируются


http://orp.sourceforge.net/
... <<RSDN@Home 1.2.0 alpha 4 rev. 1082 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re: Многопоточность завтра
От: gear nuke  
Дата: 17.04.08 02:13
Оценка:
Здравствуйте, remark, Вы писали:

R>Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер».


Кому она нужна? Тебе? Заказчикам? Зачем? И так впринципе можно жить — купите лоадбалансер Менеджерам по продажам CPU? А, ну да

Что нужно — так это реальный стимул, что бы этим занимались серьезно. И он есть — снижение сложности вычислений. In 1998 the EFF built Deep Crack for less than $250,000

Тезис Черча (не считая недоказанности — ИМХО ерунда) имеет серьёзную проблему — на "реальных МТ" требования алгоритма к времени или памяти могут быть неприемлимы. Эту особенность эксплуатирует например современная криптография. В тоже время, при достаточно большом количестве ядер, суперядерный процессор сможет эмулировать квантовый компьютер, и решать многие задачи грубой силой. Будет решена проблема P = NP современной плоской модели. RSA Security уже убрали Chalenge.

Да, для некоторого класса задач суперядерность ничего не даст! Ну и что, 2+2 можно и на калькуляторе посчитать, и даже в уме.

Но можно будет решать новые задачи, конечно это потребует некоторого повышения уровня... абстракции, вроде как обычная арифметика была, а появились поля и кольца...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Многопоточность завтра
От: WFrag США  
Дата: 17.04.08 03:21
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Тезис Черча (не считая недоказанности — ИМХО ерунда) имеет серьёзную проблему — на "реальных МТ" требования алгоритма к времени или памяти могут быть неприемлимы. Эту особенность эксплуатирует например современная криптография. В тоже время, при достаточно большом количестве ядер, суперядерный процессор сможет эмулировать квантовый компьютер, и решать многие задачи грубой силой. Будет решена проблема P = NP современной плоской модели. RSA Security уже убрали Chalenge.


Это как это будет решена? Непонятно. Всё равно при линейном росте длины ключа мы получаем экспоненциальный рост поиска обратного ключа.
Re[3]: Многопоточность завтра
От: gear nuke  
Дата: 18.04.08 02:25
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Это как это будет решена? Непонятно. Всё равно при линейном росте длины ключа мы получаем экспоненциальный рост поиска обратного ключа.


Алгоритм Шора был разработан Питером Шором в 1994 году. Семь лет спустя, в 2001 году, его работоспособность была продемонстрирована группой специалистов IBM. Число 15 было разложено на множители 3 и 5 при помощи квантового компьютера с 7 кубитами.


Понятно, что всегда можно найти неприемлимые для МТ объемы данных. Я имел ввиду вот что — сейчас рассматривают два требования алгоритма — к объёму памяти и времени выполнения (фактически принимают как функцию от тактовой частоты). Но появится третий ресурс — количество исполнителей. Если исполнителей достаточно — NP-полная задача решается брутфорсом за полиномиальное время. Конечно 80 ядер — мало, как 80 байт и wintel не та архитектура.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 24.04.08 18:44
Оценка:
Здравствуйте, Michael7, Вы писали:

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


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


M>Многопроцессорные системы и кластеры вовсе не новое явление, новое только в том, что они добрались до массового рынка для которого просто оказалось недостаточно квалифицированных специалистов, притом и среди преподавателей тоже.


M>Разумеется, проблемы написания программ с по-настоящему, параллельными вычислениями были и есть, но сдаётся мне, что 99% программистов, которым хочется эффективно задействовать несколько ядер достаточно использовать давно уже известные приёмы, методики и библиотеки. Ещё конечно проблема, что в системах, в которых до недавнего времени использовали многопроцессорность, Windows с одной стороны была не очень популярна, с другой — она сама не слишком на них рассчитывалась, несмотря на поддержку мультипроцессорности.



Если ты имеешь в виду HPC сообщество, то это совершенно не так. HPC сообществу практически нечего предложить нам — прикладным/системным программистам.
Вот, к примеру, ряд вопросов, которые поставят в ступор любого HPC специалиста.

— Как организовать архитектуру сетевого сервера для обеспечения хорошей масштабируемости?

— Как эффективно организовать управление памятью в многопроцессорной среде?

— Как эффективно организовать управление временем жизни объектов в многопроцессорной среде?

Согласись, что это базовые вопросы для любого прикладного приложения. У HPC просто нет ответов на такие вопросы. Они варятся в своей каше из гиперкубов и тета-нотации.


Есть другой класс специалистов — это разработчики высокопроизводительных серверов (сетевые, баз данных и т.д.), которые работали с SMP машинами. Они, действительно, имеют ответы на некоторые вопросы. Но во-первых, далеко не на все. Во-вторых, далеко не самые идеальные ответы. В третьих, таких людей очень мало (я общался только с одним, он действительно даёт достаточно вразуметильные ответы по поводу архитектуры, взаимодействия потоков и т.д.).
И это разработчики далеко не всех "высокопроизводительных" серверов. Например, такая "продвинутая" и "высокопроизводительная" СУБД как PostgreSQL использует "тупейшую" схему для обеспечения масштабирования — под каждую сессию запускает отдельный процесс, всё остальное решается с помощью блокировок.


Т.ч. я совершенно не согласен, что типа просто "а мужики-то не знали", уже всё есть готовое, а мы тут тупим, как же нам быть.
Сейчас многоядерность двинулась в сектор серверного ПО, клиентского ПО, игрового ПО. И на встающие вопросы ещё ни у кого нет ответов.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 24.04.08 19:25
Оценка:
Здравствуйте, gear nuke, Вы писали:

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


R>>Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер».


GN>Кому она нужна? Тебе? Заказчикам? Зачем? И так впринципе можно жить — купите лоадбалансер Менеджерам по продажам CPU? А, ну да



Я бы в принципе не отказался, если бы на моём компьютере, способном выполнять 3,6*10^10 операций в секунду, не тормозил текстовый процессор...
лоадбалансер? т.е. ты предлагаешь мне купить домой несколько компьютеров и объединить лоадбалансером?


GN>Что нужно — так это реальный стимул, что бы этим занимались серьезно. И он есть — снижение сложности вычислений. In 1998 the EFF built Deep Crack for less than $250,000


GN>Тезис Черча (не считая недоказанности — ИМХО ерунда) имеет серьёзную проблему — на "реальных МТ" требования алгоритма к времени или памяти могут быть неприемлимы. Эту особенность эксплуатирует например современная криптография. В тоже время, при достаточно большом количестве ядер, суперядерный процессор сможет эмулировать квантовый компьютер, и решать многие задачи грубой силой. Будет решена проблема P = NP современной плоской модели. RSA Security уже убрали Chalenge.



Вообще, я говорил не о HPC, не о гипер-кубах замешанных с тета-нотацией. Я говорил об обычных прикладных/системных программистах, которым надо создавать серверное ПО, клиентское ПО, stand-alone ПО, GUI ПО, игры, графические редакторы и т.д.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Многопоточность сегодня
От: remark Россия http://www.1024cores.net/
Дата: 24.04.08 23:47
Оценка:
Здравствуйте, remark, Вы писали:

R>Некоторое время назад я был свидетелем следующей ситуации. Серверное ПО запустили на двух-процессорной машине (в надежде, что оно будет работать в 2 раза быстрее. ха-ха). Оно стало работать в 10 (!) раз медленнее (как потом оказалось причиной было постоянное разделение модифицируемых данных между двумя потоками).



Ещё один в коллекцию:
http://groups.google.ru/group/comp.programming.threads/msg/fc7c3c477310e1da


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



Хммм... имхо хорошо подходит термин "Мультиплексирование". Фактически один процессор просто мультиплексирует разные функции — повыполнял одну, потом другую.


R>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Многопоточность завтра
От: gear nuke  
Дата: 24.04.08 23:52
Оценка:
Здравствуйте, remark, Вы писали:

R>Я бы в принципе не отказался, если бы на моём компьютере, способном выполнять 3,6*10^10 операций в секунду, не тормозил текстовый процессор...


Кстати, о редакторах ... показательный пример. Есть 2 родственных продукта: Understand for C++ и Source Insight. Первый в 2 раза дороже, но, я так и не смог хоть как-то его оценить — на исходниках, размер которых представляет практический интерес, эта штука просто не работает... точнее очень долго их парсит, что-то около часа было. На современном железе, думаю, будет быстрее, но даже пробовать не хочу... много модулей на перле.

R>лоадбалансер? т.е. ты предлагаешь мне купить домой несколько компьютеров и объединить лоадбалансером?


Нет конечно Но для ряда задач это вполне приемлимое решение. И, главное, железо стоит дешевле, чем что-то переделывать.

R>Вообще, я говорил не о HPC, не о гипер-кубах замешанных с тета-нотацией. Я говорил об обычных прикладных/системных программистах, которым надо создавать серверное ПО, клиентское ПО, stand-alone ПО, GUI ПО, игры, графические редакторы и т.д.


Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов. А в том, что, например, с точки зрения теории сложности вычислений, увеличение количества ядер ничего не даёт! Нужна какая-то исправленная теория, которая будет учитывать количество ядер...

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

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

Тут не сказано о внутреннем устройстве, поэтому некоторые начинают крутить спинлок или вызывают сервис ОС (суть планировщик). А между тем, для компилятора элементарная операция — создать в исполняемом модуле таблицы (подобные как для С++ исключений) с адресами участков защищенного кода, а планировщик посмотрит туда и решит, нужно ли переключать контекст. Но это фантаситка Или вспомнить упомянутое здесь отсутствие в IRPе поля affinity...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 25.04.08 01:42
Оценка: 3 (1)
Здравствуйте, gear nuke, Вы писали:

R>>лоадбалансер? т.е. ты предлагаешь мне купить домой несколько компьютеров и объединить лоадбалансером?


GN>Нет конечно Но для ряда задач это вполне приемлимое решение. И, главное, железо стоит дешевле, чем что-то переделывать.



Ну это зависит. Допустим сделать "медленный" сервер у меня займёт 2 месяца, а сделать "быстрый" сервер у меня займёт 3 месяца. Итого имеем 1 месячную зарплату программиста против стоимости 9 дополнительных железяк + администрирование + электроэнергия.

И вообще скажи это Гуглу, у которого несколько футбольных полей рэков с плотно-плотно напиханными блейд-серверами
Что бы они сказали на то, что им необходимо в 10 раз больше железа? Или на то, что есть возможность снизить кол-во железа хотя бы в 2 раза?

Это больше вопрос философии и принципа, потому что с опытом время разработки "быстрого" сервера и "медленного" сервера стремится практически к одной величине. На Java это философия — мы делаем медленный софт, но он хорошо масштабируется. Мой коллега, программист на С, говорит — надо держать 50000 соединений, значит буду писать, что б держало 50000 соединений. Я думаю, у него даже не было мысли покупки 10 железяк. Да и ставить их не куда. Да и администрить их всем лень.


R>>Вообще, я говорил не о HPC, не о гипер-кубах замешанных с тета-нотацией. Я говорил об обычных прикладных/системных программистах, которым надо создавать серверное ПО, клиентское ПО, stand-alone ПО, GUI ПО, игры, графические редакторы и т.д.


GN>Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов.



lock-free алгоритмы — это не о производительности и масштабируемости, это исключительно о гарантиях системного прогресса. lock-free алгоритмы зачастую бывают медленнее lock-based алгоритмов. Это как best-effort против QoS, или не real-time против real-time. QoS и real-time всегда медленнее, зато дают дополнительные гарантии.


GN>А в том, что, например, с точки зрения теории сложности вычислений, увеличение количества ядер ничего не даёт! Нужна какая-то исправленная теория, которая будет учитывать количество ядер...



Ну почему не даёт! HPC товарищи любят рассматривать решение задачи размера N на системе с N процессорами
Вот сейчас только книжку дочитал — там все задачи рассматриваются либо на системах с N процессорами, либо на N^(1/2), либо на крайний случай с log(N)


GN>Вот например, если ОС будет давать определённые гарантии, то можно без локов обходиться.



Падение масштабируемости не в локах!!! Падение масштабируемости в разделении данных! А тут никакая ОС не поможет.


GN>Возьмём определение Дейкстры:

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

Тут не сказано о внутреннем устройстве, поэтому некоторые начинают крутить спинлок или вызывают сервис ОС (суть планировщик). А между тем, для компилятора элементарная операция — создать в исполняемом модуле таблицы (подобные как для С++ исключений) с адресами участков защищенного кода, а планировщик посмотрит туда и решит, нужно ли переключать контекст. Но это фантаситка



Ну зачем же так сложно. Всё уже украдено до нас. В некоторых Unix'ах (Solaris/Irix) есть замечательный системный вызов schedctl(2). С его помощью можно из юзер-спейса давать хинт планировщику, что типа "я сейчас в критическом участке кода — не прерывай меня пожалуйста здесь". Всё сводится банально к установке/сбросу флажка.

schedctl(2) (смотри команду SETHINTS)


GN>Или вспомнить упомянутое здесь отсутствие в IRPе поля affinity...



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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность завтра
От: gear nuke  
Дата: 25.04.08 03:18
Оценка: 14 (1)
Здравствуйте, remark, Вы писали:

R>Ну это зависит. Допустим сделать "медленный" сервер у меня займёт 2 месяца, а сделать "быстрый" сервер у меня займёт 3 месяца.


Конечно зависит. Например есть старый софт, который уже не удовлетворяет запросы заказчика. Мне кажется, такая ситуация более распространена, и не всегда есть возможность переделать всё.

R>На Java это философия — мы делаем медленный софт, но он хорошо масштабируется.


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

R>HPC товарищи любят рассматривать решение задачи размера N на системе с N процессорами


Надо более обобщенно, задачи размера N на системе с K процессорами. Даже не так... а что бы ты всем уши прожужжал и целое поколение выросло на этом.

R>Падение масштабируемости не в локах!!! Падение масштабируемости в разделении данных!


Которые разделяются выставлением сигнала #LOCK на шину

R>Всё уже украдено до нас. В некоторых Unix'ах (Solaris/Irix) есть замечательный системный вызов schedctl(2).


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

Вот в С++ есть 2 подхода к исключениям: MSVC (32бит) создает SEH фреймы в рантайме, а GCC строит таблицы, в которые при необходимости заглянет хендлер (см. TR18015).

Сейчас и MSVC 64 строит таблицы для поддержки исключений, плюс таблицы для раскрутки стека — так что ничего сверхсложного в этом способе нет. Конечно, для гибкости надо оставить и schedctl(2)

R>Ну ничего, вот когда интегрированные сетевые карты начнут закачивать трафик прямо в кэш конкретного ядра, ситуация изменится к лучшему


Кстати, фрагмент NDIS_MINIPORT_BLOCK
    //
    //  This is the processor number that the miniport's
    //  interrupt DPC and timers are running on.
    //
    UCHAR                       AssignedProcessor;

Если я правильно понял, сейчас все запросы с одного интерфейса обрабатываются одним и тем же ядром. И так должно быть везде, ведь NDIS кросплатформ.

ИМХО действительно может измениться к лучшему, если языки и компиляторы будут как-то поддерживать существующую многоуровневую архитектуру памяти. Сейчас все абстрактные машины расматривают память как прозрачную стуктуру, хотя реально роль традиционного ОЗУ выполняет кеш, а память — по сути своп.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[6]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 26.04.08 23:40
Оценка:
Здравствуйте, gear nuke, Вы писали:

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


R>>Ну это зависит. Допустим сделать "медленный" сервер у меня займёт 2 месяца, а сделать "быстрый" сервер у меня займёт 3 месяца.


GN>Конечно зависит. Например есть старый софт, который уже не удовлетворяет запросы заказчика. Мне кажется, такая ситуация более распространена, и не всегда есть возможность переделать всё.


Полностью согласен.

R>>Падение масштабируемости не в локах!!! Падение масштабируемости в разделении данных!


GN>Которые разделяются выставлением сигнала #LOCK на шину


Нет. Никакого #LOCK. Просто обычные сохранения и загрузки.

R>>Всё уже украдено до нас. В некоторых Unix'ах (Solaris/Irix) есть замечательный системный вызов schedctl(2).


GN>Такая уж она замечательная? Конечно избавились от оверхеда на постоянные вызовы, но — как раз то о чем ты полфорума исписал — запись и чтение в разделяемую память.


Это не разделяемая память, это локальная для потока переменная.

GN>Вот в С++ есть 2 подхода к исключениям: MSVC (32бит) создает SEH фреймы в рантайме, а GCC строит таблицы, в которые при необходимости заглянет хендлер (см. TR18015).


GN>Сейчас и MSVC 64 строит таблицы для поддержки исключений, плюс таблицы для раскрутки стека — так что ничего сверхсложного в этом способе нет. Конечно, для гибкости надо оставить и schedctl(2)


Компилятор не сможет это правильно отследить в случаях более сложных, чем использование только критических секций, и при этом таких, о которых осведомлен компилятор.
И от необходимости синхронизации это всё равно не спасает. Т.к. это будет не более, чем хинт. No silver bullet!

R>>Ну ничего, вот когда интегрированные сетевые карты начнут закачивать трафик прямо в кэш конкретного ядра, ситуация изменится к лучшему


GN>Кстати, фрагмент NDIS_MINIPORT_BLOCK

GN>
GN>    //
GN>    //  This is the processor number that the miniport's
GN>    //  interrupt DPC and timers are running on.
GN>    //
GN>    UCHAR                       AssignedProcessor;
GN>

GN>Если я правильно понял, сейчас все запросы с одного интерфейса обрабатываются одним и тем же ядром. И так должно быть везде, ведь NDIS кросплатформ.

Для начала это уже не плохо. Но где работают более верхние уровни (например, TCP/IP)? И как этом можно воспользоваться пользователю?
Конечная цель — как писать программу в юзер-спейс, что бы по возможности *вся* работа с данными шла на одном процессоре. Как при отправке, так и при приёме.


GN>ИМХО действительно может измениться к лучшему, если языки и компиляторы будут как-то поддерживать существующую многоуровневую архитектуру памяти. Сейчас все абстрактные машины расматривают память как прозрачную стуктуру, хотя реально роль традиционного ОЗУ выполняет кеш, а память — по сути своп.



Это уже начинает появляться. Смотри:
http://gzip.rsdn.ru/Forum/message/2929998.1.aspx
Автор: remark
Дата: 25.04.08

Там внизу есть ссылки на научные работы, часть из них как раз рассматривает возможности автоматического "улучшения" программ для таких языков как Java/C#.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность завтра
От: Cyberax Марс  
Дата: 26.04.08 23:59
Оценка: 45 (2)
Здравствуйте, remark, Вы писали:

R>Для начала это уже не плохо. Но где работают более верхние уровни (например, TCP/IP)? И как этом можно воспользоваться пользователю?

R>Конечная цель — как писать программу в юзер-спейс, что бы по возможности *вся* работа с данными шла на одном процессоре. Как при отправке, так и при приёме.
Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU.
Sapienti sat!
Re[8]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 27.04.08 01:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


R>>Для начала это уже не плохо. Но где работают более верхние уровни (например, TCP/IP)? И как этом можно воспользоваться пользователю?

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

C>Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU.



Они сделали почти всё. Но одна передача данных с процессора на процессор остаётся, т.к. номер процессора, на котором было обработано аппаратное прерывание, и номер процессора, на котором приложение обработало данные, никак не связаны.
Т.е. я хочу сказать, что для того, что бы всё было "идеально" либо приложение должно следовать какому-то "паттерну использования" сокетов, либо должно быть какое-то явное АПИ — например что-то типа SetSocketAffinityMask(), либо что бы вместе с пачкой евентов от механизма демультиплексирования (select, epoll, GetQueuedCompletionStatusEx) для каждого евента было указано, на каком процессоре по возможности желательно обрабатывать это евент.


Кстати похоже, что это Van Jacobson читал мой пост "Многопоточность сегодня"

И кстати показательный пример — при запуске на 2 процессорах система не ускорилась, а замедлилась в 1.5. раза. После "грамотной" переработки с учётом многопроцессорности производительность поднялась в 5 раз. И главное скорее всего поднялась и масштабируемость, жаль он не замерил для 4 и 8 ядер. Было бо интересно поглядеть на динамику цифр.

Насколько я помню, McKenney репортил цифру — *500-кратное* ускорение на 32-процессорной машине после доработки какой-то системы ядра с помощью RCU.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Многопоточность завтра
От: Cyberax Марс  
Дата: 27.04.08 01:20
Оценка:
Здравствуйте, remark, Вы писали:

C>>Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU.

R>Они сделали почти всё. Но одна передача данных с процессора на процессор остаётся, т.к. номер процессора, на котором было обработано аппаратное прерывание, и номер процессора, на котором приложение обработало данные, никак не связаны.
А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров).

В теории, для аппаратного ускорителя TCP можно было бы и этот шаг перенести в железо сетевушки. На практике, пока для потоков в 10Гб и этого решения хватает.

R>Т.е. я хочу сказать, что для того, что бы всё было "идеально" либо приложение должно следовать какому-то "паттерну использования" сокетов, либо должно быть какое-то явное АПИ — например что-то типа SetSocketAffinityMask(), либо что бы вместе с пачкой евентов от механизма демультиплексирования (select, epoll, GetQueuedCompletionStatusEx) для каждого евента было указано, на каком процессоре по возможности желательно обрабатывать это евент.

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

R>Кстати похоже, что это Van Jacobson читал мой пост "Многопоточность сегодня"

Van Jacobson — это вообще известный хакер. Один только "Van Jacobson hack" с предсказанием заголовков в TCP чего стоит.
Sapienti sat!
Re[10]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 27.04.08 01:30
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU.

R>>Они сделали почти всё. Но одна передача данных с процессора на процессор остаётся, т.к. номер процессора, на котором было обработано аппаратное прерывание, и номер процессора, на котором приложение обработало данные, никак не связаны.

C>А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров).



Ну так смотри ниже.
Управлять процессором, обработавшим прерывание, не обязательно. Но пусть хоть мне (прикладному программисту) скажут, на каком процессоре этот пакет был обработан.


R>>Т.е. я хочу сказать, что для того, что бы всё было "идеально" либо приложение должно следовать какому-то "паттерну использования" сокетов, либо должно быть какое-то явное АПИ — например что-то типа SetSocketAffinityMask(), либо что бы вместе с пачкой евентов от механизма демультиплексирования (select, epoll, GetQueuedCompletionStatusEx) для каждого евента было указано, на каком процессоре по возможности желательно обрабатывать это евент.


C>А оно так и есть. Когда ты создаёшь сокет — оно по умолчанию привяжется к создавшему потоку (и процессору, соответственно). Потом при необходимости оно в нужный поток переместится.



Мммм. Не понял. Если все прерывания от сетевой карты приходят на один процессор, то что означает привязка сокетов?


R>>Кстати похоже, что это Van Jacobson читал мой пост "Многопоточность сегодня"

C>Van Jacobson — это вообще известный хакер. Один только "Van Jacobson hack" с предсказанием заголовков в TCP чего стоит.

Тем мне приятнее, жаль, что баллов не поставил



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Многопоточность завтра
От: Cyberax Марс  
Дата: 27.04.08 01:52
Оценка:
Здравствуйте, remark, Вы писали:

C>>А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров).

R>Ну так смотри ниже.
R>Управлять процессором, обработавшим прерывание, не обязательно. Но пусть хоть мне (прикладному программисту) скажут, на каком процессоре этот пакет был обработан.
Так это есть В этом и весь смысл van jacobson channels.

C>>А оно так и есть. Когда ты создаёшь сокет — оно по умолчанию привяжется к создавшему потоку (и процессору, соответственно). Потом при необходимости оно в нужный поток переместится.

R>Мммм. Не понял. Если все прерывания от сетевой карты приходят на один процессор, то что означает привязка сокетов?
В контексте прерывания берутся полученые пакеты, и указатели на них передаются в каналы (даже копирования содержимого не происходит). Так что непараллелизуемым остаётся только это небольшой кусок диспетчеризации полученых пакетов по каналам.

А затем уже сетевой стек на каждом канале уже на своём процессоре разбирается что с ними там дальше делать.
Sapienti sat!
Re[12]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 27.04.08 10:42
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров).

R>>Ну так смотри ниже.
R>>Управлять процессором, обработавшим прерывание, не обязательно. Но пусть хоть мне (прикладному программисту) скажут, на каком процессоре этот пакет был обработан.

C>Так это есть В этом и весь смысл van jacobson channels.



Как это может быть возможно? Ведь никто никак не может управлять на каких потоках пользователь вызывает recv(). Т.е. прерывание выполняется на фиксированном процессоре, а recv() вызывается на произвольном процессоре. Я не вижу, каким образом они будут всегда совпадать.
После беглого прочтения я понял, что убрали все промежуточные звенья. Осталось только аппаратное прерывание и пользовательский вызов. И по поводу них никаких гарантий нет. И как раз для компенсации этого ввели cache-friendly circular buffer для передачи данных.



C>>>А оно так и есть. Когда ты создаёшь сокет — оно по умолчанию привяжется к создавшему потоку (и процессору, соответственно). Потом при необходимости оно в нужный поток переместится.

R>>Мммм. Не понял. Если все прерывания от сетевой карты приходят на один процессор, то что означает привязка сокетов?

C>В контексте прерывания берутся полученые пакеты, и указатели на них передаются в каналы (даже копирования содержимого не происходит). Так что непараллелизуемым остаётся только это небольшой кусок диспетчеризации полученых пакетов по каналам...


... который выполняется на процессоре никак не связанном с процессором, на котором выполняется основной код канала
?

C>А затем уже сетевой стек на каждом канале уже на своём процессоре разбирается что с ними там дальше делать.



Безусловно это намного лучше, чем было. Я просто пытаюсь понять, это предел или можно сделать ещё что-то.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Многопоточность завтра
От: Константин Л. Франция  
Дата: 27.04.08 12:01
Оценка:
Здравствуйте, remark, Вы писали:

[]

GN>>Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов.



R>lock-free алгоритмы — это не о производительности и масштабируемости, это исключительно о гарантиях системного прогресса. lock-free алгоритмы зачастую бывают медленнее lock-based алгоритмов. Это как best-effort против QoS, или не real-time против real-time. QoS и real-time всегда медленнее, зато дают дополнительные гарантии.


боюсь просить, почему медленнее и о каких гарантиях идет речь

[]
Re[13]: Многопоточность завтра
От: Cyberax Марс  
Дата: 27.04.08 14:27
Оценка:
Здравствуйте, remark, Вы писали:

C>>Так это есть В этом и весь смысл van jacobson channels.

R>Как это может быть возможно? Ведь никто никак не может управлять на каких потоках пользователь вызывает recv(). Т.е. прерывание выполняется на фиксированном процессоре, а recv() вызывается на произвольном процессоре. Я не вижу, каким образом они будут всегда совпадать.
А они и не будут.

R>После беглого прочтения я понял, что убрали все промежуточные звенья. Осталось только аппаратное прерывание и пользовательский вызов. И по поводу них никаких гарантий нет. И как раз для компенсации этого ввели cache-friendly circular buffer для передачи данных.

Да, просто раньше оно почти всё выполнялось на одном процессоре (в контексте прерывания). Из-за этого, на 10Гб всё торррмозилло.

C>>В контексте прерывания берутся полученые пакеты, и указатели на них передаются в каналы (даже копирования содержимого не происходит). Так что непараллелизуемым остаётся только это небольшой кусок диспетчеризации полученых пакетов по каналам...

R>... который выполняется на процессоре никак не связанном с процессором, на котором выполняется основной код канала
R>?
Да.

C>>А затем уже сетевой стек на каждом канале уже на своём процессоре разбирается что с ними там дальше делать.

R>Безусловно это намного лучше, чем было. Я просто пытаюсь понять, это предел или можно сделать ещё что-то.
Больше уже вряд ли. Нужно тогда делать поддержку в аппаратуре.
Sapienti sat!
Re[2]: Fork/Join
От: Tonal- Россия www.promsoft.ru
Дата: 27.04.08 18:12
Оценка:
Есть ещё QtConcurrent в Qt 4.4
Вроде тоже основывается на этой модели.
... << RSDN@Home 1.2.0 alpha 4 rev. 1065>>
Re[6]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 27.04.08 18:30
Оценка:
Здравствуйте, Константин Л., Вы писали:

GN>>>Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов.


R>>lock-free алгоритмы — это не о производительности и масштабируемости, это исключительно о гарантиях системного прогресса. lock-free алгоритмы зачастую бывают медленнее lock-based алгоритмов. Это как best-effort против QoS, или не real-time против real-time. QoS и real-time всегда медленнее, зато дают дополнительные гарантии.


КЛ>боюсь просить, почему медленнее и о каких гарантиях идет речь



http://www.rsdn.ru/Forum/message/2930849.1.aspx
Автор: remark
Дата: 27.04.08




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Многопоточность завтра
От: Константин Л. Франция  
Дата: 27.04.08 19:17
Оценка:
Здравствуйте, remark, Вы писали:

[]

КЛ>>боюсь просить, почему медленнее и о каких гарантиях идет речь



R>http://www.rsdn.ru/Forum/message/2930849.1.aspx
Автор: remark
Дата: 27.04.08


ну вот как раз там-то все не очень очевидно, что касается скорости. если мы постоянно проваливаемся в ядро на lock-based, то, очевидно, lock-free при куче своих atomic* будет все-таки быстрее.

R>
Re[5]: Многопоточность завтра
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.04.08 07:09
Оценка:
Здравствуйте, remark, Вы писали:

GN>>А в том, что, например, с точки зрения теории сложности вычислений, увеличение количества ядер ничего не даёт! Нужна какая-то исправленная теория, которая будет учитывать количество ядер...



R>Ну почему не даёт! HPC товарищи любят рассматривать решение задачи размера N на системе с N процессорами

R>Вот сейчас только книжку дочитал — там все задачи рассматриваются либо на системах с N процессорами, либо на N^(1/2), либо на крайний случай с log(N)
А я думал, что это только российская академическая наука такое рожает. Читал лет пять назад какой-то из вестников СО РАН, так там на полном серьезе тётенька писала, что, дескать, получен новый алгоритм умножения матриц размера N*N не за O(N^3), а за O(N^2). Вчитавшись, я обнаружил, что речь идет о векторном процессоре, который нативно поддерживает операцию перемножения двух векторов. Ну, то есть задача решена для N <= V, где V — фиксированная длина вектора, который жрет этот процессор. Прочитав, смеялся до слез. Потому как если фиксировать верхнюю границу N, то можно любой алгоритм свести к O(1).


R>Да... есть такое дело... я потом ещё спрашивал на форумах MSDN... похоже они даже не думали о таких вопросах.

R>Ну ничего, вот когда интегрированные сетевые карты начнут закачивать трафик прямо в кэш конкретного ядра, ситуация изменится к лучшему
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Многопоточность завтра
От: remark Россия http://www.1024cores.net/
Дата: 05.05.08 17:38
Оценка:
Здравствуйте, Константин Л., Вы писали:

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


КЛ>[]


КЛ>>>боюсь просить, почему медленнее и о каких гарантиях идет речь



R>>http://www.rsdn.ru/Forum/message/2930849.1.aspx
Автор: remark
Дата: 27.04.08


КЛ>ну вот как раз там-то все не очень очевидно, что касается скорости. если мы постоянно проваливаемся в ядро на lock-based, то, очевидно, lock-free при куче своих atomic* будет все-таки быстрее.



http://www.rsdn.ru/forum/message/2939720.1.aspx
Автор: remark
Дата: 05.05.08



R>>


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Презентация "Architecting Parallel Software"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.12.08 07:08
Оценка: 24 (2)
Architecting Parallel Software интересная презентация на 264 слайда, расказывающая о различных архитектурных подходах при разработке программ с высоким уровнем параллелизма (PDF, ~5.9Mb).

Ссылка была найдена здесь:

Ok, so...why is this interesting? Consider: the present state of parallel programming looks a lot like that of object-oriented programming in the early 1990s -- a small number of practioners understand and use it, but the overall profession looks on with anxiety. The Design Patterns approach helped to shove OO into the mainstream; could it do so again for parallel programming?

To test this premise, a project has been launched to build up an integrated, coherent set of patterns useful for exposing high-level constructs to concurrency -- a pattern language, as opposed to a collection of patterns. Kurt and Tim have proposed a layer of structural and computational patterns, integrating to one or more an underlying layers of concurrency patterns. We presented a detailed snapshot of this view at the recent ICCAD; slides from that tutorial are here: Architecting Parallel Software.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Презентация "Architecting Parallel Software"
От: remark Россия http://www.1024cores.net/
Дата: 09.12.08 18:39
Оценка: 22 (1)
Здравствуйте, eao197, Вы писали:

E>Architecting Parallel Software интересная презентация на 264 слайда, расказывающая о различных архитектурных подходах при разработке программ с высоким уровнем параллелизма (PDF, ~5.9Mb).



Вот тут их homepage:
http://www.cise.ufl.edu/research/ParallelPatterns/



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Многопоточность сегодня
От: async  
Дата: 10.01.09 07:30
Оценка:
Здравствуйте.

Представляю вам свой ответ на многопоточность. Ознакомится можно здесь http://groups.google.com/group/asynclib?hl=en
В кратце библиотека представляет из себя микс между TBB (где работа task'ифицируется через интеловские примитивы и выполняется на фиксированном количетсве рабочих потоков) и windows threads (где каждый поток имеет свой контектс, который OS в любой момент может сменить на контекст другого потока). В терминологии создателя данной темы получается «многопоточность с кооперативной многозадачностью».
Другими словами, вы вашу работу разбиваете на задачи (чтение из файла/сокета, обработка чего-либо другого — без ограничений здесь), чем меньше гранулярность, тем лучше (поскоку распаллелизовываться будет лучше). Тело задачи не имеет ограничений, кроме одного условия — необходимо использовать примитивы синхронизации предоставленные библиотекой (использование стандартных примитивов не воспрещается). Далее, когда рабочий поток выполняя одну из ваших задач натыкается на блокирующее условие (например — мутекс залочен другой задачей, или ввод/вывод еще не закончился) рабочий поток автоматически переключается на следующую задачу из вашего списка задач, обеспечивая тем самым максимальный throughput ваших задач на заданном количестве рабочих потоков.

Из плюсов данного подхода можно отметить следующие:
— автоматическое скалирование на многоядерных машинах
— уменьшение времени синхронизации задач (так как происходит смена более легковесного контекста задачи, в отличие от контекста потока) и уменьшение contention'а ваших данных (поскоку в любой момент выполняется количество задач не большее чем количество рабочих потоков)
— в целом классе задач отпадает необходимость писать стейтмашины (в данном случае стейт сохраняется вместе с контекстом вашей задачи)
— более легковесные примитивы синхронизации чем нативные (самый маленький примитив занимает 2 бита)


Eсли есть вопросы, пишите.





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

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

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

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


R>И всё это становится кардинально не верным с появлением массовых многоядерных процессоров. Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потоками: здесь
Автор: remark
Дата: 20.09.07

R>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)

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


R>Потому что старые принципы многопоточности патологически не работают в новом контексте! Я уверен, что значительная часть многопоточных систем «старой школы» будут быстрее работать на многоядерном процессоре, если банально привязать все потоки программы к одному ядру! Т.к. синхронизация всё равно убивает потенциальный параллелизм, а разделение данных вносит коллосальные пенальти.

R>Некоторое время назад я был свидетелем следующей ситуации. Серверное ПО запустили на двух-процессорной машине (в надежде, что оно будет работать в 2 раза быстрее. ха-ха). Оно стало работать в 10 (!) раз медленнее (как потом оказалось причиной было постоянное разделение модифицируемых данных между двумя потоками).

R>Сейчас наиболее общий рецепт выглядит примерно следующим образом:

R> — Создать кол-во потоков по кол-ву аппаратных потоков. Как следствие — кол-во потоков не должно быть «зашито» в программу, т.к. она может выполняться на разных платформах. И как второе следствие – управление кол-вом потоков не должно быть заботой прикладного программиста (ну по крайней мере того же программиста, но когда он играет роль прикладного ).
R> — Работа должна быть распределена по потокам [примерно] равномерно. Соотв. это тоже не получится зашивать в программу и поручать прикладному программисту, т.к. кол-во потоков и кол-во и содержание работы меняться.
R> — Нельзя экстенсивно применять мьютесы/синхронизацию/блокировки. Т.к. это фактически заставит систему сериализоваться и выполняться «на одном ядре». Ни о какой масштабируемости тут не может быть и речи.
R> — По возможности надо элиминировать разделяемые данные. Совместная работа над одними модифицируемыми данными сейчас работает ооочень медленно и становится одним из важнейших новых боттлнеков аппаратной платформы, на ряду с тактами ядра, шиной к памяти, диском, сетью. И никаких изменений в лучшую сторону тут не предвидится. Только в худшую. (Это не относится к константным данным, их можно и нужно разделять между потоками)

R>Если выразить это более кратко: *каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.

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

R>Естественно могут иметь место и частные случаи. Например, приложение по обработке изображений или CAD/CAM/CAE/CASE. Тут скорее всего имеет смысл эффективно распараллеливать только одну основную функцию, например, обработку изображения, или рассчёт параметров модели (все остальные функции — графический интерфейс, фоновые задачи — по прежнему могут быть реализованы по старым принципам). Тут сейчас ситуация обстоит немного лучше. Тут (и только тут) на помощь могут придти такие средства как OpenMP, RapidMind, Intel TBB, Java Fork/Join и тд.:

R>www.openmp.org
R>www.rapidmind.com
R>osstbb.intel.com
R>gee.cs.oswego.edu/dl/papers/fj.pdf
R>К сожалению все эти средства подходят для очень ограниченного круга задач, и не подходят для реализации более общих и не типовых задач. И всё равно они не снимают с программиста основной задачи — что конкретно и как конкретно должно быть распараллелено. Это по прежнему должен решать программист, и он по прежнему должен обеспечить достаточное кол-во потенциального параллелизма, возможность для независимой работы потоков без разделяемых данных и т.д.

R>Есть ещё 2 вещи стоящие упоминания в данном контексте: готовые высокооптимизированные библиотеки и автоматическое распараллеливание кода.


R>Для решения типовых задач имеется ряд высокооптимизированных библиотек. Например можно посмотреть на:

R>Intel Integrated Performance Primitives (IPP):
R>http://www.intel.com/cd/software/products/asmo-na/eng/219767.htm
R>И AMD Performance Library (APL):
R>http://developer.amd.com/apl.jsp
R>Задачи, которые они могут решать включают:
R> — обработка/кодирование/декодирование видео
R> — обработка/кодирование/декодирование изображений
R> — обработка/кодирование/декодирование аудио
R>- операции над матрицами/векторами/строками
R>и т.д.
R>Понятно, что на общее решение такие библиотеки не тянут. Однако, если решаемая задача укладывается в возможности библиотеки, то имеет большой смысл применять такую библиотеку (Intel — платная, AMD — бесплатная).

R>Автоматическое распараллеливание кода.

R>Здесь не на что смотреть! Проходите, не задерживаетесь!
R>Сейчас автоматические распараллеливатели могут очень мало и очень конкретного. И вам всё равно придётся убеждаться, что распараллелилось то, что надо, так, как надо, и оно не ломается при последующих модификациях кода (напоминает борьбу с оптимизатором БД ). Фактически правильнее считать, что автоматического распараллеливания кода *нет*. Сейчас и в ближайшую декаду. Если кто-то утверждает обратное, то он либо не разбирается в вопросе, либо хочет вам что-то продать
R>За подробностями смотрите интервью с Джеем Хоефлингером, который занимается автоматическим распараллеливанием с середины 80:
R>http://www.thinkingparallel.com/2007/08/14/an-interview-with-dr-jay-hoeflinger-about-automatic-parallelization/


R>Подытожу. Мы сейчас находимся на перегибе развития. Что бы поспеть за развитием, а не попасть в кювет, надо многое переосмыслить и смотреть на вещи по новому. Новые принципы и подходы только формируются, ни у кого пока нет *универсальных* решений. Всё, что сейчас выдают за таковые, за универсальные решения для многоядерности (OpenMP, RapidMind, Intel TBB) — маркетинг. Ну, возможно, это лишь строительные блоки, но ни как не решение. Сейчас всё зависит исключительно от компетентности конкретного программиста, разрабатывающего конкретную систему.



R>Дополнительные ссылки для интересующихся:


R>Фундаментальная работа на тему, почему процессоры *не* будут становится всё быстрее и быстрее, и что делать теперь:

R>The Landscape of Parallel Computing Research: A View from Berkeley

R>Если кто ещё не читал — популярные заметки Герба Саттера:

R>The Free Lunch Is Over
R>The Pillars of Concurrency
R>How Much Scalability Do You Have or Need?

R>OpenMP Does Not Scale &mdash; Or Does It?. В очень забавной форме показываются проблемы, связанные с написанием параллельных программ.


R>How-to Split a Problem into Tasks. Как выявлять параллелизм в системе (подходит в основном для HPC).


R>Ещё интересные заметки Michael Suess:

R>Is the Multi-Core Revolution a Hype?
R>Moore’s Law is Dead &mdash; Long Live Moore’s Law!
R>How Much of the Industry Will Go Parallel?
R>Parallel Programming is Entering the Mainstream &mdash; or isn’t it?


R>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.