Re[3]: Закон eao-remark'а
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 12:38
Оценка: 13 (2) +2 :))) :))) :))
Здравствуйте, eao197, Вы писали:

E>У вас 1600 ядер? Мы поможем вам загрузить их все своими медленными программами!



Закон eao-remark'а:

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



Первое следствие из закона eao-remark'а:

Эффективность программ падает в 2 раза каждые 18 месяцев.




1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Автоматическое распараллеливание (было "Что почитать...")
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 07:59
Оценка: 10 (4)
Здравствуйте, Michael7, Вы писали:

M>Я бы отдельно выделил важную тему ленивых (отложенных) вычислений (lazy evolution).


M>Познакомиться с концепцией можно, например по этой статье на русском языке:

M> Джонатан Бартлет, — Ленивое программирование и ленивые вычисления

M>Тема важная, потому что это путь к написанию автоматически распараллеливаемого кода, что до некоторой степени освещено, например в этой статье: An operational semantics for parallel lazy evaluation



Меня в этом вопросе интересовала реализация этого дела и организация ран-тайм системы поддержки. Поэтому со своей стороны могу дать ссылки, касающиеся именно реализации:
Lazy Threads: Compiler and Runtime Structures for Fine-Grained Parallel Programming:
http://www.eecs.berkeley.edu/Pubs/TechRpts/1997/CSD-97-975.pdf

Cilk: An Efficient Multithreaded Runtime System:
http://supertech.csail.mit.edu/papers/cilkjpdc96.pdf


По поводу "автоматически распараллеливаемого кода". Это, конечно, очень громко сказано. Параллельные диалекты Lisp (QLisp, Multilisp etc) существуют с начала 80-ых годов, однако никакого "автоматического распараллеливания" нет и по сей день.

Непосредственно "автоматическое распараллеливание" сейчас есть только для *очень* ограниченного круга задач. Например, компилятор успешно выделяет "цикл" (легко), и успешно понимает, что все итерации независимы (сложно, в общем случае — невыполнимо), тогда компилятор может сгенерировать "параллельный" код. Очевидно, что полагаться на это в промышленной разработке *нельзя*, это не более, чем "игрушка".

"Псевдо-автоматическое распараллеливание" возможно, когда пользователь явно указывает в программе "потенциальный" параллелизм, а компилятор/ран-тайм заставляют его реально выполняться параллельно. К этому типу относятся все эти lazy-вычисления, futures, активные объекты и т.д. Но фактически тут вся работа остаётся на программисте. У компилятора тут маленькая задача. У компилятора тут, как ни странно, задача даже больше не "сделать" параллелизм, а "подавить" параллелизм.

Для таких областей, как, например, серверное ПО, ни о каком "автоматическом распараллеливании" говорить не приходится. И на горизонте ничего не предвидится. Тут всё, начиная от архитектуры и заканчивая структурами данных, лежит полностью на разработчике.

Так же такие области, как game-dev, где требуется 100% отдача от железа, не полагаются на автоматическое распараллеливание. Т.к. тут не устраивает ситуация, что "компилятор наверное что-то как-то распараллелит".

No silver bullet!



21.04.08 17:30: Ветка выделена из темы Автоматическое распараллеливание
Автор: remark
Дата: 14.04.08
— Хитрик Денис

1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Автоматическое распараллеливание (было "Что почитать...")
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 15:03
Оценка: 3 (2) :)
Здравствуйте, Michael7, Вы писали:

R>>Так же такие области, как game-dev, где требуется 100% отдача от железа, не полагаются на автоматическое распараллеливание. Т.к. тут не устраивает ситуация, что "компилятор наверное что-то как-то распараллелит".


M>Я вот ещё, что имел ввиду, затронув тему автоматизации распараллеливания, в свете будущих перспектив промышленного программирования для работы с многопроцессорными (многоядерными) системами.

M>Существуют прогнозы, что в ближайшее время (5, 10 лет) нас ожидает скачкообразный рост количества ядер на одном процессоре, вплоть до нескольких сотен ядер где-нибудь к 2015 году. Собственно, например архитектуру Cell или GPGPU можно рассматривать как первую ласточку. А несколько десятков ядер уже есть даже в Roadmap-ах производителей.


Полностью согласен:
http://gzip.rsdn.ru/?forum/?group=cpp


M>Хотя программы с мультипараллельными вычислениями пишут уже довольно давно, ведь кластеры, суперкомпьютеры и сети распределённых вычислений (вроде SETI) появились не сегодня, писать их сложнее и дороже, чем обычные, да и количество программистов, способных их написать невелико. Здесь же имеющийся опыт "обычных" пограммистов не всегда поможет, написание даже двух- четырех-поточной программы для истинно параллельного исполнения на нынешних двух-четырех-ядерниках уже имеет свои тонкости.



HPC-сообщество работает над немного другими задачами нежели большинство "обычных" программистов, и они работали на немного других аппаратных платформах, и даже там они не решили все вопросы. Поэтому я *не* считаю, что кто-там всё уже давно решил, а мы тут сидим и тупим просто потому что не знаем, что решение уже как 100 лет есть.


M>В этой связи языки и технологии, вроде Haskell, Lisp с параллельным исполнением и т.п., которые сейчас слишком расточительно расходуют ресурсы, могут оказаться востребованными. Если код на них работает, допустим в 5 — 10 — 20 раз медленее, чем на Си это часто неприемлемо медленно, особенно в вычислительных задачах, но если они позволят программисту быстро написать параллельно исполняющуюся программу на 1600 ядрах это будет всё-равно в 160 раз эффективнее, чем работа однопоточной программы.


M>То есть в случае массового распространения сильно многоядерных систем может быть экономически оправдано легкое распараллеливание и не беда, что эффективность может оказаться в размере 10% от пиковой, будет полно задач, где это допустимо.



У языков типа Haskell, Lisp, несомненно, есть некоторые приемущества. НО. Как ты правильно заметил, они не всегда могут генерировать оптимальный код для однопроцессорной мышины, и могут работать в 10 раз медленнее. Многопроцессорность вносит совершенно новые перпендикулярные аспекты:
— эффективность реализации распараллеливания/синхронизации — если это сделать "не подходящим" образом, то можно получить замедление *ещё* в 10-100 раз.
— гранулярность и состав параллельных частей — если это сделать "не подходящим" образом, то можно получить замедление *ещё* в 10-100 раз.
— принципиальная возможность к масштабированию — наличие нескольких процессоров само по себе не даёт ускорения, скорее даже наоборот — по-умолчанию получается замедление (можешь спросить у eao197 ). *Автоматически* выжать из системы масштабирование совсем не просто, это далеко не просто выделение частей, которые формально безопасно выполнять параллельно.


Безусловно сообщество функциональных языков будет над всем этим работать. В нём очень много умных людей. Допустим даже лет через 10 они доведут эти *дополнительные* накладные расходы до 10х раз. Т.е. получим 10*10 = 100х замедление. Это достаточно сложно оправдать, даже имея 160 процессоров — т.е. программа будет работать как на 1.6 процессорах. Уж проще использовать мой любимый способ ускорения многопоточных программ "SetProcessAffinityMask(GetCurrentProcess(), 1)"



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: Автоматическое распараллеливание (было "Что почитать...")
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.04.08 09:52
Оценка: :))
Здравствуйте, Michael7, Вы писали:

M>В этой связи языки и технологии, вроде Haskell, Lisp с параллельным исполнением и т.п., которые сейчас слишком расточительно расходуют ресурсы, могут оказаться востребованными. Если код на них работает, допустим в 5 — 10 — 20 раз медленее, чем на Си это часто неприемлемо медленно, особенно в вычислительных задачах, но если они позволят программисту быстро написать параллельно исполняющуюся программу на 1600 ядрах это будет всё-равно в 160 раз эффективнее, чем работа однопоточной программы.


У вас 1600 ядер? Мы поможем вам загрузить их все своими медленными программами!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Автоматическое распараллеливание (было "Что почитать...")
От: WolfHound  
Дата: 16.04.08 14:23
Оценка: 28 (1)
Здравствуйте, remark, Вы писали:

WH>>Если немного усложнить шедуллер и добавить приоритеты можно будет делать совсем веселые вещи.

WH>>Допустим если сделать 4 уровня приоритетов то высший (3) резервируем за процессором (см дальше), 2 допустим можно назначать обработчикам аппартаных прирываний, 1 реалтайм потокам и 0 нереалтайм потоками.
WH>>Ни о какой сраведливости задумываться не надо это работа ОС. Просто АЛУ переключается между своими потоками с максимальным приоритетом.
R>А как быть с голоданием?
А ни как. Если ОСь выставила высокий приоритет одному из потоков на таком проце то на современных процах (я имею в виду широкораспространенные) шедуллер ОС просто задвинит остальные потоки и все.
Те если у нас всплыл реалтаймовый поток в ядре веб сервер по любому пойдет курить. А тут если этот самый реалтаймовый поток будет промахиваться мимо кеша то веб сервер сможет в это время что-то поделать. А вычислительная задача которая что-то считает с плавучкой тем болие ибо врядли в ядре есть работа с плавучкой.

Единственное нужно для каждого из приоритетов держать свой указатель на последний отработавший с данным приоритетом поток.
Тогда не будет проблем с всплывающим каждые 5 тактов высокоприоритетным потоком.

Шедуллер для линеек кеша ессно должен быть отдельным и работать не на уровне потоков, а на уровне ядер.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Автоматическое распараллеливание (было "Что почитать.
От: Кодёнок  
Дата: 22.04.08 07:50
Оценка: 28 (1)
Здравствуйте, LaPerouse, Вы писали:

LP>По-момему, автоматический паралеллизм автоматом вытекает из ленивости и чистоты.

LP>1. Отсутствие побочных эффектов.
LP>т к fun1 и fun2 чистые, то результат, возвращаемый ими, не зависит от порядка вызова. И рантайм запускает каждую функцию в своем потоке, к моменту вычисления fun1 результат fun2 может быть вполне вычислен. Чем не автоматический параллелизм?

Тем что предназначение любой программы — это все-таки вызывать побочные эффекты. Чисто вычисления это лишь малая часть любой практически полезной программы.

Брать абстрактные примеры это ошибка. Попробуй показать автоматическое распараллеливание на простой, но практической программе, например, утилите grep или diff. Можешь писать хоть на самом чистом и ленивом языке, какой сумеешь найти.
Re[24]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 18:09
Оценка: 28 (1)
Здравствуйте, remark, Вы писали:

R>А каким из этих типов ты собираешься бить по многопотосночти? uniqueness? Т.е. это мутабельный тип, но его можно безопасно менять в обоих потоках, т.к. идёт "передача владения" от одного потока другому?

Да.

R>А как быть с mutable типами? Если они mutable и их можно передавать между потоками, то, по-моему, мы возвращаемся к рабитому корыту. Разьве нет?

Нет. Ибо объект uniqueness типа может быть прекрасным контейнером для любых типов.

Обычные изменяемые типы тоже будут но мигрировать между потоками они смогут только внутри объекта uniqueness типа.
В интерфейсе uniqueness типа могут использоватся только pure и uniqueness типы.

Благодоря выделеному потоки не смогут захапать себе ссылки на обычные изменяемые типы.
Те между потоков будут курсировать островки изменяемых данных но добраться до содержимого этих островков можно только через интерфейс объекта. А там разрешены только pure и uniqueness типы... Те система типов просто не пропустит ссылку на mutable тип за приделы объекта uniqueness типа.
Так же это позволяет создать внутри каждого объекта uniqueness типа свою кучу для mutable типов. А при наличии более вдумчивого анализатора и для части объектов pure типов.

А pure типам вобще все до лампочки. Объекты этих типов вобще никогда не меняются.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Автоматическое распараллеливание (было "Что почитать.
От: LaPerouse  
Дата: 25.04.08 06:30
Оценка: 15 (1)
Здравствуйте, remark, Вы писали:

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


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


R>>>Новые технологии нужны. Но новые технологии — это *не* автоматическое распараллеливание.


LP>>По-момему, автоматический паралеллизм автоматом вытекает из ленивости и чистоты.


LP>>1. Отсутствие побочных эффектов.

LP>>b = fun1(a)
LP>>c = fun2(a)

LP>>т к fun1 и fun2 чистые, то результат, возвращаемый ими, не зависит от порядка вызова. И рантайм запускает каждую функцию в своем потоке, к моменту вычисления fun1 результат fun2 может быть вполне вычислен. Чем не автоматический параллелизм?

R>Тут есть 2 проблемы.
R>Во-первых, а если мы захотим добавить в программу какую-то полезную работу. Ну если программа будет супер быстрая, то она должна хотя бы как-то сообщить об этом, что бы и другие могли порадоваться за неё.
R>Допустим, fun1() и fun2() отправляют что-то по сети. Их уже переставлять нельзя. А может быть и можно, если протокол допускает произвольный порядок этих сообщений. Это, кстати, система автоматического распараллеливания должна будет сама определить. Как ты предлагаешь это делать?

В исходном сообщении ясно подчеркивается, что функции fun1 и fun2 не имеют побочных эффектов. Поэтому к чему вот это:

R>Как это "автоматический распараллеливатель" будет распараллеливать серверное ПО, клиентское GUI ПО, игры, драйверы и т.д.???


R>Во-вторых, даже потенциальный, но не реализованный параллелизм имеет стоимость. Пока, насколько я знаю, никто не сумел сделать его бесплатным. У тебя есть вариант?


R>Да вот ещё, как обрабатывать разделяемые структуры данных???


Далее:

LP>>2. Ленивость. Скажем, параллельно ходу выполнения основного потока в других потоках происходит раскрутка ленивости. Когда потребуются результаты, вместо вычисления всего ленивого кома, просто берет уже вычисленные значения. Чем не автоматический параллелизм?


R>Берут вычисленные значения. Замечательно. А синхронизация сколько будет стоить?

R>Мы же говорим о мелкомодульном паралеллизме, это значит, что затраты на синхронизацию при сегодняшней ситуации могут составлять до ~1000% от полезной работы.

Я могу ошибаться, но мне кажется,что синхронизаций нужно не так много. Давай представим стек ленивых вызовов ввиде разделяемой структуры-дерева, в узлах которого будут вызовы функций, которые согласно п.1 чистые. Тогда второй поток может идти по дереву, вычисляя узлы дерева и записывая результат вычисления в те же узлы совершенно без всяких синхронизаций с основным потоком. Потом, когда придет время для раскрутки, реализация смотрит — если узел на N-ом уровне дерева вычислен, то берет значение из узла, если нет, то вычисляет его. При этом, самое интересное, что второй поток можно не останавливать, пусть скажем при вычислении первым потоком узл на N-ом уровне второй, одновременно с ним вычислив этот узел, приступит к узлу на N-1 уровне. Синхронизаций нет!

LP>>Все вышесказанное настолько очевидно, что спорить с этим невозможно.


R>Блин,а мужики-то не знают!


Мужики не думают, что все очевидно? Или мужики настолько хорошо знают, что все очевидно, что упоминание об этом все равно что сказать "дважды два четыре"?

LP>>Понятно, quckSort таким образом не распараллелить, но реально большое количество операций можно выполнять параллельно. Если учесть, что все это достается задаром (пользователь не догадывается о том, где в какой момент времени сколько будет использоваться потоков, да и вообще сказать это можно только на этапе выполнения), то имхо не стоит просто так отметать преусловутый автопаралеллизм.



R>Бесплатно? Если бы я знал, как это всё сделать бесплатно, то я бы не постил на этом форуме, я бы сейчас отдыхал на своём острове где-нибудь в тихом океане


R>Как ты сделаешь бесплатным потенциальный даже не реализованный параллелизм?

R>Как ты сделаешь бесплатным управлению временем жизни объектов?
R>Как ты сделаешь бесплатным управлению памятью?
R>Как ты сделаешь бесплатным разделяемые структуры данных?
R>Как ты сделаешь бесплатным переиспользование результатов, вычисленных другим потоком?

remark, речь ведь совсем не шла о тотальном распараллеливании всего и вся. Там упоминалось лишь два, строго очерченных случая, когда возможность автораспараллеливания очевидна и даже ты, при всей нелюбви к ней, не будешь отрицать, что хотя бы ТЕОРЕТИЧЕСКИ именно в ЭТИХ случаях автопараллелизм возможен.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[3]: PLO vs HTM
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 14:29
Оценка: 10 (1)
Здравствуйте, WolfHound, Вы писали:

WH>Комманда lock N, Rx, Ry

WH>Лочит одну или 2 линейки кеша (в которые попадают адреса из регистров Rx и Ry) на время выполнения следующих N (скажем до 16 комманд).
WH>Под локом можно обращаться только к залоченным частям памяти и делать только переходы вперед (никаких циклов под локом) и ессно никаких локов под локом.
WH>Если в одной линейке кеша есть несколько ячеек памяти которые нас интересуют то достаточно указать адрес одной из них но обращаться можно ко всем ибо всеравно вся линейка кеша залочена.
WH>Захвативший лок поток на время выполнения лока получает высший приоритет (ибо лок нужно отпустить как можно быстрее).
WH>Одновременно может выполняться только один лок на одном ядре.
WH>Думаю на этом базисе можно сделать очень много различных структур данных.


Постановка задачи правильная — дать возможность эффективно реализовывать нетривиальные структуры данных. В каком конкретно виде дать эту возможность — это вопрос.
В принципе, примерно так как ты описываешь — это уже есть.

Смотри IBM z/Architecture: Principles of Operation
http://publibz.boulder.ibm.com/epubs/pdf/dz9zr002.pdf
Appendix A -> Multiprogramming and Multiprocessing Examples -> PERFORM LOCKED OPERATION

PERFORM LOCKED OPERATION (PLO)
The PERFORM LOCKED OPERATION instruction
can be used in a multiprogramming or multiprocessing
environment to perform compare, load,
compare-and-swap, and store operations on two
or more discontiguous locations that can be words
or doublewords. The operations are performed as
an atomic set of operations under the control of a
lock that is held only for the duration of the execution
of a single PERFORM LOCKED OPERATION
instruction, as opposed to across the execution
of multiple instructions. Since lock contention
is resolved by the CPU and is very brief,
the program need not include a method for
dealing with the case when the lock to be used is
held by a program being executed by another
CPU. Also, there need be no concern that the
program may be interrupted while it holds a lock,
since PERFORM LOCKED OPERATION will complete
its operation and release its lock before an
interruption can occur.


Команда PLO действует примерно так: вначале ты подгатавливаешь микропрограмму в памяти с описанием всех действий, которые необходимо выполнить атомарно, далее скрамливаешь её PLO, и она говорит — успешно или нет. Вот пример функции добавления элемента в очередь:
LA RT,H Initialize addresses in PL (T = temp)
ST RT,PL+76 Op4 address (address of H)
LA RT,C
ST RT,PL+108 p6 address (address of C)
LA RN,N Address of N 
ST RN,PL+60 Initialize op3 in PL (address of N)
LA R1,S PLT address = address of S
------------------------------------------------
SR RS,RS Dummy S. CC1 will probably be set
SR R,R Function code  (compare andload)
PLO RS,S,RS,S Obtain S while holding lock
------------------------------------------------
LA R,16 Function code 16 (csdst)
LOOP L RT,H Consistent H
ST RT,OFSTF(,RN) OFSTF = offset of F inN
L RT,C Consistent C
LA RT,1(,RT) C+1
ST RT,PL+92 Initialize op5 in PL (C+1)
LA RSP,1(,RS) RS/RSP = even/odd pair.
S+1 in RSP
PLO RS,S,,PL
BNZ LOOP Br if S changed (if CC not 0)



Далее есть (ну точнее будет в этом году) Hardware Transactional Memory (HTM) в процессорах Rock от SUN:
http://blogs.sun.com/dave/resource/transact08-dice.pdf

Интерфейс состоит из двух команд chkpt и commit.
Пример использования:
try_trx:
  chkpt on_failure ; начинаем транзакцию
                   ; как параметр передаём адрес, куда перейти в случае провала транзакции
  ; выполняем "произвольные" нужные действия
  commit ; пытаемся закоммитить
  ; если попали сюда, значит успешно
  ; в случае ошибки попадём на on_failure
  jmp on_success

on_failure:
  ; можно считать регистр cps (checkpoint status), что бы понять почему провалились
  ; можно выполнить back-off и т.д.
  jmp try_trx

on_success:
  ; транзакция выполнена успешно и атомарно


Почему я написал — "произвольные" нужные действия. Т.к. набор действий, которые можно выполнить внутри транзакции достаточно ограничен (примерно как ты описал) — нельзя выполнять "особые" инструкции, нельзя вызывать функции, нельзя читать/писать слишком много памяти, нельзя выполняться слишком долго и т.д.

Правда, как показали авторы, алгоритмы "влоб" не начинают магически масштабироваться при использовании HTM. Как и ожидалось. No silver bullet there!


Тем не менее в будущем, конечно, хочется иметь более мощные примитивы нежели чем double-word compare-exchange (cmpxchg16b).



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 26.04.08 23:09
Оценка: 4 (1)
Здравствуйте, LaPerouse, Вы писали:

R>>Тут есть 2 проблемы.

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

LP>В исходном сообщении ясно подчеркивается, что функции fun1 и fun2 не имеют побочных эффектов.



Тут гляди как ситуация. Примерно такое распараллеливание как ты говоришь уже достаточно давно есть в High Performance Fortran. За счёт ограниченности языка компилятор имеет возможность анализировать циклы на предмет возможности распараллеливания. Но серебрянной пули не получилось.
Во-первых, идеальный цикл разработки выглядит так: программист пишет программу; во время компиляции она магически распараллеливается. На практике это выглядит так: программист пишет программу, думая о том как компилятор сможет её распараллеливать; программа компилируется; программист проверяет, что компилятор распараллелил так, как задумано; если что-то не так, то разработка итеративно повторяется; если всё так, то предпринимаются какие-то меры, что бы впоследствии полученное "хорошее" распараллеливание не "ломалось" от изменений.
Во-вторых, всё равно пришло добавить некоторые "хинты" компилятору, которые бы помогали ему сделать всё правильно. Соотв. расстановка хинтов — обязанность программиста.
В-третьих, как следует из предыдущих пунктов, думать программист обязан на низком уровне, в то время как писать — на высоком. Это причина многих проблем. Например, сложно понять как описать на высоком уровне алгоритм, что бы получить желаемый алгоритм на низком уровне. Не понятно, как надо изменить алгоритм на высоком уровне, что бы получить желаемое изменение алгоритма на низком уровне. Ну и рано или поздно некоторые сталкивались с тем, что необходимость писать на очень ограниченном высоком уровне просто связывает им руки (раз они всё равно думают на низком уровне), это приводило просто к отказу от HPF и возвращение к MPI.


Возьмем твой пример с fun1 и fun2.
Первая проблема. Если есть 100 процессоров и только fun1 и fun2, то будет задействовано максимум 2 процессора (в предположении, что компилятор будет распараллеливать на уровне функций, что вполне разумно). Т.е. программист *обязан* (уже элемент не автоматизма) предоставить компилятору хотя бы средний уровень гранулярности (сотни/тысячи элементов для распараллеливания). Тут встаёт другая проблема — надо не переборщить с гранулярностью работы. Слишком мелкие элементы работы (сложение 2 чисел) тоже будут негативно сказываться на производительности (об этом тоже надо подумать программисту).
Вторая проблема. Возможность для параллелизма должна быть выражена в правильной форме. Например, если используется рекурсия, то дерево вызовов должно быть сбалансированным. Если оно будет не сбалансированное (с множеством коротких путей), то хорошего распараллеливания не получится — расходы на постоянную синхронизацию при шедулинге работы съедят всё время. Если алгоритм выражен в виде цикла, и при этом между итерациями есть зависимости по данным, то никакого распараллеливания не получится вообще. Тут вообще нет никакого автоматизма — программист *обязан* предоставить компилятору "хорошую" структуру программы.
Третья проблема. Учитывая предыдущие 2 пункта получаем 1 и 3 пункты из вышеописанной ситуации с High Performance Fortran. Т.е. цикл разработки: пишем -> проверяем компилятор -> итеративно меняем и т.д. И постоянно боремся с компилятором: вроде всё сделали правильно, а эта сволочь почему-то не распараллелила! Почему? И как поменять программу, что всё-таки распараллелила?




R>>Во-вторых, даже потенциальный, но не реализованный параллелизм имеет стоимость. Пока, насколько я знаю, никто не сумел сделать его бесплатным. У тебя есть вариант?



Этот пункт не уходит даже если учитывать только "вычислительные задачи". Для шедулинга работы при распараллеливании сейчас де-факто применяется распределенный шедулер на основе work-stealing deque. Насколько я знаю, пока никто не смог сделать в нём "бесплатный" потенциальный параллелизм. Т.е. даже если один поток выполняет элементы работы, всё-равно приходится платить как-минимум 1 Interlocked операцию, либо тяжёлый барьер памяти (#StoreLoad, mfence) на каждый элемент работы. Так обстоит дело в Cilk, .NET TPL, Java Fork/Join и т.д.




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



Если без синхронизации, то одно значение может вычисляться N (количество процессоров) раз. Значение может быть *очень* тяжелым. Например при использовании рекурсии одно значение может представлять половину всей работы.


LP> При этом, самое интересное, что второй поток можно не останавливать, пусть скажем при вычислении первым потоком узл на N-ом уровне второй, одновременно с ним вычислив этот узел, приступит к узлу на N-1 уровне. Синхронизаций нет!



Не понял мысль. Что подразумевается под "остановкой потоков"? И под "уровнями"?


LP>>>Все вышесказанное настолько очевидно, что спорить с этим невозможно.


R>>Блин,а мужики-то не знают!


LP>Мужики не думают, что все очевидно? Или мужики настолько хорошо знают, что все очевидно, что упоминание об этом все равно что сказать "дважды два четыре"?



Мужики *знают*, что всё *не* очевидно.


LP>>>Понятно, quckSort таким образом не распараллелить, но реально большое количество операций можно выполнять параллельно. Если учесть, что все это достается задаром (пользователь не догадывается о том, где в какой момент времени сколько будет использоваться потоков, да и вообще сказать это можно только на этапе выполнения), то имхо не стоит просто так отметать преусловутый автопаралеллизм.


R>>Бесплатно? Если бы я знал, как это всё сделать бесплатно, то я бы не постил на этом форуме, я бы сейчас отдыхал на своём острове где-нибудь в тихом океане


R>>Как ты сделаешь бесплатным потенциальный даже не реализованный параллелизм?

R>>Как ты сделаешь бесплатным управлению временем жизни объектов?
R>>Как ты сделаешь бесплатным управлению памятью?
R>>Как ты сделаешь бесплатным разделяемые структуры данных?
R>>Как ты сделаешь бесплатным переиспользование результатов, вычисленных другим потоком?

LP>remark, речь ведь совсем не шла о тотальном распараллеливании всего и вся. Там упоминалось лишь два, строго очерченных случая, когда возможность автораспараллеливания очевидна и даже ты, при всей нелюбви к ней, не будешь отрицать, что хотя бы ТЕОРЕТИЧЕСКИ именно в ЭТИХ случаях автопараллелизм возможен.



Издержки на шедулинг и на управление памятью/временем жизни объектов будут в *любом* случае.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Автоматическое распараллеливание (было "Что почитать...")
От: LaPerouse  
Дата: 16.04.08 09:56
Оценка: 3 (1)
Здравствуйте, remark, Вы писали:

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


R>Так же такие области, как game-dev, где требуется 100% отдача от железа, не полагаются на автоматическое распараллеливание. Т.к. тут не устраивает ситуация, что "компилятор наверное что-то как-то распараллелит".


R>No silver bullet!


Меня интересует, как будет делаться делается ручное распараллеивание, скажем, на 100 ядрах. Том Свини, один из авторов Unreal как раз говорит, что с увеличением количества ядер на стандартном декстопе и возвращении к программному рендерингу будут востребованы новые технологии программировнаия. Интервью здесь:

http://www.thg.ru/game/tim_sweeney_interview_2008/tim_sweeney_interview_2008-01.html
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[3]: Автоматическое распараллеливание (было "Что почитать...")
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 13:52
Оценка: 2 (1)
Здравствуйте, WolfHound, Вы писали:

M>>Существуют прогнозы, что в ближайшее время (5, 10 лет) нас ожидает скачкообразный рост количества ядер на одном процессоре, вплоть до нескольких сотен ядер где-нибудь к 2015 году.

WH>Тут речь как я понимаю идет не о ядрах их сильно больше десятка на один кристал весьма проблематично засунуть. А о аппаратных потоках.
WH>Это немного разные вещи.
WH>Цель аппаратчиков заставить АЛУ работать. Ибо сейчас из-за промахов кеша АЛУ очень часто простаивает. Мне удавалось разгонять алгоритмы укатывая их под кешь процессора от 2 до 100 раз.
WH>Что хотят сделать аппаратчики: Они планируют сделать ядра максимально тупыми (никакого переупорядочивания комманд, спекулятивных вычислений и прочей магии...) за счет этого можно сильно уменьшить размер ядра и уменьшить штрафы вызванные ошибками предсказаний. После чего на ядре запускают 8-16 аппаратных потоков которые переключаются каждый такт. Если поток промазал мимо кеша то ничего страшного... его просто будут пропускать пока данные не приползут в кеш. Таким образом можно гораздо лучше загрузить АЛУ.


Будет расти и кол-во ядер и кол-во аппаратных потоков на ядро.
Уже пару лет Intel светит своим 80-ядерным опытным процессором:
http://www.news.com/2100-1006_3-6119618.html
Tilera уже более года продаёт 64-ядерные процессоры:
http://www.tilera.com/products/processors.php
IBM более 2 лет продаёт 9-ядерный Cell:
http://researchweb.watson.ibm.com/journal/rd/494/kahle.html?S_TACT=105AGX16&amp;S_CMP=LP
Т.ч. много ядер на кристалл запихать можно. Тем более, как ты сам сказал, что ядра будут "тощать", это даёт место под новые ядра. Плюс кол-во доступных транзисторов продолжает удваиваться.

Несколько аппаратных потоков на ядро тоже будет.
Уже был Intel Pentium 4 HT.
Следующий процессор Intel так же будет с 2 аппаратными потоками на ядро:
http://techreport.com/discussions.x/13232
Sun'овские Niagara имеют по 32 аппаратных потока на ядро:
http://www.sun.com/servers/coolthreads/overview/docs/Niagara_IDC_WP.pdf

Плюс к этому так же добавится асимметричная гетерогенная архитектура. Т.е. NUMA архитектура неизбежна для обеспечения масштабирования. SMP системы от AMD уже являются NUMA. Гетерогенная значит, что ядра будут разные — Cell (PPU + 8 SPU), GPCPU и т.д.

Т.е. предвидится такое вот весёленькое будущее: на одном ядре несколько аппаратных потоков, несколько ядер объединены кэшем L2, несколько этих кэшей объединены кэшем L3, несколько таких процессоров объединены в NUMA узлы, несколько таких узлов объединены коммутатором в систему.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Автоматическое распараллеливание (было "Что почитать.
От: vdimas Россия  
Дата: 24.07.08 15:28
Оценка: :)
Здравствуйте, WolfHound, Вы писали:


V>>Угу, и нам нужно будет дёргать АЛУ для банального декремента семафора или проверки состояния события. Это ничем не отличается от существующего подхода.

WH>А ты уверен что твой подход вобще имеет смысл делать?
WH>Как насчет систем которые работают на примитивах синхронизации ориентированных на данные?

Я такого еще не видел. Даже если "лочишь" область отображения памяти видеокарты или звуковой карты, то ты имеешь дело лишь с внешним АПИ, а внутри — всё равно мьютекс и еще доп. поля по обслуживанию диапазонов. Для всяких ДМА — аналогично.

WH>Для них твой подход не эффективен.


Эффективен для обслуживания того самого внутреннего мьютекса. Ведь мы не только область данных "лочим", мы лочим доступ к некоторым регистрам девайса и котроллера памяти в т.ч. (для отображения памяти девайса на обычную), и это всё — по старинке внутри ОС, через мютексы и соглашения на их использования. Просто от тебя весь этот процесс скрыт.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[11]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 30.07.08 11:01
Оценка: :)
Здравствуйте, WolfHound, Вы писали:


WH>Ну не вижу я смысла защищать код.

WH>Ибо защищать нужно только изменяемые данные.

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

WH>Я вроде гдето по твоим ссылкам читал что все выкрутасы на эту тему приводили к проездам по памяти.


С какой стати?

WH>Да и вобще куча мутной семантики типа грязного чтения итп мягко говоря настораживает.


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

WH>С деревянными локами куда как понятнее и спокойней.


Если локи нужны для логики ожидания (воода/вывода, или конца вычислений), то это понятно, ну а если локи используются для сериализации доступа — то это действительно деревянно, и транзакционная память поможет избежать лишних дорогостоящих искуственных ожиданий.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[23]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 04.08.08 20:34
Оценка: :)
Здравствуйте, WolfHound, Вы писали:


V>>>>Лочить линейку кеша надо для защиты от доступа другого ядра/проца.

WH>>>Ага. Для двух и более ядер надо лочить.
V>>Ес-но.
WH>И чем тогда нам поможет HTM?

Тем, что данные лочатся лишь однократно, что шедуллер учитывает "транзакции" при составлении очереди команд на обработку. Ведь interlocked exchange — это не достаточно для блокировки, потом надо делать ветвление, и смотреть, заблокированны мы или нет, потом опять interlocked exchange для освобождения. А тут — одной командой.

WH>Короче как не крути, а HTM просто физически не может быть лучше локов.

WH>Ибо HTM всеравно превращается в локи в случае конфликтов.

Лучше по кол-ву операций блокирования, + переупорядочивание для предварительного избежания локов.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[13]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 08.08.08 06:41
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

V>>Пока что есть, на каждый хендл ввода-вывода внутри ОС. И еще один глобальный — на создание и удаление подобных хендлов из общего списка.


S>Это всё от того, что ОС раздает хэндлы кому попало. В WH-ной системе хэндл будет uniqueness ресурсом, то есть доступ к нему имеет ровно один поток. Значит ему не нужно захватывать никакой мьютекс.


uniqueness мьютексы и семафоры


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[19]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 16.08.08 16:16
Оценка: :)
Здравствуйте, WolfHound, Вы писали:


