Здравствуйте, RegisteredUser, Вы писали:

RU>Здравствуйте, remark, Вы писали:

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

RU>А как же array languages типа старый APL и новые J и K? Не уверен что их текущая реализация реально использует многоядерность (хотя за K не скажу, уж больно быстрый по слухам), Но принциально, в силу "нефоннеймовской" архитектуры, при правильной реализации и правильном стиле программирования (да, на J тоже циклами можно писать... но не нужно ), все теоретически должно работать...


Скорее всего ты говоришь о какой-то очень ограниченной области применения, либо вообще о HPC. К сожалению, этим сейчас страдают многие, которые кричат, что у них есть *решения для многоядерности*. Скорее всего их решения позволяют только "быстро перемножать матрицы неимоверных размеров" или что-нибудь такое. Как мне это поможет при написании сетевого сервера?! Или клиентского приложения? Ну нет у меня матриц на миллионы элементов и не надо мне ничего перемножать.

Здравствуйте, remark, Вы писали:

R>Здравствуйте, сипласплас, Вы писали:

С>>btw, после прочтения введения в lock/wait free Александреску мне показалось, что они хорошо ложатся на GC


R>Что значит "ложатся"? И что значит "хорошо"?
R>Определённо их можно реализовать в присутствии GC. Это даже немного легче.
R>Но их так же можно реализовать и без GC.
R>Моё личное мнение, что без GC будет быстрее и масштабируемее. Я не уверен, что какой-либо алгоритм GC может приблизиться к RCU.

??? Либо я совсем не в теме, либо GC помогает забить на memory management в RCU

R>Использование GC здесь (как в прочем и в остальных случаях) — это просто спихивание проблемы на другого, в надежде, что другой их как-то решит.


R>

Здравствуйте, minorlogic, Вы писали:

M>Совершенно забыл, что существует прослойка профи которая давно и успешно занимается распаралеливанием.

M>Это языки , програмисты, фреймворки для распределенных расчетах для суперкомпьютеров и распределенных вычислительных сетей. К сожалению инженеры для десктопов , не обращают на них должного внимания , и во многом пытаются изобрести велосипед.


Занимаются они этим долго, но дозанимались они только до того, как быстро перемножать матрицы неимоверного размера. Да, там у них действительно есть автоматическое распараллеливание и т.д.
Как мне это поможет при написании сетевого сервера?! Или развитого клиентского приложения?!
Дай этому профи, который давно занимается распараллеливанием, такую задачу и он войдёт в ступор. Скорее всего он начнёт у тебя спрашивать "ну где тут этот самый массив на миллиард элементов, который надо распараллелить?", или "над чём тут делать преобразование Фурье?"
А если задача что-нибудь посчитать, то есть средства типа OpenMP и иже с ним, их никто не игнорирует... если они всё-таки подходят.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, iZEN, Вы писали:

ZEN>>Вы сами проверяли?
ZEN>>А я проверял. Двухъядерный процессор рвёт одноядерный на одной и той же частоте (Athlon64 X2 2ГГц vs. AthlonXP 1,8ГГц) в компиляции исходников C/C++ компилятором GCC более чем в 2,5 раза (двадцать пять минут против полутора часов) -- масштабируемость фактически линейная при одинаковой латентности подсистмы памяти и кэша L2).
GZ>2,5 — не очень то линейно.
GZ>С GCС не работал. А он действительно компилирует многопоточно, или как VS2005 загружает по проекту на каждый проц?

Кха... Юниксовый make много... параллельный короче.
Пишешь make -j 2 и он компилирует в два раза быстрее.
Даже если в машине ОДИН процессор.
А если в машине два процессора, то надо писать make -j 4.
Во как.
Разгадка простая — пока один экземпляр gcc занимает процессор, второй читает/пишет данные с диска.

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, remark, Вы писали:

R>>Шутка шуткой, а на форумах посвящённым многопоточности сейчас один из самых распространённых вопросов «Почему моя программа, которая делает Х, на 4-ёх ядерной машине работает медленнее, чем на 1-ядерной?»

AF>Кстати, а где есть такие форумы?


comp.programming.threads (USENET):
http://groups.google.com/group/comp.programming.threads/topics

