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

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

С>>А разве каждое присваивание ссылки в c# не зовет что-то типа InterlockedExchangePointer?

AF>1. нет, не зовет, и откуда у тебя такая странная мысль?

по моим сведениям присванивание ссылки в c# — атомарно. Кроме того, нужно делать memory barrier. А он делается с пом. InterlockedXXX — синхронизация кешей

AF>2. и вообще, какое это имеет отношение к моему вопросу?

Это имеет отношение к синхронизации кешей

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

N>Компилятору надо больше гигагерц.
Для чего? Лексический разбор работает на ура. Синтаксический тоже. Да и к тому же они плохо параллелятся. Оптимизация в основном на графах. А это рандомный доступ к памяти. Угадай кто-при этом тормозит?

N>Э нет, платка поможет только в очень немногих случаях. Те системы видеонаблюдения с десятком видеоканалов требуют ооочень больших ресурсов процессора.
Не совсем. Алгоритмы обнаружения достаточно просты(если не переводить в трехмерный вид). Проблема в том, что нужно перегнать большое кол-во информации, и опять упираемся в память.

R>>>О играх и серном ПО и говорить нечего.
GZ>>Для игр — важна память+граф карта. Для серверного ПО, проблемы синхронизации не стоит. Фактически — на каждого пользователя по ядру, с разделением данных. Но я говорил именно о десктопах.
N>AI в играх просчитывает именно процессор. Если поставить побольше умных ботов в каком-нибудь шутере — тормозить будет. И не из-за нехватки видео- или оперативной памяти.
Не эксперт в геймах, потому определенно сказать не могу — что является бутылочным горлышком в данном случае.

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

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

N>>Компилятору надо больше гигагерц.
GZ>Для чего? Лексический разбор работает на ура. Синтаксический тоже. Да и к тому же они плохо параллелятся. Оптимизация в основном на графах. А это рандомный доступ к памяти. Угадай кто-при этом тормозит?

Если граф read-mostly (например, уже построенное AST), то — ядро. Не память.
AST хорошо распараллеливается на функции, т.е. первое ядро оптимизирует первые 25% функций файла, второе — вторые 25% и т.д.

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

С>А он делается с пом. InterlockedXXX — синхронизация кешей
Interlocked — не относится к синхронизации кэшей. Кэш управляется чисто аппаратно. Interlocked используется для синхронизации доступа к обычной памяти.

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

R>Если граф read-mostly (например, уже построенное AST), то — ядро. Не память.
R>AST хорошо распараллеливается на функции, т.е. первое ядро оптимизирует первые 25% функций файла, второе — вторые 25% и т.д.
Не забывай о стоимости доступа к основной памяти.

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

С>>>А разве каждое присваивание ссылки в c# не зовет что-то типа InterlockedExchangePointer?

AF>>1. нет, не зовет, и откуда у тебя такая странная мысль?

С>по моим сведениям присванивание ссылки в c# — атомарно. Кроме того, нужно делать memory barrier. А он делается с пом. InterlockedXXX — синхронизация кешей


Сам точно не в курсе. Меня тоже этот вопрос интересовал.
У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.

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

[]

R>Сам точно не в курсе. Меня тоже этот вопрос интересовал.
R>У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.

А как быть с ссылками, которыми оперируют из разных тредов? Полюбому там обеспечивается атомарность присваивания. Другой вопрос каким образом.

R>

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

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

С>>А он делается с пом. InterlockedXXX — синхронизация кешей
GZ>Interlocked — не относится к синхронизации кэшей. Кэш управляется чисто аппаратно. Interlocked используется для синхронизации доступа к обычной памяти.

Почитай Рихтера. Он "может" вести к синхронизации кешей.

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

R>>Сам точно не в курсе. Меня тоже этот вопрос интересовал.
R>>У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.

С>А как быть с ссылками, которыми оперируют из разных тредов? Полюбому там обеспечивается атомарность присваивания. Другой вопрос каким образом.

Я думаю, что это просто запрещено.
А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.

R>>

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

Кё>4. Multithreading с общими данными (синхронизацией) — отстой. Языковая поддержка типа atomic {} не решает проблемы. Каждый наверное уже обжегся. Многие уже самостоятельно дошли до вывода, что чем меньше разделяемых данных — тем меньше багов. Синхронизации не дожно быть.

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

Мне не доводилось использовать Ada и ее механизм рандеву, но синхронизация на mutex-ах/cond_var-ах не слаще таковой на обмене сообщениями.

Кё>Я думаю все уже придумано (Erlang). Программа делится на мелкие процессы. Чем мельче тем лучше — больше ядер смогут заняться параллельными процессами. Каждый из них ни с кем свои данные не делит в принципе. Для каждого общего ресурса создается процесс-контроллер, с работает с ресурсом только он. Процессы могут передавать друг другу владение над частями своих данных (без копирования памяти то есть). Шедулер создает нужное для текущей системы число потоков, и исполняет эти мелкие процессы в них.

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

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

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

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

