САБЖ.

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

Предлагаю обсудить всё о NUMA применительно к c++.

1. Кросс и не кросс-платформенные API.
2. Выделение/использование памяти.
3. Привязка потока к процессору.
4. Оптимизация в коде.
5. Паттерны.

Возможно обсуждение теории применительно к возможностям c++.

Отдельно (оффтоп к тематике форума, поэтому только ссылки) интересует времена доступа и другие характеристики таких систем с большим количеством процессоров (> 2).

По теме более конкретные вопросы.
Как сделать чтобы поток выполнялся только на заданном ядре или группе ядер?
Как выделить память в локальной области заданного ядра/группы ядер/процессора?

georain, Тема довольно актуальная.
Я юзаю MPICH. А какой смысл этой? Ну чтоб понять, нужно-ненужно, зачем, как, и для чего?

Что-то я не пойму твоего вопроса. "Этой" - это что? NUMA это не библиотека, это аппаратная архитектура.

Почитал: http://ru.wikipedia.org/wiki/Non-Uniform_Memory_Access
Но так и не понял, какое отношение это имеет к программингу?  

Добавлено через 1 минуту и 22 секунды

Да, уже почитал. Но зачем это программисту?

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

Хоть пару ссылочек дай.
Тема интересная, но чёт я о тако раньше не слышал. Жду ссылок, и иду учиться...  

Добавлю. Библиотеки MPI и OpenMP - это средства обмена данными, а проблема numa - это использование памяти. Поэтому основное внимание тут нужно уделять выделению памяти и её использованию из разных потоком. Локальность памяти.
Также интересуют языковые методы борьбы с потерей производительности на поддержке кешей процессоров в актуальном состоянии (Cache coherent).

Добавлено через 1 минуту и 52 секунды

Google -> NUMA. Тут нет ничего секретного. А вот про применительно к программингу в самом деле ничего особо нет.

Это сарказм?
Ну я внатуре впервые слышу!...

C++ к NUMA абсолютно не имеет никакого отношения
NUMA поддерживается через API системы

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

искал плохо
NUMA for windows
NUMA for linux

Это не совсем верно. NUMA сделан так чтобы поддерживаться API системы так, как будто его и нет вовсе, чтобы весь спектр программного обеспечения работал на этой архитектуре. Но при масштабировании (увеличении к-ва потоков) стандартного приложения на такой архитектуре его производительность будет падать и в итоге упрётся в "узкое место" - шину. При правильной организации памяти на уровне приложения масштабирование может происходить без потери производительности.

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

Нет это не сарказм. Дело в том что это не так давно стало актуально (год, максимум два). На само деле есть много информации как это работает и "советов" как надо под это писать, но практических примеров нет.

georain, 
еще раз говорю, С++ здесь не причем
а API как раз причем

Это сообщение отредактировал(а) MAKCim - 25.6.2008, 16:11

Ну как не причём. В numa
1. использование глобальных/общих данных - большие временные затраты
2. разная скорости чтения/записи разных данных из разных потоков

И то и другое решается средствами языка программирования.

ну если только в этом смысле
в остальном API, без него ЯП не поможет
в Linux, к примеру, есть два системных вызова для работа с NUMA
mbind() и set_mempolicy()

Это сообщение отредактировал(а) MAKCim - 25.6.2008, 16:40

А, в этом смысле да.
Хотя если пофилософствовать, что работает без API...

Пока нашёл только одну библиотеку под linux
http://www.x86-64.org/pipermail/discuss/2003-May/003528.html