Здравствуйте, Cyberax, Вы писали:
G>>Я думаю, фьючерсы — это лучшее, что придумано на текущий момент в области языкостроения и параллельного программирования. C>До тех пор, пока код фьючерса не попробует обращаться к разделяемой памяти...
Отчего же, все будет в порядке. До тех пор, пока в этой разделяемой памяти лежат чисто функциональные транзакционные структуры данных .
Вообще же, фьючерсов, асинхронных сообщений, и чисто функциональных структур данных, видишь ли, достаточно для многих задач . Фьючера хороши для синхронных запросов в стиле rpc. Очереди сообщений — для асинхронного "потокового" взаимодействия. "Чистые" транзакционные структуры данных — для избавления как от необходимости межтредного маршалинга на одной машине, так и от синхронизации доступа к данным, да и от класса ошибок связанного с мутабельным состоянием заодно.
Отличный подход, который позволит писать потрясающие программы, в надежном стиле, и с почти линейной масштабируемостью. Позволяет применять метод потока данных для проектирования, что есть совершенно превосходная методология анализа, отлично приспособленная к параллельным задачам. Причем, программу, написанную в таком стиле, несложно раскидать на кластер — она получается очень толерантна к латентности передачи сообщений, и подсистем памяти.
Я думаю, F# на многоядерных мультитредных процах раскроет себя во всей красе при применении данного подхода.
Здравствуйте, Gaperton, Вы писали:
G>На практике 7% называется "одинаковая производительность", и никто не будет расшибаться в лепешку, чтобы эти 7% ликвидировать.
Расшибаться не обязательно. Достаточно выбрать для задачи подходящий инструмент. В некоторых случаях это будет OpenMP.
E>>На практике, ты не сможешь этот выигрыш нивелировать. G>На практике, смогу. Если захочу.
"Дайте мне точку опоры и я сдвину Землю". Вижу, что аргументы в разговоре уже перешли в разряд "непробиваемых".
G>В любом случае, тебе-то откуда знать, что я смогу а что нет.
Судя по твоему заявлению о том, что на C++ можно программировать в стиле Erlang с использованием MPI.
G>Да? Тогда прокомментируй еще вот это: G>
G>А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
А там все понятно. Remark дал эту оценку одному вполне конкретному примеру. Вот этому
. Все. Никаких претензий на всемирное господство разделяемой памяти.
G>Так вэлкам! Что ж ты никак не покажешь-то эти преимущества? Что тогда для тебя преградой то является, а?
Нет смысла заниматься доказательствами, когда глобальная переменная-указатель в любой момент может быть объявлена вырожденой очередью сообщений длиной 1. Что такой же маразм, как и утверждение, что точка является частным случаем прямой.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
E>>Может быть тогда ты сможешь сказать, у какой именно очереди сообщений накладные расходы на проверку наличия нового элемента будут меньше одного atomic_read?
G>Может быть, я тебе это уже сказал во второй части своего сообщения, которую ты предусмотрительно вырезал? Может быть, Синклер тебе все то же самое объяснил?
Не может быть.
G>>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
Одного обычного read будет недостаточно, о чем уже было сказано.
G>Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.
Этот красочный оборот речи был предназначен для сокрытия факта того, что нити-читатели должны проверять свою очередь сообщений перед каждой новой транзакцией, и что эта проверка не может быть дешевле одного atomic_read-а.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
C>>До тех пор, пока код фьючерса не попробует обращаться к разделяемой памяти... G>Отчего же, все будет в порядке. До тех пор, пока в этой разделяемой памяти лежат чисто функциональные транзакционные структуры данных .
Ну да, помечтать не вредно...
G>Я думаю, F# на многоядерных мультитредных процах раскроет себя во всей красе при применении данного подхода.
У меня просто в программе (на Java) фьючерсы достаточно сильно используются, так что я наталкивался на интересные проблемы с ними. Например, они часто существенно увеличивают вероятность столкновения на оптимистических блокировках в БД (которая, по сути, есть разделяемые данные).
Так как если несколько фьючерсов выполняются параллельно, то вполне вероятно, что они будут одновременно обращаться к одним данным. Оптимистические блокировки это словят и корректно откатят транзакцию, но тогда нам нужно будет её повторять или возвращать ошибку клиенту. В общем, я как-то так производительность в 10 раз поднял, заменив в одном методе параллельные вызовы на последовательные
Так что тут всё тоже не так просто...
Sapienti sat!
Re[49]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
G>>>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
E>Одного обычного read будет недостаточно, о чем уже было сказано.
Глупость, повторенная многократно, не перестает быть глупостью.
G>>Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.
E>Этот красочный оборот речи был предназначен для сокрытия факта того, что нити-читатели должны проверять свою очередь сообщений перед каждой новой транзакцией, и что эта проверка не может быть дешевле одного atomic_read-а.
Ты зачем, интересно, глупости пишешь? Тут все слишком просто, чтобы ты мог кого-то запутать.
Очередь сообщений проверяется каждый раз при приеме тех данных, которые тебе надо отмаршрутизировать. Которых, замечу, как минимум на пару порядков больше, чем обновлений таблицы. Иногда (гораздо реже, чем пакеты с данными) в ту же очередь приходит сообщение с новой таблицой, так что ничего специального для приема корня таблицы делать не нужно. При обработке этого пакета происходит вычитка корня дерева из очереди, и сохранение в локальную память, откуда он уже читается без всяких atomic_read на каждое сообщение, которое тебе надо отмаршрутизировать. Без всякого atomic_read, на котором в твоем случае и будет просос.
Re[50]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>Глупость, повторенная многократно, не перестает быть глупостью.
Подобные банальные истины обоюдоостры и могут быть с такой же степенью уверености обращены к тебе.
G>Очередь сообщений проверяется каждый раз при приеме тех данных, которые тебе надо отмаршрутизировать.
Один раз ты принимаешь N пакетов, каждый из которых тебе нужно отмаршрутизировать. При маршрутизации этого пакета тебе нужно проверить, не изменилась ли таблица маршрутизации. Ась?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G> Потом — просто пользуемся массивом, не выставляя никакой явной синхронизации, и не принимая сообщений. Допустим, так же пробегаемся по нему в цикле, считая сумму.
Пример из моего последнего выступления на Платформе:
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
G>>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
G>Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.
Даже на архитектуре POWER, с одной из самых расслабленных моделей памяти на сегодняшний день, atomic_read с требуемым в данном случае упорядочиванием consume, является не более чем обычной инструкцией загрузки из памяти ld (той самой, которая десятками встречается в любой функции и занимает доли такта):
Example POWER Implementation for C/C++ Memory Model: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
(раздел "PowerPC Code Sequences")
И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Gaperton, Вы писали:
G>>>"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.
E>>Классическое образование, надо полагать, заставляет думать, что доступ к разделяемым данным можно сделать только на семафорах. Ничего не поделать, у классического образования так же есть недостатки.
G>Извини, пока я не вижу никаких фактов, демонстрирующих какие-либо твои познания и представления, выходящие за рамки стандартного API, которое реализует в основном семафорную модель. Ты можешь меня разубедить, переведя тему разговоров с личностей обратно на предмет дискуссии. Вопрос по существу — ты сказал, что реализация очереди будет "избыточнее", чем то неизвестно что, что ты там планируешь в данной задаче вместо нее применять. Докажи.
Вот реализация "семафора" (или мьютекса), которая для доступа "на чтение" требует только 2 обычных сохранения в память, несколько загрузок из памяти и одно предсказываемое ветвление. При этом алгоритм распределенный, т.е. при доступе "на чтение" потоки работают с локальной памятью. За счёт этого такой мьютекс оказывается быстрее очереди с одним CAS в 300(!) раз уже на четырёх-ядерном процессоре Q6600 на тесте с высокой нагрузкой: http://groups.google.com/group/lock-free/browse_frm/thread/1efdc652571c6137
И не говоря уже о случае, когда разделяемый объект иммутабельный (или используются более гибкие и мощные подходы типа partial copy-on-write) и для доступа к объекту достаточно обычной операции загрузки (доли такта): http://www.rsdn.ru/forum/message/3213225.1.aspx
Здравствуйте, Gaperton, Вы писали:
E>>Если же поток-модификатор один, то не важно, как потоки-читатели будут видеть изменения -- через разделяемую переменную или через уведомления. Но тогда и протокол не нужен, тут вы правы.
G>Это как раз очень важно, потому что работая через "разделяемую переменную" ты налетаешь на примитив синхронизации на каждом чтении. И на синхронное взаимодействие, требующее "рандеву" — все должны ждать, когда ты ее изменишь
"Примитив синхронизации и рандеву" в языках платформы CLI (C#) и Java представляет из себя копирование объектной ссылки, что является не более чем обычной инструкцией загрузки указателя (доли такта) на всех современных аппаратных платформах.
Именно таким образом в этих языках и реализовывалось бы распространение неизменяемого объекта: изменяющий поток совершает подмену объектной ссылки на новый объект (одна обычная запись в память), читающие потоки совершают считывание текущей объектной ссылки (одно обычное чтение из памяти). Это в противопоставление обмену сообщениями, где придётся рассылать N сообщений, принимать N сообщений, и ещё ряд неприятных факторов (типа работы не обязательно с текущей версией объекта, жадного обновления объект в отличие от ленивого и др.).
G>Чтобы добиться таких же характеристик, как с решением на актерах, не изображая при этом актеров, тебе придется через задний проход реализовать их на семафорной модели, проиграв в сложности, и не выиграв ничего в производительности. Так как ты не владеешь дизайн-идиомой актеров, то ты во многих случаях просто не додумаешься до такого решения, как привел я.
Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. Евгений разработал несколько версий собственной библиотеки для агентно/актёрно-ориентированного программирования (SObjectizer), и работал с этим подходом ещё в 1994 году. Скорее всего это не всё, это так сказать "по материалам открытой печати". И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
Я, хочешь ты этого или нет, тоже разработал 2 библиотеки для актёрно-ориентированного программирования, и вплотную работаю с такими вещами как использование иммутабельных структур в многопоточном окружении (а также значительно более общим и гибким подходом — partial copy-on-write; STM; примитивы синхронизации; современные модели для параллельного программирования и др.).
Твои же технические знания и опыт пока под большим сомнением. Очевидно, не представляешь что такое атомарное чтение (http://www.rsdn.ru/forum/message/3213225.1.aspx
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, remark, Вы писали:
R>>>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
AVK>>Афигеть. Ну тогда я делаю тезис — remark пьет по ночам кровь христианских младенцев. Все согласны? Нет? Ну тггда вперед, доказывай
G>Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.
Какое самопожертвование
Из множества не доказанных и не подтверждённых фактами высказываний Gaperton выберем самые интересные.
Здравствуйте, Gaperton, Вы писали:
G>Ой ли. А давай посмотрим, что конкретно кроется за словом "быстрее".
G>2%, 7%, 9%, и 69% — тесты с выигрышем OpenMP. Значимый отрыв только в одном тесте. 2% — это вообще не смешно, а что такое 9% — ну вместо минуты займет у тебя расчет 55 секунд. Для вашей пенисометрии это может быть и значимый отрыв, но мне, честно, на такую разницу плевать — что есть она, что нет.
G>27% и 139% — тесты с выигрышем MPI. Значимый отрыв в двух тестах.
G>Я весь внимание — все еще жду как ты будешь делать вывод о преимуществах разделяемой памяти.
Gaperton, постарайся хотя бы для начала понять моё изначальное высказывание, которое изложено на вполне нормальном русском языке, и которое, я вижу, тут понял не один человек, и даже были попытки тебе его тут пояснить.
Ещё раз, дабы не затуманить основную мысль: ТЫ НЕ ПОНЯЛ МОЁ ВЫСКАЗЫВАНИЕ, и говоришь о чём-то другом.
Здравствуйте, remark, Вы писали:
R>Даже на архитектуре POWER, с одной из самых расслабленных моделей памяти на сегодняшний день, atomic_read с требуемым в данном случае упорядочиванием consume, является не более чем обычной инструкцией загрузки из памяти ld (той самой, которая десятками встречается в любой функции и занимает доли такта):
Неправда.
1) "Доли такта" не занимает ни одна инструкция. Вообще.
2) По причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync, то есть барьер выставить, что занимает в районе 30-50 тактов. Это на многоядерном кристалле с общим кэшом L2, таком, какой стоит в XBox360. Это во-вторых.
R>И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? .
И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса.
Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
different location.
Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
Что же касается всех "остальных современных архитектур", то даже архитектуры с TSO (что из не-embedded процов имеет только Sun-овские Ниагары) для корректного поведения вашей программы с atomiс_read потребуют мемори барьеров. В случае SMP с несколькими кристаллами и независимыми кэшами, ты налетишь на проблемы когерентности и будешь вынужден выставить memory barrier, что необходимо просадит производительность. Чудес-то не бывает.
R>Вот реализация "семафора" (или мьютекса), которая для доступа "на чтение" требует только 2 обычных сохранения в память, несколько загрузок из памяти и одно предсказываемое ветвление. При этом алгоритм распределенный, т.е. при доступе "на чтение" потоки работают с локальной памятью. За счёт этого такой мьютекс оказывается быстрее очереди с одним CAS в 300(!) раз уже на четырёх-ядерном процессоре Q6600 на тесте с высокой нагрузкой: R>http://groups.google.com/group/lock-free/browse_frm/thread/1efdc652571c6137
Ну вот, в аккурат после пропущенного Comedy Club ты опять поднимаешь мне настроение. Ну неужели такой крупный специалист по параллелизму как ты не заметил, что у тебя внутри каждого чтения стоит МЕМОРИ БАРЬЕР (20-90 накладных тактов в зависимости от ситуации на x86 сам по себе, плюс эффект от отключения переупорядочивания). На код свой посмотри!
void reader_lock()
{
reader_inside[current_thread_index] = true;
// no explicit #StoreLoad
// but it will be implicitly executed
// by sys_synch() in writer_lock() if (writer_pending)
{
// if writer is pending
// than signal that we see it
// and wait for writer to complete
reader_inside[current_thread_index] = false;
EnterCriticalSection(&cs);
reader_inside[current_thread_index] = true;
LeaveCriticalSection(&cs);
}
// need to order user code inside critical section
// acquire compiler barrier
_ReadWriteBarrier();
}
Объясни мне, каким именно образом такой барьер будет быстрее чем CAS в 300 раз (откуда ты вообще эту цифру взял, интересно), при том, что CAS занимает на x86 те же 30-90 тактов? Ась?
R>И не говоря уже о случае, когда разделяемый объект иммутабельный (или используются более гибкие и мощные подходы типа partial copy-on-write) и для доступа к объекту достаточно обычной операции загрузки (доли такта): R>http://www.rsdn.ru/forum/message/3213225.1.aspx
Здравствуйте, remark, Вы писали:
R>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.
Одно могу сказать — в отличии от тебя и Действительно Умного Человека, я не чувствую необходимости привлекать в дискуссии в качестве аргументов матюги (чем давеча отметился ты), переходы на личности (чем ты сейчас занят), и вранье (на котором здесь ловили вас обоих — но в этом больше Действительно Умный Человек" отметился). Мне проще привести факты с логикой.
R> Евгений разработал... Я, хочешь ты этого или нет, тоже разработал... R>Твои же технические знания и опыт пока под большим сомнением.
Тебе не приходило в голову, что на фоне той белиберды, которая присутствует в некоторых постах Действительно Умных Людей, мне может быть совершенно пофигу, что Действительно Умные Человеки разработали, и что они думают про мои технические знания и опыт? Нет? Ну так вот — твои сомнения в моей технической экспертизе я как-нибудь переживу.
я и не претендую. Где мне с Действительно Умными Людьми сравняться, тонко представляющими себе стоимость примитивных операций . Вот, например, оказывается, что самая "обычная инструкция загрузки из памяти ld (та самая, которая десятками встречается в любой функции)", в соответствии с авторитетнейшим исследованиям remark, "занимает доли такта".
"Доля такта" — ну кто мог бы подумать. Надо же, ld выполняется быстрее, команда "регистр-регистр" . Жжешь, адский сатана.
ЗЫ: Знаешь, чем опасен переход на личности, которым ты занялся? Тем, что ты случайно можешь выставить полным идиотом самого себя. Поэтому, а не почему-то другому, не стоит переходить на личности. Однако, я вижу — ты упорный, и тебя с линии не собьешь, ты любишь дела до конца доводить.
Здравствуйте, Gaperton, Вы писали:
R>>Вот реализация "семафора" (или мьютекса), которая для доступа "на чтение" требует только 2 обычных сохранения в память, несколько загрузок из памяти и одно предсказываемое ветвление. При этом алгоритм распределенный, т.е. при доступе "на чтение" потоки работают с локальной памятью. За счёт этого такой мьютекс оказывается быстрее очереди с одним CAS в 300(!) раз уже на четырёх-ядерном процессоре Q6600 на тесте с высокой нагрузкой: R>>http://groups.google.com/group/lock-free/browse_frm/thread/1efdc652571c6137
G>Ну вот, в аккурат после пропущенного Comedy Club ты опять поднимаешь мне настроение. Ну неужели такой крупный специалист по параллелизму как ты не заметил, что у тебя внутри каждого чтения стоит МЕМОРИ БАРЬЕР (20-90 накладных тактов в зависимости от ситуации на x86 сам по себе, плюс эффект от отключения переупорядочивания). На код свой посмотри!
G>
G> void reader_lock()
G> {
G> reader_inside[current_thread_index] = true;
G> // no explicit #StoreLoad
G> // but it will be implicitly executed
G> // by sys_synch() in writer_lock()
G> if (writer_pending)
G> {
G> // if writer is pending
G> // than signal that we see it
G> // and wait for writer to complete
G> reader_inside[current_thread_index] = false;
G> EnterCriticalSection(&cs);
G> reader_inside[current_thread_index] = true;
G> LeaveCriticalSection(&cs);
G> }
G> // need to order user code inside critical section
G> // acquire compiler barrier
G> _ReadWriteBarrier();
G> }
G>
G>Объясни мне, каким именно образом такой барьер будет быстрее чем CAS в 300 раз (откуда ты вообще эту цифру взял, интересно), при том, что CAS занимает на x86 те же 30-90 тактов? Ась?
Ну ты опять жжёшь! Я от предыдущего сообщения ещё отойти не могу. Ты лучше Comedy Club не пропускай — им нужен твой юмор!
_ReadWriteBarrier() — это барьер КОМПИЛЯТОРА. Подавляет переупорядочивания компилятором. Всё. 0 тактов оверхеда в ран-тайм.
CAS занимает 30-90 тактов? Ну всё понятно — на одноядерном мерил или без разделения данных между разными ядрами. Да, на одноядерном и/или без раздлеления действительно 30-90 тактов. Только проблема в том, что в очереди у тебя будет разделение, и тогда уже стоимость CAS никого не волнует. Тогда начинает волновать издержки на когерентность — порядка 200-500 тактов на современных системах.
Ну ты не огорчайся. В принципе, у неискушённых людей может возникнуть ощущение, что ты осведомлённый и пишешь разумные вещи.
R>>И не говоря уже о случае, когда разделяемый объект иммутабельный (или используются более гибкие и мощные подходы типа partial copy-on-write) и для доступа к объекту достаточно обычной операции загрузки (доли такта): R>>http://www.rsdn.ru/forum/message/3213225.1.aspx
G>Когда разделяемый объект иммутабельный — это мой случай, а не твой.
Ну ладно-ладно, ты только не горячись. Оставляю его тебе. Благо таким подходом реализуется *очень* ограниченное число структур и *очень* ограниченнное число операций над ними.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Даже на архитектуре POWER, с одной из самых расслабленных моделей памяти на сегодняшний день, atomic_read с требуемым в данном случае упорядочиванием consume, является не более чем обычной инструкцией загрузки из памяти ld (той самой, которая десятками встречается в любой функции и занимает доли такта):
G>Неправда. G>1) "Доли такта" не занимает ни одна инструкция. Вообще.
Есть разные определения и методики измерения времени, занимаемого командой. Здесь я имею в виду CPI, как наиболее интересную для программиста. Я надеюсь, ты в курсе, что CPI может быть меньше 1.
Ну на самом деле это совершенно не принципиально в данном вопросе. Назвать можно по-разному, но суть — что это обычная инструкция загрузки, которые можно найти в изобилии в любой функции. Т.е. стоимость синхронизации в данном случае можно считать равной нулю, что с трудом можно сказать о массовой рассылке и приёме сообщений.
G>2) По причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync, то есть барьер выставить, что занимает в районе 30-50 тактов. Это на многоядерном кристалле с общим кэшом L2, таком, какой стоит в XBox360. Это во-вторых.
Ну и чем ты можешь это аргументировать?
Ты хочешь сказать, что по ссылке приведена некорректная реализация атомарного чтения с упорядочиванием consume? Или что consume (data-dependent load) не достаточно в данном случае?
Да, про Comedy Club можно забыть после твоих отжигов.
Никакого lwsync там не надо.
R>>И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
G>Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? .
Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
G>И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса. G>
G>Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
G>different location.
G>Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
Я поражаюсь, как тебе получается такую ахинею оборачивать в благовидный облик.
Нет, не Абыдно. Где ты в паттерне публикации увидел store-load последовательность, которую надо упорядочивать? Поток потребителя её исполняет? Ну и что же он сохраняет и куда?
G>Что же касается всех "остальных современных архитектур", то даже архитектуры с TSO (что из не-embedded процов имеет только Sun-овские Ниагары) для корректного поведения вашей программы с atomiс_read потребуют мемори барьеров. В случае SMP с несколькими кристаллами и независимыми кэшами, ты налетишь на проблемы когерентности и будешь вынужден выставить memory barrier, что необходимо просадит производительность. Чудес-то не бывает.
Слушай, где ты такого понабирался? Можешь хоть ссылки какие-то дать? Интересно становится...
В каком месте-то ты там хоть этот барьер себе представляешь? Да, и какого, кстати, типа это барьер? Как-либо затрагивать когерентность и иметь отношение к SMP может только если полный барьер — значит тут полный барьер будет где-то в паттерне публикации на стороне потребителя?
Здравствуйте, Gaperton, Вы писали:
R>>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
G>Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.
G>Одно могу сказать — в отличии от тебя и Действительно Умного Человека, я не чувствую необходимости привлекать в дискуссии в качестве аргументов матюги (чем давеча отметился ты), переходы на личности (чем ты сейчас занят), и вранье (на котором здесь ловили вас обоих — но в этом больше Действительно Умный Человек" отметился). Мне проще привести факты с логикой.
Хммм... неплохой приём — вот так в последний момент переменить своё точку зрения, и накатать такое "высокое" оправдание, что бы типа очистить свою совесть. Неплохо!
Личности тебе значит по-барабану? И тебя волнует только конкретная дискуссия? Если немного пройтись по твоим сообщениям в этом топике:
Говоришь собеседнику, что ему придётся реализовывать что-то через "задний проход"; абсолютно необоснованно говоришь, что собеседник не владеет "дизайн-идиомой актёров"; говоришь, что собеседник не додумается до таких решений как ты: http://www.rsdn.ru/forum/message/3213290.aspx
сказал собеседнику: "ты, что, правда, всерьез думаешь, что ты в состоянии реалистично представить себе оптимальное решение на "актерах", не написав ни одной программы": http://www.rsdn.ru/forum/message/3197730.1.aspx
Будь добр, поясни как это всё согласуется с твоей позицией, что тебя интересует только дискуссия, а на личность собеседника ты типа не обращаешь внимания? По-моему, практически каждый твой пост пропитан неуважением к собеседнику, личными оскорблениями и чувством собственного превосходства. При этом, кстати, техническая сторона страдает. Говоришь людям приводить аргументы и ссылки, сам же никаких ссылок не приводишь, и отвечаешь "Сам поищи. Лень".
Где, кстати, на вранье меня поймали?
Самое забавное, что ты так и не понял моё первоначальное высказывание. Как при этом вообще спорил и шашкой махал — совершенно не понятно...
R>> Евгений разработал... Я, хочешь ты этого или нет, тоже разработал... R>>Твои же технические знания и опыт пока под большим сомнением.
G>Тебе не приходило в голову, что на фоне той белиберды, которая присутствует в некоторых постах Действительно Умных Людей, мне может быть совершенно пофигу, что Действительно Умные Человеки разработали, и что они думают про мои технические знания и опыт? Нет? Ну так вот — твои сомнения в моей технической экспертизе я как-нибудь переживу.
G>Видишь-ли, меня интересует мнение о моей персоне тех людей, кого я уважаю.
Это я заметил, что тебя интересуют только те, кого ты уважаешь. А на тех кого, ты не уважаешь тебе плевать. При этом, где истина и объективность тебя совершенно не волнует.
G>я и не претендую. Где мне с Действительно Умными Людьми сравняться, тонко представляющими себе стоимость примитивных операций . Вот, например, оказывается, что самая "обычная инструкция загрузки из памяти ld (та самая, которая десятками встречается в любой функции)", в соответствии с авторитетнейшим исследованиям remark, "занимает доли такта".
G>"Доля такта" — ну кто мог бы подумать. Надо же, ld выполняется быстрее, команда "регистр-регистр" . Жжешь, адский сатана.
Это я тоже заметил, что ты на ум не претендуешь. Нет, определенный звон (МЕМОРИ БАРЬЕР, lwsync и т.д) ты видимо слышал. Но вот где он совершенно не представляешь.
Смотри ответ: http://www.rsdn.ru/Forum/message/3214044.aspx
Но при этом шанса по-оскорблять собеседника ты не упустил: "Абыдно, да?", "На, почитай первоисточник", "И здесь ты неправ".
G>ЗЫ: Знаешь, чем опасен переход на личности, которым ты занялся? Тем, что ты случайно можешь выставить полным идиотом самого себя. Поэтому, а не почему-то другому, не стоит переходить на личности. Однако, я вижу — ты упорный, и тебя с линии не собьешь, ты любишь дела до конца доводить.
А ты прям ангел такой. У тебя типа в каждом втором посте не встречаются плохо замаскированные оскорбления, неуважительные высказывания и указания на собственное превосходство.
Да ещё вот эта тема непонятная — дофантазирование технических деталей. Откуда на POWER lwsync в load-consume? Откуда в паттерне публикации на стороне потребителя store-load последовательность? Как барьеры памяти влияют на когерентность? Откуда ты эти факты взял? У меня 2 варианта: (1) либо действительно любишь фантазировать (такое можно понять на уроке литературы, но в техническом форуме ), (2) либо очень хитро врёшь/выставляешь реальные факты лживо в надежде типа "а вдруг прокатит", со стороны неискушенного читатели выглядит типа авторитетно.
Или просто прочитал где-то такие некорректные факты? Будь добр укажи, где такое пишут.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
G>Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.
По-существу то хоть что-нибудь ответишь:
"Примитив синхронизации и рандеву" в языках платформы CLI (C#) и Java представляет из себя копирование объектной ссылки, что является не более чем обычной инструкцией загрузки указателя (доли такта) на всех современных аппаратных платформах.
Именно таким образом в этих языках и реализовывалось бы распространение неизменяемого объекта: изменяющий поток совершает подмену объектной ссылки на новый объект (одна обычная запись в память), читающие потоки совершают считывание текущей объектной ссылки (одно обычное чтение из памяти). Это в противопоставление обмену сообщениями, где придётся рассылать N сообщений, принимать N сообщений, и ещё ряд неприятных факторов (типа работы не обязательно с текущей версией объекта, жадного обновления объект в отличие от ленивого и др.).
"Абыдно, Да?" (с) Gaperton
"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
.
), (2) либо очень хитро врёшь/выставляешь реальные факты лживо в надежде типа "а вдруг прокатит", со стороны неискушенного читатели выглядит типа авторитетно.