Здравствуйте, сипласплас, Вы писали:
С>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, сипласплас, Вы писали:
С>[]
R>>После "захвата" _shared в ThreadProc() надо просто проверить на null. InterlockedXXX здесь не нужен. R>>И это надо сделать в люом случае в такой ситуации, даже если обращения к _shared защищено мьютексами.
С>А если заменить _shared = null на _shared = new SharedResource()? Ты понял о чем я?
Тогда это можно сделать без InterlockedXXX. И без барьеров памяти вообще на x86.
Просто обычное сохранение/загрузка указателя.
R>>
Здравствуйте, сипласплас, Вы писали:
С>Ошибочные в том, что при любое присваивание ссылки ведет к full fence?
Не ведет, конечно. Хотя меня интересовал другой вопрос — как обмениваться данными между ядрами, не залезая во внешнюю память. Ответ, боюсь — никак.
С>Вау! Какой слог!
Здравствуйте, сипласплас, Вы писали:
С>>>>>Ты у себя в программе вот так спокойно делаешь с поинтерами, к которым идет доступ из разных тредов?
R>>>>На x86 да, а почему бы и нет? Это экстремально быстро.
С>>>remark, а memory barrier? Или это я один тут параноик?
R>>Нет, я тоже параноик. R>>Но на x86 тут можно и нужно делать без барьеров.
С>Почему?!
Скетч кода примерно такой (в терминах С++):
std::atomic<int*> p;
void thread1()
{
int* p2 = new int();
p.store(p2, std::msync::ssb); // sink-store barrier -- release not affecting loads
}
void thread2()
{
int p2 = p.load(std::msync::ddacq); // acquire with data dependency
}
На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq.
На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.
Здравствуйте, iZEN, Вы писали:
ZEN>Да только что нашёл в Google, что такое ACE. Примочка на C++ для решения вдруг возникших проблем с управлением нагрузкой многоядерных процессоров.
з.ы. ACE существует с 1993 года и является самой портируемой С++ библиотекой, и одной из самых распространённых. Для сведения.
Здравствуйте, Andrei F., Вы писали:
R>>>>А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.
С>>>Ты у себя в программе вот так спокойно делаешь с поинтерами, к которым идет доступ из разных тредов?
R>>На x86 да, а почему бы и нет? Это экстремально быстро.
AF>Тут будет возможна ситуация, когда на другом ядре обновленное значение указателя уже будет в кэше, а сами данные, на которые он указывает — нет. Поэтому на многоядерной системе так делать нельзя. На одноядерной можно, но тоже есть ограничение — переменная с указателем должна быть правильно выровнена.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, сипласплас, Вы писали:
С>>Здравствуйте, remark, Вы писали:
R>>>Здравствуйте, сипласплас, Вы писали:
С>>[]
R>>>После "захвата" _shared в ThreadProc() надо просто проверить на null. InterlockedXXX здесь не нужен. R>>>И это надо сделать в люом случае в такой ситуации, даже если обращения к _shared защищено мьютексами.
С>>А если заменить _shared = null на _shared = new SharedResource()? Ты понял о чем я?
R>Тогда это можно сделать без InterlockedXXX. И без барьеров памяти вообще на x86. R>Просто обычное сохранение/загрузка указателя.
Здравствуйте, iZEN, Вы писали:
ZEN>Что системное программирование: то, что работает в режиме ядра -- это прежде всего драйверы и шедулер аппаратных потоков исполнения.
Ok. Значит remark говорил о прикладном программировании.
(Хотя в начале 90-х в курсе по системному программированию в университеты мы изучали компиляторы. Ну да ладно, времена меняются).
ZEN>Да только что нашёл в Google, что такое ACE. Примочка на C++ для решения вдруг возникших проблем с управлением нагрузкой многоядерных процессоров.
Нужно Дугласу Шмидту написать о том, чем на самом деле является The ADAPTIVE Communication Environment. А то вот он чего понаписал:
The ADAPTIVE Communication Environment (ACE) is a freely available, open-source object-oriented (OO) framework that implements many core patterns for concurrent communication software. ACE provides a rich set of reusable C++ wrapper facades and framework components that perform common communication software tasks across a range of OS platforms. The communication software tasks provided by ACE include event demultiplexing and event handler dispatching, signal handling, service initialization, interprocess communication, shared memory management, message routing, dynamic (re)configuration of distributed services, concurrent execution and synchronization.
ACE is targeted for developers of high-performance and real-time communication services and applications. It simplifies the development of OO network applications and services that utilize interprocess communication, event demultiplexing, explicit dynamic linking, and concurrency. In addition, ACE automates system configuration and reconfiguration by dynamically linking services into applications at run-time and executing these services in one or more processes or threads.
(это я по поводу вашего "вдруг возникших проблем" прикалываюсь).
ZEN>На его основе что-либо системное сделали (работающее в ядре ОС) или делают только приложения, так как на основе Pthreads и LWP? (Инетресуюсь, потому что хочу провести/или не провести черту применимости ACE между системным и прикладным использованием)
ACE работает поверх имеющихся системных средств (т.е. поверх pthreads, LWP, WinThreads и т.д.).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, iZEN, Вы писали:
ZEN>Вы сами проверяли? ZEN>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).
2,5 — не очень то линейно.
С GCС не работал. А он действительно компилирует многопоточно, или как VS2005 загружает по проекту на каждый проц?
ZEN>Но всё это костыли. Если всё рабочее окружение отправить в своп, а при загрузке компьютера оотуда всё доставать в оперативку... Но можно использовать энергонезависимое ОЗУ большой ёмкости (несколько гигабайт) и отказаться от винчестера вообще, тогда все установленые приложения и система фактически имеют включенную готовность, как радиоприёмник.
Очень похоже на Висту
Здравствуйте, Andrei F., Вы писали:
AF>Тут будет возможна ситуация, когда на другом ядре обновленное значение указателя уже будет в кэше, а сами данные, на которые он указывает — нет. Поэтому на многоядерной системе так делать нельзя. На одноядерной можно, но тоже есть ограничение — переменная с указателем должна быть правильно выровнена.
Это касается не только указателей, но и обычных данных. x86 берет на себя всю ответсвенность за кэш. Попробуй сделать тест — записывать в одну и ту же память двумя процами. А потом в разную (главное чтобы подальше, по крайней мере 256 байт от нее). Познаешь то, с чем в одном проекте мне приходится бороться.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, remark, Вы писали:
AF>А какие сейчас есть средства для синхронизации работы ядер? Можно ли например передавать данные между ядрами, не затрагивая при этом основную память? А то если диспетчеру придется постоянно делать полную синхронизацию всех кэшей, то это на корню убьет преимущества от распараллеливания, когда фрагменты задачи невелики по времени выполнения....
Если ты имеешь в виду явный мессаджинг, то на Intel/AMD такого нет.
Но. Данные передавать между кэшами минуя основную память можно. Обычно так и происходит. Передача данных между ядрами обеспечивается протоколом когерентности кэшей. Сейчас обычно не происходит и блокировки шины памяти при InterlockedXXX операциях, обычно происходит блокировка строк кэша.
... правда передача данных между кэшами, без затрагивания основной памяти, медленнее, чем загрузка из основной памяти
Основная идея следующая — обращений к разделяемым структурам должно быть минимально необходимое кол-во. Совсем без них, естественно, не обойтись. Но если их мало, то это не ударит по производительности и масштабируемости.
Тут как с аллокацией памяти, например. Аллокация памяти относительно дорогая операция. Если их делать тысячи на транзакцию. А если их 10 на транзакцию, то сервер всё ещё способен обрабатывать десятки тысяч транзакций в секунду.
Про диспетчер не понял, о чём ты.
При распараллеливании, естестевенно, гранулярность должна быть не fine-grained, не coarse-grained, а fine-grained
Здравствуйте, GlebZ, Вы писали:
GZ>Это касается не только указателей, но и обычных данных. x86 берет на себя всю ответсвенность за кэш. Попробуй сделать тест — записывать в одну и ту же память двумя процами. А потом в разную (главное чтобы подальше, по крайней мере 256 байт от нее). Познаешь то, с чем в одном проекте мне приходится бороться.
Здравствуйте, AVM, Вы писали:
AVM>IMHO самое основное, что мешает жить и что является первичной проблемой — как разделять данные.
Я это и говорю:
*каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*.
AVM>Когда еще был студентом мой знакомый работал в одном НИИ который занимался разработкой многопроцессорных систем и знакомому (а он потом подключил меня к этой работе) предложили принять участие в разработке транслятора для многопроцессорных систем. AVM>Основная идея которую туда пытались заложить — при написании кода можно было указать, может ли этот кусок код выполняться параллельно (если да — при каких условиях) и что является событием для запуска этого куска на выполнение.
AVM>Основной проблемой было как грамотно организовать распределение данных между потоками выполнения — это сильно затрагивает алгоритмы обработки данных.
AVM>К сожалению НИИ был настигнут молодым капитализмом с советским лицом и финансирование темы прикрыли. Работы через несколько лет продолжились и сейчас есть результаты — вот только люди, которые это делают рассказать ничего конкретного не могут — у них на работе интернета нет.
Скорее всего они занимаются распараллеливанием какого-то подмножества задач. Или вообще HPC.
Что-то разговоры о проблемах программирования в условиях многоядерности напоминают мне шумиху вокруг перехода на Win32. Тогда так же было много шума. Многие выгоды сулили. Мол не будет для ваших данных барьеров в 64K, будут доступны файлы объемом свыше 2Gb и пр.
А в итоге -- многих ли этот переход действительно серьезно затронул? Я вот помню, что были некоторые проблемы у тех, кто писал приложения в чистом WinAPI и без распаковщиков сообщений. Тогда действительно превращение wParam в 32-х битовое значение из 16-ти битового и соответствующе изменение ряда Windows-сообщений требовало правки кода. Но те, кто пользовался объектными обертками вокруг WinAPI этого, возможно, даже и не заметили.
Так и сейчас. Что-то будет, а что не понятно. Неизвестность пугает. Хотя, подозреваю, для большинства из нас может вообще ничего не измениться.
Ну действительно, много кому приходится заниматься распределением работы приложения по десятку-другому потоков? Сейчас ведь столько всего упрятано в фреймворки, в сервера приложений, в сервера баз данных, что разработчику не так уж не сильно приходится заботится о распараллеливании чего-либо.
Да и ради чего это распараллеливание нужно? Для общей скорости работы ПО?
Во времена, когда под написанное на Ruby (!) web-приложение выделяются тысячи (!) серверов кто будет заботиться об увеличении скорости работы за счет усложнения разработки?
Конечно, кто-то занимается большими вычислениями. Типа прогнозов погоды или моделирования ядерных взрывов. Кто-то занимается кодированием видео/аудио (вот когда AutoGuardianKnot перекодирует фильмы, он запускает lame, а тот пишет, что мол используются ASM-модули и MMX, SSE расширения, в будущем будет писать -- running on 2/4/8/80 cores), кто-то еще чем-то ресурсоемким. Но ведь они уже давно используют специализированные инструменты (вроде PVM и MPI). Ну будут ими востребованны еще OpenMP, TBB и какая-нибудь другая специализированная хрень. Однако вопрос в том, сколько их, этих разработчиков, которые постоянно нуждаются в увеличении числа доступных им ядер?
А может быть все наоборот? Может быть осваивание большого количества ядер станет новой нишей, как в свое время Web? Сомнительно, однако.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, сипласплас, Вы писали:
R>>Единственное, что будет быстрее в случае процессов — это однопоточный рантайм в каждом процессе. Но это из-за тупого реплицирования всех данных. Я думаю, что основная проблема тут это — аллокация памяти. Но я надеюсь, что ты не используешь стандартный аллокатор памяти из crt в многопоточных программах?
С>А какой надо использовать?
Здравствуйте, remark, Вы писали:
R>Если бы произошёл всемирный и вечный фича-фриз у производителей софта, то да, достаточно было бы выпустить ещё одно поколение процессоров и всё, его бы хватило бы на всегда.
К сожалению даже "фича фриз" не поможет. Многие программы работают не так качественно как могли бы если бы производительность не была бы проблемой. Например, те же игрушки. Сейчас говорят о почти полной фотореалистичности и т.п., но пройдет 10 лет и все равно конца и края совершенству не будет.
Кроме того есть проблема сложности. Одна и та же задача может быть решена совершенно с разными трудозатратами если выбирать более прямые методы решения. Ну, скажем у первых писюков была сегментная организация памяти и памяти явно было очень мало. Это вынуждало тратить тонну времени на то чтобы изобретать способы того как решить задачу в данных условиях. Сейчас у меня на машине 2Гб оперативки и я для многих задач могу выбрать весьма простые решения (скажем скачать 100 мегабайтный файл в память). Ранее я этого не мог. Далее, когда будет 1Тб пмяти я смогу, скажем использовать позиционную сортировку для int32. Сегодня это выглядит бредом. (в прочем может так будет и завтра ).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
R>Про диспетчер не понял, о чём ты.
Я имел в виду, что если нужно распределять между ядрами части задачи, то нужен какой-то диспетчер, который будет это делать. А в его работе без разделяемых данных никак не обойтись. Поэтому получается, что нет смысла делить между ядрами поиск элемента в массиве не очень большого размера, к примеру — из-за существующей архитектуры затраты на работу диспетчера съедят больше, чем выполнение задачи целиком на одном ядре (я правда не уверен, где тут лежит граница, с которой начинается хоть какой-то прирост производительности)
В общем, не нравится мне архитектура. Ядер понапихали, а эффективных средств для координации не дали
Здравствуйте, сипласплас, Вы писали:
С>btw, после прочтения введения в lock/wait free Александреску мне показалось, что они хорошо ложатся на GC
Что значит "ложатся"? И что значит "хорошо"?
Определённо их можно реализовать в присутствии GC. Это даже немного легче.
Но их так же можно реализовать и без GC.
Моё личное мнение, что без GC будет быстрее и масштабируемее. Я не уверен, что какой-либо алгоритм GC может приблизиться к RCU.
Использование GC здесь (как в прочем и в остальных случаях) — это просто спихивание проблемы на другого, в надежде, что другой их как-то решит.
[]
R>Скетч кода примерно такой (в терминах С++):
R>
R>std::atomic<int*> p;
R>void thread1()
R>{
R> int* p2 = new int();
R> p.store(p2, std::msync::ssb); // sink-store barrier -- release not affecting loads
R>}
R>void thread2()
R>{
R> int p2 = p.load(std::msync::ddacq); // acquire with data dependency
R>}
R>
R>На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq. R>На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.
Что _это_? Это реальный код и мне пора на свалку? Откуда взялся этот std::atomic?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Зато при использовании процессов ты гарантированно: R>> — Имеешь очень дорогое взаимодействие. Это скорее всего будет 2 системных вызова, 2 полных копирования данных, плюс ещё синхронизация и ещё куча непонятно чего. Более-менее не так ужасно тормозно это может быть только с IO-Lite: R>>http://www.usenix.org/publications/library/proceedings/osdi99/full_papers/pai/pai.pdf R>>Хотя его видимо никто не использует. R>>В случае же потоков это может действительно очень-очень-очень быстро. Порядка нескольких тактов. R>> — Имеешь копии read-mostly данных в памяти и каждого процесса. И в кэше. R>> — Имеешь сложность запуска/остановки/настройки приложения.
E>Зато имеешь возможно безболезненно килять сбойные процессы. Тогда как в многопоточном приложении придется убивать всех.
В пределе можно сделать что-то типа такого:
Приложение реализовано на основе процессов, но для константных данных отводится отдельная разделяемая память, которой пользуются все процессы. А для обмена сообщениями используются отдельные "окна" разделяемой памяти, т.к. эти "окна" ограничены, то данные в них можно полностью верифицировать.
Т.о. образом получается лучшее от двух миров — в большинстве своём процессы изолированы и их можно убивать отдельно, с другой обмен идёт быстро и данные не дублируются.
... правда сбойный процесс может попортить разделяемую память, это не приведёт к падению остальных процессов, но работать они будут не корректно.
... в прочем это же может произойти и при полной изоляции, если сбойный процесс будет слать сообщения с некорректными данными...
Здравствуйте, remark, Вы писали:
R>На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq. R>На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.
