А чего так мало 8-сокетных материнок?

Вы цены на 32 Гб модули видели?

з.ы. на 2-сокетной платформе все гораздо более весело.

и кстати кто сказал что у процессоров нет ограничения на объем памяти?

на десктопе интель такое точно делал.

8 сокетов от амд всяко были бы быстрее 4 от интела)))

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

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

Одну кучку слить в одну панораму, вторую кучку слить во вторую панораму и 2 панорамы сшить между собой.

«параллакс» знаешь такое?

И... что «параллакс»?

уже у двухпроцессорных память у каждого проца своя.

man NUMA

Видел) Самый дешевый 21к руб.
А вот 16гб модули уже по 4.5-5.5к руб.

Ограничения есть. Но мы же не об «ай семь» тут говорим.
Е5-4ххх от 512гб на камень тянут.

уже у двухпроцессорных память у каждого проца своя.

Агащаз.

man NUMA

сам man NUMA :) И его отличия от ccNUMA..

Я не совсем понял о чем именно ты.

http://ekburg.artstudio-3d.ru (только флеш, на хтмл5 буду через месяц переводить). народ спрашивает «почему ты три панорамы не сшил в одну общую?» ответ в параллаксе. Если точки съемки удалены друг от друга, то физически не возможно без искажений и косяков собрать воедино. Грубо говоря с одной точки съемки я вижу только левую стену здания, а с другой - только правую.

Несколько метров для высокой крыши еще можно разнести точки. Но когда это десятки и сотни метров. то воедино никак не сшить.

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

а есть уверенность что 2 e5-2670 его не порвут?

расчетные модули на 26XX я видел, а вот на 4ХХХ нет

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

у каждого процессора своя память.

поскольку контроллер памяти в проце.

то что один проц может дотянуться до памяти другого это уже другой вопрос.

У меня и такая теория была. Но там какой-то хитрый вопрос еще с датами фоток)

А описанное тобой - это будет только оверхед. А местами и невозможно. Сшивалка не умеет как сырье принимать файлы в сотни килопикселей по стороне.

А это большой оверхед дает? Когда процы друг друга дергают?

честно не измерял и даже не проверял как у меня работает.

по-идее на амд с Open3.0 проблем должно быть меньше, как у интела связаны между собой процы честно не вникал.

А это большой оверхед дает? Когда процы друг друга дергают?

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

Дальше, если у тебя один поток на одном процессоре инкрементирует общий счётчик одновременно с другим потоком, что они делают? Каждый из них считывает значение счётчика из памяти (например там сейчас значение 42), затем производит над ним математическую операцию и записывает обратно в RAM. Но когда один поток записывает новое значение (43) в RAM, оказывается что другой туда уже записал своё 43. И эту коллизию надо разруливать как-то или избегать посредством блокирования одного ядра пока операция с общей памятью не завершится. Это не ускоряет быстродействия.

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

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

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

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

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

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

только ты это все описал для классических блокирующих алгоритмов, если авторы ПО накурились fork-join (что очень врядли) то описанные коллизии будут только на этапе join, при определенных условиях выигрыш будет

а вообще все эти многоядерный штуки хороши для request-ориентированных систем (веб, базы и т.п.)

сшивка панорамы - это работа с геометрией (трансформация кадров). 1 панорама и панорама_из_двух_частей - это две разных геометрии.

только никто не мешает трансформацию проводить для каждого кадра в отдельном потоке - тут то у тебя и будет задачка для каждого ядра

Ну по идее все так и делают - тестируют свою задачу на целевой конфигурации и по результатам принимают решение покупать это железо или нет. Связывайся с продавцами железа.

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

только ты это все описал для классических блокирующих алгоритмов, если авторы ПО накурились fork-join (что очень врядли) то описанные коллизии будут только на этапе join, при определенных условиях выигрыш будет

Сам-то понял что сказал? А то я нет..

только никто не мешает трансформацию проводить для каждого кадра в отдельном потоке - тут то у тебя и будет задачка для каждого ядра

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

а зачем в общей?