V>>Уже по второму вопросу отсылка к формальным спецификациям и уход от того, как это будет в механике (хотя мы тут обсуждаем именно это).

WH>Лично я думал что всем очевидно что ВМ на то и нужна чтобы прикладных программистов механика нне волновала.
WH>А как будут устроены примитивы ВМ на конкретной железке дело десятое.

Угу, особенно после твоих обсуждений о блокировках линеек кеша и "вновьпридуманной" разновидности uniqueness типов. В общем, вопрос о владении примитивом синхронизации "событие" в системе uniqueness типов остаётся открытым пока что...
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re: Автоматическое распараллеливание (было "Что почитать...")
От: Michael7 Россия  
Дата: 16.04.08 08:52
Оценка:
Здравствуйте, remark, Вы писали:

R>Меня в этом вопросе интересовала реализация этого дела и организация ран-тайм системы поддержки. Поэтому со своей стороны могу дать ссылки, касающиеся именно реализации:

R>Lazy Threads: Compiler and Runtime Structures for Fine-Grained Parallel Programming:
R>http://www.eecs.berkeley.edu/Pubs/TechRpts/1997/CSD-97-975.pdf

R>Cilk: An Efficient Multithreaded Runtime System:

R>http://supertech.csail.mit.edu/papers/cilkjpdc96.pdf

Спасибо за ссылки!

R>"Псевдо-автоматическое распараллеливание" возможно, когда пользователь явно указывает в программе "потенциальный" параллелизм, а компилятор/ран-тайм заставляют его реально выполняться параллельно. К этому типу относятся все эти lazy-вычисления, futures, активные объекты и т.д. Но фактически тут вся работа остаётся на программисте. У компилятора тут маленькая задача. У компилятора тут, как ни странно, задача даже больше не "сделать" параллелизм, а "подавить" параллелизм.


Конечно, совсем автоматического распараллеливания, наверное никогда не будет, тут я каюсь слишком громко выразился.

R>Так же такие области, как game-dev, где требуется 100% отдача от железа, не полагаются на автоматическое распараллеливание. Т.к. тут не устраивает ситуация, что "компилятор наверное что-то как-то распараллелит".


Я вот ещё, что имел ввиду, затронув тему автоматизации распараллеливания, в свете будущих перспектив промышленного программирования для работы с многопроцессорными (многоядерными) системами.
Существуют прогнозы, что в ближайшее время (5, 10 лет) нас ожидает скачкообразный рост количества ядер на одном процессоре, вплоть до нескольких сотен ядер где-нибудь к 2015 году. Собственно, например архитектуру Cell или GPGPU можно рассматривать как первую ласточку. А несколько десятков ядер уже есть даже в Roadmap-ах производителей.

Хотя программы с мультипараллельными вычислениями пишут уже довольно давно, ведь кластеры, суперкомпьютеры и сети распределённых вычислений (вроде SETI) появились не сегодня, писать их сложнее и дороже, чем обычные, да и количество программистов, способных их написать невелико. Здесь же имеющийся опыт "обычных" пограммистов не всегда поможет, написание даже двух- четырех-поточной программы для истинно параллельного исполнения на нынешних двух-четырех-ядерниках уже имеет свои тонкости.

В этой связи языки и технологии, вроде Haskell, Lisp с параллельным исполнением и т.п., которые сейчас слишком расточительно расходуют ресурсы, могут оказаться востребованными. Если код на них работает, допустим в 5 — 10 — 20 раз медленее, чем на Си это часто неприемлемо медленно, особенно в вычислительных задачах, но если они позволят программисту быстро написать параллельно исполняющуюся программу на 1600 ядрах это будет всё-равно в 160 раз эффективнее, чем работа однопоточной программы.

То есть в случае массового распространения сильно многоядерных систем может быть экономически оправдано легкое распараллеливание и не беда, что эффективность может оказаться в размере 10% от пиковой, будет полно задач, где это допустимо.
Re[2]: Автоматическое распараллеливание (было "Что почитать...")
От: WolfHound  
Дата: 16.04.08 10:19
Оценка:
Здравствуйте, Michael7, Вы писали:

M>Существуют прогнозы, что в ближайшее время (5, 10 лет) нас ожидает скачкообразный рост количества ядер на одном процессоре, вплоть до нескольких сотен ядер где-нибудь к 2015 году.

Тут речь как я понимаю идет не о ядрах их сильно больше десятка на один кристал весьма проблематично засунуть. А о аппаратных потоках.
Это немного разные вещи.
Цель аппаратчиков заставить АЛУ работать. Ибо сейчас из-за промахов кеша АЛУ очень часто простаивает. Мне удавалось разгонять алгоритмы укатывая их под кешь процессора от 2 до 100 раз.
Что хотят сделать аппаратчики: Они планируют сделать ядра максимально тупыми (никакого переупорядочивания комманд, спекулятивных вычислений и прочей магии...) за счет этого можно сильно уменьшить размер ядра и уменьшить штрафы вызванные ошибками предсказаний. После чего на ядре запускают 8-16 аппаратных потоков которые переключаются каждый такт. Если поток промазал мимо кеша то ничего страшного... его просто будут пропускать пока данные не приползут в кеш. Таким образом можно гораздо лучше загрузить АЛУ.




Мои размышления на тему (я в разработке процессоров ничего не понимаю по этому можно не читать):
Еще можно сделать 3 типа АЛУ на ядре.
1)Занимается условными и без условными переходами. Чтением/записью в память. Барьеры памяти. И всем остальным что связано с работой с памятью.
2)Целочисленная арифметика.
3)Арифметика с плавающей точкой.
Таким образом у потока может быть 4 состояния
1)Не готов. (Промазал мимо кеша или просто делать нечего.)
2, 3, 4)Комманда для соответствующего АЛУ.
Соответственно шедуллер каждого из АЛУ выберает следующей поток с коммандой для этого АЛУ.

Если немного усложнить шедуллер и добавить приоритеты можно будет делать совсем веселые вещи.
Допустим если сделать 4 уровня приоритетов то высший (3) резервируем за процессором (см дальше), 2 допустим можно назначать обработчикам аппартаных прирываний, 1 реалтайм потокам и 0 нереалтайм потоками.
Ни о какой сраведливости задумываться не надо это работа ОС. Просто АЛУ переключается между своими потоками с максимальным приоритетом.

Комманда lock N, Rx, Ry
Лочит одну или 2 линейки кеша (в которые попадают адреса из регистров Rx и Ry) на время выполнения следующих N (скажем до 16 комманд).
Под локом можно обращаться только к залоченным частям памяти и делать только переходы вперед (никаких циклов под локом) и ессно никаких локов под локом.
Если в одной линейке кеша есть несколько ячеек памяти которые нас интересуют то достаточно указать адрес одной из них но обращаться можно ко всем ибо всеравно вся линейка кеша залочена.
Захвативший лок поток на время выполнения лока получает высший приоритет (ибо лок нужно отпустить как можно быстрее).
Одновременно может выполняться только один лок на одном ядре.
Примеры:
AtomicIncrement
lock 3, r1, r1
ld r1 -> r2
add r2, 1
st r2 -> r1

AtomicCompareExchange
lock 4, r1, r1
ld r1 -> r2
cmp r2, r3
jne end
st r4 -> r1
end:

AtomicSwap
lock 4, r1, r2
ld r1 -> r3
ld r2 -> r4
st r4 -> r1
st r3 -> r2

Думаю на этом базисе можно сделать очень много различных структур данных.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Автоматическое распараллеливание (было "Что почитать...")
От: Sergey Россия  
Дата: 16.04.08 11:58
Оценка:
> В этой связи языки и технологии, вроде Haskell, Lisp с параллельным
> исполнением и т.п., которые сейчас слишком расточительно расходуют
> ресурсы, могут оказаться востребованными. Если код на них работает,
> допустим в 5 — 10 — 20 раз медленее, чем на Си это часто неприемлемо
> медленно, особенно в вычислительных задачах, но если они позволят
> программисту быстро написать параллельно исполняющуюся программу на 1600
> ядрах это будет всё-равно в 160 раз эффективнее, чем работа однопоточной
> программы.
>
> То есть в случае массового распространения сильно многоядерных систем
> может быть экономически оправдано легкое распараллеливание и не беда, что
> эффективность может оказаться в размере 10% от пиковой, будет полно задач,
> где это допустимо.

Проблема в том, что для реализации такого сценария понадобится
1600-канальная память и 1600 хотя бы полумегабайтных кэшей. Иначе программа
у вас будет не в 160 раз эффективнее, а, например, в 2 раза. Или вообще
медленнее однопоточной. IMHO.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: Автоматическое распараллеливание (было "Что почитать...")
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 13:04
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


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


R>>Так же такие области, как game-dev, где требуется 100% отдача от железа, не полагаются на автоматическое распараллеливание. Т.к. тут не устраивает ситуация, что "компилятор наверное что-то как-то распараллелит".


R>>No silver bullet!


LP>Меня интересует, как будет делаться делается ручное распараллеивание, скажем, на 100 ядрах. Том Свини, один из авторов Unreal как раз говорит, что с увеличением количества ядер на стандартном декстопе и возвращении к программному рендерингу будут востребованы новые технологии программировнаия. Интервью здесь:



Новые технологии нужны. Но новые технологии — это *не* автоматическое распараллеливание.
Да в принципе и новых технологий-то особо не нужно. Всё уже давно есть — Cilk, CSP, Erlang, активные объекты, агентно-ориентированные системы и т.д. Просто надо реализовать это нормально. Для людей.
Valve, например, уже пепеписал свой движок для поддержки многоядерных процессоров. Ничего принципиально нового там нет — ран-тайм + хороший шедулер + выделение потенциального параллелизма пользователем.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Автоматическое распараллеливание (было "Что почитать...")
От: LaPerouse  
Дата: 16.04.08 13:42
Оценка:
Здравствуйте, remark, Вы писали:

R>Новые технологии нужны. Но новые технологии — это *не* автоматическое распараллеливание.


По-момему, автоматический паралеллизм автоматом вытекает из ленивости и чистоты.
1. Отсутствие побочных эффектов.
b = fun1(a)
c = fun2(a)

т к fun1 и fun2 чистые, то результат, возвращаемый ими, не зависит от порядка вызова. И рантайм запускает каждую функцию в своем потоке, к моменту вычисления fun1 результат fun2 может быть вполне вычислен. Чем не автоматический параллелизм?

2. Ленивость. Скажем, параллельно ходу выполнения основного потока в других потоках происходит раскрутка ленивости. Когда потребуются результаты, вместо вычисления всего ленивого кома, просто берет уже вычисленные значения. Чем не автоматический параллелизм?

Все вышесказанное настолько очевидно, что спорить с этим невозможно. Понятно, quckSort таким образом не распараллелить, но реально большое количество операций можно выполнять параллельно. Если учесть, что все это достается задаром (пользователь не догадывается о том, где в какой момент времени сколько будет использоваться потоков, да и вообще сказать это можно только на этапе выполнения), то имхо не стоит просто так отметать преусловутый автопаралеллизм.

PS. Что случилось? Отправлять сообщения из RSDN at home невозможно. "You are bunned". Со вчерашнего дня. И не только у меня, у других из подсетки тоже.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[3]: Автоматическое распараллеливание (было "Что почитать...")
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 14:06
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Мои размышления на тему (я в разработке процессоров ничего не понимаю по этому можно не читать):

WH>Еще можно сделать 3 типа АЛУ на ядре.
WH>1)Занимается условными и без условными переходами. Чтением/записью в память. Барьеры памяти. И всем остальным что связано с работой с памятью.
WH>2)Целочисленная арифметика.
WH>3)Арифметика с плавающей точкой.
WH>Таким образом у потока может быть 4 состояния
WH>1)Не готов. (Промазал мимо кеша или просто делать нечего.)
WH>2, 3, 4)Комманда для соответствующего АЛУ.
WH>Соответственно шедуллер каждого из АЛУ выберает следующей поток с коммандой для этого АЛУ.


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


WH>Если немного усложнить шедуллер и добавить приоритеты можно будет делать совсем веселые вещи.

WH>Допустим если сделать 4 уровня приоритетов то высший (3) резервируем за процессором (см дальше), 2 допустим можно назначать обработчикам аппартаных прирываний, 1 реалтайм потокам и 0 нереалтайм потоками.
WH>Ни о какой сраведливости задумываться не надо это работа ОС. Просто АЛУ переключается между своими потоками с максимальным приоритетом.


А как быть с голоданием?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Автоматическое распараллеливание (было "Что почитать...")
От: remark Россия http://www.1024cores.net/
Дата: 16.04.08 14:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>Если немного усложнить шедуллер и добавить приоритеты можно будет делать совсем веселые вещи.

WH>>>Допустим если сделать 4 уровня приоритетов то высший (3) резервируем за процессором (см дальше), 2 допустим можно назначать обработчикам аппартаных прирываний, 1 реалтайм потокам и 0 нереалтайм потоками.
WH>>>Ни о какой сраведливости задумываться не надо это работа ОС. Просто АЛУ переключается между своими потоками с максимальным приоритетом.
R>>А как быть с голоданием?
WH>А ни как. Если ОСь выставила высокий приоритет одному из потоков на таком проце то на современных процах (я имею в виду широкораспространенные) шедуллер ОС просто задвинит остальные потоки и все.
WH>Те если у нас всплыл реалтаймовый поток в ядре веб сервер по любому пойдет курить. А тут если этот самый реалтаймовый поток будет промахиваться мимо кеша то веб сервер сможет в это время что-то поделать. А вычислительная задача которая что-то считает с плавучкой тем болие ибо врядли в ядре есть работа с плавучкой.

WH>Единственное нужно для каждого из приоритетов держать свой указатель на последний отработавший с данным приоритетом поток.

WH>Тогда не будет проблем с всплывающим каждые 5 тактов высокоприоритетным потоком.


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


WH>Шедуллер для линеек кеша ессно должен быть отдельным и работать не на уровне потоков, а на уровне ядер.



А вот, кстати, ещё момент. В SUN'овских CMT процессорах поток, пока заблокирован в ожидании загрузки кэш-линии, не стоит без дела — он переходит в режим hardware scouting. Это очень эффективный вариант hardware prefetching'а, поток начинает выполнять свой код в режиме "перемотки вперёд", т.е. просматривает поток инструкций, предугадывает переходы, и для всех обращений к памяти, которые встречает, инициирует предвыборку.
Т.е. фактически такты ядра не высвобождаются от заблокированных потоков. Поэтому, возможно, приоритеты потоков негативно скажутся на hardware scouting, т.к. высокоприоритетный поток будет отнимать у остальных потоков возможность делать эффективный prefetching, т.е. потом сталкнёмся с большими простоями...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Автоматическое распараллеливание (было "Что почитать...")
От: WolfHound  
Дата: 16.04.08 15:15
Оценка:
Здравствуйте, remark, Вы писали:

R>Хммм... Ну вообще на первый взгляд звучит заманчиво.

R>Но нигде больше я про такое не слышал...
Да мне просто на днях не спалось и я думал о том что можно сделать с процессорами.

R>Возможно просто производители процессоров ещё не дошли до таких вопросов, т.е. пока технология CMT только обкатывается. Возможно есть какие-то объективные причины против этого.

Может есть причины. Я не спец по процам.
А может просто не подумали об этом.

R>А вот, кстати, ещё момент. В SUN'овских CMT процессорах поток, пока заблокирован в ожидании загрузки кэш-линии, не стоит без дела — он переходит в режим hardware scouting. Это очень эффективный вариант hardware prefetching'а, поток начинает выполнять свой код в режиме "перемотки вперёд", т.е. просматривает поток инструкций, предугадывает переходы, и для всех обращений к памяти, которые встречает, инициирует предвыборку.

Тут палка о двух концах... с одной стороны это может предотвратить промах кеша (который у нас и так дешовый) с другой стороны это увеличивает размеры ядра.
Те мы можем поставить меньше ядер или меньше однотипных АЛУ в одном ядре.

R>Т.е. фактически такты ядра не высвобождаются от заблокированных потоков. Поэтому, возможно, приоритеты потоков негативно скажутся на hardware scouting, т.к. высокоприоритетный поток будет отнимать у остальных потоков возможность делать эффективный prefetching, т.е. потом сталкнёмся с большими простоями...

