OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 07:44

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Один поток или много?
СообщениеДобавлено: Пятница, 30 Август, 2013 13:54 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
(модератор) выделено из темы viewtopic.php?p=82087#p82087 согл. п. 3.3

Илья Ермаков писал(а):
Потом же пришло разочарование в мультитредовости вообще.

Ну, у тебя видимо задачи немного не те (скажем сервер который только и делает что отправляет html-странички не нуждается в многопоточности) :-) А у меня тут без многопоточности все становится сразу ну очень грустно (в том числе в вебе, ибо веб-сервера иногда не только html да картинки отгружают).


Последний раз редактировалось Евгений Темиргалеев Суббота, 31 Август, 2013 21:58, всего редактировалось 1 раз.
пометка о разделении


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Красноярская сборка BlackBox 1.6rc6
СообщениеДобавлено: Пятница, 30 Август, 2013 16:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Илья Ермаков писал(а):
Потом же пришло разочарование в мультитредовости вообще.

Ну, у тебя видимо задачи немного не те (скажем сервер который только и делает что отправляет html-странички не нуждается в многопоточности) :-) А у меня тут без многопоточности все становится сразу ну очень грустно (в том числе в вебе, ибо веб-сервера иногда не только html да картинки отгружают).


Слушай, ну а как же Redis, Tarantool и ряд других NoSQL прекрасно живут на одном потоке? И имеют фантастическую пропускную способность. Именно из-за отказа от блокировок и конкурентности...
А загрузить все ядра можно и группой процессов. Если же хотим распределяться - то проще использовать один механизм (изолированные процессы), чем какие-то заморочки с общей памятью.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Красноярская сборка BlackBox 1.6rc6
СообщениеДобавлено: Пятница, 30 Август, 2013 19:05 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
Alexey Veselovsky писал(а):
... А у меня тут без многопоточности все становится сразу ну очень грустно (в том числе в вебе, ибо веб-сервера иногда не только html да картинки отгружают).
Слушай, ну а как же Redis, Tarantool и ряд других NoSQL прекрасно живут на одном потоке? И имеют фантастическую пропускную способность. Именно из-за отказа от блокировок и конкурентности...
А загрузить все ядра можно и группой процессов. Если же хотим распределяться - то проще использовать один механизм (изолированные процессы), чем какие-то заморочки с общей памятью.
Хорошо бы в этой теме найти систематические основания какие-то.
Какую-нибудь опорную теорему, что ли, как, типа, с GOTO.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Красноярская сборка BlackBox 1.6rc6
СообщениеДобавлено: Суббота, 31 Август, 2013 00:47 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Один поток будет тормозить весь сервер, если он будет блокироваться на вводе-выводе (жёсткий диск, сеть, IPC, другие устройства).

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

Так что, если существует механизм неблокирующего ввода-вывода, то однопоточное приложение часто будет лучше.

Но здесь ещё есть нюанс с ядрами процессора.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Красноярская сборка BlackBox 1.6rc6
СообщениеДобавлено: Воскресенье, 01 Сентябрь, 2013 10:51 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Valery Solovey писал(а):
Один поток будет тормозить весь сервер, если он будет блокироваться на вводе-выводе (жёсткий диск, сеть, IPC, другие устройства).

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

Так что, если существует механизм неблокирующего ввода-вывода, то однопоточное приложение часто будет лучше.

Но здесь ещё есть нюанс с ядрами процессора.

А вы пробовали потоки из А2 ? Там вроде как 50000 потоков без проблем держит. При том, что нет переключения контекстов (т.е. накладных расходов).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Воскресенье, 01 Сентябрь, 2013 21:41 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Madzi писал(а):
А вы пробовали потоки из А2 ? Там вроде как 50000 потоков без проблем держит. При том, что нет переключения контекстов (т.е. накладных расходов).
Нет, я их не видел. Всё руки не дойдут посмотреть такие потоки, их реализацию. Всё никак не могу понять, почему они есть в отдельных продуктах, но не в ОС, на которой продукты крутятся. ОС в данном случае - винда и линукс.