Threading on Intel® Parallel Architectures:
http://softwarecommunity.intel.com/isn/Community/en-us/forums/1042/ShowForum.aspx

Parallel.ru:
http://hp.parallel.ru/parBB/index.php

Thinking Parallel (блог, но много интересного, в комментах бывает что-то типа форума):
http://www.thinkingparallel.com/

Здравствуйте, GlebZ, Вы писали:

R>>Так думали при появлении процессора 1 МГц.
R>>Так думали при появлении процессора 10 МГц.
R>>Так думали при появлении процессора 100 МГц.
R>>Так думали при появлении процессора 500 МГц.
R>>Так думали при появлении процессора 1 ГГц.
R>>Так думали при появлении процессора 2 ГГц.
R>>Так думали при появлении процессора 3 ГГц.
R>>Так думают при появлении 4-ёх ядерного процессора 3 ГГц.
GZ>Двухядерный забыл. По двухядерному могу сказать что думал что будет лучше, а на деле оказалось что нет.

А что ты на нём запускал?

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, сипласплас, Вы писали:

С>>Ошибочные в том, что при любое присваивание ссылки ведет к full fence?

AF>Не ведет, конечно. Хотя меня интересовал другой вопрос — как обмениваться данными между ядрами, не залезая во внешнюю память. Ответ, боюсь — никак.

Обмен идёт через кэши.

Здравствуйте, remark, Вы писали:

R>Обмен идёт через кэши.

Есть какие-то другие виды обмена кроме того, который иницируется явно при помощи барьера памяти?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, remark, Вы писали:

R>>Если бы произошёл всемирный и вечный фича-фриз у производителей софта, то да, достаточно было бы выпустить ещё одно поколение процессоров и всё, его бы хватило бы на всегда.

VD>К сожалению даже "фича фриз" не поможет. Многие программы работают не так качественно как могли бы если бы производительность не была бы проблемой. Например, те же игрушки. Сейчас говорят о почти полной фотореалистичности и т.п., но пройдет 10 лет и все равно конца и края совершенству не будет.

Я имею в виду *полный* фича фриз. Т.е. не увеличивается фотореалистичность игр и т.д.
Я надеюсь, все понимают, что я это говорю иронично. Ключевое слово "Если бы".

Здравствуйте, remark, Вы писали:

R>dlmalloc:
R>http://gee.cs.oswego.edu/dl/html/malloc.html

Кстати, сам Дуг Ли советует для многопоточных программ использовать ptmalloc, производный от dlmalloc. Но он только Unix-овый.

А dlmalloc, по слухам, в большинстве Linux-ов является частью libc и поэтому там он как раз штатный аллокатор.

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, remark, Вы писали:

R>>Про диспетчер не понял, о чём ты.

AF>Я имел в виду, что если нужно распределять между ядрами части задачи, то нужен какой-то диспетчер, который будет это делать. А в его работе без разделяемых данных никак не обойтись.

Не обязательно


AF>Поэтому получается, что нет смысла делить между ядрами поиск элемента в массиве не очень большого размера, к примеру — из-за существующей архитектуры затраты на работу диспетчера съедят больше, чем выполнение задачи целиком на одном ядре (я правда не уверен, где тут лежит граница, с которой начинается хоть какой-то прирост производительности)

Распараллеливать работу на уровне отдельных машинных инструкций определенно не стоит.

Здравствуйте, Andrei F., Вы писали:

AF>В общем, не нравится мне архитектура. Ядер понапихали, а эффективных средств для координации не дали


Не слышу! Говори громче! В другое ухо мне очень громко кричит CEO из Intel, о том какое крутое они сделали новое поколение процессоров, и о том, какие все программисты тупые, что ни как не могут научиться эффективно их использовать, хотя уже прошёл целый год, и они написали целых 2 white paper, о том, что надо программировать как-то по-новому.

Здравствуйте, сипласплас, Вы писали:

E>>Но, на двух ядрах оказывается, что стоимость переключения контекста между нитью-обработчиком и нитью ACE_Reactor-а слишком высока, чтобы передавать входящий/исходящий трафик через очереди сообщений.

С>При чем здесь это? Чем оно дороже чем на одноядерной машине?

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