R>>Если граф read-mostly (например, уже построенное AST), то — ядро. Не память.
R>>AST хорошо распараллеливается на функции, т.е. первое ядро оптимизирует первые 25% функций файла, второе — вторые 25% и т.д.
GZ>Не забывай о стоимости доступа к основной памяти.

Просто считать один раз AST не дорого. Если, конечно, оно лежит в более-менее компактном виде, а не побито на биты и не разбросано хаотично по всему адресному пространству.
Обработка его будет значительно дольше.

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

С>Почитай Рихтера. Он "может" вести к синхронизации кешей.
Это уже побочно. Ссылка в Net атомарно, потому что GC перед сборкой мусора останавливает работу программы, собирает граф живых объектов (на который существуют ссылки хранящиеся в том числе в регистрах процессора) и перемещает требуемые объекты с переписыванием ссылок. Кэш тут вообще не причем. Interlocked при присваивании не делается.

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

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

С>>Почитай Рихтера. Он "может" вести к синхронизации кешей.
GZ>Это уже побочно.

Ах значит вес-таки может вести к сбросу кеша? Уже лучше.

GZ>Ссылка в Net атомарно, потому что GC перед сборкой мусора останавливает работу программы, собирает граф живых объектов (на который существуют ссылки хранящиеся в том числе в регистрах процессора) и перемещает требуемые объекты с переписыванием ссылок. Кэш тут вообще не причем. Interlocked при присваивании не делается.

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

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

E>а вот попробуйте на Erlang-е Emacs или Vim написать -- откуда там взятся мелким процессам?

Мелкие процессы нужны, что можно было параллелить. Если параллелить не надо, то и делить на подпроцессы не надо.

Если в Emacs или Vi есть что синхронизировать, значит там есть параллельные процессы. Если там есть параллельные процессы, то сериализацию доступа к общим данным можно сменить на посылку сообщения процессу-контроллеру над этими данными. Синхронизация остается, только её уже как минимум не надо делать вручную над каждым общим ресурсом, создавая возможность ошибки в каждом таком месте.

Я не могу придумать случая, когда многопоточность с ручной синхронизацией нельзя было бы заменить на обмен сообщениями.

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

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

R>>>Сам точно не в курсе. Меня тоже этот вопрос интересовал.
R>>>У них же там не синхронное управление памятью, а GC. Т.е. там собственно и референс каунтера не надо. Просто скопировал указатель и всё. А сколько ссылок потом разберётся GC.

С>>А как быть с ссылками, которыми оперируют из разных тредов? Полюбому там обеспечивается атомарность присваивания. Другой вопрос каким образом.

R>Я думаю, что это просто запрещено.

нет.

R>А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.

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

R>>>
R>

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

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

С>>Почитай Рихтера. Он "может" вести к синхронизации кешей.
GZ>Это уже побочно. Ссылка в Net атомарно, потому что GC перед сборкой мусора останавливает работу программы, собирает граф живых объектов (на который существуют ссылки хранящиеся в том числе в регистрах процессора) и перемещает требуемые объекты с переписыванием ссылок. Кэш тут вообще не причем. Interlocked при присваивании не делается.
Хотя нет, соврал. В нем нужна синхронизация ссылок из старых поколений в новые поколения в случае Concurrent режима. Но про interlocked там я не слышал.

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

R>>А если разрешено, то тут не надо никаких InterlockedXXX, просто присвоить/считать значение указателя.

С>Ты у себя в программе вот так спокойно делаешь с поинтерами, к которым идет доступ из разных тредов?

На x86 да, а почему бы и нет? Это экстремально быстро.

R>>>>
R>>

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

Кё>Я не могу придумать случая, когда многопоточность с ручной синхронизацией нельзя было бы заменить на обмен сообщениями.

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

Какие выигрышы даст здесь обмен сообщениями по сравнению с ожиданием на cond_var/mutex-е?

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

С>При чем здесь сборка мусора? А между ними что будем делать с изменением ссылок в разных потоках?
А в чем проблема то? Адрес экземпляра объекта "неизменяемо". Единственный кто может его изменить — GC. Присваивание int — атомарно на аппаратном уровне. Так в чем дело?

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

N>>Э нет, платка поможет только в очень немногих случаях. Те системы видеонаблюдения с десятком видеоканалов требуют ооочень больших ресурсов процессора.
GZ>Не совсем. Алгоритмы обнаружения достаточно просты(если не переводить в трехмерный вид). Проблема в том, что нужно перегнать большое кол-во информации, и опять упираемся в память.

обнаружение движения — простая (вычислительная) задача, которая давным-давно решена. Сейчас главный вопрос — распознавание движущихся объектов, оставленных предметов. Т.е. не распознавание лиц или автомобильных номеров (что подразумевает поиск по базе данных), а просто определение класса объекта: человек, автомобиль и т.д. Даже самые быстрые на сегодняшний момент методы не позволяют это делать real-time на нескольких видеоканалах. А ведь их может быть очень много!