Но переключение контекстов всё равно есть: банально состояние регистров и стэк у каждого потока свои. И, вроде, самая большая проблема в потоках - общие данные. Решается она не всегда эффективно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Воскресенье, 01 Сентябрь, 2013 22:45 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
A2 по сути ОС и есть. WinAOS и UnixAOS - лишь прослойки для её запуска поверх другой ОС.
В ней (А2) переключения контекстов нет, так как всё выполняется в одном адресном пространстве (соответственно и проблем с общим доступом к памяти нет, точнее они есть, но решаются через эксклюзивный доступ (директива {EXCLUSIVE})).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Понедельник, 02 Сентябрь, 2013 01:21 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Madzi писал(а):
A2 по сути ОС и есть. WinAOS и UnixAOS - лишь прослойки для её запуска поверх другой ОС.
Я знаю. Просто, проблемы и решения, касающиеся многопоточности, я встречал в сети только для этих ОС. Поэтому их и упомянул: чтобы не казалось, что сказанное относится и к другим ОС (помимо A2 есть ещё много других: Plan 9, Inferno, Haiku, AROS, RiscOS и т.д.).
Madzi писал(а):
В ней (А2) переключения контекстов нет, так как всё выполняется в одном адресном пространстве (соответственно и проблем с общим доступом к памяти нет, точнее они есть, но решаются через эксклюзивный доступ (директива {EXCLUSIVE})).
Вы, наверно, используете понятие "контекст" в узкоспециализированном смысле. У разных потоков есть уникальные ресурсы. Именно потому потоки и разные. И чтобы при переключении не потерять ресурсы потока, ОС делает некоторые действия, чтобы потом всё корректно восстановить. Допускаю, что в A2 переключение происходит несколько быстрее, но сомневаюсь, что разница большая.

Что же касается совместного доступа к ресурсу в памяти, то только лишь директивой проблему не решить. Если методы синхронизации классические, то и производительность будет примерно на уровне других ОС. Архитектура ОС здесь не важна, важен алгоритм. И если в ETH ничего нового не придумали, то чудес ожидать не стоит.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Понедельник, 02 Сентябрь, 2013 07:13 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
В Composita у них поддерживались сотни тысяч потоков - за счёт того, что компилятор как-то хитро "сшивает" потоки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Понедельник, 02 Сентябрь, 2013 21:25 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
Илья Ермаков писал(а):
В Composita у них поддерживались сотни тысяч потоков - за счёт того, что компилятор как-то хитро "сшивает" потоки.

Композита работает поверх A2, используя её "родные" потоки. Фактически это "метапрограммиронивание". Создаются новые сущность поверх существующих.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Понедельник, 02 Сентябрь, 2013 21:48 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Вообще, название темы довольно неграмотное. Точнее было бы её назвать - "нужна ли вытесняющая многозадачность?".

Вытесняющая многозадачность например совсем не нужна вот в этом случае:
Valery Solovey писал(а):
Один поток будет тормозить весь сервер, если он будет блокироваться на вводе-выводе (жёсткий диск, сеть, IPC, другие устройства).

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