На 1 ядре atomic_xxx — это
— запретить прерывания — чтобы планировщик не вломился и не вытеснил поток
— выполнить операцию
— разрешить прерывания

А на многоядерном — это
— запретить прерывания
— заблокировать память — чтобы остальные ядра туда не выстрелили
— выполнить операцию
— разблокировать память
— разрешить прерывания

То есть, во-первых, танец становится длиннее, а во-вторых, он становится сольным.
Атомарная операция как-бы выполняется сразу во всех ядрах (в родном — содержательно, в остальных — вхолостую).

Здравствуйте, remark, Вы писали:

[]

Этот std::atomic появится в C++0x? Что мне сейчас делать? Какая у меня сейчас есть альтернатива Interlocked?

Здравствуйте, Константин Л., Вы писали:

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>>

КЛ>Что _это_? Это реальный код и мне пора на свалку? Откуда взялся этот std::atomic?


Сильно не напрягайся. Это примерный вариант реализации примитивов работы с памятью в C++0x.
Со слов Peter Dimov/Alexander Terekhov.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, remark, Вы писали:

КЛ>[]

Хотя вот Hans-J. Boehm говорит по-другому:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2381.html


КЛ>Этот std::atomic появится в C++0x? Что мне сейчас делать? Какая у меня сейчас есть альтернатива Interlocked?


К сожалению, *никакой*!

Можно пошариться по готовым библиотекам. Базовые Interlocked скорее всего можно будет найти. Можно ACE посмотреть.
С портируемыми барьерами памяти всё значительно хуже. В ядре линукса можно найти жалкое подобие с убогим С интерфейсом.
Скорее всего писать самому.

Здравствуйте, remark, Вы писали:

R>Не обязательно

И как ты себе это представляешь? На примере простой задачи поиска элемента в массиве простым перебором, например.

R>Распараллеливать работу на уровне отдельных машинных инструкций определенно не стоит.

см выше. У меня есть сомнения, что есть смысль параллелить эту задачу в рамках существующей архитектуры при размере массива < ~100 элементов. Может быть, даже 1000.

Здравствуйте, remark, Вы писали:

[]

R>К сожалению, *никакой*!

R>Можно пошариться по готовым библиотекам. Базовые Interlocked скорее всего можно будет найти. Можно ACE посмотреть.
R>С портируемыми барьерами памяти всё значительно хуже. В ядре линукса можно найти жалкое подобие с убогим С интерфейсом.
R>Скорее всего писать самому.

Но почему ты не делаешь барьер памяти?

R>

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, сипласплас, Вы писали:

E>>>Но, на двух ядрах оказывается, что стоимость переключения контекста между нитью-обработчиком и нитью ACE_Reactor-а слишком высока, чтобы передавать входящий/исходящий трафик через очереди сообщений.

С>>При чем здесь это? Чем оно дороже чем на одноядерной машине?

К>Дороговизна не в переключениях, а в атомарных операциях.

А я о чем?

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

[]

Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, remark, Вы писали:

R>>На x86 любое сохранение имеет неявный msync::rel барьер, который включает в себя msync::ssb. А любая загрузка имеет неявный msync::acq барьер, который включает в себя msync::ddacq.
R>>На других архитектурах возможно необходим msync::ssb барьер при сохранении указателя. А msync::ddacq не нужен нигде, т.к. он везде неявный.

AF>Не верю! (С)
AF>Ссылку на источник информации?


http://developer.intel.com/products/processor/manuals/318147.pdf

Радуйтесь. Intel снизошла до публикации оффициальной модели памяти x86 около месяца назад. Видимо освободилось немного времени между горыди ударами в грудь, криками какие крутые новые процессоры они выпустили, и криками, что все программисты тупые, т.к. не могут научиться эффективно использовать их процессры, хотя прошёл уже год после выпуска, и они написали столько пресс-релизов, о том, что теперь надо программировать как-то но-другому.
Елси бы у них ещё освободилось немного времени на ответы на вопросы на их форуме посвящённым их процессорам, было совсем замечательно, и возможно бы тогда тупые программисты всё-таки немного бы поумнели.
Ну это так... о наболевшем...