OberonCore
https://forum.oberoncore.ru/

Один поток или много?
https://forum.oberoncore.ru/viewtopic.php?f=31&t=4475
Страница 1 из 2

Автор:  Alexey Veselovsky [ Пятница, 30 Август, 2013 13:54 ]
Заголовок сообщения:  Один поток или много?

(модератор) выделено из темы viewtopic.php?p=82087#p82087 согл. п. 3.3

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

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

Автор:  Илья Ермаков [ Пятница, 30 Август, 2013 16:09 ]
Заголовок сообщения:  Re: Красноярская сборка BlackBox 1.6rc6

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

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


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

Автор:  Info21 [ Пятница, 30 Август, 2013 19:05 ]
Заголовок сообщения:  Re: Красноярская сборка BlackBox 1.6rc6

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

Автор:  Valery Solovey [ Суббота, 31 Август, 2013 00:47 ]
Заголовок сообщения:  Re: Красноярская сборка BlackBox 1.6rc6

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

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

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

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

Автор:  Madzi [ Воскресенье, 01 Сентябрь, 2013 10:51 ]
Заголовок сообщения:  Re: Красноярская сборка BlackBox 1.6rc6

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

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

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

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

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

Автор:  Valery Solovey [ Воскресенье, 01 Сентябрь, 2013 21:41 ]
Заголовок сообщения:  Re: Один поток или много?

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

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

Автор:  Madzi [ Воскресенье, 01 Сентябрь, 2013 22:45 ]
Заголовок сообщения:  Re: Один поток или много?

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

Автор:  Valery Solovey [ Понедельник, 02 Сентябрь, 2013 01:21 ]
Заголовок сообщения:  Re: Один поток или много?

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

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

Автор:  Илья Ермаков [ Понедельник, 02 Сентябрь, 2013 07:13 ]
Заголовок сообщения:  Re: Один поток или много?

В Composita у них поддерживались сотни тысяч потоков - за счёт того, что компилятор как-то хитро "сшивает" потоки.

Автор:  Madzi [ Понедельник, 02 Сентябрь, 2013 21:25 ]
Заголовок сообщения:  Re: Один поток или много?

Илья Ермаков писал(а):
В Composita у них поддерживались сотни тысяч потоков - за счёт того, что компилятор как-то хитро "сшивает" потоки.

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

Автор:  Alexey Veselovsky [ Понедельник, 02 Сентябрь, 2013 21:48 ]
Заголовок сообщения:  Re: Один поток или много?

Вообще, название темы довольно неграмотное. Точнее было бы её назвать - "нужна ли вытесняющая многозадачность?".

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

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

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

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

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

Автор:  Alexey Veselovsky [ Понедельник, 02 Сентябрь, 2013 21:52 ]
Заголовок сообщения:  Re: Один поток или много?

Но, судя по комментариям, большинству в этой теме многопоточность действительно не нужна :-)

Автор:  Илья Ермаков [ Вторник, 03 Сентябрь, 2013 05:05 ]
Заголовок сообщения:  Re: Один поток или много?

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

Автор:  Alexey Veselovsky [ Вторник, 03 Сентябрь, 2013 06:20 ]
Заголовок сообщения:  Re: Один поток или много?

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


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

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

Автор:  Илья Ермаков [ Вторник, 03 Сентябрь, 2013 06:28 ]
Заголовок сообщения:  Re: Один поток или много?

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

Автор:  Madzi [ Вторник, 03 Сентябрь, 2013 06:34 ]
Заголовок сообщения:  Re: Один поток или много?

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

Автор:  Илья Ермаков [ Вторник, 03 Сентябрь, 2013 06:41 ]
Заголовок сообщения:  Re: Один поток или много?

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

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

Автор:  Alexey Veselovsky [ Вторник, 03 Сентябрь, 2013 06:42 ]
Заголовок сообщения:  Re: Один поток или много?

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

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

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

Автор:  Илья Ермаков [ Вторник, 03 Сентябрь, 2013 06:50 ]
Заголовок сообщения:  Re: Один поток или много?

А ты вкурил тот вариант, который я тебе выше предложил?
N ядер Оберона в одном процессе ОС. И имей сколько угодно общей памяти, вне-языково-управляемой.

Автор:  Alexey Veselovsky [ Вторник, 03 Сентябрь, 2013 07:02 ]
Заголовок сообщения:  Re: Один поток или много?

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

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

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

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

Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/