Это не есть факт. Некоторые потоки конечно могут застрять но другие будут работать.
Болие того можно сделать для hardware scouting отдельное АЛУ. И скаутить оно будет сначала потоки с болие высоким приоритетом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Автоматическое распараллеливание (было "Что почитать.
От: LaPerouse  
Дата: 22.04.08 09:30
Оценка:
Здравствуйте, Кодёнок, Вы писали:

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


LP>>По-момему, автоматический паралеллизм автоматом вытекает из ленивости и чистоты.

LP>>1. Отсутствие побочных эффектов.
LP>>т к fun1 и fun2 чистые, то результат, возвращаемый ими, не зависит от порядка вызова. И рантайм запускает каждую функцию в своем потоке, к моменту вычисления fun1 результат fun2 может быть вполне вычислен. Чем не автоматический параллелизм?

Кё>Тем что предназначение любой программы — это все-таки вызывать побочные эффекты. Чисто вычисления это лишь малая часть любой практически полезной программы.


Кё>Брать абстрактные примеры это ошибка. Попробуй показать автоматическое распараллеливание на простой, но практической программе, например, утилите grep или diff. Можешь писать хоть на самом чистом и ленивом языке, какой сумеешь найти.



Асинхронный ввод-вывод прекрасно параллелится. Правда, это уже будет не автоматический параллелизм. Речь шла не о том.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[3]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 24.04.08 18:57
Оценка:
Здравствуйте, Sergey, Вы писали:


>> В этой связи языки и технологии, вроде Haskell, Lisp с параллельным

>> исполнением и т.п., которые сейчас слишком расточительно расходуют
>> ресурсы, могут оказаться востребованными. Если код на них работает,
>> допустим в 5 — 10 — 20 раз медленее, чем на Си это часто неприемлемо
>> медленно, особенно в вычислительных задачах, но если они позволят
>> программисту быстро написать параллельно исполняющуюся программу на 1600
>> ядрах это будет всё-равно в 160 раз эффективнее, чем работа однопоточной
>> программы.
>>
>> То есть в случае массового распространения сильно многоядерных систем
>> может быть экономически оправдано легкое распараллеливание и не беда, что
>> эффективность может оказаться в размере 10% от пиковой, будет полно задач,
>> где это допустимо.

S>Проблема в том, что для реализации такого сценария понадобится

S>1600-канальная память и 1600 хотя бы полумегабайтных кэшей. Иначе программа
S>у вас будет не в 160 раз эффективнее, а, например, в 2 раза. Или вообще
S>медленнее однопоточной. IMHO.


Именно.
К этому всё и движется. У AMD это уже так, у Intel это тоже будет так со следующего семейства процессоров:
http://www.intel.com/pressroom/archive/reference/whitepaper_nehalem.pdf
(раздел "New System Architecture: Intel QuickPath Technology")
Я имею в виду, что систему будут ссNUMA.... а потом может быть non-ccNUMA. И такие "асимметричные" архитектуры создают дополнительные проблемы для всех, в том числе и для автоматического распараллеливания.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 24.04.08 19:19
Оценка:
Здравствуйте, LaPerouse, Вы писали:

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


R>>Новые технологии нужны. Но новые технологии — это *не* автоматическое распараллеливание.


LP>По-момему, автоматический паралеллизм автоматом вытекает из ленивости и чистоты.


LP>1. Отсутствие побочных эффектов.

LP>b = fun1(a)
LP>c = fun2(a)

LP>т к fun1 и fun2 чистые, то результат, возвращаемый ими, не зависит от порядка вызова. И рантайм запускает каждую функцию в своем потоке, к моменту вычисления fun1 результат fun2 может быть вполне вычислен. Чем не автоматический параллелизм?



В таком "узком" виде "автоматический" параллелизм уже существует достаточно давно. Смотри, например, LazyThreads (1996 год):
http://citeseer.ist.psu.edu/cache/papers/cs2/59/http:zSzzSzwww.cs.cmu.eduzSz~sethzSzLazyzCz20ThreadszCz20ImplementingzCz20azCz20FastzCz20ParallelzCz20Call.pdf/goldstein96lazy.pdf
Реализовали его, кстати, на основе С.

Тут есть 2 проблемы.
Во-первых, а если мы захотим добавить в программу какую-то полезную работу. Ну если программа будет супер быстрая, то она должна хотя бы как-то сообщить об этом, что бы и другие могли порадоваться за неё.
Допустим, fun1() и fun2() отправляют что-то по сети. Их уже переставлять нельзя. А может быть и можно, если протокол допускает произвольный порядок этих сообщений. Это, кстати, система автоматического распараллеливания должна будет сама определить. Как ты предлагаешь это делать?
Как это "автоматический распараллеливатель" будет распараллеливать серверное ПО, клиентское GUI ПО, игры, драйверы и т.д.???

Во-вторых, даже потенциальный, но не реализованный параллелизм имеет стоимость. Пока, насколько я знаю, никто не сумел сделать его бесплатным. У тебя есть вариант?

Да вот ещё, как обрабатывать разделяемые структуры данных???


LP>2. Ленивость. Скажем, параллельно ходу выполнения основного потока в других потоках происходит раскрутка ленивости. Когда потребуются результаты, вместо вычисления всего ленивого кома, просто берет уже вычисленные значения. Чем не автоматический параллелизм?


Берут вычисленные значения. Замечательно. А синхронизация сколько будет стоить?
Мы же говорим о мелкомодульном паралеллизме, это значит, что затраты на синхронизацию при сегодняшней ситуации могут составлять до ~1000% от полезной работы.


LP>Все вышесказанное настолько очевидно, что спорить с этим невозможно.


Блин,а мужики-то не знают!


LP>Понятно, quckSort таким образом не распараллелить, но реально большое количество операций можно выполнять параллельно. Если учесть, что все это достается задаром (пользователь не догадывается о том, где в какой момент времени сколько будет использоваться потоков, да и вообще сказать это можно только на этапе выполнения), то имхо не стоит просто так отметать преусловутый автопаралеллизм.



Бесплатно? Если бы я знал, как это всё сделать бесплатно, то я бы не постил на этом форуме, я бы сейчас отдыхал на своём острове где-нибудь в тихом океане

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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 24.04.08 19:30
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Здравствуйте, Кодёнок, Вы писали:


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


LP>>>По-момему, автоматический паралеллизм автоматом вытекает из ленивости и чистоты.

LP>>>1. Отсутствие побочных эффектов.
LP>>>т к fun1 и fun2 чистые, то результат, возвращаемый ими, не зависит от порядка вызова. И рантайм запускает каждую функцию в своем потоке, к моменту вычисления fun1 результат fun2 может быть вполне вычислен. Чем не автоматический параллелизм?

Кё>>Тем что предназначение любой программы — это все-таки вызывать побочные эффекты. Чисто вычисления это лишь малая часть любой практически полезной программы.


Кё>>Брать абстрактные примеры это ошибка. Попробуй показать автоматическое распараллеливание на простой, но практической программе, например, утилите grep или diff. Можешь писать хоть на самом чистом и ленивом языке, какой сумеешь найти.



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



Именно.


LP>Речь шла не о том.



А о чём же шла речь? О том, что текстовый препроцессор может пройтись по тексту программы и дописать к каждому вызову функции fork, а к каждому обращению к результату join?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Автоматическое распараллеливание (было "Что почитать.
От: Кодёнок  
Дата: 25.04.08 06:56
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>remark, речь ведь совсем не шла о тотальном распараллеливании всего и вся. Там упоминалось лишь два, строго очерченных случая, когда возможность автораспараллеливания очевидна и даже ты, при всей нелюбви к ней, не будешь отрицать, что хотя бы ТЕОРЕТИЧЕСКИ именно в ЭТИХ случаях автопараллелизм возможен.


Это настолько же очевидно, как и бесполезно, потому что какой процент составляет такой код в существующих программах? 1%? 5%? Я и предлагаю тебе взять любую практическую тулсу на хаскеле и оценить соотношение.

К твоему же примеру следует отметить, что если параллелящиеся ветки слишком короткие, то их дешевле вообще не параллелить. Ибо когда-то параллельные результаты должны слиться вместе, а это синхронизация, и само по себе «дерганье» ядра ради исполнения 50 тактов, с учетом заморочек с кешами и пр. даст только замедление. Несомненно, чистых от побочных эффектов веток хватает в любой программе, а вот сколько там достаточно длинных?
Re[4]: Автоматическое распараллеливание (было "Что почитать.
От: Sergey Россия  
Дата: 27.04.08 08:25
Оценка:
> S>Проблема в том, что для реализации такого сценария понадобится
> S>1600-канальная память и 1600 хотя бы полумегабайтных кэшей. Иначе
> программа
> S>у вас будет не в 160 раз эффективнее, а, например, в 2 раза. Или вообще
> S>медленнее однопоточной. IMHO.
>
>
> Именно.
> К этому всё и движется. У AMD это уже так, у Intel это тоже будет так со
> следующего семейства процессоров:
> http://www.intel.com/pressroom/archive/reference/whitepaper_nehalem.pdf
> (раздел "New System Architecture: Intel QuickPath Technology")
> Я имею в виду, что систему будут ссNUMA.... а потом может быть non-ccNUMA.
> И такие "асимметричные" архитектуры создают дополнительные проблемы для
> всех, в том числе и для автоматического распараллеливания.

Я собственно имел в виду чисто техническую проблему — 800 Мб кэша это вам не
хухры-мухры. Я еще могу поверить, что на кристал в ближайшее время научатся
пихать по полторы тыщи сильно упрощенных ядер, но вот в такое количество
кэша за разумные деньги пока поверить не получается.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[5]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 27.04.08 10:23
Оценка:
Здравствуйте, Sergey, Вы писали:


>> S>Проблема в том, что для реализации такого сценария понадобится

>> S>1600-канальная память и 1600 хотя бы полумегабайтных кэшей. Иначе
>> программа
>> S>у вас будет не в 160 раз эффективнее, а, например, в 2 раза. Или вообще
>> S>медленнее однопоточной. IMHO.
>>
>>
>> Именно.
>> К этому всё и движется. У AMD это уже так, у Intel это тоже будет так со
>> следующего семейства процессоров:
>> http://www.intel.com/pressroom/archive/reference/whitepaper_nehalem.pdf
>> (раздел "New System Architecture: Intel QuickPath Technology")
>> Я имею в виду, что систему будут ссNUMA.... а потом может быть non-ccNUMA.
>> И такие "асимметричные" архитектуры создают дополнительные проблемы для
>> всех, в том числе и для автоматического распараллеливания.

S>Я собственно имел в виду чисто техническую проблему — 800 Мб кэша это вам не

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


Может там и не будет кэша. В процессорах Cell у SPE ядер нет кэша.
Хотя Tilera умудрилась запихать 64, а Intel — 80 кэшей на одну подложку уже сейчас.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Автоматическое распараллеливание (было "Что почитать.
От: maggot  
Дата: 16.07.08 16:58
Оценка:
Здравствуйте, LaPerouse, Вы писали:

LP>Все вышесказанное настолько очевидно, что спорить с этим невозможно. Понятно, quckSort таким образом не распараллелить, но реально большое количество операций можно выполнять параллельно.


Это почему не распараллелить?
По моему как раз очень хорошо можно распараллелить.
Re[5]: Автоматическое распараллеливание (было "Что почитать.
От: vdimas Россия  
Дата: 22.07.08 18:22
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>Шедуллер для линеек кеша ессно должен быть отдельным и работать не на уровне потоков, а на уровне ядер.


Более того, нужно часть шедуллера прямо в железке и делать, и давать возможность этим шедуллером управлять программно. Аналогично насчёт примитивов синхронизации, десяток-другой тысяч их прямо в ядре не помешал бы. Идея-то старая, а с современным кол-вом транзисторов на ядро вполне реализуема для требуемого кол-ва одновременно созданных этих примитивов. (Ну уж если кончатся ядерные, то можно делать по-старинке, в ОП).
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[6]: Автоматическое распараллеливание (было "Что почитать.
От: WolfHound  
Дата: 22.07.08 19:25
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Более того, нужно часть шедуллера прямо в железке и делать, и давать возможность этим шедуллером управлять программно.

Что это даст?

Единственное что имеет смысл это для управляемых ОС сделать простенькую комманду для организации safe point'ов.
Это просто условный переход который срабатывает от того что у потока кончился квант времени, ГЦ захотел собрать мусор, случилось прирываение...
По этому переходу переходим на код который сохраняет все регистры которые имеет смысл сохранять, записывает адрес кода который потом востановит сохраненные регистры и передает управление шедуллеру.

V>Аналогично насчёт примитивов синхронизации, десяток-другой тысяч их прямо в ядре не помешал бы.

Каких еще примитивов?
Они ведь очень разные бывают.

Кстати если говорить о всяких там мъютексах, семафорах и тп то меня всегда мягко говоря настораживало то что лочится хрен знает что. Никакой формализации. Одни мутные ничем не проверяемые соглашения.
Мой lock
Автор: WolfHound
Дата: 16.04.08
гораздо понятнее. Лочим 1 или 2 куска памяти и с ними работаем. Все что за их приделами трогать нельзя.

V>Идея-то старая, а с современным кол-вом транзисторов на ядро вполне реализуема для требуемого кол-ва одновременно созданных этих примитивов. (Ну уж если кончатся ядерные, то можно делать по-старинке, в ОП).

Если уж что-то в процессор вкручивать то ту комманду которую описал я.
На ней можно сделать вобще все. Ибо все данные мъютекса, семафора и тп укатываются в одну линейку кеша.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 22.07.08 19:29
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Более того, нужно часть шедуллера прямо в железке и делать, и давать возможность этим шедуллером управлять программно. Аналогично насчёт примитивов синхронизации, десяток-другой тысяч их прямо в ядре не помешал бы. Идея-то старая, а с современным кол-вом транзисторов на ядро вполне реализуема для требуемого кол-ва одновременно созданных этих примитивов. (Ну уж если кончатся ядерные, то можно делать по-старинке, в ОП).



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


Похоже, что HTM как раз и есть реализация таких хардварных примитивов синхронизации. По крайней мере её можно так использовать (HTM lock elission). Причём похоже, что на Sun Rock такая хитрая реализация мьютексов (через HTM lock elission) работает таки быстрее честных мьютексов и масштабируется лучше.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 22.07.08 19:46
Оценка:
Здравствуйте, WolfHound, Вы писали:


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



Так и есть. Мьютекс защищает не данные, а код. TM защищает данные, но не код.


WH>Если уж что-то в процессор вкручивать то ту комманду которую описал я.

WH>На ней можно сделать вобще все. Ибо все данные мъютекса, семафора и тп укатываются в одну линейку кеша.


С линейками кэша не покатит. Надо лочить слова. Иначе это не будет юзабельно ни в одном высокоуровневом языке (кроме С/С++ с очень большой натяжкой). Т.к. как компиялтору надо будет размещать данные? Ему надо будет как-то угадывать, что разместить в одной линейне, а что в разных. Я думаю, что в общем случае это нельзя будет вписать в высокоуровневые языки. Не говоря о том, что кэш должен быть практически полностью прозрачен для ПО, и размер линейки кэша может меняться от модели процессора к модели.


По поводу юзабельности тоже возникают вопросы. Особенно в сравнении с HTM.
Таким примитивом сам бог велел реализовывать уже не мьютексы и семафоры, а сами структуры данных. Т.к. мьютексы и семафоры хорошо реализуются и InterlockedCompareExchange, смысла городить для них что-то более сложное мало. А тут получаем возможность делать lock-free реализации стуктур данных, а это уже немного другое чем структуры на мьютексах и семафорах. А кол-во изменяемых разрозненных слов для произвольной структуры данных уже вполне может быть и не ограничено 2. Очереди, стеки и двух-связанные списки вписываются, а всякие скип-листы, деревья и т.д. уже нет...
Хотя, это бесспорно значительно лучше, чем InterlockedCompareExchange, но если уж мечтать, так мечтать!


Кстати, смотри PLO
Автор: remark
Дата: 16.04.08
это практически то, о чем ты говоришь.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Автоматическое распараллеливание (было "Что почитать.
От: WolfHound  
Дата: 22.07.08 20:30
Оценка:
Здравствуйте, remark, Вы писали:

R>Так и есть. Мьютекс защищает не данные, а код.

Защищать код это мягко говря странное занятие.

R>TM защищает данные, но не код.

Кто?

R>С линейками кэша не покатит. Надо лочить слова.

Один хрен меньше линейки не залочить.
Разве что лиейку сделать размером с слово.

R>Иначе это не будет юзабельно ни в одном высокоуровневом языке (кроме С/С++ с очень большой натяжкой). Т.к. как компиялтору надо будет размещать данные? Ему надо будет как-то угадывать, что разместить в одной линейне, а что в разных. Я думаю, что в общем случае это нельзя будет вписать в высокоуровневые языки. Не говоря о том, что кэш должен быть практически полностью прозрачен для ПО, и размер линейки кэша может меняться от модели процессора к модели.

Вот у С++ будут проблемы.
А у виртуальных машин никаких.
Они под железку легко адаптируются.

R>По поводу юзабельности тоже возникают вопросы. Особенно в сравнении с HTM.

Который не работает.
И работать не будет.
Ибо очень сложный.

R>Таким примитивом сам бог велел реализовывать уже не мьютексы и семафоры, а сами структуры данных.

Так никто и не говорит что ими только мъютексы реализовывать будут.

R>Т.к. мьютексы и семафоры хорошо реализуются и InterlockedCompareExchange, смысла городить для них что-то более сложное мало.

С циклом внутри... А тут нет цикла.

R>А тут получаем возможность делать lock-free реализации стуктур данных, а это уже немного другое чем структуры на мьютексах и семафорах. А кол-во изменяемых разрозненных слов для произвольной структуры данных уже вполне может быть и не ограничено 2.

R>Очереди, стеки и двух-связанные списки вписываются,
Вот их и хватит.

R>а всякие скип-листы, деревья и т.д. уже нет...

А надо?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 22.07.08 22:33
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


R>>Так и есть. Мьютекс защищает не данные, а код.

WH>Защищать код это мягко говря странное занятие.

Ну, что ж делать?

R>>TM защищает данные, но не код.

WH>Кто?

Транзакционная память (TM, Transactional Memory)

R>>С линейками кэша не покатит. Надо лочить слова.

WH>Один хрен меньше линейки не залочить.
WH>Разве что лиейку сделать размером с слово.

А ну если со стороны реализации смотреть, то да, согласен. Я просто посмотрел со стороны семантики.


R>>Иначе это не будет юзабельно ни в одном высокоуровневом языке (кроме С/С++ с очень большой натяжкой). Т.к. как компиялтору надо будет размещать данные? Ему надо будет как-то угадывать, что разместить в одной линейне, а что в разных. Я думаю, что в общем случае это нельзя будет вписать в высокоуровневые языки. Не говоря о том, что кэш должен быть практически полностью прозрачен для ПО, и размер линейки кэша может меняться от модели процессора к модели.

WH>Вот у С++ будут проблемы.
WH>А у виртуальных машин никаких.
WH>Они под железку легко адаптируются.

Ну, если считать, что лочится именно кэш-линия и мы хотим предоставить пользователю возможность этим пользоваться, то сколько смежных слов мы будем гарантировать как попадающию в одну кэш-линию (это нам надо делать на уровне языка)? Потом это, мне кажется, будет накладывать какие-то хитрые ограничения на перемещения объектов GC, на размещение членов внутри объекта, на размещение объектов относительно друг друга и т.д. При этом, что бы знать эти ограничения надо знать к каким объектам будут обращения с помощью этой хитрой команды, а если это не знать, то будет субоптимальные решения. Вобщем, я это особо не продумывал, но мне кажется, что тут будет очень засадно для высокоуровневых (управляемых) языков, в таких языках-то адресов у объектов нет, а тут надо понятие кэш-линии в язык протащить...


R>>По поводу юзабельности тоже возникают вопросы. Особенно в сравнении с HTM.

WH>Который не работает.
WH>И работать не будет.
WH>Ибо очень сложный.

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


R>>Таким примитивом сам бог велел реализовывать уже не мьютексы и семафоры, а сами структуры данных.

WH>Так никто и не говорит что ими только мъютексы реализовывать будут.

Просто с твоих слов:

На ней можно сделать вобще все. Ибо все данные мъютекса, семафора и тп укатываются в одну линейку кеша.

Ризонинг относительно того, что с помощью 2 линеек кэша можно сделать все опирается на то, что 2 линейки кэша достаточно для реализации мьютексов и семафоров.


R>>Т.к. мьютексы и семафоры хорошо реализуются и InterlockedCompareExchange, смысла городить для них что-то более сложное мало.

WH>С циклом внутри... А тут нет цикла.

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


R>>А тут получаем возможность делать lock-free реализации стуктур данных, а это уже немного другое чем структуры на мьютексах и семафорах. А кол-во изменяемых разрозненных слов для произвольной структуры данных уже вполне может быть и не ограничено 2.

R>>Очереди, стеки и двух-связанные списки вписываются,
WH>Вот их и хватит.

Ну их и сейчас можно сделать...

R>>а всякие скип-листы, деревья и т.д. уже нет...

WH>А надо?

Некоторые используют...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Автоматическое распараллеливание (было "Что почитать.
От: vdimas Россия  
Дата: 23.07.08 09:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


V>>Более того, нужно часть шедуллера прямо в железке и делать, и давать возможность этим шедуллером управлять программно.

WH>Что это даст?

Для многоядерных систем в связке со встроенными примитивами синхронизации даст аппаратное переключение потоков без дорогостоящего механизма прерываний.

V>>Аналогично насчёт примитивов синхронизации, десяток-другой тысяч их прямо в ядре не помешал бы.

WH>Каких еще примитивов?
WH>Они ведь очень разные бывают.

Атомарные аппаратные счётчики, больше ничего не надо, и аппаратная логика для них, которая позволит делать из них семафоры, мьютексы или события. При наличии большого файла регистров вся информация о состоянии потоков может хранится прямо в памяти ядра (опять же, что не поместиться в крайнем случае — по старинке в ОП).

WH>Кстати если говорить о всяких там мъютексах, семафорах и тп то меня всегда мягко говоря настораживало то что лочится хрен знает что.


Я имею ввиду, что "лочится" или "отпускается" некий поток, а остальное, действительно, заложено в семантике самой программы.


WH>Никакой формализации. Одни мутные ничем не проверяемые соглашения.


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


WH>Мой lock
Автор: WolfHound
Дата: 16.04.08
гораздо понятнее. Лочим 1 или 2 куска памяти и с ними работаем. Все что за их приделами трогать нельзя.


"Лочим" — понятие растяжимое.

V>>Идея-то старая, а с современным кол-вом транзисторов на ядро вполне реализуема для требуемого кол-ва одновременно созданных этих примитивов. (Ну уж если кончатся ядерные, то можно делать по-старинке, в ОП).

WH>Если уж что-то в процессор вкручивать то ту комманду которую описал я.
WH>На ней можно сделать вобще все. Ибо все данные мъютекса, семафора и тп укатываются в одну линейку кеша.

Угу, и нам нужно будет дёргать АЛУ для банального декремента семафора или проверки состояния события. Это ничем не отличается от существующего подхода.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[10]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 10:46
Оценка:
Здравствуйте, remark, Вы писали:

WH>>Защищать код это мягко говря странное занятие.

R>Ну, что ж делать?
Ну не вижу я смысла защищать код.
Ибо защищать нужно только изменяемые данные.

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

Смысл в том что высокоуровневые ВМ вобще уберают связь с железом прикладного кода.
Разговоры о том что в высокоуровневой ВМ есть комманда которая както отображается на некоторорые железки вобще не имеет смысла.
Такие ВМ можно довети до того что пользователям не нужно будет даже знать слова "модель памяти" ибо можно создать модель в которой переход изменяемых данных между потоками контролируется статически.
А все эти выкрутасы будут нужны только десятку маньяков которые пилят ядро ВМ.
Соответственно эти маньяки берут спецификацию проца и за пару недель выпиливают специализацию ядра под этот проц.

R>А можно поподробнее? Это просто личные наблюдения или есть какие-то внешние источники? Просто Sun'овская реализация-то готовится к выходу... Пока, конечно, сильно не понятно, как это будет в реальной жизни работать, но судя по результатам моделирования вроде должно. Да и вообще сомнительно, что в железе реализуется вещь, уж совсем не рабочая. Пока это всё было на уровне программных реализаций, то да, это было сильно сомнительно...

Я вроде гдето по твоим ссылкам читал что все выкрутасы на эту тему приводили к проездам по памяти.
Да и вобще куча мутной семантики типа грязного чтения итп мягко говоря настораживает.
С деревянными локами куда как понятнее и спокойней.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Автоматическое распараллеливание (было "Что почитать.
От: WolfHound  
Дата: 23.07.08 10:55
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Для многоядерных систем в связке со встроенными примитивами синхронизации даст аппаратное переключение потоков без дорогостоящего механизма прерываний.


Что нужно я уже сказал.

V>Атомарные аппаратные счётчики, больше ничего не надо, и аппаратная логика для них, которая позволит делать из них семафоры, мьютексы или события. При наличии большого файла регистров вся информация о состоянии потоков может хранится прямо в памяти ядра (опять же, что не поместиться в крайнем случае — по старинке в ОП).

А ты не думал о том что система может работать в совсем другом базисе?

V>Разумеется, защита неких данных мьютексом например — это внутреннее соглашение некоей программы, при ошибках в программе она может использовать эти данные и без мьютекса.

В том то и проблема.
Прикладного программиста даже если он пишет драйвер такие вещи парить не должны.

WH>>Мой lock
Автор: WolfHound
Дата: 16.04.08
гораздо понятнее. Лочим 1 или 2 куска памяти и с ними работаем. Все что за их приделами трогать нельзя.

V>"Лочим" — понятие растяжимое.
В данном случае очень конкретное.
И там все подробно описано.

V>Угу, и нам нужно будет дёргать АЛУ для банального декремента семафора или проверки состояния события. Это ничем не отличается от существующего подхода.

А ты уверен что твой подход вобще имеет смысл делать?
Как насчет систем которые работают на примитивах синхронизации ориентированных на данные?
Для них твой подход не эффективен.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 11:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>Защищать код это мягко говря странное занятие.

R>>Ну, что ж делать?
WH>Ну не вижу я смысла защищать код.
WH>Ибо защищать нужно только изменяемые данные.

Ну да, последние 40 лет нам сильно не везло с примитивами синхронизации


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

WH>Смысл в том что высокоуровневые ВМ вобще уберают связь с железом прикладного кода.
WH>Разговоры о том что в высокоуровневой ВМ есть комманда которая както отображается на некоторорые железки вобще не имеет смысла.
WH>Такие ВМ можно довети до того что пользователям не нужно будет даже знать слова "модель памяти" ибо можно создать модель в которой переход изменяемых данных между потоками контролируется статически.
WH>А все эти выкрутасы будут нужны только десятку маньяков которые пилят ядро ВМ.
WH>Соответственно эти маньяки берут спецификацию проца и за пару недель выпиливают специализацию ядра под этот проц.

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


R>>А можно поподробнее? Это просто личные наблюдения или есть какие-то внешние источники? Просто Sun'овская реализация-то готовится к выходу... Пока, конечно, сильно не понятно, как это будет в реальной жизни работать, но судя по результатам моделирования вроде должно. Да и вообще сомнительно, что в железе реализуется вещь, уж совсем не рабочая. Пока это всё было на уровне программных реализаций, то да, это было сильно сомнительно...

WH>Я вроде гдето по твоим ссылкам читал что все выкрутасы на эту тему приводили к проездам по памяти.
WH>Да и вобще куча мутной семантики типа грязного чтения итп мягко говоря настораживает.
WH>С деревянными локами куда как понятнее и спокойней.

Ты наверное читал про STM (Software Transactional Memory).
С HTM (Hardware Transactional Memory) ситуация получше. Проездов по памяти нет, грязных чтений нет. Производительность вроде лучше, чем у мьютексов... по крайней мере на *некоторых* тестах.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[12]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 12:02
Оценка:
Здравствуйте, remark, Вы писали:

R>Ну да, последние 40 лет нам сильно не везло с примитивами синхронизации

Последние 40 лет народ думал не в том направлении.
Ибо защищать код есть бред полный.
Данные защищать нужно. ДАННЫЕ! Не код.

R>В высокоуровневых языках эта команда не будет доступна. Об этом и говорю. Как всегда будет оставаться только ждать пока разработчики языка сами сделают, потом ждать пока они сделают то что нужно, а потом ждать пока они сделают так как нужно, ну а потом можно будет и пользоваться.

На то они и высокоуровневые что бы работать везде (включая железки где даже указатель атомарно не запишешь...) и не напрягать прикладников страшными словами типа "модель памяти".

R>Ты наверное читал про STM (Software Transactional Memory).

Может быть.

R>С HTM (Hardware Transactional Memory) ситуация получше. Проездов по памяти нет, грязных чтений нет. Производительность вроде лучше, чем у мьютексов... по крайней мере на *некоторых* тестах.

Всеравно не верю что хорошо работать будет.
Сложная очень.
Короче ИМХО будет работать только на полегонах.
А как дело дойдет до грязи...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 12:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>В высокоуровневых языках эта команда не будет доступна. Об этом и говорю. Как всегда будет оставаться только ждать пока разработчики языка сами сделают, потом ждать пока они сделают то что нужно, а потом ждать пока они сделают так как нужно, ну а потом можно будет и пользоваться.


WH>На то они и высокоуровневые что бы работать везде (включая железки где даже указатель атомарно не запишешь...)


Ну такую ещё поискать надо. А как, кстати, ты предлагаешь на такой железяке реализовывать Java/C#? Языки-то дают гарантии атомарного присвоения/чтения объектных ссылок. Каждое обращение к объектной ссылке обрамлять в мьютекс это не решение
У С++0х, кстати, в этом плане более грамотный подход — атомарные объекты гарантированно атомарно читаются/пишутся (пусть хоть и с мьютексом), а насчёт "обычных" объектов никаких гарантий нет. Что и разумно, т.к. они *обычные* и к синхронизации потоков отношения не имеют, следовательно и требования атомарности к ним не релевантны. А в Java/C# получается, что любой объект потенциально может использоваться как примитив синхронизации, и компилятор обязан с этим считаться, несмотря на то, что в большинстве случаев это бессмысленно.

WH>и не напрягать прикладников страшными словами типа "модель памяти".


Ну по крайней мере императивные языки с явным тридингом себе такого позволить не могут (Java/C#). Такое себе могут позволить только языки с очень изощренными моделями программирования (DSL типа SQL).


R>>С HTM (Hardware Transactional Memory) ситуация получше. Проездов по памяти нет, грязных чтений нет. Производительность вроде лучше, чем у мьютексов... по крайней мере на *некоторых* тестах.

WH>Всеравно не верю что хорошо работать будет.
WH>Сложная очень.
WH>Короче ИМХО будет работать только на полегонах.
WH>А как дело дойдет до грязи...

Да, хотелось бы увидеть его в деле. Вообще это будет очень серьёзная проверка для всей концепции TM, на которую сейчас возлагаются большие надежды. Ну вообще, посколько это Sun, то зуб даю, что вскоре после выпуска чипов во внутренностях их JVM должно появиться использование этой штуковины, тогда и увидим бенчмарки. А потом и на уровне языка должна появиться поддержка транзакций на основе HTM.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Автоматическое распараллеливание (было "Что почитать.
От: RailRoadMan  
Дата: 23.07.08 12:57
Оценка:
R>Похоже, что HTM как раз и есть реализация таких хардварных примитивов синхронизации. По крайней мере её можно так использовать (HTM lock elission). Причём похоже, что на Sun Rock такая хитрая реализация мьютексов (через HTM lock elission) работает таки быстрее честных мьютексов и масштабируется лучше.

Ты приводил ссылку по моделированию HTM на некоем эмуляторе Sun Rock. Результаты вроде не плохие, но:
1) Все таки это был эмулятор
2) На мой взгляд там было достаточно оговорок и ограничение в хардварных примитивах

Посмотрим, что из этого получится

R>
Re[14]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 13:26
Оценка:
Здравствуйте, remark, Вы писали:

WH>>На то они и высокоуровневые что бы работать везде (включая железки где даже указатель атомарно не запишешь...)

R>Ну такую ещё поискать надо.
Cyberax говорит что есть такие.
Проверять мне лень. Оснований не верить ему у меня нет.

R>А как, кстати, ты предлагаешь на такой железяке реализовывать Java/C#?

R>Языки-то дают гарантии атомарного присвоения/чтения объектных ссылок. Каждое обращение к объектной ссылке обрамлять в мьютекс это не решение
Ну так жабу на той железке запустили... а ксакепы эксплойт на эту тему сделали...

R>Ну по крайней мере императивные языки с явным тридингом себе такого позволить не могут (Java/C#).

Я говорил про ВМ которая не парит программиста моделью памяти.
Жаба и ЦЛР парят.

R>Такое себе могут позволить только языки с очень изощренными моделями программирования (DSL типа SQL).

Языки с явним тредингом тоже могут.
Я еще не до конца проработал систему типов (застрял на компонентной модели) но методы гарантировать отсутствие race condition по объектам управляемым ВМ при явном распаралеливании и без создания жуткого гемороя программисту я уже придумал.
Причем защита у меня ориентированна на данные, а не на куски кода.

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

Короче поживем увидим какой из меня предсказамус.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 13:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>>>На то они и высокоуровневые что бы работать везде (включая железки где даже указатель атомарно не запишешь...)

R>>Ну такую ещё поискать надо.

WH>Cyberax говорит что есть такие.

WH>Проверять мне лень. Оснований не верить ему у меня нет.

comp.arch говорит, что таких днём с огнём поискать. Оснований не верить ему у меня тоже нет:
http://groups.google.com/group/comp.arch/browse_frm/thread/7f4a3877420d6d91



R>>Такое себе могут позволить только языки с очень изощренными моделями программирования (DSL типа SQL).

WH>Языки с явним тредингом тоже могут.
WH>Я еще не до конца проработал систему типов (застрял на компонентной модели) но методы гарантировать отсутствие race condition по объектам управляемым ВМ при явном распаралеливании и без создания жуткого гемороя программисту я уже придумал.
WH>Причем защита у меня ориентированна на данные, а не на куски кода.


А как примерно это будет выглядеть со стороны пользователя?

В принципе, если все примитивы синхронизации языка ограничить мьютексами (семафорами, условными переменными), то можно прийти к достаточно тривиальной модели памяти:

Все обращения к защищенному объекту происходят в глобальном порядке. Каждое обращение к объекту видит изменения сделанные предыдущим обращением. Обращения к объекты без защиты запрещены (или не допускаются синтаксисом — нужное подчеркнуть).


Т.е. на примере Java оставить только:
synchronized(obj)
{
  ... obj ...
}


Ну в принципе по сути POSIX как раз и есть такая максимально примитивная модель памяти.
Ты хочешь предложить что-то ещё более простое? Или что-то такое же простое, но более мощное по возможностям?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[16]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 15:15
Оценка:
Здравствуйте, remark, Вы писали:

R>comp.arch говорит, что таких днём с огнём поискать. Оснований не верить ему у меня тоже нет:

Мне лень искать.
Подождем Cyberax'а.

R>А как примерно это будет выглядеть со стороны пользователя?

Скорей всего так: http://en.wikipedia.org/wiki/Uniqueness_typing
Хотя есть еще варианты.
Что выбрать определюсь когда будут понятны другие части системы типов.

R>Ты хочешь предложить что-то ещё более простое? Или что-то такое же простое, но более мощное по возможностям?

Проще и более мощьное.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 15:33
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>А как примерно это будет выглядеть со стороны пользователя?

WH>Скорей всего так: http://en.wikipedia.org/wiki/Uniqueness_typing
WH>Хотя есть еще варианты.
WH>Что выбрать определюсь когда будут понятны другие части системы типов.


Хммм... на первый взгляд выглядит просто как оптимизация — если на объект только одна ссылка, то изменим на месте; если больше одной, то создадим копию... Как это может дать основу для параллельной модели программирования?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[18]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 15:43
Оценка:
Здравствуйте, remark, Вы писали:

R>Хммм... на первый взгляд выглядит просто как оптимизация — если на объект только одна ссылка, то изменим на месте; если больше одной, то создадим копию...

Откуда ты взял про копию?

R>Как это может дать основу для параллельной модели программирования?

Может.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 16:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Хммм... на первый взгляд выглядит просто как оптимизация — если на объект только одна ссылка, то изменим на месте; если больше одной, то создадим копию...

WH>Откуда ты взял про копию?
Правильнее сказать — ещё один объект такого же типа? Или я вообще не понял о чём речь?

R>>Как это может дать основу для параллельной модели программирования?

WH>Может.
Как?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[20]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 16:32
Оценка:
Здравствуйте, remark, Вы писали:

R>Правильнее сказать — ещё один объект такого же типа? Или я вообще не понял о чём речь?

Думаю второе.

R>Как?

ВМ смотрит чтобы небыло двух ссылок на один объект. Что-то типа std::auto_ptr только формализовано и прошито в систему типов.
И все.
Передача ссылки в другой поток происходит явно.

Благодоря формализации все проверки делаются статически.

На этом же базисе делается IO.
И много чего еще.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 16:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Как?

WH>ВМ смотрит чтобы небыло двух ссылок на один объект. Что-то типа std::auto_ptr только формализовано и прошито в систему типов.
WH>И все.
WH>Передача ссылки в другой поток происходит явно.

Мммм... А если я (программист) явно и намеренно делаю 2 ссылки на объект, а потом ещё явно и намеренно передаю ссылку на этот объект в другой поток, то как тогда быть?


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[22]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 16:58
Оценка:
Здравствуйте, remark, Вы писали:

R>Мммм... А если я (программист) явно и намеренно делаю 2 ссылки на объект,

Давно пытался из одного auto_ptr 2 ссылки получить?
Вот попробуй еще раз.

А тут у тебя программа даже не скомпилируется.

Обычные изменяемые типы тоже будут но мигрировать между потоками они смогут только внутри объекта uniqueness типа.
В интерфейсе uniqueness типа могут использоватся только pure и uniqueness типы.

Те будут 3 семейства типов pure(immutable), mutable и uniqueness.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 17:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


R>>Мммм... А если я (программист) явно и намеренно делаю 2 ссылки на объект,

WH>Давно пытался из одного auto_ptr 2 ссылки получить?
WH>Вот попробуй еще раз.

WH>А тут у тебя программа даже не скомпилируется.


WH>Обычные изменяемые типы тоже будут но мигрировать между потоками они смогут только внутри объекта uniqueness типа.

WH>В интерфейсе uniqueness типа могут использоватся только pure и uniqueness типы.

WH>Те будут 3 семейства типов pure(immutable), mutable и uniqueness.



Аааа. Вот теперь становится немного понятно.
А каким из этих типов ты собираешься бить по многопотосночти? uniqueness? Т.е. это мутабельный тип, но его можно безопасно менять в обоих потоках, т.к. идёт "передача владения" от одного потока другому?

А как быть с mutable типами? Если они mutable и их можно передавать между потоками, то, по-моему, мы возвращаемся к рабитому корыту. Разьве нет?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[25]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 18:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>А как быть с mutable типами? Если они mutable и их можно передавать между потоками, то, по-моему, мы возвращаемся к рабитому корыту. Разьве нет?

WH>Нет. Ибо объект uniqueness типа может быть прекрасным контейнером для любых типов.
WH>

WH>Обычные изменяемые типы тоже будут но мигрировать между потоками они смогут только внутри объекта uniqueness типа.
WH>В интерфейсе uniqueness типа могут использоватся только pure и uniqueness типы.

WH>Благодоря выделеному потоки не смогут захапать себе ссылки на обычные изменяемые типы.
WH>Те между потоков будут курсировать островки изменяемых данных но добраться до содержимого этих островков можно только через интерфейс объекта. А там разрешены только pure и uniqueness типы... Те система типов просто не пропустит ссылку на mutable тип за приделы объекта uniqueness типа.


Мммм... ну это *пользователю* uniqueness типа не добраться до mutable содержимого, а разработчику uniqueness типа?
Т.е. допустим я разрабатываю uniqueness тип, внутри которого присутствует mutable содержимое. Я то должен как-то работать с этим mutable содержимым внутри uniqueness типа, пусть даже наружу я буду выдавать только pure и uniqueness типы. Что-то до конца в голове не укладывается... Т.е. передача между потоками mutable объектов возможна или нет? Если да, то возвращается к разбитому корыту. Если нет, то на нет и суда нет.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[26]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 18:38
Оценка:
Здравствуйте, remark, Вы писали:

R>Мммм... ну это *пользователю* uniqueness типа не добраться до mutable содержимого, а разработчику uniqueness типа?

R>Т.е. допустим я разрабатываю uniqueness тип, внутри которого присутствует mutable содержимое. Я то должен как-то работать с этим mutable содержимым внутри uniqueness типа, пусть даже наружу я буду выдавать только pure и uniqueness типы. Что-то до конца в голове не укладывается...
Берешь и работаешь.
Вот как-то так:
uniqueness type UniquenessArray[Type]
where Type : pure
{
    public this(size : int)
    {
        arr = mutable array(size);
    }
    public Get(i : int) : Type
    {
        arr[i];
    }
    public Set(i : int, value : Type) : ()
    {
        arr[i] = value;
    }
    private arr : mutable array[Type];
}

Фишка в том что дергать методы этого объекта в один момент времени может только один поток.

R>Т.е. передача между потоками mutable объектов возможна или нет? Если да, то возвращается к разбитому корыту. Если нет, то на нет и суда нет.

Только внутри uniqueness типа.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 18:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>
WH>uniqueness type UniquenessArray[Type]
WH>where Type : pure
WH>{
WH>    public this(size : int)
WH>    {
WH>        arr = mutable array(size);
WH>    }
WH>    public Get(i : int) : Type
WH>    {
WH>        arr[i];
WH>    }
WH>    public Set(i : int, value : Type) : ()
WH>    {
WH>        arr[i] = value;
WH>    }
WH>    private arr : mutable array[Type];
WH>}
WH>

WH>Фишка в том что дергать методы этого объекта в один момент времени может только один поток.


А, понятно. Меня смутили слова, что можно передавать mutable объекты между потоками. Получается фактически нельзя. Т.е. если mutable объект внутри uniqueness объекта, и на mutable объект больше нет никаких ссылок из вне, то фактически это уже не mutable объект, а uniqueness объект.
Т.е. можно переписать без потери смысла:
uniqueness type UniquenessArray[Type]
where Type : pure
{
    public this(size : int)
    {
        arr = uniqueness array(size);
    }
    public Get(i : int) : Type
    {
        arr[i];
    }
    public Set(i : int, value : Type) : ()
    {
        arr[i] = value;
    }
    private arr : uniqueness array[Type];
}


Т.е. по сравнениею с чисто функциональным языком (где есть только pure типы) в борьбе с многопоточностью появляется только одно средство — передача владения. А mutable объекты к многопоточности отношения не имеют, их можно "одновременно" менять только внутри одного потока.
Я на правильном пути, или опять заблудился?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[28]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 19:24
Оценка:
Здравствуйте, remark, Вы писали:

R>А, понятно. Меня смутили слова, что можно передавать mutable объекты между потоками. Получается фактически нельзя. Т.е. если mutable объект внутри uniqueness объекта, и на mutable объект больше нет никаких ссылок из вне, то фактически это уже не mutable объект, а uniqueness объект.

R>Т.е. можно переписать без потери смысла:
В общем случае нет.
Главная фишка объекта uniqueness типа это то что на этот объект может существовать только одна ссылка.
2 ссылки на один объект uniqueness типа существовать не могут.
Никогда.

mutable типы этим свойством не страдают. Те их можно завернуть в графы любой сложности.

R>Т.е. по сравнениею с чисто функциональным языком (где есть только pure типы) в борьбе с многопоточностью появляется только одно средство — передача владения. А mutable объекты к многопоточности отношения не имеют, их можно "одновременно" менять только внутри одного потока.

R>Я на правильном пути, или опять заблудился?
В правильной программе один и тот же mutable объект в один момент времени по любому может менять только один поток.
Другое дело что "классические" системы типов не гарантируют правильность многопоточного доступа к изменяемым данным, а моя гарантирует.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: Автоматическое распараллеливание (было "Что почитать
От: Cyberax Марс  
Дата: 23.07.08 19:33
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Главная фишка объекта uniqueness типа это то что на этот объект может существовать только одна ссылка.

WH>2 ссылки на один объект uniqueness типа существовать не могут.
WH>Никогда.
На самом деле, у тебя получается вещь, изоморфная обычным мьютексам (которые тоже могут в один момент времени быть захваченными только в одном экземпляре).
Sapienti sat!
Re[30]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 20:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

WH>>Главная фишка объекта uniqueness типа это то что на этот объект может существовать только одна ссылка.

WH>>2 ссылки на один объект uniqueness типа существовать не могут.
WH>>Никогда.

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



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

Ну вообще хотя, по своему опыту могу сказать, что в многопоточной программе это НЕ ПРОБЛЕМА. Т.е. то, что мне приходится придерживаться некого неявного соглашения, что такой-то мьютекс защищает такие-то данные обычно НЕ ЯВЛЯЕТСЯ проблемой в многопоточной программе, т.е. не приводит к потерям времени, или ошибкам.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[31]: Автоматическое распараллеливание (было "Что почитать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.07.08 20:05
Оценка:
Здравствуйте, remark, Вы писали:

R>Ну вообще хотя, по своему опыту могу сказать, что в многопоточной программе это НЕ ПРОБЛЕМА. Т.е. то, что мне приходится придерживаться некого неявного соглашения, что такой-то мьютекс защищает такие-то данные обычно НЕ ЯВЛЯЕТСЯ проблемой в многопоточной программе, т.е. не приводит к потерям времени, или ошибкам.


Я думаю, все же проблема. Потому что данные, они по определению в единственном экземпляре, а вот кода, использующего эти данные, может быть много. Отсюда либо приходится оборачивать эти данные в защитный код, либо следить за доступом в куче мест. И то и другое — не фонтан.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[29]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 20:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>А, понятно. Меня смутили слова, что можно передавать mutable объекты между потоками. Получается фактически нельзя. Т.е. если mutable объект внутри uniqueness объекта, и на mutable объект больше нет никаких ссылок из вне, то фактически это уже не mutable объект, а uniqueness объект.

R>>Т.е. можно переписать без потери смысла:

WH>В общем случае нет.

WH>Главная фишка объекта uniqueness типа это то что на этот объект может существовать только одна ссылка.
WH>2 ссылки на один объект uniqueness типа существовать не могут.
WH>Никогда.

WH>mutable типы этим свойством не страдают. Те их можно завернуть в графы любой сложности.



Но когда mutable объект находится внутри uniqueness объекта, то на mutable объект тоже гарантированно только одна ссылка. Правильно?



R>>Т.е. по сравнениею с чисто функциональным языком (где есть только pure типы) в борьбе с многопоточностью появляется только одно средство — передача владения. А mutable объекты к многопоточности отношения не имеют, их можно "одновременно" менять только внутри одного потока.

R>>Я на правильном пути, или опять заблудился?

WH>В правильной программе один и тот же mutable объект в один момент времени по любому может менять только один поток.


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


WH>Другое дело что "классические" системы типов не гарантируют правильность многопоточного доступа к изменяемым данным, а моя гарантирует.


А насколько ты считаешь это проблемой?
По моему личному опыту, это НЕ ПРОБЛЕМА. Ну то есть, конечно, если это так, то хорошо; но если и не так, то тоже нормально.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[32]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 23.07.08 20:15
Оценка:
Здравствуйте, AndrewVK, Вы писали:

R>>Ну вообще хотя, по своему опыту могу сказать, что в многопоточной программе это НЕ ПРОБЛЕМА. Т.е. то, что мне приходится придерживаться некого неявного соглашения, что такой-то мьютекс защищает такие-то данные обычно НЕ ЯВЛЯЕТСЯ проблемой в многопоточной программе, т.е. не приводит к потерям времени, или ошибкам.


AVK>Я думаю, все же проблема. Потому что данные, они по определению в единственном экземпляре, а вот кода, использующего эти данные, может быть много. Отсюда либо приходится оборачивать эти данные в защитный код, либо следить за доступом в куче мест. И то и другое — не фонтан.



Я обычно пользуюсь до смешного тупым паттерном:
class synch_queue
{
  queue q;
  mutex guard;
  
  void enqueue(T v)
  {
    lock l (guard);
    q.enqueue(v);
  }

  T dequeue()
  {
    lock l (guard);
    return q.dequeue();
  }
};



Проблема, что кода много, тут не проблема, т.к. схема реализации тупа как тумбочка.
Проблема, что следить из многих мест, тут тоже не проблема, т.к. место одно.


Так в чём же проблема?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[33]: Автоматическое распараллеливание (было "Что почитать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.07.08 20:21
Оценка:
Здравствуйте, remark, Вы писали:

R>Я обычно пользуюсь до смешного тупым паттерном:


Ну то есть свой аналог CDS?

R>Проблема, что кода много, тут не проблема, т.к. схема реализации тупа как тумбочка.


Проблема в том, что производительность этой схемы не ахти. Лок на каждый чих. Для типовых современных многопоточных задач это обычно не страшно, но если нам именно вычисления многопоточные нужны для ускорения единой задачи на многоядерниках, может не прокатить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[30]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 20:34
Оценка:
Здравствуйте, remark, Вы писали:

R>Но когда mutable объект находится внутри uniqueness объекта, то на mutable объект тоже гарантированно только одна ссылка. Правильно?

Внутри uniqueness объекта куча mutable объектов могут создавать произвольные графы.

R>Ну вообще, в совсем общем случае, — нет.

R>Например, счётчик ссылок можно модифицировать одновременно из разных потоков с помощью атомарных операций.
Неявный мьютекс.

R>А насколько ты считаешь это проблемой?

R>По моему личному опыту, это НЕ ПРОБЛЕМА. Ну то есть, конечно, если это так, то хорошо; но если и не так, то тоже нормально.
Людей которые разбираются в многопоточности на твоем уровне ой как мало.
Даже просто способных написать код без race condition'ов не все могут.
А если учесть еще существование различных библиотек с хрен хнает какими неявными контрактами
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 23.07.08 20:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

Вобще говоря все операции синхронизации изоморфны... те через один примитив можно реализовать любой другой...

Главное отличие от мьютексов в том что у меня четко определен объект защиты.
Еще эта система обладает возможностью спокойно перекинуть весь uniqueness объект на другую машину...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: Автоматическое распараллеливание (было "Что почитать
От: Cyberax Марс  
Дата: 23.07.08 21:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Главное отличие от мьютексов в том что у меня четко определен объект защиты.

WH>Еще эта система обладает возможностью спокойно перекинуть весь uniqueness объект на другую машину...
Идея неплохая. Но оно не решит проблемы дэдлоков — мне больше STM/HTM тут нравится.

До меня только что дошло, что я использую этот паттерн уже года четыре в С++
void someFunction(global_ptr<MyObject> obj)
{
    local_ptr<MyObject> loc=obj; //Тут берём блокировку
    ... //Работаем
}
Sapienti sat!
Re[32]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 24.07.08 10:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Идея неплохая. Но оно не решит проблемы дэдлоков —

А я вобще не вижу способа ее решить не превратив жизнь программистов в ад.
А если вспомнить про распределеннае дедлоки, лайвлоки, старвейшены,... Короче голову никто не отменял.

Тем не менее безгеморойная гарантированная защита от локальных race condition'ов уже многого стоит.

C>мне больше STM/HTM тут нравится.

1)STM не работает. Вобще.
2)С HTM то же не все понятно. Скорей всего будет та же байда.
3)Проблем дедлоков и тп они то же не решат. Вспомни хотябы про дедлоки у MSSQL и "не могу сериализовать" у Oracle...

C>До меня только что дошло, что я использую этот паттерн уже года четыре в С++

А local_ptr может передавать владение так же как std::auto_ptr?
А про барьеры памяти local_ptr не забывает?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: Автоматическое распараллеливание (было "Что почитать
От: RailRoadMan  
Дата: 24.07.08 11:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


R>>Но когда mutable объект находится внутри uniqueness объекта, то на mutable объект тоже гарантированно только одна ссылка. Правильно?

WH>Внутри uniqueness объекта куча mutable объектов могут создавать произвольные графы.

У меня сложилось впечатление, что remark интересовался следующей ситуацией:
— существует некий граф mutable объектов и среди них объект "А" на ктр существует произвольное количество ссылок
— возникает необхродимость передать этот объект "А" в другой поток, для этого его надо поместить в uniqueness объект и отдать в этой обертке в другой поток. правильно?
— но тут основной вопрос, что делать с тем, что у первого потока остаются ссылки на "А" из упомянутого графа
— придется либо копировать "А" либо в процесе помещения его в uniquness объект как-то обрезать ссылки или требовать, чтобы их не было?

Мне кстати тоже интересно
Re[32]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 24.07.08 13:08
Оценка:
Здравствуйте, RailRoadMan, Вы писали:

RRM>У меня сложилось впечатление, что remark интересовался следующей ситуацией:

RRM>- существует некий граф mutable объектов и среди них объект "А" на ктр существует произвольное количество ссылок
RRM>- возникает необхродимость передать этот объект "А" в другой поток, для этого его надо поместить в uniqueness объект и отдать в этой обертке в другой поток. правильно?
Вот на это месте ты получишь по рукам от компилятора.
Ибо нельзя передать ссылку на mutable объект в uniqueness объект.
Ни через методы ни через конструктор. Вернуть mutable объект то же нельзя.
mutable объект можно только создать внутри uniqueness объекта и работать с ним то же только внутри этого объекта.

Те тебе придется изменить архитектуру чтобы такого небыло.
Впрочем тебе это придется делать по любоу иначе получишь RC от которого и бежали.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Автоматическое распараллеливание (было "Что почитать.
От: vdimas Россия  
Дата: 24.07.08 14:03
Оценка:
Здравствуйте, remark, Вы писали:

R>Интересно а какой производительности можно добиться для таких аппаратных примитивов синхронизации? Понятно, что можно сделать более специализировано, чем кэш, но фактор расстояния всё равно остаётся...

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

Никак, речь шла о многоядерных. Передавать поток с одного многоядерного процессора на другой — это моветон, ИМХО.


R>Похоже, что HTM как раз и есть реализация таких хардварных примитивов синхронизации. По крайней мере её можно так использовать (HTM lock elission). Причём похоже, что на Sun Rock такая хитрая реализация мьютексов (через HTM lock elission) работает таки быстрее честных мьютексов и масштабируется лучше.


Надо посмотреть, что за зверь...
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[33]: Автоматическое распараллеливание (было "Что почитать
От: RailRoadMan  
Дата: 24.07.08 14:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


RRM>>У меня сложилось впечатление, что remark интересовался следующей ситуацией:

RRM>>- существует некий граф mutable объектов и среди них объект "А" на ктр существует произвольное количество ссылок
RRM>>- возникает необхродимость передать этот объект "А" в другой поток, для этого его надо поместить в uniqueness объект и отдать в этой обертке в другой поток. правильно?
WH>Вот на это месте ты получишь по рукам от компилятора.
WH>Ибо нельзя передать ссылку на mutable объект в uniqueness объект.
WH>Ни через методы ни через конструктор. Вернуть mutable объект то же нельзя.
WH>mutable объект можно только создать внутри uniqueness объекта и работать с ним то же только внутри этого объекта.

Что можно положить в uniqueness объект? Могу я сделать копию mutual объекта и положить его в uniqueness объект?
Видимо тип объекта при такого рода копировании должен измениться на uniqueness. Правильно?
Или надо создать сначала mutual объект внитри uniqueness и потом произвести копирование туда из другого mutual-а находящегося вне uniqueness

В общем как перетащить данные из mutual объекта в uniqueness, чтобы потом их можно было отправить в другой поток?
Re[34]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 24.07.08 14:50
Оценка:
Здравствуйте, RailRoadMan, Вы писали:

RRM>Что можно положить в uniqueness объект?

Передать в метод uniqueness объекта можно только объекты pure и uniqueness типов.

RRM>Могу я сделать копию mutual объекта и положить его в uniqueness объект?

Нет.
Эта копия не пролезит через интерфейс uniqueness объекта.

RRM>Видимо тип объекта при такого рода копировании должен измениться на uniqueness. Правильно?

Типы меняться не умеют.

RRM>Или надо создать сначала mutual объект внитри uniqueness и потом произвести копирование туда из другого mutual-а находящегося вне uniqueness

Это можно. Но через зад автогеном.
Те тебе придется дергать методы uniqueness объекта чтобы привести состояние mutable объекта в нужное.

Как вариант можно попросить рантайм создать глубокий клон uniqueness объекта при условии что он не держит ссылок на uniqueness объекты.

RRM>В общем как перетащить данные из mutual объекта в uniqueness, чтобы потом их можно было отправить в другой поток?

Я думаю нужно просто изначально проектировать так чтобы это было не нужно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: Автоматическое распараллеливание (было "Что почитать
От: Cyberax Марс  
Дата: 24.07.08 14:59
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>мне больше STM/HTM тут нравится.

WH>1)STM не работает. Вобще.
WH>2)С HTM то же не все понятно. Скорей всего будет та же байда.
WH>3)Проблем дедлоков и тп они то же не решат. Вспомни хотябы про дедлоки у MSSQL и "не могу сериализовать" у Oracle...
Да, дедлоков нет, зато возможны лайвлоки и оно всё равно не поможет для contended-ресурсов.

C>>До меня только что дошло, что я использую этот паттерн уже года четыре в С++

WH>А local_ptr может передавать владение так же как std::auto_ptr?
Нет, достаточно было простого scope-владения.

WH>А про барьеры памяти local_ptr не забывает?

Примитивы синхронизации их и так ставят.
Sapienti sat!
Re[10]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 24.07.08 16:19
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Я такого еще не видел.

Переход к таким системам неизбежен.
Ибо защищать код идея бредовая.
Про то что взамен читай ветку еще раз.

V>Эффективен для обслуживания того самого внутреннего мьютекса.

Да нету никакого мъютекса.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 24.07.08 16:46
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>Я такого еще не видел.

WH>Переход к таким системам неизбежен.
WH>Ибо защищать код идея бредовая.
WH>Про то что взамен читай ветку еще раз.

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

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

V>>Эффективен для обслуживания того самого внутреннего мьютекса.

WH>Да нету никакого мъютекса.

Пока что есть, на каждый хендл ввода-вывода внутри ОС. И еще один глобальный — на создание и удаление подобных хендлов из общего списка.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[34]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 24.07.08 18:16
Оценка:
Здравствуйте, AndrewVK, Вы писали:

R>>Я обычно пользуюсь до смешного тупым паттерном:


AVK>Ну то есть свой аналог CDS?


R>>Проблема, что кода много, тут не проблема, т.к. схема реализации тупа как тумбочка.


AVK>Проблема в том, что производительность этой схемы не ахти. Лок на каждый чих.



Нет, нет, нет. Очередь тут просто в качестве примера. Я имел в виду, что делается безопасная "синхронизированная" обертка для какой-то функциональности. Гранулярность функций — "бизнес операция", а не примитивное действие, т.ч. производительность такая же, как если бы блокировки были "снаружи".


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



По моему личному опыту такая схема покрывает более 90% случаев. Хотя, действительно, есть более изощренные ситуации, когда надо, например, блокировать сразу несколько произвольных объектов из множества; или когда блокировки должны быть вложенными.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[34]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 24.07.08 18:39
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>но если нам именно вычисления многопоточные нужны для ускорения единой задачи на многоядерниках, может не прокатить.



А вот, кстати, по поводу вычислительных задач. Допустим возьмем следующую задачу. Итеративно считаем некую матрицу. Всегда храним 2 версии матрицы — одна текущая, значения в которой модифицируются; вторая — значения на предыдущей итерации, значения в этой матрице только читаются. После очередной итерации матрицы меняются местами. Для определенности допустим, что у нас есть 4 процессора/потока, каждый поток обсчитывает свой квадрант текущей матрицы, но при этом читает он значения из всей предыдущей матрицы.

Интересно, справится ли система типов WolfHound'а с такой задачей? Интересно было бы услышать комментарии.
Я тут вижу 2 интересных момента.
Во-первых, доступ к матрице (читай массиву) тут надо обеспечивать не на уровне всего массива, а на уровне определенных частей массива (квадрантов). В системах статического анализа массивы — это стандартная засада, обычно системы анализа трактуют массив как один объект, что в некоторых случаях очень не благоприятно сказывается на свойствах системы анализа. Вариант разбить массив на несколько объектов не очень хорошая, т.к. массив — это быстро; индексация в матрице на основе массива очень быстрая; работать на основе массивов просто принято в HPC сообществе; да и вообще не возможность решить именно поставленную задачу бьет по "мощности" и "гибкости" системы.
Второй момент, константность ("pureness") объекта определяется не статически, а динамически. Т.е. на одной итерации одна матрица pure, на другой — другая. Необходимость получения доступа на чтение к "предыдущей" матрице без всяких блокировок — критична. Копировать матрицы на каждой итерации тоже не вариант.

Вообще идея динамическо-статической типизации, по-моему, достаточно интересна. Что-то типа такого:
vector v = new mutable vector (100);
mutate(v);
declare_const(v);
read(v);
mutate(v); // - не скомпилируется

Т.е. можем менять тип объекта в ран-тайм, но в тоже время компилятор следит какой тип имеет объект в каждой точке программы. Соотв. трюки типа такого компилятор будет просто запрещать:
if (rand())
  declare_const(v);

Типа того, как это есть для определений переменных в С/С++:
{
  int x = 0; // можно
  switch (y)
  {
    case 0:
    {
      int w = 0; // можно
    }
    break;
    case 1:
      int q = 0; // нельзя
      break;
  }
}

Т.е. с одной стороны переменные можно создавать динамически, и кол-во созданных переменных зависит от ран-тайм состояния; но с другой стороны компилятор всё равно точно знает какая переменная доступна/жива в каждой конкретной точке программы. Соотв. аналогично трюки с "условным" созданием переменных запрещены.

Но правда похоже, что всё равно корректность не всех динамических изменений типа можно проверить во-время компиляции, и соотв. придется вставлять динамические проверки, кидающие исключения. Что, конечно, не очень круто.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[35]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 24.07.08 19:11
Оценка:
Здравствуйте, remark, Вы писали:

R>А вот, кстати, по поводу вычислительных задач. Допустим возьмем следующую задачу. Итеративно считаем некую матрицу. Всегда храним 2 версии матрицы — одна текущая, значения в которой модифицируются; вторая — значения на предыдущей итерации, значения в этой матрице только читаются. После очередной итерации матрицы меняются местами. Для определенности допустим, что у нас есть 4 процессора/потока, каждый поток обсчитывает свой квадрант текущей матрицы, но при этом читает он значения из всей предыдущей матрицы.

Ты подходишь к решению как императивный программист.
Тут нужно уточнить как именно получаются новые значения.
Если они зависят исключительно от состояния предыдущего шага и индекса ячейки матрици то тут за нас вобще все рантайм в лучшем виде сделает:
def mtxN = array(100, 200, (i, j) => mtxNminus1[i, j] + 1);

В данном случае мы просто указали системе какими значениями заполнить матрицу на очередном шаге.
Видя независимость по данным ячеек матрици рантайм при жилании может запустить обсчет каждой ячейки в своем потоке.
Матрицу с шага N-2 просто уберет GC.
А при более вдумчивом анализе (довольно простом в данном случае) система просто переиспользует память от матрици на предыдущем шаге.

R>Второй момент, константность ("pureness") объекта определяется не статически, а динамически. Т.е. на одной итерации одна матрица pure, на другой — другая. Необходимость получения доступа на чтение к "предыдущей" матрице без всяких блокировок — критична. Копировать матрицы на каждой итерации тоже не вариант.

В принципе если ввести аналог С++'ного const для методов uniqueness типа то можно сделать преобразование uniqueness -> pure при условии что у pure варианта можно будет трогать только const методы.
Обратная трансформация невозможна.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: Автоматическое распараллеливание (было "Что почитать
От: RailRoadMan  
Дата: 25.07.08 08:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


RRM>>Что можно положить в uniqueness объект?

WH>Передать в метод uniqueness объекта можно только объекты pure и uniqueness типов.

RRM>>Могу я сделать копию mutual объекта и положить его в uniqueness объект?

WH>Нет.
WH>Эта копия не пролезит через интерфейс uniqueness объекта.

RRM>>Видимо тип объекта при такого рода копировании должен измениться на uniqueness. Правильно?

WH>Типы меняться не умеют.

RRM>>Или надо создать сначала mutual объект внитри uniqueness и потом произвести копирование туда из другого mutual-а находящегося вне uniqueness

WH>Это можно. Но через зад автогеном.
WH>Те тебе придется дергать методы uniqueness объекта чтобы привести состояние mutable объекта в нужное.

Здесь
Автор: WolfHound
Дата: 24.07.08
ты говоришь, что внутри uniqueness объекта куча mutable объектов могут создавать произвольные графы.
Это делается тоже через методы uniqueness объекта? тоже через зад получается...

RRM>>В общем как перетащить данные из mutual объекта в uniqueness, чтобы потом их можно было отправить в другой поток?

WH>Я думаю нужно просто изначально проектировать так чтобы это было не нужно.

Я не согласен с такой точкой зрения. У меня есть две достаточно сложные модели (граф mutual объектов), каждая и ктр обрабатывается своим потоком. Мне необходимо передавать данные между этими моделями (не всю можель целиком). Как я могу это сделать?
Я должен сразу в модели для тех данных ктр я потом буду передавать в другую модель сразу использовать uniquness объекты?
Re[36]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 25.07.08 09:21
Оценка:
Здравствуйте, RailRoadMan, Вы писали:

RRM>Здесь
Автор: WolfHound
Дата: 24.07.08
ты говоришь, что внутри uniqueness объекта куча mutable объектов могут создавать произвольные графы.

RRM>Это делается тоже через методы uniqueness объекта? тоже через зад получается...
Зачем демагогию то разводить?
Одно дело когда мы пытаемся ломиться в открытую дверь и совсем другое когда просто работаем накапливая данные в контейнере.

RRM>Я не согласен с такой точкой зрения. У меня есть две достаточно сложные модели (граф mutual объектов), каждая и ктр обрабатывается своим потоком.

Закатываем каждую из них в uniquness объект.
Общаемся через типизированные каналы (типа как в сингулярити).
Концы канала uniquness объекты. Соответственно проходить через каналы могут только uniquness и pure объекты.

RRM>Мне необходимо передавать данные между этими моделями (не всю можель целиком). Как я могу это сделать?

RRM>Я должен сразу в модели для тех данных ктр я потом буду передавать в другую модель сразу использовать uniquness объекты?
Как вариант.
Но я думаю тебе таки стоит обратить внимание на pure объекты. Те твои модели будут смесью из mutable и где возможно pure объектов.
В очень многих ситуациях на них можно сделать гораздо более эффективные решения чем думают программисты с большим императивным опытом.
Свежий пример.
Автор: WolfHound
Дата: 24.07.08

Еще можно посмотреть на то как на операциях конкатенации, втавки, удаления и взятия подстроки неизменяемые rope'ы жестоко рвут классические строки. Причем и по памяти и по производительности.
Еще один хрестоматийный пример это неизменяемые сбалансированные деревья (RB, AVL, 2-3,...) когда у нас сотни тысяч словарей с разным содержанием занимают N*log(N) памяти. Например в компиляторах бывает очень полезно.
...

А к uniquness объектам нужно относится как к границам синхронизации. И использовать их соответственно. Даже не смотря на то что при однопоточной рабете с таким объектом мы имеем нулевой оверхед вплоть до инлайна методов.
Еще один вариант их использования это организация детерминированной финализации. Да у uniquness объектов есть полноценные деструкторы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 25.07.08 12:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>А вот, кстати, по поводу вычислительных задач. Допустим возьмем следующую задачу. Итеративно считаем некую матрицу. Всегда храним 2 версии матрицы — одна текущая, значения в которой модифицируются; вторая — значения на предыдущей итерации, значения в этой матрице только читаются. После очередной итерации матрицы меняются местами. Для определенности допустим, что у нас есть 4 процессора/потока, каждый поток обсчитывает свой квадрант текущей матрицы, но при этом читает он значения из всей предыдущей матрицы.


WH>Ты подходишь к решению как императивный программист.

WH>Тут нужно уточнить как именно получаются новые значения.
WH>Если они зависят исключительно от состояния предыдущего шага и индекса ячейки матрици то тут за нас вобще все рантайм в лучшем виде сделает:
WH>
WH>def mtxN = array(100, 200, (i, j) => mtxNminus1[i, j] + 1);
WH>

WH>В данном случае мы просто указали системе какими значениями заполнить матрицу на очередном шаге.
WH>Видя независимость по данным ячеек матрици рантайм при жилании может запустить обсчет каждой ячейки в своем потоке.
WH>Матрицу с шага N-2 просто уберет GC.

Я поражаюсь как у тебя всё всегда просто

А компилятор в действительности сможет это сделать приемлемо?
Ну хорошо, допустим даже, что сможет.

А теперь допустим, что матрица — это у нас изображение. Которое мы обсчитываем путем ray-tracing'а. Как компилятор побъет эту матрицу для независимой обработки потоками? Бить её квадрантами или широкими горизонтальными или вертикальными линиями очень не хорошо. Т.к. при ray-tracing'е объем работы сильно зависит от изображения, соотв., если мы будем бить широкими горизонтальными полосами, мы получим, что объем работы для обработки верхней полосы, где небо, будет в 100 раз меньше, чем объем работы для нижней полосы, где несколько детализированных моделей деревьев. Соотв. бить надо в зависимости от задачи, например очень узкими горизонтальными полосами, и каждому потоку достается множество полос, удовлетворяющее (stripe_index % thread_count == thread_index).
Теперь допустим, что компилятор не сможет это сделать автоматически и вернемся к исходному вопросу.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[36]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 25.07.08 12:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Второй момент, константность ("pureness") объекта определяется не статически, а динамически. Т.е. на одной итерации одна матрица pure, на другой — другая. Необходимость получения доступа на чтение к "предыдущей" матрице без всяких блокировок — критична. Копировать матрицы на каждой итерации тоже не вариант.


WH>В принципе если ввести аналог С++'ного const для методов uniqueness типа то можно сделать преобразование uniqueness -> pure при условии что у pure варианта можно будет трогать только const методы.

WH>Обратная трансформация невозможна.


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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[37]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 25.07.08 13:29
Оценка:
Здравствуйте, remark, Вы писали:

R>Я поражаюсь как у тебя всё всегда просто

Ну что поделать если все действительно просто когда нет зависимостей по данным.

R>А компилятор в действительности сможет это сделать приемлемо?

R>Ну хорошо, допустим даже, что сможет.
Думаю что если за эту часть компилятора посадить тебя предварительно объяснив философию работы с неизменяемыми данными то наверняка сможет.

R>А теперь допустим, что матрица — это у нас изображение. Которое мы обсчитываем путем ray-tracing'а.

Не вопрос.

R>Как компилятор побъет эту матрицу для независимой обработки потоками?

Как угодно.
Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно.
Ибо значение пикселя это функция от сцены, камеры и координат пикселя.

R>Бить её квадрантами или широкими горизонтальными или вертикальными линиями очень не хорошо. Т.к. при ray-tracing'е объем работы сильно зависит от изображения, соотв., если мы будем бить широкими горизонтальными полосами, мы получим, что объем работы для обработки верхней полосы, где небо, будет в 100 раз меньше, чем объем работы для нижней полосы, где несколько детализированных моделей деревьев. Соотв. бить надо в зависимости от задачи, например очень узкими горизонтальными полосами, и каждому потоку достается множество полос, удовлетворяющее (stripe_index % thread_count == thread_index).

fork/join + work stealing
В случае с перемножением матриц это вобще идеальный вариант.
В случае с ray-tracing поддерево с небом быстренько обсчитается и все ресурсы переползут на поддерево с лесом.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 25.07.08 13:29
Оценка:
Здравствуйте, remark, Вы писали:

WH>>В принципе если ввести аналог С++'ного const для методов uniqueness типа то можно сделать преобразование uniqueness -> pure при условии что у pure варианта можно будет трогать только const методы.

WH>>Обратная трансформация невозможна.
R>Мне кажется, что наличие только одного этого преобразования не добавляет много к языку, из-за... однобокости... и ограниченности.
Вобще да. Отдает некой костыльностью.

R>Т.е. хотелось бы чего-то более... как сказать... мощного.

Хотелось бы.

R>Можно ли ещё что-то добавить?

Может что-то еще придумаю.

R>Хотя, возможно, и наличие только такого одного преобразования будет тоже полезным на практике. Мне сейчас сложно сказать. Что думаешь? Будет оно полезно?

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

Хотя нужно еще подумать. Может из меня еще не доконца вышли императивные замашки.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 25.07.08 13:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Хотя, возможно, и наличие только такого одного преобразования будет тоже полезным на практике. Мне сейчас сложно сказать. Что думаешь? Будет оно полезно?


WH>Думаю будет.

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


Хороший пример. В одном императивном языке, не будем называть имён, часто делается так:
hash_map const m = create_and_initialize_complex_hash_map();

И тут действительно происходит неявное преобразование unique -> const. И оно действительно всегда безопасно. Хотя, конечно, ответственность, что объект был действительно unique тут лежит на программисте.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[38]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 25.07.08 14:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Как компилятор побъет эту матрицу для независимой обработки потоками?


WH>Как угодно.

WH>Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно.
WH>Ибо значение пикселя это функция от сцены, камеры и координат пикселя.

В том-то и дело, что можно. Можно, но не нужно.


R>>Бить её квадрантами или широкими горизонтальными или вертикальными линиями очень не хорошо. Т.к. при ray-tracing'е объем работы сильно зависит от изображения, соотв., если мы будем бить широкими горизонтальными полосами, мы получим, что объем работы для обработки верхней полосы, где небо, будет в 100 раз меньше, чем объем работы для нижней полосы, где несколько детализированных моделей деревьев. Соотв. бить надо в зависимости от задачи, например очень узкими горизонтальными полосами, и каждому потоку достается множество полос, удовлетворяющее (stripe_index % thread_count == thread_index).


WH>fork/join + work stealing


Т.е. ты просто предлагаешь ввести типы шедулинга, как в OpenMP — static, dynamic etc.
Ну в принципе для данной конкретной задачи это сработает.

Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками? Видимо, что бы программист мог реализовать что-то сам, чего не умеет язык/ран-тайм. Раз так, значит должна быть соотв. поддержка. Какая например поддержка видно из вышеприведенного примера — например, указывать доступ к массиву на уровне элементов. Или давать доступ к объекту как к pure, а потом как к mutable, а потом опять как к pure.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[37]: Автоматическое распараллеливание (было "Что почитать
От: palm mute  
Дата: 25.07.08 14:36
Оценка:
Здравствуйте, remark, Вы писали:


WH>>В принципе если ввести аналог С++'ного const для методов uniqueness типа то можно сделать преобразование uniqueness -> pure при условии что у pure варианта можно будет трогать только const методы.

WH>>Обратная трансформация невозможна.

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

R>Хотя, возможно, и наличие только такого одного преобразования будет тоже полезным на практике. Мне сейчас сложно сказать. Что думаешь? Будет оно полезно?

Менее однобокий вариант: Lazy Functional State Threads.
В двух словах: описаны примитивы для работы с изменяемыми переменными/массивами (вида newVar, newArray, readVar, writeVar), и показано, как гарантировать, что выражение 'runImperative func' компилируется только в том случае, если изменяемые объекты не доступны снаружи func.
Re[39]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 25.07.08 14:50
Оценка:
Здравствуйте, remark, Вы писали:

WH>>Как угодно.

WH>>Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно.
WH>>Ибо значение пикселя это функция от сцены, камеры и координат пикселя.
R>В том-то и дело, что можно. Можно, но не нужно.
Почему не нужно?

R>Т.е. ты просто предлагаешь ввести типы шедулинга, как в OpenMP — static, dynamic etc.

R>Ну в принципе для данной конкретной задачи это сработает.
Не предлагаю.
Пусть рантайм сам разбирается.

R>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками?

Есть разные задачи.
Например http сервер. Вот ему очень нужен явный трединг.
А числомолотилкам он вреден.

R>Видимо, что бы программист мог реализовать что-то сам, чего не умеет язык/ран-тайм. Раз так, значит должна быть соотв. поддержка.

R>Какая например поддержка видно из вышеприведенного примера — например, указывать доступ к массиву на уровне элементов.
Все несколько не так.
Данная механика уневерсальна для любых pure данных.
Ибо в их случае всегда легко прослеживается зависимость по данным.

R>Или давать доступ к объекту как к pure, а потом как к mutable, а потом опять как к pure.

Вот этого небудет.
Ибо неверефицируемо.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 25.07.08 19:50
Оценка:
Здравствуйте, palm mute, Вы писали:

PM>Менее однобокий вариант: Lazy Functional State Threads.

Не-не-не. palm mute Не-не-не.
Это гораздо более однобокий вариант.

Например в их системе невозможен обмен между потоками. Все что они умеют это передать в поток кучу pure данных и дождаться пока он вернет другую кучу pure данных.
Для реальных применений этого недостаточно.
А всякие interleaveST разрушают все доказательства.
Что совсем приговор.

Мой подход этим не страдает.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Автоматическое распараллеливание (было "Что почитать.
От: vdimas Россия  
Дата: 26.07.08 11:53
Оценка:
Здравствуйте, remark, Вы писали:

Добавлю:

R>Интересно а какой производительности можно добиться для таких аппаратных примитивов синхронизации? Понятно, что можно сделать более специализировано, чем кэш, но фактор расстояния всё равно остаётся...


Кеш — это память, она не умеет делать простейших операций, типа декремента или проверки значения на 0, например. Поэтому дёргается АЛУ, со всеми прелестями типа доп. загрузки аппаратного шедуллера, срыва конвеера и т.д. Использовать сверхсложное АЛУ для обслуживания примитивов синхронизации — это из пушки по воробьям, т.к. для реализации аппаратного примитива синхронизации нужен лишь банальный аппаратный счётчик. Добавить десяток-другой тысяч их в современный проц ничего не стоит. Далее, было бы неплохо иметь довольно большой общий файл регистров, в котором можно было бы хранить состояния регистров конкретного потока с той целью, чтобы при вытеснении потока не копировать состояния регистров во внешнюю память, и не загружать оттуда сохранённое состояние. Все эти переключения потоков должны происходить аппаратно в течении одного такта (и то, аналогия "переключения" не совсем верна).

Насколько эффективна такая системы мы все давно знаем, за счёт увеличения внутреннего файла регистров и небольшого усложнения шедуллера, который завязан и на задержки (пока что лишь) доступа к памяти, интеловские процы умудряются из одного ядра делать практически два, за счёт исполнения 2-х потоков, и всего-навсего достаточно мгновенного переключение потоков для такого фокуса (повторюсь, "переключение" — это не совсем верно, для случая, когда два или более конвеера АЛУ работают одновременно). Ведь мы имеем более чем одно целочисленное АЛУ и обычно более чем одно для плавающей запятой, т.е. суть в том, что понятия "многоядрный" и "многопоточный" малость сливаются в одно.

Я себе так представляю действительно многоядерный/многопоточный процессор:
— несколько потоков исполнения, т.е. просто большой файл внутренних регистров
— приличное кол-во блоков АЛУ
— шедуллер, который управляет потоками и загрузками АЛУ

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

Помимо этого в процах есть еще логика по дешифровке кодов команд, переименованию регистров, спекулятивное выполнение и т.д. Но мне кажется, что таких блоков может быть гораздо меньше, чем потоков, учитывая, что потоки могут приличную часть времени проводить в ожидании загрузки кеша, или же в ожидании сигналов от наших гипотетических доп. прикладных примитивов синхронизации.
Re[37]: Автоматическое распараллеливание (было "Что почитать
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.07.08 14:00
Оценка:
Здравствуйте, remark, Вы писали:

R>А теперь допустим, что матрица — это у нас изображение. Которое мы обсчитываем путем ray-tracing'а.


Плохой пример. При рейтрейсинге обрабатываемые данные не меняются, и никакой синхронизации не нужно, а меняющийся выхлоп ничтожно мал по сравнению с перевариваемыми объемами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[8]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 27.07.08 16:13
Оценка:
Здравствуйте, vdimas, Вы писали:

R>>Интересно а какой производительности можно добиться для таких аппаратных примитивов синхронизации? Понятно, что можно сделать более специализировано, чем кэш, но фактор расстояния всё равно остаётся...

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

V>Никак, речь шла о многоядерных. Передавать поток с одного многоядерного процессора на другой — это моветон, ИМХО.


По крайней мере современные многоядерные процессоры Intel/AMD позволяют многопроцессорные конфигурации. И значительная часть серверов именно несколько-процессорная. Что-то не увязывается...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 27.07.08 16:27
Оценка:
Здравствуйте, vdimas, Вы писали:

R>>Интересно а какой производительности можно добиться для таких аппаратных примитивов синхронизации? Понятно, что можно сделать более специализировано, чем кэш, но фактор расстояния всё равно остаётся...


V>Кеш — это память, она не умеет делать простейших операций, типа декремента или проверки значения на 0, например. Поэтому дёргается АЛУ



Не очень понятно, а в чём проблема дергать АЛУ? АЛУ — это ж самая быстродействующая и, зачастую, недозагруженная часть системы. Если считать, что АЛУ может выдавать 3 команды за такт, а на перемещение кэш-линии тратится 200 тактов, то доля АЛУ тут получается менее 1%. Плюс к этому, примерно в 50% случаев обращение к примитиву синхронизации связано с проверкой, т.е. это ветвление, т.е. конвеер в любом случае должен быть осведомлен об этой операции, выполнять её полностью в разрыве с АЛУ не видится возможным.
А вот сам специализированный и мелко-гранулярный счетчик не помешало бы иметь... Если бы его можно было реализовать значительно быстрее, чем протокол когерентности общего назначения. Я в этом не большой специалист, но я думаю, что с доступом к одному счетчику из раных ядер должны быть определенные проблемы (например, синхронизация частот). Ну и по прежнему не понятно, как быть с многопроцессорными конфигурациями.


V>Далее, было бы неплохо иметь довольно большой общий файл регистров, в котором можно было бы хранить состояния регистров конкретного потока с той целью, чтобы при вытеснении потока не копировать состояния регистров во внешнюю память, и не загружать оттуда сохранённое состояние. Все эти переключения потоков должны происходить аппаратно в течении одного такта (и то, аналогия "переключения" не совсем верна).


Ну так это ж вроже Sun Niagara/Rock. У них там сколько аппаратных потоков? Вроде 32 было на одном процессоре. И встроенный шедулер. У Intel пока дело дошло только до 2 аппаратных потоков на ядро, но я думаю, что в ближайшем будущем будет больше.


V>понятия "многоядрный" и "многопоточный" малость сливаются в одно.


Для такой схему применяются термины CMT (Chip MultiThreading), HWT (Hardware MultiThreading), HT (HyperThreading). А обобщенный поток исполнения называется Аппаратный Поток Исполнения (Hardware Thread), т.е. это может быть либо процессор, либо ядро, либо поток внутри ядра.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[40]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 27.07.08 16:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Как угодно.

WH>>>Если сцена неизменяемая и расчет пикселея не завист от соседей то можно делать что угодно.
WH>>>Ибо значение пикселя это функция от сцены, камеры и координат пикселя.
R>>В том-то и дело, что можно. Можно, но не нужно.
WH>Почему не нужно?

R>>Т.е. ты просто предлагаешь ввести типы шедулинга, как в OpenMP — static, dynamic etc.

R>>Ну в принципе для данной конкретной задачи это сработает.
WH>Не предлагаю.
WH>Пусть рантайм сам разбирается.


Не нужно, потому что, я в это не верю, это, блин, какой-то rocket science.
Это должна быть монсторская система, которая на основе само-рефлексии занимается само-твикингом. Тут гарантированно есть 2 недетерминированных фактора — входные данные и загрузка системы сторонними приложениями. Т.е. помимо монсторского алгоритмы, тут нужна выборка репрезентативных приложений и пара лет ручного твикинга параметров. И даже если это будет сделано, сомнительно, что это имеет смысл перед ручным анализом и реализацией алгоритма, которая может занять порядка нескольких дней.


R>>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками?


WH>Есть разные задачи.

WH>Например http сервер. Вот ему очень нужен явный трединг.
WH>А числомолотилкам он вреден.


Т.е. тут твой тезис, что для "http сервера" будут не нужны такие вещи как контроль доступа на уровне элементов массива, и изменение pure/mutable в ран-тайм? Ну что ж, возможно, это вполне разумно... В любом случае примера-убийцы у меня нет...


R>>Видимо, что бы программист мог реализовать что-то сам, чего не умеет язык/ран-тайм. Раз так, значит должна быть соотв. поддержка.

R>>Какая например поддержка видно из вышеприведенного примера — например, указывать доступ к массиву на уровне элементов.

WH>Все несколько не так.

WH>Данная механика уневерсальна для любых pure данных.
WH>Ибо в их случае всегда легко прослеживается зависимость по данным.


Но это НЕ достаточное условие для эффективной автоматической реализации. Это лишь необходимое условие!



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[41]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 27.07.08 17:46
Оценка:
Здравствуйте, remark, Вы писали:

R>Не нужно, потому что, я в это не верю, это, блин, какой-то rocket science.

Все проще. Нужно просто немного статистики собрать.
А на длинных расчетах статистика наберется уже после пары итераций.

R>Это должна быть монсторская система, которая на основе само-рефлексии занимается само-твикингом.

hotspot...
Только тут все еще проще и круче будет ибо жаба совсем не формализована, а тут куча теорем с доказательствами есть.

R>Тут гарантированно есть 2 недетерминированных фактора — входные данные и загрузка системы сторонними приложениями.

И с тем и с другим (особенно с загрузкой системы) можно разобраться только во время работы программы.

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

Если таки делать уневерсальный рантайм то несколько человеколет тюнинга многократно окупятся последующим применением.

R>>>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками?

WH>>Есть разные задачи.
WH>>Например http сервер. Вот ему очень нужен явный трединг.
WH>>А числомолотилкам он вреден.
R>Т.е. тут твой тезис, что для "http сервера" будут не нужны такие вещи как контроль доступа на уровне элементов массива, и изменение pure/mutable в ран-тайм? Ну что ж, возможно, это вполне разумно... В любом случае примера-убийцы у меня нет...
Нет тезис в том что явный трединг то же нужен.
В случае с http сервером у нас есть куча явных, независимых запросов.
И обрабатывать их удобно в отдельных потоках. Если во время обработки запроса будет удобно запустить еще потоки то так тому и быть.
А возиться с расчетом матрици который может на раз распаралелить рантайм смысла нет.
А если при запросе по http нам приспичило матрици отплющить то рантайм должен эту самую часть запроса сам распаралелить.

R>Но это НЕ достаточное условие для эффективной автоматической реализации. Это лишь необходимое условие!

Согласен.
Но достаточность это дело техники которую в условиях когда у нас все зависимости как на лодоне получить относительно просто.
Это тебе не С++ паралелить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 27.07.08 18:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Не нужно, потому что, я в это не верю, это, блин, какой-то rocket science.

WH>Все проще. Нужно просто немного статистики собрать.
WH>А на длинных расчетах статистика наберется уже после пары итераций.

R>>Это должна быть монсторская система, которая на основе само-рефлексии занимается само-твикингом.

WH>hotspot...
WH>Только тут все еще проще и круче будет ибо жаба совсем не формализована, а тут куча теорем с доказательствами есть.

R>>Тут гарантированно есть 2 недетерминированных фактора — входные данные и загрузка системы сторонними приложениями.

WH>И с тем и с другим (особенно с загрузкой системы) можно разобраться только во время работы программы.

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

WH>Если таки делать уневерсальный рантайм то несколько человеколет тюнинга многократно окупятся последующим применением.


Ну что я могу на всё это сказать... извести, когда это будет работать. Будет очень интересно посмотреть.


R>>>>Ну хорошо зайду с другой стороны — а зачем тогда вообще возможность явного тридинга и возможность передавать что-то между потоками?

WH>>>Есть разные задачи.
WH>>>Например http сервер. Вот ему очень нужен явный трединг.
WH>>>А числомолотилкам он вреден.
R>>Т.е. тут твой тезис, что для "http сервера" будут не нужны такие вещи как контроль доступа на уровне элементов массива, и изменение pure/mutable в ран-тайм? Ну что ж, возможно, это вполне разумно... В любом случае примера-убийцы у меня нет...
WH>Нет тезис в том что явный трединг то же нужен.
WH>В случае с http сервером у нас есть куча явных, независимых запросов.
WH>И обрабатывать их удобно в отдельных потоках. Если во время обработки запроса будет удобно запустить еще потоки то так тому и быть.
WH>А возиться с расчетом матрици который может на раз распаралелить рантайм смысла нет.
WH>А если при запросе по http нам приспичило матрици отплющить то рантайм должен эту самую часть запроса сам распаралелить.


А вот за это по рукам его. Если у нас уже есть достаточный источник параллелизма (а во многих высокопроизводительных серверах "запросы" — это достаточный источник параллелизма, на то они и высокопроизводительные, что запросов у них *много*), то распараллеливать ещё дополнительно на более низком уровне — это исключительно дополнительные накладные расходы. Расходы на work-stealing (или что там выберет умный ран-тайм), и расходы на уменьшение локальности вычислений.
Так что это супер-умный ран-тайм тоже должен будет уметь автоматически определять. Иначе я его на С++ как тузик грелку


R>>Но это НЕ достаточное условие для эффективной автоматической реализации. Это лишь необходимое условие!

WH>Согласен.
WH>Но достаточность это дело техники которую в условиях когда у нас все зависимости как на лодоне получить относительно просто.


Так тут дело не только в определении зависимостей, и вообще не в зависимостях. Например смотри абзац выше.


WH>Это тебе не С++ паралелить.



А С++ программист и не надеятся на дядю со счётами, что бы он распараллелил; и на тётю с совком тоже не надеятся



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[43]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 27.07.08 19:09
Оценка:
Здравствуйте, remark, Вы писали:

R>Ну что я могу на всё это сказать... извести, когда это будет работать. Будет очень интересно посмотреть.

Будет.

R>А вот за это по рукам его.

Не надо.

R>Если у нас уже есть достаточный источник параллелизма

Уерен что достаточнй?

R>(а во многих высокопроизводительных серверах "запросы" — это достаточный источник параллелизма, на то они и высокопроизводительные, что запросов у них *много*),

Я такие системы и пишу.

R>то распараллеливать ещё дополнительно на более низком уровне — это исключительно дополнительные накладные расходы. Расходы на work-stealing (или что там выберет умный ран-тайм), и расходы на уменьшение локальности вычислений.

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

R>Так что это супер-умный ран-тайм тоже должен будет уметь автоматически определять.

Вот он то это проделать сможет. В отличии от С++ника...

R>Иначе я его на С++ как тузик грелку

Ну-ну.

R>А С++ программист и не надеятся на дядю со счётами, что бы он распараллелил; и на тётю с совком тоже не надеятся

Ага. Он тупо воюет с ужасной моделью языка и тупейшим рантаймом... ядро линуха от любого не осторожного движения уходит в нирвану и перестает возвращать управление из сиколов... хорошо что оно иногда от туда возвращается.
С другими ОСями таже фигня.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 27.07.08 19:41
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Ну что я могу на всё это сказать... извести, когда это будет работать. Будет очень интересно посмотреть.

WH>Будет.

Что "будет"? Будет работать? Или будет интересно посмотреть?


R>>А вот за это по рукам его.

WH>Не надо.

А кого тогда, если не его?


R>>Если у нас уже есть достаточный источник параллелизма

WH>Уерен что достаточнй?

Полностью. Для производительных/нагруженных OLTP или Web систем это будет так.


R>>(а во многих высокопроизводительных серверах "запросы" — это достаточный источник параллелизма, на то они и высокопроизводительные, что запросов у них *много*),

WH>Я такие системы и пишу.

R>>то распараллеливать ещё дополнительно на более низком уровне — это исключительно дополнительные накладные расходы. Расходы на work-stealing (или что там выберет умный ран-тайм), и расходы на уменьшение локальности вычислений.


WH>Так вот там где хватает там на низком уровне ничего не распаралелить.


Как же ничего не распараллелить? Если применить анализ по данным/управлению, то мы везде найдём столько распараллелить, что мало не покажется.

WH>А там где нет...


Ну естественно есть приложения, где и на обоих уровнях имеет смысл распараллеливать. Например, OLAP. Но речь о тех приложениях, где достаточно.


WH>Я у себя давно хочу распаралелить интерпретатор (накладные расходы на интерпретацию в данном случае ничтожны) одного язычка нарисованного под задачу да только руки не доходят.

WH>А вот еслиб оно само могло... то я бы изначально все написал так что бы рантайм сам все сделал.

Ну что ж, осталось только подождать выхода магического ран-тайма, и уж тогда никаких проблем не будет — "оно само там как-то магически всё будет".


R>>Так что это супер-умный ран-тайм тоже должен будет уметь автоматически определять.

WH>Вот он то это проделать сможет. В отличии от С++ника...

Как бы он только не начал все запросы в одном потоке обрабатывать, а "мясо" запросов по другим потокам разбрасывать


R>>Иначе я его на С++ как тузик грелку

WH>Ну-ну.

Ну я пока на кошках потренируюсь


R>>А С++ программист и не надеятся на дядю со счётами, что бы он распараллелил; и на тётю с совком тоже не надеятся

WH>Ага. Он тупо воюет с ужасной моделью языка и тупейшим рантаймом...

Он не воюет с ней, он её эксплуатирует


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Автоматическое распараллеливание (было "Что почитать.
От: vdimas Россия  
Дата: 28.07.08 10:21
Оценка:
Здравствуйте, remark, Вы писали:


R>По крайней мере современные многоядерные процессоры Intel/AMD позволяют многопроцессорные конфигурации. И значительная часть серверов именно несколько-процессорная. Что-то не увязывается...


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

Да и вообще, всяко лучше иметь некое кол-во ядер на одном кристелле, чем такое же их суммарное кол-во, раскиданное по разным процам.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[9]: Автоматическое распараллеливание (было "Что почитать.
От: vdimas Россия  
Дата: 28.07.08 10:21
Оценка:
Здравствуйте, remark, Вы писали:

V>>Кеш — это память, она не умеет делать простейших операций, типа декремента или проверки значения на 0, например. Поэтому дёргается АЛУ


R>Не очень понятно, а в чём проблема дергать АЛУ? АЛУ — это ж самая быстродействующая и, зачастую, недозагруженная часть системы. Если считать, что АЛУ может выдавать 3 команды за такт,


3 команды сложения за такт означают наличие 3-х сумматоров, например.

R>а на перемещение кэш-линии тратится 200 тактов, то доля АЛУ тут получается менее 1%.


В том-то и дело, что сейчас счётчики примитивов надо еще в кеш предварительно загружать.

R> Плюс к этому, примерно в 50% случаев обращение к примитиву синхронизации связано с проверкой, т.е. это ветвление,


Для встроенного примитива не должно быть ветвления, кроме случаев таймаута (т.е. постпроверки — по таймауту прошли примитив или нет). Для семафора/мьютекса/события должна быть просто некая команда wait #sync безо-всяких ветвлений. "Ветвление" должен делать шедуллер, путём распределения загрузок внутренних блоков. С предпросмотром тоже всё нормально — ведь шедуллер может посмотреть — будет в ближайшие несколько тактов изменяться данный примитив в других потоках, или нет (напомню, я считаю всю эту схему эффективной только при возможности хранить состояния приличного кол-ва потоков в процессоре). Если примитив в сигнальном состоянии, и шедуллер в видимой последовательности команд в других потоках не обнаруживает операций с этим примитивом, то на выполнение команды wait должно тратиться ровно 0 тактов.


R>А вот сам специализированный и мелко-гранулярный счетчик не помешало бы иметь... Если бы его можно было реализовать значительно быстрее, чем протокол когерентности общего назначения. Я в этом не большой специалист, но я думаю, что с доступом к одному счетчику из раных ядер должны быть определенные проблемы (например, синхронизация частот).


Как раз аппаратно логика атомарного управления строится легко. Какая может быть проблема с синхронизацией внутри проца? Там общая синхронизация для всех ядер. Если в течении одного гипотетического такта несколько команд пытаются _изменять_ примитив, то изменяет пусть только один, остальные задействованные пусть задерживаются на такт (и кстати, шедуллер заранее может спланировать потоки так, чтобы не пришлось иметь доступ в течении одного такта разным потокам). А вот параллельное чтение может проводиться одновременно несколькими потоками.

R>Ну и по прежнему не понятно, как быть с многопроцессорными конфигурациями.


Пусть остануться только для суперкомпьютеров. Как уже сказал рядом, всяко эффективней всё необходимое кол-во ядер иметь на одном проце.


V>>Далее, было бы неплохо иметь довольно большой общий файл регистров, в котором можно было бы хранить состояния регистров конкретного потока с той целью, чтобы при вытеснении потока не копировать состояния регистров во внешнюю память, и не загружать оттуда сохранённое состояние. Все эти переключения потоков должны происходить аппаратно в течении одного такта (и то, аналогия "переключения" не совсем верна).


R>Ну так это ж вроже Sun Niagara/Rock. У них там сколько аппаратных потоков? Вроде 32 было на одном процессоре. И встроенный шедулер. У Intel пока дело дошло только до 2 аппаратных потоков на ядро, но я думаю, что в ближайшем будущем будет больше.


Угу.

V>>понятия "многоядрный" и "многопоточный" малость сливаются в одно.


R>Для такой схему применяются термины CMT (Chip MultiThreading), HWT (Hardware MultiThreading), HT (HyperThreading). А обобщенный поток исполнения называется Аппаратный Поток Исполнения (Hardware Thread), т.е. это может быть либо процессор, либо ядро, либо поток внутри ядра.


Именно что логический поток внутри ядра. ИМХО, за этим будущее многоядерных процов, т.е. вместо выделенных ядер внутри проца будет просто большой внутренний файл регистров и приличное кол-во разделяемых выч. ресурсов, например, тот же АЛУ — это не монолит, сумматоры, умножители и делители — это физически разные исполняющие блоки. Простых блоков АЛУ (которые только суммируют и оперируют с битами) может быть вообще неограниченное кол-во, они очень примитивны. Ведь не думаешь ты, что для банального ветвления по знаку операции (например) надо результат операции грузить в выделенное устройство? Всё проще, после сумматора ветвление происходит по результату регистра сумматора, после умножения — по его выходному регистру и т.д.

Да, ты еще упоминал в предыдущих сообщениях проблему расстояний (внутри кристалла, правильно?) Эта проблема есть давно, обсуждалась еще на подходе к 200МГц и её обещают в конце концов решить многослойной структурой, т.е. будуще за 3D. В конце-концов, печатные платы несколько десятилетий оставались односторонними, потом еще несколько — двусторонними, а последние несколько — в основном многослойные.

Да и вообще, кеш второго уровня должен стать единственным (или даже превратиться в обычную ОП на кристалле), а первого — слиться в экстазе с общим файлом регистров (т.е. быть непосредственно доступен логике шедуллера поячеечно).
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[10]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 28.07.08 17:21
Оценка:
Здравствуйте, vdimas, Вы писали:

R>>По крайней мере современные многоядерные процессоры Intel/AMD позволяют многопроцессорные конфигурации. И значительная часть серверов именно несколько-процессорная. Что-то не увязывается...


V>Думаю, что шедуллер должен учитывать многоядерность, и передавать поток с проца на проц только при необходимости....


Может не быть никакой передачи вообще. Просто 2 потока изначально работают на разных процессорах и обращаются к одному примитиву синхронизации. Как тут быть?

V>Да и вообще, всяко лучше иметь некое кол-во ядер на одном кристелле, чем такое же их суммарное кол-во, раскиданное по разным процам.


Лучше-то может оно и лучше, только к жизни не имеет отношения...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 28.07.08 17:42
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Кеш — это память, она не умеет делать простейших операций, типа декремента или проверки значения на 0, например. Поэтому дёргается АЛУ


R>>Не очень понятно, а в чём проблема дергать АЛУ? АЛУ — это ж самая быстродействующая и, зачастую, недозагруженная часть системы. Если считать, что АЛУ может выдавать 3 команды за такт,


V>3 команды сложения за такт означают наличие 3-х сумматоров, например.


Да, пожалуйста. Если у меня CPI 2 вместо 0.3, то мне вообще пофигу.
Разговор об АЛУ — это разговор о единицах тактов, разговор о синхронизации — это разговор о сотнях тактов.


R>>а на перемещение кэш-линии тратится 200 тактов, то доля АЛУ тут получается менее 1%.


V>В том-то и дело, что сейчас счётчики примитивов надо еще в кеш предварительно загружать.


В любом случае надо делать какую-то "удаленную" работу. "Удаленная" работа — это в любом случае дорого. Вопрос — насколько? Мне кажется, что меньше 50 тактов это сделать не получится.
На последних AMD latency инструкции RDTSC(P) — 57 тактов, именно из-за того, что она обращается к NorthBridge.


R>> Плюс к этому, примерно в 50% случаев обращение к примитиву синхронизации связано с проверкой, т.е. это ветвление,


V>Для встроенного примитива не должно быть ветвления, кроме случаев таймаута (т.е. постпроверки — по таймауту прошли примитив или нет). Для семафора/мьютекса/события должна быть просто некая команда wait #sync безо-всяких ветвлений. "Ветвление" должен делать шедуллер, путём распределения загрузок внутренних блоков. С предпросмотром тоже всё нормально — ведь шедуллер может посмотреть — будет в ближайшие несколько тактов изменяться данный примитив в других потоках, или нет (напомню, я считаю всю эту схему эффективной только при возможности хранить состояния приличного кол-ва потоков в процессоре). Если примитив в сигнальном состоянии, и шедуллер в видимой последовательности команд в других потоках не обнаруживает операций с этим примитивом, то на выполнение команды wait должно тратиться ровно 0 тактов.



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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 30.07.08 01:22
Оценка:
Здравствуйте, remark, Вы писали:


R>Допустим поток 1 захватил аппаратный мьютекс 1, потом ОС отключила поток 1 от процессора, и поставила выполняться 100 других потоков на всё имеющиеся 100 аппаратных потоков. Все эти 100 потоков заблокировались на захвате аппаратного мьютекса 1. Система теряет 100 квантов времени на тупое ожидание мьютекса.

R>Я не вижу как это хорошо сделать без ветвления и ОС.

Да пускай себе теряет на здоровье. Ожидающие потоки не нагружают исполнительные блоки. Вся суть предложения этой схемы в том, что аппаратных потоков должно быть гораздо больше, чем исполнительных блоков (желательно на порядки, я же писал, что первая кеш-память и файл регистров должны слиться в одно целое). В случае, если шедуллер ОС захотел загрузить в проц очередной поток из памяти, а у того нет слотов под потоки, тогда надо вытеснять ступорные потоки, согласно приоритетам и времени ожидания. Логику вытеснения тоже можно поддержать аппаратно, если добавить аппаратное поле приоритета для потока и счётчик тактов ожидания потока. (Поле приоритета в любом случае должно быть у такой схемы, где в проце хранится множество аппаратных потоков)
Re[12]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 30.07.08 09:04
Оценка:
Здравствуйте, vdimas, Вы писали:

R>>Допустим поток 1 захватил аппаратный мьютекс 1, потом ОС отключила поток 1 от процессора, и поставила выполняться 100 других потоков на всё имеющиеся 100 аппаратных потоков. Все эти 100 потоков заблокировались на захвате аппаратного мьютекса 1. Система теряет 100 квантов времени на тупое ожидание мьютекса.

R>>Я не вижу как это хорошо сделать без ветвления и ОС.

V>Да пускай себе теряет на здоровье.


Если эта схема не о производительности, тогда о чём?

V>Ожидающие потоки не нагружают исполнительные блоки. Вся суть предложения этой схемы в том, что аппаратных потоков должно быть гораздо больше, чем исполнительных блоков (желательно на порядки, я же писал, что первая кеш-память и файл регистров должны слиться в одно целое). В случае, если шедуллер ОС захотел загрузить в проц очередной поток из памяти, а у того нет слотов под потоки, тогда надо вытеснять ступорные потоки, согласно приоритетам и времени ожидания. Логику вытеснения тоже можно поддержать аппаратно, если добавить аппаратное поле приоритета для потока и счётчик тактов ожидания потока. (Поле приоритета в любом случае должно быть у такой схемы, где в проце хранится множество аппаратных потоков)


Я не думаю, что целесообразно делать аппаратных потоков значительно больше, чем это было бы необходимо иначе, только для маскирования отсутствия хорошего высокоуровневого шедулинга.
Процессор может делать только микро-шедулинг, например, если поток вызвал промах кэша или некорректно предсказан переход. Макро-шедулинг же должен оставаться за ОС. Блокировка на мьютексе относится к макро-шедулингу, потому что время ожидания заранее не известно и может быть сколь угодно большим.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 30.07.08 09:16
Оценка:
Здравствуйте, remark, Вы писали:

Добавлю так же, что кеш первого уровня, впервые появившийся в 386-м нужен был, в первую очередь, для эффективной реализации страничной памяти, доступ к кешу первого уровня равен по скорости доступу к файлу регистров, преобразователь адресов непосредственно оперирует данными таблиц распределения страниц из этого кеша без задержек. Т.е. фактически уже на процах имеется достаточное кол-во памяти, адресуемой со скоростью регистров.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[12]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 30.07.08 09:26
Оценка:
Здравствуйте, vdimas, Вы писали:

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



Я бы не сказал, что для всех программ достаточно 64K памяти
Тем более, что кэши обычно разделяются между аппаратными потоками. Т.е. если у нас 2 аппаратных потока (HT), то на поток фактически 32К. Это, кстати, проблема если делать *много* аппаратных потоков, т.к. L1$ много на кристалл не запихаешь.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[13]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 30.07.08 11:01
Оценка:
Здравствуйте, remark, Вы писали:

V>>Да пускай себе теряет на здоровье.


R>Если эта схема не о производительности, тогда о чём?


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

R>Я не думаю, что целесообразно делать аппаратных потоков значительно больше, чем это было бы необходимо иначе, только для маскирования отсутствия хорошего высокоуровневого шедулинга.


Да какой, блин, шедуллинг для потока в режиме ожидания?
И откуда ты вообще взял потерянные кванты (в пред. сообщении)? ОС, в отличие от прикладных программ, прекрасно знает, из-за какого конкретно хендлера (или списка хендлеров) поток находится в режиме ожидания.


R>Процессор может делать только микро-шедулинг, например, если поток вызвал промах кэша или некорректно предсказан переход. Макро-шедулинг же должен оставаться за ОС.


Чем макро отличается от микро? Системой приоритетов и очередей, не правда ли? Ну дык, а для ввода-вывода тем не менее уже имеется система приоритетов, которая разруливает "одновременно" пришедшие прерывания. Вот тебе зачатки макро-шедуллинга.

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


R>Блокировка на мьютексе относится к макро-шедулингу, потому что время ожидания заранее не известно и может быть сколь угодно большим.


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


------------
Кстати, бенефиты обсуждаемой схемы в первую очередь скажутся на вводе-выводе. Драйверы могут просто представлять из себя потоки, ожидающие некие хендлы. Высокоприоритетный поток ввода-вывода может постоянно находится в ядре, и автоматически получать выч. ресурсы (с помощью аппаратного шедуллера) по приходу данных без дорогостоящих прерываний. А то наблюдал я картину, когда росла наша местная городская сеть, и в одной маске IP крутилось пара тысяч домашних компьютеров, и все качают видео, либо рубятся в игры, в общем свист по витой паре в 100МГб стоял — закачаешься. Воткнешь сетевой кабель, и комп сразу заметно притормаживать начинает. Пока более мелко не порубили, да маршрутизаторов дополнительных не понаставили, ситуация с каждым месяцом ухудшалась. Привел как пример того, что задержки ввода-вывода вполне заметны даже субъективно.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[12]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 30.07.08 11:43
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Вообще-то, защищать надо логические сущности.

А кто спорит?

V>А что это — код, или данные — дело десятое,


Код защищать не надо.
Никогда.
Он не меняется.
Следовательно защищать нечего.

V>и больше зависит от гранулярности блокировок. Если защищать только данные, то гранулярность может получиться неприлично малой, в итоге из дедлоков не будем вылезать.

Ты точно прочитал то что я написал про систему типов?

WH>>Да и вобще куча мутной семантики типа грязного чтения итп мягко говоря настораживает.

V>Нормальное чтение.
Что значит нормальное?
Нам нужны гарантии того что мы никогда и ни при каких условиях не увидим то что делает паралельная не закомиченная транзакция.
Иначе мы вобще ни на что пологаться не можем.
А обеспечение данной гарантии для TM задачка мягко говоря не тривиальная. Там же код что попало делать может.

V>Просто атомарным может быть не только ячейка, размером со слово, но и целая область.

Ага. Размером с линейку кеша.
Меньше не залочить. Больше не эффективно.
Разве что если совсем приперло.

V>Особенно удобно будет для сценариев, завязанных не на ожидание данных, а на периодический их мониторинг.

Если к тому локу что я описал добавить ридонли версию то этот сценарий становится вполне себе работающим.
А если нам нужно одно слово мониторить то вобще локи не нужны.

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

А что делать если место в буфере закончится?

V>без выделения динамической памяти под каждую ячейку безлокового списка.

Ой беда то какая.
Особенно при наличии мусорщика.

V>Если локи нужны для логики ожидания (воода/вывода, или конца вычислений), то это понятно,

Эти локи нужно реализовывать на уровне шедуллера ОС.

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


Ты точно понял что будет делать этот лок
Автор: WolfHound
Дата: 16.04.08
? (кстати он тоже ориентирован на синхронизацию по памяти)
Сделать операцию дешевле чем описанный примитив просто не реально.
Ибо у тебя в этой твоей транзакционной памяти при коммите будет тоже самое...
Так нафига козе баян?
Нафига мутные примитивы с мутной семантикой?
Если есть простой и понятный примитив?
Который просто лочит на несколько тактов кусочек памяти.
При том что сам по себе лок кусочка памяти куда дороже и он всеравно будет происходить при коммите HTM...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 30.07.08 16:03
Оценка:
Здравствуйте, remark, Вы писали:


R>Я бы не сказал, что для всех программ достаточно 64K памяти

R>Тем более, что кэши обычно разделяются между аппаратными потоками. Т.е. если у нас 2 аппаратных потока (HT), то на поток фактически 32К. Это, кстати, проблема если делать *много* аппаратных потоков, т.к. L1$ много на кристалл не запихаешь.

— потоки одного процесса могут работать с одними и теми же данными (числодробилки или просто какая-нить т.н. "бизнес-логика"), в любом случае, обычные потоки тоже делят эту память, и так же используют её под файлы регистров неявно при загрузке/выгрузке оных при смене текущего потока в проце.

— таблицы распределения виртуальной памяти общие для всех потоков одного процесса

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


В общем, учитывая, что закон Мура относительно транзисторов на кристалле пока что соблюдается, не в размере L1 кеша загвоздка. Самая загвоздка будет в планировщиках, кои сейчас составляют приличную долю от сложности кристалла. Однако, при современной численности транзисторов, уже через пару лет прирост их общего кол-ва (по Муру) покроет с лихвой требуемый.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[13]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 31.07.08 08:17
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>Вообще-то, защищать надо логические сущности.

WH>А кто спорит?

Ты споришь, приравнивая логическую сущность к данным. Логической сущностью может быть некое устройство, например pipe, который может иметь разные хендлы в разных процессах. Как записать туда транзакционно единый блок данных с помощью твоей модели мне понятно — это делать сериализацию на уровне OC (драйвера и т.д., который имеет однозначную ссылку на ассоциированную с устройством структуру). Но как транзакционно записать туда несколько данных, или тем паче — обменяться транзакционно — это с т.з. твоей модели полное хз. Ты же предлагаешь такую фундаментальную вещь, как грануляцию блокировок, прибить нафик, и подменить системой типов. Понимаешь... на современном уровне абстракции ПО система типов не отображается однозначно на систему логических понятий, до такого мы пока не доросли и вряд ли дорастём в ближайшие несколько десятилетий. По крайней мере, C#/Java/Nemerle и пр. — вовсе не из этой фантастической области, хоть пересыпь ты их любым сахаром и макросами. Потому как логическое понятие — это не статическая структура, это может быть и операция, и данные.

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

В твоей системе потребуется хранить доп. immutable структуру на каждую сущность, котрая хранит immutable ключ и uniqueness ссылку на данные (которые тоже хранят свой ключ), в итоге мы еще больше будем усложнять систему типов, вместо упрощения.

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

V>>А что это — код, или данные — дело десятое,

WH>
WH>Код защищать не надо.
WH>Никогда.
WH>Он не меняется.
WH>Следовательно защищать нечего.

Да никто и не защищает код. С чего ты решил, что термин "защита" тут уместен? Речь идёт о сериализации доступа, и больше ни о чём. И как раз сериализировать исполнение определённых участков кода — вполне нормально. Тут Андрей высказывался, что это не всегда удобно, ибо зачастую раскидано по логике, ну дык это дело десятое пока что...


V>>и больше зависит от гранулярности блокировок. Если защищать только данные, то гранулярность может получиться неприлично малой, в итоге из дедлоков не будем вылезать.

WH>Ты точно прочитал то что я написал про систему типов?

Прочитал всё, не волнуйся. Сама идея блочить линейки кеша представляется не очень. Там не так много линеек кеша в проце, буквально еще несколько лет и 4/8/16-ядерные процы станут нормой, и каждое ядро будет исполнять по 4 потока минимум, а доступ к ОП будет идти по тысячеразрядной шине данных, твоя система прибъёт эффективность L1 на корню. L1 никогда не будет очень большим, ибо статический триггер требует в общей сложности 6 транзисторов на исполнение. Транзакционная память, о которой тебе говорят — это практически одно и то же, но они не претендуют на логическую защиту данных, как претендуешь ты (ибо опять же — термин защита тут неуместен, более того — вреден, ибо речь всё время идёт только об атомарности последовательностей операций, боле не о чём). Сама транзакционность предполагает, что в транзакции может участвовать произвольный набор логических сущностей, согласись, это гораздо более гибкое и широкое решение.

WH>>>Да и вобще куча мутной семантики типа грязного чтения итп мягко говоря настораживает.

V>>Нормальное чтение.
WH>Что значит нормальное?
WH>Нам нужны гарантии того что мы никогда и ни при каких условиях не увидим то что делает паралельная не закомиченная транзакция.
WH>Иначе мы вобще ни на что пологаться не можем.

Правильно рассуждаешь, только выводы не правильные делаешь. Зачем сразу предлагаешь техническое решение, какие-то мифические блокировки линеек? Надо просто формулировать задачу, а не бросаться в технические подробности.
Если в твоём решении расширить от линейки до произвольного набора данных, и отказаться от т.н. "передачи владения" то твоё решение превратиться в то, что предлагает Sun. Они ведь тоже начали пока с очень малого в этой области (понятное дело, выпуск серийного проца новой архитектуры — это целая эпоха в жизни каждой фирмы, они пока просто осторожничают).

WH>А обеспечение данной гарантии для TM задачка мягко говоря не тривиальная. Там же код что попало делать может.


Да, параллельно и что попало. Но если проц увидит, что в результате менялись и читались разные участки данных даже у одной и той же сущности (разные поля твоего типа, например, а тип целиком лежит в линейке кеша, понятное дело), то одновременные транзакции разрешаются, иначе — сериализуются. Прочувствуй разницу, как говорится. Серваки БД работают именно так на определённых уровнях транзакции, зачем что-то изобретать, всё давно изобретено. Речь идёт лишь о том, чтобы частично (пока) поддержать часть этой логики в железе.

V>>Просто атомарным может быть не только ячейка, размером со слово, но и целая область.

WH>Ага. Размером с линейку кеша.
WH>Меньше не залочить. Больше не эффективно.

С чего бы это меньше не залочить? Да хоть целый список областей произвольной длины, даже если все эти области не помещаются целиком в целый кеш. Сейчас под этот список в новом сановском проце, насколько я понял, отведено 4 ячейки на поток, значит всего 32*4=128, их в перспективе может быть произвольное кол-во.

WH>Разве что если совсем приперло.


Припрёт уже прямо сейчас на современных задачах. Пусть они поиграют с тем, насколько такая система эффективна для целей сериализации доступа, если окажется эффективной (в чём я не сомневаюсь), то оно будет расти вширь (ибо по частоте практически упёрлись, теоретический предел современного тех-процесса в районе 10МГц, даже при произвольной дальнейшей миниатюризации, так что расти можно будет только вширь одновременно с дальнейшей миниатюризацией... возможно придумают что-то вместо транзисторов когда-нить, но пока не придумали, и используют их, родимых, и дырочную проводимость, которая имеет геометрический минимальный предел, чтобы диод оставался диодом, и порог около 0.5-0.6В для кремния, так что пока упёрлись вплотную, и 1-1.2В — это примерно минимум для напряжения питания).

V>>Особенно удобно будет для сценариев, завязанных не на ожидание данных, а на периодический их мониторинг.

WH>Если к тому локу что я описал добавить ридонли версию то этот сценарий становится вполне себе работающим.
WH>А если нам нужно одно слово мониторить то вобще локи не нужны.

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

WH>А что делать если место в буфере закончится?

Выделить новый, после этого обновить ссылку на буфер, делов то. В следующий раз читатель полезет уже в новый буфер.

V>>без выделения динамической памяти под каждую ячейку безлокового списка.

WH>Ой беда то какая.
WH>Особенно при наличии мусорщика.

Как показала практика — всё-таки беда. Даже для моей задачи микширования звука. Сервак загибается, если всего-лишь 50 раз в сек выделять динамически под каждый буфер данных 320 байт, и кол-во пользователей всего-лишь 4096, а на каждого — 4 таких буфера. Пока что рулят статические буфера. Так же сильно помогло использование, где можно, безлоковых алгоритмов. Мало того, что Monitor.Enter/Exit работает гораздо тормознее чем родные CriticalSection, так даже последние прилично тормозят процесс.

V>>Если локи нужны для логики ожидания (воода/вывода, или конца вычислений), то это понятно,

WH>Эти локи нужно реализовывать на уровне шедуллера ОС.

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

WH>
WH>Ты точно понял что будет делать этот лок
Автор: WolfHound
Дата: 16.04.08
? (кстати он тоже ориентирован на синхронизацию по памяти)

WH>Сделать операцию дешевле чем описанный примитив просто не реально.

Транзакционная память дешевле, чем блокировка целой линейки кеша из-за одного int.

WH>Ибо у тебя в этой твоей транзакционной памяти при коммите будет тоже самое...


Ты наверно недопонял. Еще до коммита понятны намерения участников, кто что будет читать/писать. В случае отсутствия кофликтов вообще ничего не происходит, иначе — сериализация на уровне планировщика потоков в проце.

WH>Так нафига козе баян?

WH>Нафига мутные примитивы с мутной семантикой?

Согласен, мютекс — это искуственный примитив, отсутствующий в теории о синхронизации. Так и есть, этот семафор с N=1, имеющий собственное имя, нужен исключительно для сериализации последовательности операций.

WH>Если есть простой и понятный примитив?


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

WH>Который просто лочит на несколько тактов кусочек памяти.


Его не надо лочить
Надо проследить за атомарностью изменений в нём.

WH>При том что сам по себе лок кусочка памяти куда дороже и он всеравно будет происходить при коммите HTM...


Нет, не будет, ты недопонял. Коммит — это вообще абстракция, реально никакого коммита нет, есть атомарные изменения 2-х ячеек (пока 2-х).
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[14]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 31.07.08 11:24
Оценка:
Здравствуйте, vdimas, Вы писали:

У тебя просто ацкая каша в голове.

Тот примитив процессора что я описал не имеет никакого отношения к системе типов.
Это совершенно не зависящие друг от друга сущьности.
Которые могут использоваться отдельно или вместе.

V>Ты споришь, приравнивая логическую сущность к данным.

Так они всегда данными и выражаются.

V>Логической сущностью может быть некое устройство, например pipe, который может иметь разные хендлы в разных процессах.

pipe устройство? Интересная точка зрения.
А я то думал что это FIFO комуникационный канал.
В любом случае мимо ибо на мою систему типов ложаться гораздо более кучерявые примитивы.
Например каналы из сингулярити.

V>Как записать туда транзакционно единый блок данных с помощью твоей модели мне понятно — это делать сериализацию на уровне OC (драйвера и т.д., который имеет однозначную ссылку на ассоциированную с устройством структуру). Но как транзакционно записать туда несколько данных, или тем паче — обменяться транзакционно — это с т.з. твоей модели полное хз.

Ты совсем ничего не понял.
Все это делается очень легко.
Легче чем на всяких там мъютексах.

V>Ты же предлагаешь такую фундаментальную вещь, как грануляцию блокировок, прибить нафик, и подменить системой типов.

Да не нужны нам блокировки.
Нам нужна синхронизация. А она может быть достигнута различными способами.

V>Понимаешь... на современном уровне абстракции ПО система типов не отображается однозначно на систему логических понятий, до такого мы пока не доросли и вряд ли дорастём в ближайшие несколько десятилетий. По крайней мере, C#/Java/Nemerle и пр. — вовсе не из этой фантастической области, хоть пересыпь ты их любым сахаром и макросами.

А кто их предлагает?
Я давно говорю что модель CLR и тем более жабы унылое говно которое ни для чего использовать нельзя.

V>Потому как логическое понятие — это не статическая структура, это может быть и операция, и данные.

Операция всегда производится над некими данными.
И сериализовать выполнение некой последовательности комманд при условии что работа происходит с независимыми данными смысла нет вобще.

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

Конечно пройдет.

V> Подобный сценарий имеет хорошо известное решение: необходимые сущности сортируются по какому-нить признаку, предполагающему однозначную сортировку (по ключу обычно), а затем блокируются согласно сортированному списку, тогда мы не нарвёмся на дедлок.

И?

V>В твоей системе потребуется хранить доп. immutable структуру на каждую сущность, котрая хранит immutable ключ и uniqueness ссылку на данные (которые тоже хранят свой ключ), в итоге мы еще больше будем усложнять систему типов, вместо упрощения.

Чё?
Вобще говоря immutable данные могут ссылаться только на immutable данные.

V>Еще больше непонятно, что будет происходить с большинством современных паттернов проектирования, которые в большинстве своём представляют комбинации типов.

Еще один проектирующий паттернами...
Другая система типов — другие решения.
Все просто.
Даже С++ные решения при переходе на жабу приходится выкидывать. Факт медицинский.
А тут совсем другая система типов.

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

Моя система типов справляется с этим иделально.
Читай ветку до просветления.

V>Да никто и не защищает код. С чего ты решил, что термин "защита" тут уместен? Речь идёт о сериализации доступа, и больше ни о чём. И как раз сериализировать исполнение определённых участков кода — вполне нормально. Тут Андрей высказывался, что это не всегда удобно, ибо зачастую раскидано по логике, ну дык это дело десятое пока что...

И зачем сериализовать доступ к коду?
Сериализовать доступ к не изменяемым сущьностям бред полный и без просветный.
А код сущьность таки не изменяемая.
Его один раз скомпилировали и все.

Или ты пишешь полиморфные вирусы? Как по мне чем у вирусописателей больше проблем тем лучше.

V>>>и больше зависит от гранулярности блокировок. Если защищать только данные, то гранулярность может получиться неприлично малой, в итоге из дедлоков не будем вылезать.

WH>>Ты точно прочитал то что я написал про систему типов?
V>Прочитал всё, не волнуйся. Сама идея блочить линейки кеша представляется не очень.
Какие к черту линейки кеша?
Я про систему типов высокоуровневой ВМ говорю.
Именно она гарантирует синхронизацию.
А линейки кеша это деталь реализации на конкретной жележзке.

V>Там не так много линеек кеша в проце, буквально еще несколько лет и 4/8/16-ядерные процы станут нормой, и каждое ядро будет исполнять по 4 потока минимум, а доступ к ОП будет идти по тысячеразрядной шине данных, твоя система прибъёт эффективность L1 на корню.

Чё? Ты все это к чему?

V>L1 никогда не будет очень большим,

А ему и не надо.

V>ибо статический триггер требует в общей сложности 6 транзисторов на исполнение.

И чё?

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

Ты не переводи разговор на спор о терминах.

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

Ага. Только эффективно не реализуемое.

V>Правильно рассуждаешь, только выводы не правильные делаешь.

Это какие же?

V>Зачем сразу предлагаешь техническое решение, какие-то мифические блокировки линеек?

Мифические? Интересно. А что префикс lock на современных x86'х процессорах делает?
Ни когда не задумывался?

V>Надо просто формулировать задачу, а не бросаться в технические подробности.

Задача простая: Обеспечить правильную синхронизация в многопоточной среде.

V>Если в твоём решении расширить от линейки до произвольного набора данных,

Каком именно?
Ты постоянно путаешься.
Система типов не накладывает подобных ограничений.
А в железе один хрен меньше чем с линейкой кеша работать не получится.

V>и отказаться от т.н. "передачи владения"

Не выдет.
Ни там ни там.
Ты знаешь что делают процессоры при записи в память?
Вот поинтересуйся...

V>то твоё решение превратиться в то, что предлагает Sun.

Нет.
Оно никогда не будет таким мутным и страшным.

V>Они ведь тоже начали пока с очень малого в этой области (понятное дело, выпуск серийного проца новой архитектуры — это целая эпоха в жизни каждой фирмы, они пока просто осторожничают).

Я думаю это будет последний процессор с этой архитектурой.

V>Да, параллельно и что попало. Но если проц увидит, что в результате менялись и читались разные участки данных даже у одной и той же сущности (разные поля твоего типа, например, а тип целиком лежит в линейке кеша, понятное дело), то одновременные транзакции разрешаются, иначе — сериализуются. Прочувствуй разницу, как говорится.

Теперь осталась маленькая проблема. Реализовать это технически.
И что-то мне подсказывает что оверхед бедт такой что

V>Серваки БД работают именно так на определённых уровнях транзакции, зачем что-то изобретать, всё давно изобретено. Речь идёт лишь о том, чтобы частично (пока) поддержать часть этой логики в железе.

Оракл в железе. Круто.

V>С чего бы это меньше не залочить?

С такой.
Память в железке ходит нашенкованная на линейки кеша.

V>Да хоть целый список областей произвольной длины, даже если все эти области не помещаются целиком в целый кеш.

Чё? Ты хочень сказать что можно делать в железе эффективные транзакции на нескольких кусках памяти каждый из которых не влезает в L1 кешь?
Ты серьезно?

V>Сейчас под этот список в новом сановском проце, насколько я понял, отведено 4 ячейки на поток, значит всего 32*4=128, их в перспективе может быть произвольное кол-во.

4 слова на поток в одной тразакции? Гы! Даже не смешно.

V>Припрёт уже прямо сейчас на современных задачах. Пусть они поиграют с тем, насколько такая система эффективна для целей сериализации доступа, если окажется эффективной (в чём я не сомневаюсь),

А я сомневаюсь что оно вобще будет работать.

V>то оно будет расти вширь (ибо по частоте практически упёрлись, теоретический предел современного тех-процесса в районе 10МГц,

Ты точно несколько ноликов не потерял?

V>даже при произвольной дальнейшей миниатюризации, так что расти можно будет только вширь одновременно с дальнейшей миниатюризацией... возможно придумают что-то вместо транзисторов когда-нить, но пока не придумали, и используют их, родимых, и дырочную проводимость, которая имеет геометрический минимальный предел, чтобы диод оставался диодом, и порог около 0.5-0.6В для кремния, так что пока упёрлись вплотную, и 1-1.2В — это примерно минимум для напряжения питания).

А это тут вобще причем?

V>Как показала практика — всё-таки беда. Даже для моей задачи микширования звука. Сервак загибается, если всего-лишь 50 раз в сек выделять динамически под каждый буфер данных 320 байт, и кол-во пользователей всего-лишь 4096, а на каждого — 4 таких буфера. Пока что рулят статические буфера.

Не занимайся поддтасовками.
Ты взял тупой мусорщик из .NET. И обобщаешь на все...
Я так тоже могу взять сортировку из этой темы
Автор: minorlogic
Дата: 08.11.07
и обобщить на все сортировки.

V>Так же сильно помогло использование, где можно, безлоковых алгоритмов. Мало того, что Monitor.Enter/Exit работает гораздо тормознее чем родные CriticalSection, так даже последние прилично тормозят процесс.

Так я и предлагаю на корню убить все эти локи просто перейдя в другой базис.

V>Транзакционная память дешевле, чем блокировка целой линейки кеша из-за одного int.

А ты в курсе что для записи одного int'а линейка кеша всегда захватывается для монопольного доступа.
В данном случае ее захватывают на один такт.
Если ее захватить на 3-10 тактов то на фоне 100 тактов которые требуются для того чтобы ее доставить в L1...

V>Ты наверно недопонял. Еще до коммита понятны намерения участников, кто что будет читать/писать. В случае отсутствия кофликтов вообще ничего не происходит, иначе — сериализация на уровне планировщика потоков в проце.



V>Согласен, мютекс — это искуственный примитив, отсутствующий в теории о синхронизации. Так и есть, этот семафор с N=1, имеющий собственное имя, нужен исключительно для сериализации последовательности операций.

В какой именно? Даже wikipedia http://en.wikipedia.org/wiki/Category:Process_calculi знает несколько теорий.
Еще раз: Есть разные базисы на которых можно строить синхронизацию.

WH>>Который просто лочит на несколько тактов кусочек памяти.

V>Его не надо лочить
V>Надо проследить за атомарностью изменений в нём.
Так на данном уровне эффективнее лока ничего не сделать.

V>Нет, не будет, ты недопонял. Коммит — это вообще абстракция, реально никакого коммита нет, есть атомарные изменения 2-х ячеек (пока 2-х).

А у меня что?
У меня атомарное изменение одной или 2х линеек кеша.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 31.07.08 12:27
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>Зачем сразу предлагаешь техническое решение, какие-то мифические блокировки линеек?

WH>Мифические? Интересно. А что префикс lock на современных x86'х процессорах делает?
WH>Ни когда не задумывался?

Дык, он по другому пока не умеет. А задумывался лет 10 или больше назад, если тебя дата интересует.


V>>Надо просто формулировать задачу, а не бросаться в технические подробности.

WH>Задача простая: Обеспечить правильную синхронизация в многопоточной среде.

Атомарность, скорее. Синхронизация — это ближе к событиям, а если речь о данных — то атомарность.


V>>Если в твоём решении расширить от линейки до произвольного набора данных,

WH>Каком именно?
WH>Ты постоянно путаешься.
WH>Система типов не накладывает подобных ограничений.

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

WH>А в железе один хрен меньше чем с линейкой кеша работать не получится.


Получилось же у Sun.


WH>Ты знаешь что делают процессоры при записи в память?

WH>Вот поинтересуйся...

Началась старая песня... А ты знаешь как работают многоканальные контроллеры памяти? Поинтересуйся


V>>то твоё решение превратиться в то, что предлагает Sun.

WH>Нет.
WH>Оно никогда не будет таким мутным и страшным.

Это тебе оно кажется страшным, а мне кажется логичным.


V>>Они ведь тоже начали пока с очень малого в этой области (понятное дело, выпуск серийного проца новой архитектуры — это целая эпоха в жизни каждой фирмы, они пока просто осторожничают).

WH>Я думаю это будет последний процессор с этой архитектурой.

С этой, не этой... Кол-во потоков на ядро будет только расти, транзакционность всё-равно нужна и её будут делать.


V>>Да, параллельно и что попало. Но если проц увидит, что в результате менялись и читались разные участки данных даже у одной и той же сущности (разные поля твоего типа, например, а тип целиком лежит в линейке кеша, понятное дело), то одновременные транзакции разрешаются, иначе — сериализуются. Прочувствуй разницу, как говорится.

WH>Теперь осталась маленькая проблема. Реализовать это технически.
WH>И что-то мне подсказывает что оверхед бедт такой что

Хочешь об этом поговорить?
Я вот не вижу никакого оверхеда в аппаратном исполнении, могу даже схему принципиальную накидать, которая сравнивает транзакционные области и сигнализирует о конфликтах. А шедуллер потоков (там несколько потоков на ядро), может просто так раскидать потоки, чтобы обеспечить сериализацию доступа в случае конфликтов. Пока что доступна операция атомарного изменения 2-х ячеек, но их может быть и больше. Понятно, что аппаратно всегда будет некий предел на такую аппаратную транзакцию. Дык, если проц не позволяет аппаратно включить достаточное кол-во сущностей в транзакцию, всегда можно по-старинке.

V>>Серваки БД работают именно так на определённых уровнях транзакции, зачем что-то изобретать, всё давно изобретено. Речь идёт лишь о том, чтобы частично (пока) поддержать часть этой логики в железе.

WH>Оракл в железе. Круто.

Частоизменяемых данных в реальных приложениях не много. В большинстве своём данные накапливаются и опрашиваются. Индекс идёт отдельно от данных. Сами данные идут мимо проца и его кешей напрямую через DMA, что с диска, что в сетку.

V>>С чего бы это меньше не залочить?

WH>С такой.
WH>Память в железке ходит нашенкованная на линейки кеша.

Пусть себе ходит, зачём всю линейку лочить? В линейке могут лежать логические несвязанные данные.


V>>Да хоть целый список областей произвольной длины, даже если все эти области не помещаются целиком в целый кеш.

WH>Чё? Ты хочень сказать что можно делать в железе эффективные транзакции на нескольких кусках памяти каждый из которых не влезает в L1 кешь?
WH>Ты серьезно?

Я о том, что хранить список диапазонов участвующих в транзакциях данных — это весьма экономно в общем случае. А сами данные могут занимать произвольный объём. Да, почему бы планировщику не спланировать задачи даже в тех случаях, когда все данные за один раз не лезут в L1? Ведь есть еще L2, разрядность обмена с ним растёт не по дням, а по часам, т.е. скорость обмена L1 и L2 тоже растёт. Есть еще и другие потоки, которым нужен L1, так что интеерсующие данные можно "прокачать" через выделенный участок L1 (примерно 50 тактов на обмен сегодня). Сейчас речь идёт о 32-х потоках, когда зайдет о 256-ти, то это будет вполне нормальный сценарий.

V>>Сейчас под этот список в новом сановском проце, насколько я понял, отведено 4 ячейки на поток, значит всего 32*4=128, их в перспективе может быть произвольное кол-во.

WH>4 слова на поток в одной тразакции? Гы! Даже не смешно.

Да понятно, что это эксперимент.

V>>Припрёт уже прямо сейчас на современных задачах. Пусть они поиграют с тем, насколько такая система эффективна для целей сериализации доступа, если окажется эффективной (в чём я не сомневаюсь),

WH>А я сомневаюсь что оно вобще будет работать.

Работает на отладчике, при том что отладчик — это не как они хотят чтобы работало, а тупой эмулятор вентилей железки.


V>>то оно будет расти вширь (ибо по частоте практически упёрлись, теоретический предел современного тех-процесса в районе 10МГц,

WH>Ты точно несколько ноликов не потерял?

3 потерял.

V>>даже при произвольной дальнейшей миниатюризации, так что расти можно будет только вширь одновременно с дальнейшей миниатюризацией... возможно придумают что-то вместо транзисторов когда-нить, но пока не придумали, и используют их, родимых, и дырочную проводимость, которая имеет геометрический минимальный предел, чтобы диод оставался диодом, и порог около 0.5-0.6В для кремния, так что пока упёрлись вплотную, и 1-1.2В — это примерно минимум для напряжения питания).

WH>А это тут вобще причем?

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


V>>Как показала практика — всё-таки беда. Даже для моей задачи микширования звука. Сервак загибается, если всего-лишь 50 раз в сек выделять динамически под каждый буфер данных 320 байт, и кол-во пользователей всего-лишь 4096, а на каждого — 4 таких буфера. Пока что рулят статические буфера.

WH>Не занимайся поддтасовками.
WH>Ты взял тупой мусорщик из .NET. И обобщаешь на все...

Я ответил насчёт эффективности передачи без локов данных на кольцевых буферах взамен lock-free списка из динамических узлов. Какие нафик обощения? что имеем, то имеем.

V>>Транзакционная память дешевле, чем блокировка целой линейки кеша из-за одного int.

WH> А ты в курсе что для записи одного int'а линейка кеша всегда захватывается для монопольного доступа.
WH>В данном случае ее захватывают на один такт.

Ты не знаешь, как это реально происходит в многопоточных ядрах. Я вот не уверен, что на каждый поток там свой контроллер доступа к памяти. Sun предложила именно это, но пока контроллирует только 2 значения на поток.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[16]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 31.07.08 13:22
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Надо просто формулировать задачу, а не бросаться в технические подробности.

WH>>Задача простая: Обеспечить правильную синхронизация в многопоточной среде.
V>Атомарность, скорее. Синхронизация — это ближе к событиям, а если речь о данных — то атомарность.
Ага. Событие чтения. Событие записи...
Короче хватит заниматься разведением спора то терминах.

V>Накладывает, ведь мы можем в экземпляре типа менять и читать независимые одиночные поля, нафига нам тут блокировки? А можем захотеть транзакционно прочитать/изменить сразу несколько полей. Твоя система типов с этим не справляется.

Справится.
Читай еще раз ибо ты вобще ничего не понял.

WH>>А в железе один хрен меньше чем с линейкой кеша работать не получится.

V>Получилось же у Sun.
И с какой эффективностью?

V>С этой, не этой... Кол-во потоков на ядро будет только расти, транзакционность всё-равно нужна и её будут делать.

Потоки да.
Транзакционная память нет.

V>Я вот не вижу никакого оверхеда в аппаратном исполнении, могу даже схему принципиальную накидать, которая сравнивает транзакционные области и сигнализирует о конфликтах. А шедуллер потоков (там несколько потоков на ядро), может просто так раскидать потоки, чтобы обеспечить сериализацию доступа в случае конфликтов.

Точно оракл в железе.

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

По какой из: http://en.wikipedia.org/wiki/Category:Process_calculi
И колличество "старинок" этим списком не ограничивается.

V>Частоизменяемых данных в реальных приложениях не много. В большинстве своём данные накапливаются и опрашиваются. Индекс идёт отдельно от данных. Сами данные идут мимо проца и его кешей напрямую через DMA, что с диска, что в сетку.

И?

V>Пусть себе ходит, зачём всю линейку лочить?

За тем что для того чтобы в линейку что-то записить нужно по любому получить эксклюзивный доступ.
А если у нас есть эксклюзивный доступ то продержим мы эту линейку один или 10 тактов разници нет.
AtomicIncrement — 3 такта
AtomicCompareExchange — 3-4 такта

V>В линейке могут лежать логические несвязанные данные.

Откуда они там возьмутся?
Ты что предлагаешь эффективной раскладкой данных на низком уровне вобще не заниматься?
Может еще и на аллигмент забить?

V>Я о том, что хранить список диапазонов участвующих в транзакциях данных — это весьма экономно в общем случае.

В общем!?

V>А сами данные могут занимать произвольный объём. Да, почему бы планировщику не спланировать задачи даже в тех случаях, когда все данные за один раз не лезут в L1? Ведь есть еще L2, разрядность обмена с ним растёт не по дням, а по часам, т.е. скорость обмена L1 и L2 тоже растёт. Есть еще и другие потоки, которым нужен L1, так что интеерсующие данные можно "прокачать" через выделенный участок L1 (примерно 50 тактов на обмен сегодня). Сейчас речь идёт о 32-х потоках, когда зайдет о 256-ти, то это будет вполне нормальный сценарий.

Не оракл отдыхает.

WH>>4 слова на поток в одной тразакции? Гы! Даже не смешно.

V>Да понятно, что это эксперимент.
А сильно больше и не будет.
Можешь не надеяться.

V>Работает на отладчике, при том что отладчик — это не как они хотят чтобы работало, а тупой эмулятор вентилей железки.

ню-ню.

V>При том, что дальнейшее развитие будет идти только вширь на текущих технологиях. Т.е. линейки кеша будут всё шире и шире, аппаратных потоков будет всё больше, и тем менее эффективно будет лочить всю линейку ради одного int.

А куда ты от этого денешься?

V>Я ответил насчёт эффективности передачи без локов данных на кольцевых буферах взамен lock-free списка из динамических узлов.

V>Какие нафик обощения?
Такие.

V>что имеем, то имеем.

В частном случае.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 31.07.08 16:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

V>>Накладывает, ведь мы можем в экземпляре типа менять и читать независимые одиночные поля, нафига нам тут блокировки? А можем захотеть транзакционно прочитать/изменить сразу несколько полей. Твоя система типов с этим не справляется.

WH>Справится.
WH>Читай еще раз ибо ты вобще ничего не понял.

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

WH>>>А в железе один хрен меньше чем с линейкой кеша работать не получится.

V>>Получилось же у Sun.
WH>И с какой эффективностью?

Наверно, с эффективностью обычного исполнения кода.

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

WH>По какой из: http://en.wikipedia.org/wiki/Category:Process_calculi
WH>И колличество "старинок" этим списком не ограничивается.

Имел ввиду — через примитивы синхронизации.

V>>Частоизменяемых данных в реальных приложениях не много. В большинстве своём данные накапливаются и опрашиваются. Индекс идёт отдельно от данных. Сами данные идут мимо проца и его кешей напрямую через DMA, что с диска, что в сетку.

WH>И?

Что и? Если кеша хватает размещать индексы, то оракл в железе получается.

V>>Пусть себе ходит, зачём всю линейку лочить?

WH>За тем что для того чтобы в линейку что-то записить нужно по любому получить эксклюзивный доступ.

Еще раз, ты не знаешь, как это реально происходит в многопоточных ядрах.

V>>В линейке могут лежать логические несвязанные данные.

WH>Откуда они там возьмутся?
WH>Ты что предлагаешь эффективной раскладкой данных на низком уровне вобще не заниматься?
WH>Может еще и на аллигмент забить?

Какое еще выравнивание на два рядомстоящих int в массиве или в полях одного типа?

V>>Я о том, что хранить список диапазонов участвующих в транзакциях данных — это весьма экономно в общем случае.

WH>В общем!?

Ес-сно, кроме случаев, когда запись о диапазоне (адрес+длина) больше чем содержимое.

V>>Работает на отладчике, при том что отладчик — это не как они хотят чтобы работало, а тупой эмулятор вентилей железки.

WH>ню-ню.

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


V>>Я ответил насчёт эффективности передачи без локов данных на кольцевых буферах взамен lock-free списка из динамических узлов.

V>>Какие нафик обощения?
WH>Такие.

Ну так я тебе показал сценарий, где подобная транзакционность даст приличный выигрыш при передаче данных м/у потоками, ввиду пользования статическими буферами. Ты сам напомнил про ГЦ, а потом заявляешь о каких-то обобщениях, когда по факту 16к выделений в секунду — это для GC оказалось плохо. А для передачи такого кол-ва данных через статические буфера — загрузка проца близка к нулевой, если примитивами синхронизации не пользоваться.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[18]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 31.07.08 16:59
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Еще раз, как в твоей системе типов разные потоки могут одновременно атомарно менять непересекающиеся множества полей типа int твоего uniqueness типа?

Говорю же ничего не понял.
2 потока не могут не только писать но и читать разные поля одного объекта uniqueness типа. Ибо ссылку может держать только один поток.

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

ЗАЧЕМ?
Только смотри чтобы не получилось как тут
Автор: WolfHound
Дата: 24.07.08
.

WH>>>>А в железе один хрен меньше чем с линейкой кеша работать не получится.

V>>>Получилось же у Sun.
WH>>И с какой эффективностью?
V>Наверно, с эффективностью обычного исполнения кода.
Чудес не бывает.

WH>>По какой из: http://en.wikipedia.org/wiki/Category:Process_calculi

WH>>И колличество "старинок" этим списком не ограничивается.
V>Имел ввиду — через примитивы синхронизации.
Они разные бывают.

V>Что и? Если кеша хватает размещать индексы, то оракл в железе получается.

А он в железе нужен?

V>>>Пусть себе ходит, зачём всю линейку лочить?

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

Только не забудь про то что у нас несколько ядер на кристале.
А на серваках несколько процессоров.

И так 2 потока работающих на разных процессорах хотят сделать на одной ячейке памяти AtomicCompareExchange.
Расказывай как ты это сделаешь без локов линейки кеша.

Ворос по проще: Тоже самое но только потоки живут на двух ядрах одного кристала.

А на одном ядре тормознуть один из 32х потоков на 3-4 такта не проблема.

V>>>В линейке могут лежать логические несвязанные данные.

WH>>Откуда они там возьмутся?
WH>>Ты что предлагаешь эффективной раскладкой данных на низком уровне вобще не заниматься?
На вопрос ответь.

WH>>Может еще и на аллигмент забить?

V>Какое еще выравнивание на два рядомстоящих int в массиве или в полях одного типа?
Такое. Можно же эти инты по адресу 1111111111 разместить.

V>Ну так я тебе показал сценарий, где подобная транзакционность даст приличный выигрыш при передаче данных м/у потоками, ввиду пользования статическими буферами. Ты сам напомнил про ГЦ, а потом заявляешь о каких-то обобщениях, когда по факту 16к выделений в секунду — это для GC оказалось плохо.

ДЛЯ КОНКРЕТНОГО ГЦ!
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 01.08.08 09:25
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>Еще раз, как в твоей системе типов разные потоки могут одновременно атомарно менять непересекающиеся множества полей типа int твоего uniqueness типа?

WH>Говорю же ничего не понял.
WH>2 потока не могут не только писать но и читать разные поля одного объекта uniqueness типа. Ибо ссылку может держать только один поток.

Тогда твоя схема идёт в сад.
Uniqueness type был разработан для совсем других вещей, а именно — для оптимизаций выделения памяти в функциональных языках. Это техника позволяет придавать ссылочным типам семантику value-типов, и не перевыделять память, например, под операнд в рекурсии. Когда существует конфликт, то создаётся просто копия

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

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

Так вот, где тут должен начинаться uniqueness тип, чтобы твоя схема нам помогла оптимизировать блокировки? И как не допустить конфликтов? В каком месте конкретно в этом графе компилятор заранее выдаст ошибку о нарушении совместного владения? (Ведь мы идём к конкретному объекту через цепочку ссылок).

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

WH>ЗАЧЕМ?

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

WH>>>И с какой эффективностью?

V>>Наверно, с эффективностью обычного исполнения кода.
WH>Чудес не бывает.

Да нет никаких чудес, включи воображение и прикинь, как это реализовано в ядре того проца.

V>>Что и? Если кеша хватает размещать индексы, то оракл в железе получается.

WH>А он в железе нужен?

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

V>>>>Пусть себе ходит, зачём всю линейку лочить?

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

Лочить линейку кеша надо для защиты от доступа другого ядра/проца. Для потоков одного ядра достаточно переупорядочивания инструкций, чтобы избежать конфликтов, не зачем каждому потоку "перелочивать" на себя всю линейку, если ядро уже владеет линейкой кеша. Актуально, кстати, при обсчёте тех же матриц. Но вот атомарное изменение или чтение нескольких ячеек — по прежнему проблема, для которой предлагается экспериментальное решение.

Учитывая, что вместо многоядерности расширение идёт в сторону многопоточности, то наши представления должны будут малость поменяться.

WH>А на одном ядре тормознуть один из 32х потоков на 3-4 такта не проблема.


Почему один? Сколько потоков на других ядрах будут работать с этой линейкой, столько и тормознётся. Может и не одного.

V>>>>В линейке могут лежать логические несвязанные данные.

WH>>>Откуда они там возьмутся?
WH>>>Ты что предлагаешь эффективной раскладкой данных на низком уровне вобще не заниматься?
WH>На вопрос ответь.

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

WH>>>Может еще и на аллигмент забить?

V>>Какое еще выравнивание на два рядомстоящих int в массиве или в полях одного типа?
WH>Такое. Можно же эти инты по адресу 1111111111 разместить.

Это ничего не даст при независимом доступе к соседним ячейкам.

V>>Ну так я тебе показал сценарий, где подобная транзакционность даст приличный выигрыш при передаче данных м/у потоками, ввиду пользования статическими буферами. Ты сам напомнил про ГЦ, а потом заявляешь о каких-то обобщениях, когда по факту 16к выделений в секунду — это для GC оказалось плохо.

WH>ДЛЯ КОНКРЕТНОГО ГЦ!

Да не видно пока лучше упомянутого. Хуже — полно.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[20]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 01.08.08 12:34
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Тогда твоя схема идёт в сад.

Ни куда она не идет.

V>Uniqueness type был разработан для совсем других вещей,

Да мне плевать для чего их разработали.
Вобще говоря я их придумал сам задолго до того как узнал слова uniqueness type.

V>А теперь смотри еще весьма популярный сценарий для многопоточности в бизнес-логике:

Популярные сценарии идет в сад.
Другая система.
Другие сценарии.

V>Схема весьма эффективна для типовых серваков приложений, обрабатывающих "много" запросов в единицу времени.

Эта схема формализуется pure типами.

V>Затем, что этот массив является кешем данных некоего апп-сервака, обслуживающего по 100тыс запросов в секунду.

1)100К RPS Ты где железо такое видел?
2)Кешей в вакууме не бывает. Бывают кеши для конкретной задачи.

V>Лочить линейку кеша надо для защиты от доступа другого ядра/проца.

Ага. Для двух и более ядер надо лочить.
Запомним.

V>Для потоков одного ядра достаточно переупорядочивания инструкций, чтобы избежать конфликтов,

Ну вот локи и переупорядочат.
Тем более что нафига двум потоком писать в одну линейку памяти если они не занимаются пересылкой данных друг другу не ясно.

V>не зачем каждому потоку "перелочивать" на себя всю линейку, если ядро уже владеет линейкой кеша.

А в чем проблема?
Если ядро владеет линейкой то это один такт.

V>Почему один? Сколько потоков на других ядрах будут работать с этой линейкой, столько и тормознётся. Может и не одного.

Стоять! Выше ты сказал что для двух ядер нужно лочить!
Те потоки на других ядрах тормознутся по любому.

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

Я так и не понял откуда у тебя такие объекты.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 01.08.08 13:02
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А теперь смотри еще весьма популярный сценарий для многопоточности в бизнес-логике:



А можно узнать, где это популярный сценарий? Я думал, что такие приложения я могу пересчитать по пальцам одной руки...
В Java/CLI для обеспечения многопоточного доступа скорее всего придётся использовать volatile переменные (если не использовать TLS, который ты говоришь плох), следовательно доступ на чтение без барьеров памяти не реализуется. В С/С++ реализуется, но это огромный pain-in-the-ass, который может взять на себя не каждый...
Где можно посмотреть примеры таких приложений? Если closed-source, то хотя бы названия.


V>- мы имеем некий граф объектов, чей корень хранится в статической памяти или в некоем передаваемом по стеку контексте (больше способов не знаю для

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


С транзакциями тут большие проблемы. Транзакций в общем понимании (ACID) тут не получится.
Например если взять транзакцию на чтение. Допустим поток читает 2 списка. Другой поток (который выполняет транзакцию на запись) одновременно хочет "транзакционно" переместить элемент из одного списка во второй. При такой схеме может получится, что первый поток либо не увидит элемент ни в одном списке, либо увидит сразу в двух. Что, безусловно, противоречит определению ACID транзакции.
Теперь возьмём транзакцию на запись. Допустим потоку надо выполнить следующую операцию. Добавить элемент в список 1, только если в списке 2 нет некого элемента. Он проверяет, что в списке 2 нет некого элемента, и планирует операцию добавления элемента в список 1. При коммите добавление элемента в список 1 производится, хотя в этот момент некий элемент в списке 2 уже может присутствовать. Опять же не ACID семантика.

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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[21]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 01.08.08 13:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

V>>Затем, что этот массив является кешем данных некоего апп-сервака, обслуживающего по 100тыс запросов в секунду.


WH>1)100К RPS Ты где железо такое видел?



Не так фантастично, как кажется на первый взгляд.
Допустим у нас 8-ми ядерная система, каждое ядро 3 GHz — типовой сервер на основе "бытового" (х86) железа. Получается по 240'000 тактов на запрос. Не так уж и мало.
Ввод-вывод. Допустим сервер общается с другими серверами, т.е. есть мало сокетов с большим потоком. Допустим 64 байта на запрос/ответ. Получается поток 100Mbps. Тоже вполне реалистично.
Конечно, для сервера, обрабатывающего web приложение, это не реалистично. Но в то же время для некоторых типов серверов это видится более-менее реалистичным. Ну и очевидно, так такая производительность не получилась "сама собой".



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[22]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 01.08.08 13:29
Оценка:
Здравствуйте, remark, Вы писали:

WH>>1)100К RPS Ты где железо такое видел?

R>Не так фантастично, как кажется на первый взгляд.
Так просто считать нельзя.
Там еще ОСь под ногами путается...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 01.08.08 15:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>1)100К RPS Ты где железо такое видел?


R>>Не так фантастично, как кажется на первый взгляд.


WH>Так просто считать нельзя.

WH>Там еще ОСь под ногами путается...


Давай считать не просто. Единственное, где ОС под ногами обязательно — это IO. Приём/отправку делаем пакетами по, допустим, 1000 сообщений. Т.е. получается 200 системных вызовов в сек. Опять вполне реалистично.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[24]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 01.08.08 16:04
Оценка:
Здравствуйте, remark, Вы писали:

R>Давай считать не просто. Единственное, где ОС под ногами обязательно — это IO.

Не единственное.
У нее еще шедуллер есть.
Менеджер виртуальной памяти.
...

R>Приём/отправку делаем пакетами по, допустим, 1000 сообщений. Т.е. получается 200 системных вызовов в сек. Опять вполне реалистично.

Ага. 1000 сообщений в пакете. Каждое сообщение 1 байт. Обработка сообщения увеличение значения каждого байта на 1...
Так может быть и больше...

Только это подтасовки.

А вот в 100К реальных (даже очень легких) запросов на обычном железе и обычных ОС я что-то не верю.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 01.08.08 16:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


R>>Давай считать не просто. Единственное, где ОС под ногами обязательно — это IO.

WH>Не единственное.
WH>У нее еще шедуллер есть.
WH>Менеджер виртуальной памяти.
WH>...

Делаем по потоку на процессор. Шедулер отпадает.
Память кэшируем. Менеджер виртуальной памяти отпадает.
Что скрывается за "..."?


R>>Приём/отправку делаем пакетами по, допустим, 1000 сообщений. Т.е. получается 200 системных вызовов в сек. Опять вполне реалистично.

WH>Ага. 1000 сообщений в пакете. Каждое сообщение 1 байт. Обработка сообщения увеличение значения каждого байта на 1...
WH>Так может быть и больше...
WH>Только это подтасовки.

А что плохого в 1000 сообщений в пакете? Если у нас 100'000 в сек, то надо надо всего лишь собирать запросы за 10 мсек, и тогда отправлять.
Пакетная обработка — это паттерн производительности. Он неё никуда не уйти в высокопроизводительном приложении. Естественно ничего хорошего не получится, если каждое сообщение отправлять блокирующим send'ом.

Каждое сообщение не 1 байт, а я считал 64 байта. Если взять гипотетические запросы "получить баланс л/с", "изменить баланс л/с", то они вполне укладываются в 64 байта (если мы берём внутренний интерфейс между серверами одной компании).
Обработка запроса — 240'000 тактов, можно сделать и побольше сложения 2 чисел.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[21]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 03.08.08 19:37
Оценка:
Здравствуйте, WolfHound, Вы писали:


V>>Схема весьма эффективна для типовых серваков приложений, обрабатывающих "много" запросов в единицу времени.

WH>Эта схема формализуется pure типами.

Мне не формализация нужна, а сериализация доступа. Даже в терминах pure-типа, при пересоздании коллекции объектов необходимо заблокировать другие потоки от подобного пересоздания.


V>>Затем, что этот массив является кешем данных некоего апп-сервака, обслуживающего по 100тыс запросов в секунду.

WH>1)100К RPS Ты где железо такое видел?

Ну, несколько тысяч простых запросов (не к БД, разумеется) поддерживает обычное современное железо, если вместо remoting и пр. использовать напрямую UDP (отдельная тема, как-то уже поднималась в рамках обсуждения стека IP, в котором отсутствует тип обслуживания "гарантированная доставка одного пакета"), этот тип обслуживания некоторые системы (IAX/IAX2) делают через UDP, и получают приличную скорость при малых затратах железа.

WH>2)Кешей в вакууме не бывает. Бывают кеши для конкретной задачи.


Тем не менее, сериализация доступа к кешу при изменениях — это общая задача, одна из самых распространённых для сценариев сериализации доступа как таковых.


V>>Лочить линейку кеша надо для защиты от доступа другого ядра/проца.

WH>Ага. Для двух и более ядер надо лочить.

Ес-но.

V>>Для потоков одного ядра достаточно переупорядочивания инструкций, чтобы избежать конфликтов,

WH>Ну вот локи и переупорядочат.
WH>Тем более что нафига двум потоком писать в одну линейку памяти если они не занимаются пересылкой данных друг другу не ясно.

Не в одну, а в соседние (я же упомянул обсчёт матриц).

V>>Почему один? Сколько потоков на других ядрах будут работать с этой линейкой, столько и тормознётся. Может и не одного.

WH>Стоять! Выше ты сказал что для двух ядер нужно лочить!
WH>Те потоки на других ядрах тормознутся по любому.

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

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

WH>Я так и не понял откуда у тебя такие объекты.

Обычный массив ссылок, являющийся основой любого быстрого кеша.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[21]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 03.08.08 19:37
Оценка:
Здравствуйте, remark, Вы писали:

V>>А теперь смотри еще весьма популярный сценарий для многопоточности в бизнес-логике:


R>А можно узнать, где это популярный сценарий? Я думал, что такие приложения я могу пересчитать по пальцам одной руки...


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

R>В Java/CLI для обеспечения многопоточного доступа скорее всего придётся использовать volatile переменные (если не использовать TLS, который ты говоришь плох), следовательно доступ на чтение без барьеров памяти не реализуется.


А зачем volatile? Другим потокам не критично, когда они увидят изменения — прямо сейчас, или в следующий запрос. Главное — это целостность, поэтому контейнеры не изменяются, а пересоздаются заново при каждом изменении и просто обновляется ссылка так, чтобы указывать на новый контейнер. Юзвери входят/выходят из конференций (или меняют состояние) на много порядков реже, чем идёт обращение к микшируемым данным (50 раз в сек для каждого юзверя).

Серваков конференций — много, их ферма, зато management сервак — один, хранит всё в БД, но его дёргают множества серваков коференций (на одном серваке конференций множество одновременно обслуживаемых конференций, сколько железо позволяет), поэтому в нём кеши организованны аналогично, т.к. в свою очередь данные о конференциях меняются на порядки реже, чем юзвери заходят и выходят из них.

R>В С/С++ реализуется, но это огромный pain-in-the-ass, который может взять на себя не каждый...

R>Где можно посмотреть примеры таких приложений? Если closed-source, то хотя бы названия.

Пример таких приложений — Centra, WebEx и т.д., мы делаем аналог, который на одном железе позволит хостить больше всей этой ерунды.


R>С транзакциями тут большие проблемы. Транзакций в общем понимании (ACID) тут не получится.

R>Например если взять транзакцию на чтение. Допустим поток читает 2 списка. Другой поток (который выполняет транзакцию на запись) одновременно хочет "транзакционно" переместить элемент из одного списка во второй. При такой схеме может получится, что первый поток либо не увидит элемент ни в одном списке, либо увидит сразу в двух. Что, безусловно, противоречит определению ACID транзакции.

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


R>Тут можно говорить только о транзакционности на уровне отдельных объектов, которая с т.з. бизнес-логики имеет мало смысла.


Нет, транзакции как раз нужны для атомарного выполнения множества операций.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[22]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 03.08.08 20:28
Оценка:
Здравствуйте, vdimas, Вы писали:

R>>С транзакциями тут большие проблемы. Транзакций в общем понимании (ACID) тут не получится.

R>>Например если взять транзакцию на чтение. Допустим поток читает 2 списка. Другой поток (который выполняет транзакцию на запись) одновременно хочет "транзакционно" переместить элемент из одного списка во второй. При такой схеме может получится, что первый поток либо не увидит элемент ни в одном списке, либо увидит сразу в двух. Что, безусловно, противоречит определению ACID транзакции.

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


Это плохо сочетается с тезисом о том, доступ на чтение — бесплатный, без атомарных операций и барьеров памяти. Заблокировать ряд мьютексов объектов — это атнюдь не без барьеров памяти.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[12]: Автоматическое распараллеливание (было "Что почитать
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 04.08.08 09:31
Оценка:
Здравствуйте, remark, Вы писали:
R>С HTM (Hardware Transactional Memory) ситуация получше. Проездов по памяти нет, грязных чтений нет. Производительность вроде лучше, чем у мьютексов... по крайней мере на *некоторых* тестах.
Performance pathologies in hardware transactional memory:

None of the systems performs best on all of our benchmarks. We identify seven performance pathologies-interactions between workload and system that degrade performance-as the root cause of many performance differences: FriendlyFire, StarvingWriter, SerializedCommit, FutileStall, StarvingElder, RestartConvoy, and DuelingUpgrades.

Доступа у меня к статье нет, но, похоже, не всё так очевидно.
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 04.08.08 09:51
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

R>>С HTM (Hardware Transactional Memory) ситуация получше. Проездов по памяти нет, грязных чтений нет. Производительность вроде лучше, чем у мьютексов... по крайней мере на *некоторых* тестах.
ANS>Performance pathologies in hardware transactional memory:

ANS>

None of the systems performs best on all of our benchmarks. We identify seven performance pathologies-interactions between workload and system that degrade performance-as the root cause of many performance differences: FriendlyFire, StarvingWriter, SerializedCommit, FutileStall, StarvingElder, RestartConvoy, and DuelingUpgrades.

ANS>Доступа у меня к статье нет, но, похоже, не всё так очевидно.


Да вот же она:
http://www.cs.wisc.edu/multifacet/papers/isca07_pathologies.pdf

Ситуация получше, чем с STM.
А с концепцией TM, с как таковой, связан ряд врожденных проблем.
Т.е. вот этот их вывод видится достаточно симнительным:

The insight provided
by these pathologies motivated four enhanced systems that often significantly reduce transactional memory overhead. Importantly,
by avoiding transaction pathologies, each enhanced system performs well across our suite of benchmarks.

Надо будет прочитать.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[22]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 04.08.08 12:02
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Лочить линейку кеша надо для защиты от доступа другого ядра/проца.

WH>>Ага. Для двух и более ядер надо лочить.
V>Ес-но.
И чем тогда нам поможет HTM?

WH>>Ну вот локи и переупорядочат.

WH>>Тем более что нафига двум потоком писать в одну линейку памяти если они не занимаются пересылкой данных друг другу не ясно.
V>Не в одну, а в соседние
Тогда вобще проблем нет.
Линейки кеша лочатся независимо.

V>(я же упомянул обсчёт матриц).

Никто так мелко его распаралеливать не будет.
Это просто не имеет смысла.

V>Не уверен, что внутри одного многоядерного проца другие потоки задерживаются при блокировке линейки кеша в случае отсутствия кофликтов доступа к одной линейке. Всё-таки менеджер памяти — это железка, и задерживать доступ она вполне может позволить себе только при наличии конфликтов.

Ага. Если нет конфликтов то у локов не будет никаких проблем.
А если есть то никакой HTM нам не поможет ибо он всеравно все лочить будет.

Короче как не крути, а HTM просто физически не может быть лучше локов.
Ибо HTM всеравно превращается в локи в случае конфликтов.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 04.08.08 20:34
Оценка:
Здравствуйте, remark, Вы писали:


R>Это плохо сочетается с тезисом о том, доступ на чтение — бесплатный, без атомарных операций и барьеров памяти. Заблокировать ряд мьютексов объектов — это атнюдь не без барьеров памяти.


Блокируются обычно не экземпляры, а их контейнеры. Опять же, транзакционные потребности на чтение сразу большого кол-ва сущностей обычно редки, а получение доступа к одному экземпляру получается бесплатным. Для редактирования одного экземпляра создаётся копия, которая помещается на место старого, контейнер просто блокируется. При добавлении-удалении контейнер не только блокируется, но и пересоздаётся. Читатели одиночных экземпляров по прежнему читают всё бесплатно.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[24]: Автоматическое распараллеливание (было "Что почитать
От: remark Россия http://www.1024cores.net/
Дата: 05.08.08 11:09
Оценка:
Здравствуйте, vdimas, Вы писали:

R>>Это плохо сочетается с тезисом о том, доступ на чтение — бесплатный, без атомарных операций и барьеров памяти. Заблокировать ряд мьютексов объектов — это атнюдь не без барьеров памяти.


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



А, ясно, значит я изначально не так понял. Я думал и транзакционность и бесплатный доступ на чтение.

з.ы. а если не секрет, на каком языке разрабатывается именно эта часть приложения? И под какие платформы работает? Только x86 или более портируемое?


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[23]: HTM
От: remark Россия http://www.1024cores.net/
Дата: 05.08.08 11:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

V>>Не уверен, что внутри одного многоядерного проца другие потоки задерживаются при блокировке линейки кеша в случае отсутствия кофликтов доступа к одной линейке. Всё-таки менеджер памяти — это железка, и задерживать доступ она вполне может позволить себе только при наличии конфликтов.


WH>Ага. Если нет конфликтов то у локов не будет никаких проблем.

WH>А если есть то никакой HTM нам не поможет ибо он всеравно все лочить будет.

WH>Короче как не крути, а HTM просто физически не может быть лучше локов.

WH>Ибо HTM всеравно превращается в локи в случае конфликтов.


Ну нет, не скажи. При использовании мьютексов, из-за очень жесткого API, реализация максимально прямолинейная, при использовании TM, из-за "гибкого" API, получается громадное множество (порядка сотни) вариантов реализации, и некоторые аспекты реализации, которые можно варьировать, коренным образом влияют на производительность и масштабируемость.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[24]: HTM
От: WolfHound  
Дата: 05.08.08 14:31
Оценка:
Здравствуйте, remark, Вы писали:

R>Ну нет, не скажи. При использовании мьютексов, из-за очень жесткого API, реализация максимально прямолинейная, при использовании TM, из-за "гибкого" API, получается громадное множество (порядка сотни) вариантов реализации, и некоторые аспекты реализации, которые можно варьировать, коренным образом влияют на производительность и масштабируемость.

Мъютексы и мои локи
Автор: WolfHound
Дата: 16.04.08
несколько отличаются...
И я не вижу где HTM будет лучше моих локов.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: HTM
От: remark Россия http://www.1024cores.net/
Дата: 05.08.08 15:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Ну нет, не скажи. При использовании мьютексов, из-за очень жесткого API, реализация максимально прямолинейная, при использовании TM, из-за "гибкого" API, получается громадное множество (порядка сотни) вариантов реализации, и некоторые аспекты реализации, которые можно варьировать, коренным образом влияют на производительность и масштабируемость.


WH>Мъютексы и мои локи
Автор: WolfHound
Дата: 16.04.08
несколько отличаются...

WH>И я не вижу где HTM будет лучше моих локов.

Основное отличие в том, что с помощью мьютексов и TM можно предоставлять высокоуровневый API:
mutex.lock();
моя_произвольная_бизнес_логика();
mutex.unlock();


htm_trx_begin();
моя_почти_произвольная_бизнес_логика();
htm_trx_commit();


А с помощью твоих локов — нет. Они сродни InterlockedCompareExchange() — хороша, да только большинству разработчиков и в большинстве ситуаций — никакой пользы.

Этим я не говорю, что твои локи плохи, я говорю, что сравнивать их с TM бессмысленно. Учитывая, что они на более низком уровне, не удивительно, что они могут предоставлять большую производительность.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[26]: HTM
От: WolfHound  
Дата: 05.08.08 15:16
Оценка:
Здравствуйте, remark, Вы писали:

R>
R>htm_trx_begin();
R>моя_почти_произвольная_бизнес_логика();
R>htm_trx_commit();
R>

моя_почти_произвольная_бизнес_логика очень сильно сказано.
Транзакция ограничена 4мя машинными словами.
Сомневаюсь что это колличество когда либо будет заметно больше 10.
Иначе это уже будет оракл в железе.

R>А с помощью твоих локов — нет. Они сродни InterlockedCompareExchange() — хороша, да только большинству разработчиков и в большинстве ситуаций — никакой пользы.

Разработчики получат более высокоуровневые механизмы.

R>Этим я не говорю, что твои локи плохи, я говорю, что сравнивать их с TM бессмысленно. Учитывая, что они на более низком уровне, не удивительно, что они могут предоставлять большую производительность.

Фигня в том что по факту они на том же уровне. Только без всякого кучерявого булщита который не дает ничего кроме мутной семантики и не нужного усложнения.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 05.08.08 15:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Комманда lock N, Rx, Ry

WH>Лочит одну или 2 линейки кеша (в которые попадают адреса из регистров Rx и Ry) на время выполнения следующих N (скажем до 16 комманд).
WH>Под локом можно обращаться только к залоченным частям памяти и делать только переходы вперед (никаких циклов под локом) и ессно никаких локов под локом.
WH>Если в одной линейке кеша есть несколько ячеек памяти которые нас интересуют то достаточно указать адрес одной из них но обращаться можно ко всем ибо всеравно вся линейка кеша залочена.
WH>Захвативший лок поток на время выполнения лока получает высший приоритет (ибо лок нужно отпустить как можно быстрее).
WH>Одновременно может выполняться только один лок на одном ядре.


Я так понимаю, что ты хочешь запрещать прерывания на время удержания lock. Правильно?
Будет не очень приятно, если в это время будут происходить промахи в L1-I кэше... таким образом мы можем запретить прерывания на тысячи тактов... Да и дедлок можно словить. Причём такой дедлок будет означать, что N процессоров выводятся из работы системы до следующей перезагрузки. Ну если сами процессоры ещё можно будет как-то реанимировать, то процессы точно придётся мочить в сортире.

Мне кажется более реалистичной идея "fixed size" HTM:
trx_begin failure_address, read_write_set, read_write_mask
trx_commit

trx_begin — начинает транзакцию, failure_address — адрес куда перейти в случае ошибки при выполнении транзакции, read_write_set — указатель на область памяти, где лежит 8 указателей на память, которую надо добавить в read_set или write_set (не используемые указатели отмечаем нулями), read_write_mask — битовая маска, указывающая куда надо добавлять адрес — в read_set или write_set.
trx_commit — коммитит транзакцию

Тут не будет проблем ни с дедлоками, ни с запретом прерываний, т.к. при любой неуверенности транзакцию можно просто отменять.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[27]: HTM
От: remark Россия http://www.1024cores.net/
Дата: 05.08.08 15:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>
R>>htm_trx_begin();
R>>моя_почти_произвольная_бизнес_логика();
R>>htm_trx_commit();
R>>

WH>моя_почти_произвольная_бизнес_логика очень сильно сказано.
WH>Транзакция ограничена 4мя машинными словами.
WH>Сомневаюсь что это колличество когда либо будет заметно больше 10.
WH>Иначе это уже будет оракл в железе.

4 слова на что? На код? На readset? На writeset? Или на сумму?

R>>А с помощью твоих локов — нет. Они сродни InterlockedCompareExchange() — хороша, да только большинству разработчиков и в большинстве ситуаций — никакой пользы.

WH>Разработчики получат более высокоуровневые механизмы.

Разработчики не получат ничего нового, чего они не имеют сейчас. Ну где-то производительность немного увеличится.
TM пытается решить другую задачу — дать разработчику новые мехинизмы.

R>>Этим я не говорю, что твои локи плохи, я говорю, что сравнивать их с TM бессмысленно. Учитывая, что они на более низком уровне, не удивительно, что они могут предоставлять большую производительность.

WH>Фигня в том что по факту они на том же уровне. Только без всякого кучерявого булщита который не дает ничего кроме мутной семантики и не нужного усложнения.

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


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Автоматическое распараллеливание (было "Что почитать.
От: WolfHound  
Дата: 05.08.08 15:41
Оценка:
Здравствуйте, remark, Вы писали:

R>Я так понимаю, что ты хочешь запрещать прерывания на время удержания lock. Правильно?

В том потоке где лок да.
Но у нас много потоков на одном ядре...
Да и ядер несколько.

R>Будет не очень приятно, если в это время будут происходить промахи в L1-I кэше...

В том потоке где случился лок во время лока никаких промохов не может быть в принципе.
Ибо процессор подтянет в L1 и в L1-I все что нужно.
А промохи в других потоках нас не волнуют.

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

С чего бы?

Короче ИМХО проблем будет не больше чем с префиксом lock в x86'х процессорах.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 05.08.08 15:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Я так понимаю, что ты хочешь запрещать прерывания на время удержания lock. Правильно?

WH>В том потоке где лок да.
WH>Но у нас много потоков на одном ядре...
WH>Да и ядер несколько.

Это что-то меняет в данном контексте?


R>>Будет не очень приятно, если в это время будут происходить промахи в L1-I кэше...

WH>В том потоке где случился лок во время лока никаких промохов не может быть в принципе.
WH>Ибо процессор подтянет в L1 и в L1-I все что нужно.
WH>А промохи в других потоках нас не волнуют.

Как он подтянет инструкции, на которые мы хотим выполнить вычисляемый переход? За 16 инструкций можно успеть "поскакать" по 16-ти различным страницам с кодом. Да, кстати, если страничное прерывание, то предется держать лок 10 мс.


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

WH>С чего бы?

Что именно?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Автоматическое распараллеливание (было "Что почитать.
От: WolfHound  
Дата: 05.08.08 16:21
Оценка:
Здравствуйте, remark, Вы писали:

WH>>В том потоке где лок да.

WH>>Но у нас много потоков на одном ядре...
WH>>Да и ядер несколько.
R>Это что-то меняет в данном контексте?
Все. Прерывания по факту никуда не запрещаются. Просто будут прирываться другие потоки.

R>Как он подтянет инструкции, на которые мы хотим выполнить вычисляемый переход?

А мы хотим?

R>За 16 инструкций можно успеть "поскакать" по 16-ти различным страницам с кодом.

Мне наверное следовало явно написить что имеются в виду не любых инструкций, а только тех что идут непосредственно за lock'ом.
Посмотри еще раз на AtomicCompareExchange там мы просто выскакиваем за приделы залоченного региона и все.

R>Да, кстати, если страничное прерывание, то предется держать лок 10 мс.

Оно случится на входе в lock и управление просто заберет ОСь.

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

WH>>С чего бы?
R>Что именно?
Все те ужосы что ты описал.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Автоматическое распараллеливание (было "Что почитать.
От: remark Россия http://www.1024cores.net/
Дата: 05.08.08 17:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>В том потоке где лок да.

WH>>>Но у нас много потоков на одном ядре...
WH>>>Да и ядер несколько.
R>>Это что-то меняет в данном контексте?
WH>Все. Прерывания по факту никуда не запрещаются. Просто будут прирываться другие потоки.

Прерывания связываются с логическим процессором (аппаратным потоком). Например, все прерывания от сетевой карты идут на логический процессор 7.


R>>Как он подтянет инструкции, на которые мы хотим выполнить вычисляемый переход?

WH>А мы хотим?

Какая разница. Пользователь-то может написать что угодно.


R>>За 16 инструкций можно успеть "поскакать" по 16-ти различным страницам с кодом.

WH>Мне наверное следовало явно написить что имеются в виду не любых инструкций, а только тех что идут непосредственно за lock'ом.
WH>Посмотри еще раз на AtomicCompareExchange там мы просто выскакиваем за приделы залоченного региона и все.

В общем случае кол-во инструкций нельзя посчитать сколько их там штук. С адреса 1000 может начинаться одна 4-ёх байтовая инструкция, а с адреса 1001 может начинаться другая 5-ти байтовая инструкция, и мы можем переходить как на адрес 1000, так и на адрес 1001.


R>>Да, кстати, если страничное прерывание, то предется держать лок 10 мс.

WH>Оно случится на входе в lock и управление просто заберет ОСь.

Это что касается данных — да. А что касается кода — тут не понятно. Если считать, что под количеством инструкций имеется в виду "непосредственно следующие за командой lock", то такой проблемы нет. Но тут свои проблемы.


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

WH>>>С чего бы?
R>>Что именно?
WH>Все те ужосы что ты описал.

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


Не пойми меня неправильно, я не против самой идеи. Мне лично она как раз очень нравится. Я именно про реализацию.
Погляди про инструкцию PLO:
http://www.rsdn.ru/Forum/?mid=2918312
Автор: remark
Дата: 16.04.08

Там смысл примерно такой же, но обходятся все проблемы с тем, что мы даём пользователю выполнять "произвольный" код под локом.
PLO может атомарно выполнить одну из 6 операций: compare and load, compare and swap, double compare and swap, compare and swap and store, compare and swap and double store, or compare and swap and triple store. Над 32, 64 или 128 битными данными.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Автоматическое распараллеливание (было "Что почитать.
От: WolfHound  
Дата: 05.08.08 17:35
Оценка:
Здравствуйте, remark, Вы писали:

R>Прерывания связываются с логическим процессором (аппаратным потоком). Например, все прерывания от сетевой карты идут на логический процессор 7.

А что это обязательно?
Можно и иначе раскидывание прирываний организовать.
Например назначаем крайним за прирывание сразу все ядро.
А оно само прирывает любой свой поток для которого разрешены прирывания.
Если ОСь будет следить что бы таких потоков было не меньше десятка то никаких проблем не будет.

R>Какая разница. Пользователь-то может написать что угодно.

И получит аппартаным исключением по башке.

R>В общем случае кол-во инструкций нельзя посчитать сколько их там штук. С адреса 1000 может начинаться одна 4-ёх байтовая инструкция, а с адреса 1001 может начинаться другая 5-ти байтовая инструкция, и мы можем переходить как на адрес 1000, так и на адрес 1001.

Это зависит...
1)Можно указывать не колличество инструкций, а адрес до которого лочить.
2)Есть архитектуры у которых комманды занимают одинаковое колличество байт.

R>Это что касается данных — да. А что касается кода — тут не понятно. Если считать, что под количеством инструкций имеется в виду "непосредственно следующие за командой lock", то такой проблемы нет.

Чтд.

R>Но тут свои проблемы.

Какие?

R>Надо гарантировать, что внутри лока не будет прерываний, промахов кэша, нехороших инструкций, страничных прерываний и т.д. Тогда то, что я написал, не актуально.

Это все можно гарантировать просто описав что можно использовать под локом.
А если юзер не юзер, а глупый ксакеп то что у нас там при access violation происходит...

R>В противном случае можно ожидать чего-угодно.

А кто спорит?

R>Не пойми меня неправильно, я не против самой идеи. Мне лично она как раз очень нравится. Я именно про реализацию.

Так я и хочу понять что ты там криминального нашол.
Пока ничего не видно.
Вернее все эти вопросы я продумал еще до того как то сообщение написать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 06.08.08 20:22
Оценка:
Здравствуйте, remark, Вы писали:


R>з.ы. а если не секрет, на каком языке разрабатывается именно эта часть приложения? И под какие платформы работает? Только x86 или более портируемое?


С прицелом на портирование сервера на уровне исходников. В дотнетном коде, например, есть CriticalSection, ибо она заметно быстрее, чем стандартный дотнетный Monitor.Enter/Exit, но опять же, CriticalSection — это "наш" класс, внутренности которого для других платформ на Mono можно заменить на использование Monitor. Микшеры переписали в блоках unsafe и используем редкоперевыделяемые буфера в обычной памяти (не GC), ибо у дотнета все еще плохо с доступом к элементам массивов (он постоянно проверяет попадание индекса), т.е. математика не ахти пашет, к сожалению. Доступы к сокетам — тоже "наши", т.к. дотнетные внутри себя порой занимаются фигней, в виде создания промежуточных массивов byte[] и т.д. В дотнете удобный интерфейс для задания параметров сокета и его бинда (со всей логикой проверок и иерархией исключений), затем мы просто берём его хендл после бинда, и инициализируем им наш "быстрый" ропер, который есть value-type. Вообще, упор на value-type серьезный, всякие коллекции-буфера, не предназначенные для передачи ссылки на них (это практически большинство), переписаны на value-type, дабы уменьшить число ссылочных цепочек для доступа к конечным данным, и т.д. и т.п.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[12]: Автоматическое распараллеливание (было "Что почитать
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.08 04:11
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Пока что есть, на каждый хендл ввода-вывода внутри ОС. И еще один глобальный — на создание и удаление подобных хендлов из общего списка.

Это всё от того, что ОС раздает хэндлы кому попало. В WH-ной системе хэндл будет uniqueness ресурсом, то есть доступ к нему имеет ровно один поток. Значит ему не нужно захватывать никакой мьютекс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Автоматическое распараллеливание (было "Что почитать
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.08 08:08
Оценка:
Здравствуйте, remark, Вы писали:

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


V>>>Пока что есть, на каждый хендл ввода-вывода внутри ОС. И еще один глобальный — на создание и удаление подобных хендлов из общего списка.


S>>Это всё от того, что ОС раздает хэндлы кому попало. В WH-ной системе хэндл будет uniqueness ресурсом, то есть доступ к нему имеет ровно один поток. Значит ему не нужно захватывать никакой мьютекс.


R>uniqueness мьютексы и семафоры

На всякий случай поясню случайным читателям, что сия шутка юмора отнюдь не означает, что remark считает мьютексы и семафоры объектами ввода-вывода.
R>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 10.08.08 04:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

V>>Пока что есть, на каждый хендл ввода-вывода внутри ОС. И еще один глобальный — на создание и удаление подобных хендлов из общего списка.

S>Это всё от того, что ОС раздает хэндлы кому попало. В WH-ной системе хэндл будет uniqueness ресурсом, то есть доступ к нему имеет ровно один поток. Значит ему не нужно захватывать никакой мьютекс.

А как быть с синхронизациецй потоков, например по событиям? Ввод-вывод без событий себе не представляю. Объект event принципиально из разных потоков виден и оперируем.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[14]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 10.08.08 17:38
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А как быть с синхронизациецй потоков, например по событиям? Ввод-вывод без событий себе не представляю. Объект event принципиально из разных потоков виден и оперируем.

Тебе еще сколько раз эту ссылку показать?
http://en.wikipedia.org/wiki/Category:Process_calculi
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 12.08.08 05:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


V>>А как быть с синхронизациецй потоков, например по событиям? Ввод-вывод без событий себе не представляю. Объект event принципиально из разных потоков виден и оперируем.

WH>Тебе еще сколько раз эту ссылку показать?
WH>http://en.wikipedia.org/wiki/Category:Process_calculi

Ты издеваешься или придуриваешься?
Мне глубоко пофиг формальное описание и даже любой высокоуровневый язык, ему соответствующий. Ты мне скажи как это в процах реально работать будет, мы сейчас именно это обсуждаем. Любые высокоуровневые и супер-типизированные каналы сообщений м/у процессами по-любому должны синхронизировать свою работу на уровне исполнения, и я пока не вижу достойной альтернативы таким примитивам синхронизации как события (даже если высокоуровневый код не использует события напрямую, а лишь определяет коммуникационные каналы или же операторы коммуникаций, если те встроены в язык). Так вот, еще раз, на уровне механики, объект-событие должен быть виден из разных потоков/процессов.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[16]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 12.08.08 12:01
Оценка:
Здравствуйте, vdimas, Вы писали:

WH>>Тебе еще сколько раз эту ссылку показать?

WH>>http://en.wikipedia.org/wiki/Category:Process_calculi
V>Ты издеваешься или придуриваешься?
Разговор окончен.
Бесполезно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Автоматическое распараллеливание (было "Что почитать
От: vdimas Россия  
Дата: 12.08.08 17:04
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>>>Тебе еще сколько раз эту ссылку показать?

WH>>>http://en.wikipedia.org/wiki/Category:Process_calculi
V>>Ты издеваешься или придуриваешься?
WH>Разговор окончен.
WH>Бесполезно.

Уже по второму вопросу отсылка к формальным спецификациям и уход от того, как это будет в механике (хотя мы тут обсуждаем именно это). Что такое идеология обмена сообщениями тут знают не хуже (просто предположи), более того, статья в вики на эту тему, мягко говоря, далеко не полна.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[18]: Автоматическое распараллеливание (было "Что почитать
От: WolfHound  
Дата: 12.08.08 17:28
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Уже по второму вопросу отсылка к формальным спецификациям и уход от того, как это будет в механике (хотя мы тут обсуждаем именно это).

Лично я думал что всем очевидно что ВМ на то и нужна чтобы прикладных программистов механика нне волновала.
А как будут устроены примитивы ВМ на конкретной железке дело десятое.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.