Comments | frotmnenogi: Разработка с использованием SIMT архитектур

frotmnenogi

Разработка с использованием SIMT архитектур

Nov 04, 2011 22:20

Введение.Развитие компьютерных технологий подошло пределу масштабирования за счет только линейного увеличения прироста быстродействия, наращивания размеров кеша, и роста количества ядер процессоров. Как неизбежность вошли в повседневность внешние сопроцессоры (GPU), как в свое время появились сопроцессоры на Intel процессорах. История повторяется, ( Read more... )

Comments 7

*-наци nponeccop November 5 2011, 08:38:22 UTC

GPGPU - это не SIMD, а смешанная модель SIMD+SPMD. См. первую страницу здесь:

http://www.rocksclusters.org/rocksapalooza/2006/lab-mpi.pdf

Причём в посте вы обсуждаете именно аспекты, связанные с SPMD (при SIMD по определению шедулинга нет). SIMD в GPGPU - это векторные инструкции.

Ещё вы употребили "синтаксис" всуе.

Re: *-наци frotmnenogi November 5 2011, 15:03:06 UTC

Да, верно. Как упрощенный вариант мне нравится предложенный NVidia - SIMT (Threads - последняя буква в акрониме). Внес исправления в заголовок, чтоб было не так многозначимо, как в контексте "современный SIMD"

nponeccop November 5 2011, 08:54:19 UTC

Теперь по сути. Вы не заметили фундаментального отличия вытеснения кода на GPGPU. Проблема больше похожа на проблему виртуальной памяти, чем на проблему CPU scheduling. Проблему быстродействия в условиях свопа так и не решили - по сути, решение свелось к отказу от свопа ( ... )

frotmnenogi November 5 2011, 15:40:14 UTC

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

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

Буду отвечать по одному пункту, чтобы не накидывать все в одну кучу.

frotmnenogi November 5 2011, 15:47:44 UTC

Проблема заключается в том, что программы на GPGPU имеют HPC-специфику, а именно им никогда не хватает ресурсов, и они написаны так, чтобы потреблять все имеющиеся ресурсы, сколько бы им не предоставляли. Представьте себе, что вы запускаете, скажем, БД-сервер с терабайтной базой. Он видит, что есть 64 гб памяти, и всю отъедает. Затем вы пускаете второй сервер с такого же порядка размером базы. И он тоже отъедает столько памяти, сколько установлено в системе.

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

frotmnenogi November 5 2011, 16:18:05 UTC

Понятно, что новым шедулером виртуальной памяти проблему быстродействия компьютера с двумя базами не решить - надо переделывать сами БД-сервера, чтобы вся доступная память делилась между серверами пропорционально их загрузке. Нужно не просто переделывать шедулер, а добавлять некий Baloon API, позволяющий серверам как-то самим модифицировать свои алгоритмы в соответствии с тем, что внезапно количество доступной памяти увеличилось или уменьшилось.Немного обобщу - речь может идти совсем не СУБД. Например, видео-обработка тоже весьма ресурсоемка. То есть речь идет о пользовательских программах и пользовательском коде. И есть очень великий риск, что в виду отсутствия общих стандартов, договориться они все же не смогут. Планировщик - это то, что есть у каждой ОС, есть и у виртуализаторов. Кстати, ОС, с точки зрения виртуализации, можно рассматривать как специфический пользовательский процесс, который имеет горсть завязанных только на него потомков ( ... )

Thread 5