Но представим что у нас не просто веб-сервер, у нас, скажем, сервер видеоконференций. (и пусть у него, чтобы пример был ярче, всего один процессор с одним ядром, так что многопоточность нам тут скорости не прибавит). Он не просто байтики перекладывает, но над полученными байтиками он производить сложные и длительные математические вычисления (кодирование/декодирование h264/h265, всякие фильтры и так далее). На очередную порцию байтиков может действительно уйти МНОГО времени - до одной секунды (ключевой кадр например). И, что важнее - прервать эту операцию на середине, и передать управление другому коду в случае кооперативной (не вытесняющей) многозадачности просто невозможно (если у нас математический код не спец. компилятором собран, который навтыкает счетчиков да yield'ов, тем самым СИЛЬНО (в 4-10 раз) снизив производительность на современном x86 (из за условных переходов предсказатель переходов начнет ошибаться)). Следовательно вызов такой вот математики - блокирующий. А мы не имеем права уходить в себя на целую секунду - jitter buffer обычно настроен на 200ms максимум, нельзя чтобы другие клиенты страдали. У нас реалтайм. Поэтому в этом классе задач вытесняющая многозадачность нужна.

Теперь вопрос в том - потоки, или процессы? Увы, но множество процессов тоже не годится - объем передаваемых данных велик, поэтому накладные расходы на IPC будут слишком велики (причем как на передачу данных так и на примитивы синхронизации). Плодить по процессу на каждую конференцию или на каждого клиента - также слишком затратно.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Понедельник, 02 Сентябрь, 2013 21:52 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Но, судя по комментариям, большинству в этой теме многопоточность действительно не нужна :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 05:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Если учесть тенденцию к применению спец. вычислителей типа GPU... То я таки бы оформлял такую обработку как отдельную службу - и пусть она там, чего хочет, делает - либо многопоточно эти данные перемалывает, либо скидывает на внешние спец. вычислители...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 06:20 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Если учесть тенденцию к применению спец. вычислителей типа GPU... То я таки бы оформлял такую обработку как отдельную службу - и пусть она там, чего хочет, делает - либо многопоточно эти данные перемалывает, либо скидывает на внешние спец. вычислители...


Во-первых GPU далеко не во всех задачах применимы в принципе. А целесообразно применять GPU еще в меньшем классе задач.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 06:28 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Никто не запрещает использовать разделяемый двоичный кусок памяти - буферы данных и проч.
Кроме memory-mapping, можно и просто засадить два и более экземпляров Оберон-рантайма в один процесс.
Речь про то, что каждый рантайм - однопоточный и не заморачивается тем, что во время сборки мусора кто-то ещё шарится по объектам языкового уровня ))
И программист не заморачивается тем, что каждый метод может быть вызван конкурентно...
А с разделяемыми двоичными данными никаких проблем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 06:34 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 575
Откуда: Россия, Санкт-Петербург
А теперь представим, что один поток завис при расчёте кадра. В случае вытесняющей многозадачности мы "потеряем" одного клиента, а в случае не вытесняющей - "ляжет" сервер.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 06:41 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Так завис поток? Или кооперативный актор? Выше я же описал конструкцию вполне многопоточную, только каждому потоку - изолированное объектное пространство.

В рамках однопоточной же модели делается отдельный служебный поток, который контролирует лимит времени каждому актору, при перерасходе - делает исключение (в ББ такой поток реагирует на Ctrl-Break, но ничто не мешает его научить другой логике). Watchdog, короче.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 06:42 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Никто не запрещает использовать разделяемый двоичный кусок памяти - буферы данных и проч.
Кроме memory-mapping, можно и просто засадить два и более экземпляров Оберон-рантайма в один процесс.
Речь про то, что каждый рантайм - однопоточный и не заморачивается тем, что во время сборки мусора кто-то ещё шарится по объектам языкового уровня ))
И программист не заморачивается тем, что каждый метод может быть вызван конкурентно...
А с разделяемыми двоичными данными никаких проблем.

Еще раз - передача данных между двумя процессами, даже через shared memmory, работает медленней чем внутри процесса между потоками. Примитивы синхронизации между двумя процессами также сложнее и тормознее чем между двумя потоками в одном процессе.

Я не спорю что для ББ (в том состоянии в котором он сейчас) это решение (в нескольких процессах) было бы наиболее приемлемым (а тормоза из за разных процессов играли бы роль не сильно заметную на фоне общей тормознутости генерируемого компилятором ББ кода), но не нужно доказывать что это решение оптимально для всех других инструментов и ЯП. Это просто не так. Мы пробовали.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 06:50 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А ты вкурил тот вариант, который я тебе выше предложил?
N ядер Оберона в одном процессе ОС. И имей сколько угодно общей памяти, вне-языково-управляемой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Один поток или много?
СообщениеДобавлено: Вторник, 03 Сентябрь, 2013 07:02 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
А ты вкурил тот вариант, который я тебе выше предложил?
N ядер Оберона в одном процессе ОС. И имей сколько угодно общей памяти, вне-языково-управляемой.

Этот момент я упустил, да. Много рантаймов внутри одного процесса - это, пожалуй, хорошее решение (по крайней мере я не вижу особых проблем там прямо сейчас).

Как предлагаешь между ними передавать жиррные бинари? Также как это делается между легковесными потоками в erlang'e? (то есть вопрос о том, кто владеет данным вот куском памяти и кто ответственнен за его убиение, сборщик мусора тут не слишком годится, зато хорошо подходит счетчик ссылок, именно так в erlang'e и сделано).

Хотя, если у нас это "буфер обмена" между рантаймами на постоянной основе для конкретной задачи, то он может создаваться и убиваться явным образом в момент запуска и останова системы. То есть в этом случае, если не пытаться обобщить задачу, а решать конкретную, то решение будет значительно проще и, видимо, эффективнее.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB