Re: xserver-xorg и hal
Anton Anikin -> debian-russian@lists.debian.org @ Tue, 5 May 2009 00:28:17 +0900:
>> >> Бывают. Но это очень специфический класс задач. И нет,
>> >> нижеприведенные примеры к таковым не относятся.
>>
>> AA> Хорошо, озвучьте тогда этот класс, если вас не затруднит.
>>
>> Я верю в осмысленность разделяемой памяти для баз данных. Для
>> беготни по индексам в условиях, когда mmap() работает на запись
>> неоптимально. А так как-то сходу больше и не приведу примеров...
AA> Разработкой БД не занимался, но вот для быстрой распределенной (в
AA> рамках SMP) обработки большого объема данных (когда обработка одной
AA> части не влияет на другую - как тупейший пример - возведение
AA> элементов матрицы в квадрат) - вполне применима.
... если эта матрица вообще в память лезет целиком (ибо если нет - то на
кой там shared memory? а нитки, кстати, при этом можно использовать, они
на этой задаче при правильном подходе от процессов практически не
отличаются). Но если матрица такая маленькая, что в память лезет
целиком, то от масштабирования на этой задаче проку немного...
AA> Или вместо последовательного запуска независимого фрагмента кода N
AA> раз (итерации в какой-нибудь счетном алгоритме как пример) в
AA> несколько потоков - тоже нормально. Лично я 2-мя строками с помощью
AA> openMP добавил в один из своих расчетных алгоритмов возможность
AA> использования всех доступных ядер без побочных эффектов и сегфолтов
AA> - это разве плохо? И я уверен, что мой код корректно отработает
AA> везде, где есть нитки и компилятор тянет openMP.
Если можно двумя строками включить, а главное - если что пойдет не так,
двумя строками отключить, то это не плохо. Это, кстати, скорее всего,
свидетельствует об архитектуре, под которой могут лежать и ни разу не
нитки. В конце концов, с точки зрения процессора разные процессы - это
тоже такие нитки, и память у них общая. Поэтому я бы не смешивал
программирование на нитках с программированием на чем-то, у чего _в
потрохах_ нитки. Это очень разные вещи...
--
Think of C++ as an object-oriented assembly language.
-- Bruce Hoult (bruce@hoult.actrix.gen.nz)
Reply to: