Да это понятно как она расшифровывается.. Только есть большие сомнения что оно применимо на кластерах, в которых вычисления распределяются по большому количеству несильно связанных дешёвых машин.
Когда UNIX-машина начинает работать на свопе - это уже проблема, которую нужно решать немедленно, а насколько сетка быстрее - это ещё вопрос. В больших системах ведь и файловая система не на локальном винте живёт, скорее всего там окажется внешний супернаворочанный рейд для этих целей подключен.
Страйп был в старых HP-шных реализациях (лет этак 10 назад, до ccNUMA).. Насколько я понимаю, всё что этим достигается - скорость доступа к памяти можно считать постоянной и эквивалентной скорости доступа к нелокальной памяти. Хотя при этом остаётся открытым вопрос нахера оно такое нужно вообще. Скорости вроде не должно добавлять если выравнивается по доступу к памяти к самому медленному, и проблему совместного доступа тоже не решает.
Ведь сама физическая память не обслуживает процессы одновременно, следовательно запросы строятся в очередь. Допустим твои интенсивные вычислительные процессы (ага, интенсивные - иначе зачем кластер) постоянно доступаются к памяти. Память медленнее современных процов, значит один процесс может её занять на 100%. Но, допустим даже, процессу нужно всего лишь 20% полосы. Сколько процессоров сможет работать одновременно с данным куском памяти? Ага, пять. Больше процессоров - процессоры будут ждать шины, 10 процессоров будут половину своего времени ждать байта с шины.
А ведь есть и логический уровень при котором процессы в памяти неатомарно читают и пишут чего-нибудь с точки зрения программы осмысленное. И если твой процесс что-то там из памяти читает, а другой туда в то же время чего-то пишет - просто так ведь ничего хорошего не получится. Значит программа должна память блокировать, семафоры-мьютексы использовать и какую часть времени процессы будут висеть на этих мьютексах в ожидании своего шанса почитать/пописать память - одному богу известно, может у них больше времени на синхронизацию будет больше времени уходить чем собственно на работу.
Т.е. чтобы многочисленные процессы могли эффективно сотрудничать в рамках одной задачи, они должны минимизировать доступ к общим ресурсам, решать свою часть задачи по возможности локально - но тогда и NUMA какбэ не нужна, раз доступ к общим ресурсам минимален. Я так думаю..
Re: что в ваше понимании является кластером?
Да это понятно как она расшифровывается.. Только есть большие сомнения что оно применимо на кластерах, в которых вычисления распределяются по большому количеству несильно связанных дешёвых машин.
Когда UNIX-машина начинает работать на свопе - это уже проблема, которую нужно решать немедленно, а насколько сетка быстрее - это ещё вопрос. В больших системах ведь и файловая система не на локальном винте живёт, скорее всего там окажется внешний супернаворочанный рейд для этих целей подключен.
Страйп был в старых HP-шных реализациях (лет этак 10 назад, до ccNUMA).. Насколько я понимаю, всё что этим достигается - скорость доступа к памяти можно считать постоянной и эквивалентной скорости доступа к нелокальной памяти. Хотя при этом остаётся открытым вопрос нахера оно такое нужно вообще. Скорости вроде не должно добавлять если выравнивается по доступу к памяти к самому медленному, и проблему совместного доступа тоже не решает.
Ведь сама физическая память не обслуживает процессы одновременно, следовательно запросы строятся в очередь. Допустим твои интенсивные вычислительные процессы (ага, интенсивные - иначе зачем кластер) постоянно доступаются к памяти. Память медленнее современных процов, значит один процесс может её занять на 100%. Но, допустим даже, процессу нужно всего лишь 20% полосы. Сколько процессоров сможет работать одновременно с данным куском памяти? Ага, пять. Больше процессоров - процессоры будут ждать шины, 10 процессоров будут половину своего времени ждать байта с шины.
А ведь есть и логический уровень при котором процессы в памяти неатомарно читают и пишут чего-нибудь с точки зрения программы осмысленное. И если твой процесс что-то там из памяти читает, а другой туда в то же время чего-то пишет - просто так ведь ничего хорошего не получится. Значит программа должна память блокировать, семафоры-мьютексы использовать и какую часть времени процессы будут висеть на этих мьютексах в ожидании своего шанса почитать/пописать память - одному богу известно, может у них больше времени на синхронизацию будет больше времени уходить чем собственно на работу.
Т.е. чтобы многочисленные процессы могли эффективно сотрудничать в рамках одной задачи, они должны минимизировать доступ к общим ресурсам, решать свою часть задачи по возможности локально - но тогда и NUMA какбэ не нужна, раз доступ к общим ресурсам минимален. Я так думаю..