Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 42925
Форкнул отдельно тему с coroutines 21708273
18 окт 18, 22:01    [21708275]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6384
Немного вернемся к этому.
полудух
4. stackfull корутины без ниток (fibers) дают ~30k rps на поток;

Откуда цифра?

Потому что у меня например на порядок выше на простой виртуалке - 350 Krps.
Тест кейс - одна корутина передает другой сообщение в 32 байта через io_service (Asio) и принимает обратно ответ. Следующее сообщение посылается после получения ответа. Все в одном потоке.

При этом я вижу что при передаче HTTP между двумя процессами (в одном потоке на процесс) действительно 30 Кrps, но из предудущего теста видно что это не лимит корутин, как следует из вашего сообщения. Просто на данной комбинации софта и харда получается такая скорость обработки HTTP (аллокации, IPC, TCP и другие оверхеды).
19 окт 18, 14:17    [21709150]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
цифра из тех видео, что в том же посте, и следующее за ним. Там в каждом вроде свои тесты есть
где взять кошерный, самый честный/чистый/профессиональный тест между C++ и Haskell/Erlang я не знаю (
прямо чтобы профи со знанием дела одно и то же потестили
19 окт 18, 14:38    [21709196]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
anyway, coroutines + fibers + future это самое быстрое соотношение скорости и лёгкости кода
быстрее только опускаться ниже этих абстракций, но прирост будет всего %10
это очень быстрое решение для сотен тысяч и даже миллионов rps
у вас 350к на 1 поток?
19 окт 18, 14:43    [21709202]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6384
полудух
у вас 350к на 1 поток?

Ну да, я же выше написал условия теста.
19 окт 18, 15:11    [21709243]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
хм, вы там случайно Nginx не обогнали?
19 окт 18, 15:58    [21709302]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6384
полудух
хм, вы там случайно Nginx не обогнали?

А причем здесь nginx?
350krps - это просто передача небольших массивов байтов туда сюда без какой либо обработки.

А вот HTTP у нас намного медленнее приведенных результатов nginx. 30krps в одном потоке и до 700 Кrps на 40 ядрах (c HT) . У nginx чуть больше 2 Mrps для такого же кол. ядер, судя по вашей ссылке. Разница - 3х.
Да, корутины и всякие С++ вкусности имеют свою цену
19 окт 18, 17:25    [21709385]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6384
Ну а в том синтетическом тесте в 40 потоков конечно обошли nginx - 12 Mrps
Жалко что это не HTTP
19 окт 18, 17:30    [21709390]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6384
полудух,

Кстати, я посмотрел видос от David Sackstein, и из него не следует что нити (fiber) быстрее чем корутины.
Потому что внутри это одно и то же - и там и там - переключение стека через Context.
В видосе сравниваются только потоки с нитями, а не нити с корутинами.

Откуда у вас взялась цифра 30Krps так и не понятно.
19 окт 18, 18:30    [21709431]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
ну 30к рпс это именно про HTTP, насколько я помню
а откуда именно уже не помню
и кто там и как тестил это тоже вопрос...
по мне так это мало.

нитки кооперируются с корутинами. Он же вот что говорил:
автор
# FIBERS
Логический поток выполнения. И ему нужен Scheduler (планировщик потоков выполнения).
* A fiber is a userland thread - a thread of execution that is scheduled cooperatively (main difference between fiber and thread).
* The library is organized as coroutines + manager + scheduler.
* Each fiber has its own stack.
* Like Boost Coroutine the library uses Boost Context to allocate and switch between stacks.
* Tou can choose the stack allocation strategy. The default is fixed size. The size itself is configurable.
# fibers vs threads
* At most one fiber on a thread can be running;
* Therefore a fiber does not need to protect resources from other fibers running on the same thread;
* However, if a fiber on another thread access the resource - protection is required;
* Spawning fibers does not distribute your computation across more hardware cores;
* But fibers do help you manage the division between working and waiting on a thread.
# manager
* A fiber can be in the running, suspended or ready state;
* The running fiber can call the manager to yield or suspend itself:
- when a fiber yields it moves to the ready state; // yield = оставить тред и заниматься своими делами, пока он не даст сигнал. Тогда сделать resume.
- when a fiber suspend it moves to a suspended state;
* In both cases the manager uses a scheduling algorithm to select another ready fiber to run;
* The manager performs a context switch to the selected fiber;
* If there were no ready fibers, manager blocks the thread;
* Context switching is direct, the manager runs on the source fiber.
# Scheduler Algorithm (46:35):
* There is one scheduler algorithm for all fibers in a thread;
* The scheduler's responsibility is to pick one of the ready fibers that should to run;
* The default is a round-robin scheduler among the ready fibers on the thread;
* So, by default a fiber will always be resumed on the thread where it was created;
* A blocked fiber can hovewer be awoken by another thread.
* The scheduling algorithm is an extension point. You can also implement and install your own.
* You can also install others provided by the library for instance:
- shared_work: ready fibers from all threads are treated equally;
- work_stealing: local ready fibers are selected if any, otherwise a fiber is stolen from another scheduler.
* Note that these algorithms migrate fibers between threads which requires care in protecting shared resources.

# Fiber Suspension
* A fiber can yield itself or it can suspend itself (a.k.a. block) in a number of ways:
- it can request to sleep (until a time or for a specified duration);
- use fiber synchronization objects that are defined in the library (mutexes, conditional variables and so on).
* The semantic of the synchronization object are similar to those in the std::thread library, however:
- the fiber types suspend only the current fiber. They do not block the thread (unless there are no other fibers to run).


есть ещё такое видео:

автор
разница между threads & fibers + coroutines:
- читаемость у фиберов, как у синхронного кода;
- производительность, как у Асинхронного кода;
- (-) потребовалось написать "кусочек ОС" - свой планировщик, его надо поддерживать, отлаживать, итд;
- (+) переключение контекста стоит 50-100нс (это на 2 порядка быстрее, чем переключить поточный контекст (нитей исполнения);
если системное время - 10%, то в секунду не более 10-20М переключений потоков, что в 100-500 раз больше (производительней), чем переключений в ядро.
Соот-но, если в вашем коде очень маленькие фрагменты полезной логики и время их выполнения сопоставимо со временем переключения контекста, тогда вы сможете оптимизировать своё приложение за счёт того, что вы будете явно у себя управлять многозадачностью. Именно поэтому все сетевые вещи, типа веб-серверов и прочие строятся, как асинхронный код, потому что там действий по существу очень мало, там надо перекладывать байтики из одной корзины в другую и более-менее ничего больше не делать. Там нет никаких симуляций, сложных интегрирований и т.д., там процессор, в основном, простаивает. Поэтому мы можем срезать накладные расходы на ... (взаимодействие?) с ядром, чуть больше делая ... (?) и чуть меньше платя за перекл-е контекста.


и ещё
19 окт 18, 19:13    [21709478]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Addx
Member

Откуда:
Сообщений: 957
полудух
"Основная проблема многопоточности" в следующем:
Компьютер выполняет только ОДНУ программу за раз. Точка. (конечный автомат)

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

полудух
Программа может быть ЗАГРУЖЕНА В ПАМЯТЬ параллельно с другой, но выполняться будет только одна.


Даже команды одного потока могут исполняться параллельно. Спекулятивное исполнение называется.
Что уж говорить о процессах, которые иногда не просто исполняются параллельно, а и аппаратные ресурсы (память, диск, видеокарта) используют также параллельно.

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

В наши дни программы имеют сотни и тысячи инструкций, что нагружает то самое "бутылочное горлышко" в процессоре - блок разбора инструкций, куда они попадают в первую очередь.
И чтобы компьютер не простаивал, а был занят делом постоянно, нужно держать в памяти более 1й программы (этим уже занимается ОС). Тут встаёт вопрос об эффективном распределении ресурсов.
Потом появилась идея "а почему бы нам не воткнуть более 1го процессора в систему?" - и вот отсюда пошли проблемы с параллельным программированием (параллелизмом)...
У всех процессоров одно и тоже адресное пространство, что означает: каждый процессор может получить доступ к любому биту памяти. Т.е. память ПОЛНОСТЬЮ доступна всем процессорам одинаково.
Отсюда растут ноги у всех видов overheads и bottlenecks - попытки решить эти проблемы с эффективным управлением этими процессорами.

А самый п....ц наступает при слове "threads". Несколько потоков внутри одного процесса с пересекающимися адресными пространствами (читай: могут править одну и ту же память)...
И что тогда делать с планированием? Потоки могут одновременно получить доступ к любому биту, к любой глобальной переменной и как они там будут себя вести - сотрудничать или нет - неизвестно.
А ещё потоки они тяжёлые и ими сложно рулить = много не наделаешь.
Потоки были представлены, в первую очередь, чтобы эффективно юзать мульти-процессорные системы. Но при этом забыли полностью переосмыслить всю проблему, и это её только усугубило.
Расшаривание адресного пространства между процессами это попытка расширить UNIX-модель для решения проблемы.

"If you have to write programms which take advantage of parallelism this is where most of the mistakes are made."
Очень много нюансов надо держать в голове и поэтому легко наделать ошибок.
И ещё больше гемора вылезает, если система real-time. Потому что надо лочить процессы и потоки, разбираться с приоритетами, итд.
А ещё очень сложно дебажить многопоточные программы, в особенности потому, что нельзя получить полной точной репликации пройденного программой пути от одного запуска до другого, потому что они всегда движутся, как timing differences... Короче нет тулзов, чтобы это отследить. Единственное, что можно сделать, это запускать программу в постоянном debug-mode, что есть оверхед.
И ничего не поделаешь с этим. Можно только признать недостатки этой модели и придумать другую...


У Вас сплошная путаница. Перемешаны вопросы архитектуры железа, ОС, алгоритмов.
В процессоре нет "бутылочных горлышек". Есть менее используемые блоки, есть более.
Например блок работы с AVX инструкциями обычно "менее загружен".
К любому биту получить доступ нельзя, есть защита памяти. Аппаратная, кстати, дополнительных ресурсов на проверки выделять не нужно. Каждому процессу доступна только своя память. Внутри же процесса проблема "thread safe" решается стандартными способами, не нужно изобретать велосипеды.
Активно взаимодействующие потоки даже на разных ядрах общаются через очень быстрый кэш, не залезая в память, абсолютно прозрачно для них.
А конкретная реализация потоков - это не проблема компьютера или процессора, это проблема ОС. И в целом она вполне справляется. Не во всех сценариях, но все же.

полудух
В общем армии локов это ПЛОХО. Локи это очень ПЛОХО. Гемор это ПЛОХО. И с т.з. ОС локи тоже ПЛОХО, потому что интерфейс, который мы юзаем, это просто набор примитивов, которые не несут сильно много информации для ОС о том, а для чего этот лок. Они никогда не были спроектированы под программы для конечного юзера, они есть низкоуровневые примитивы.


С т.з. ОС сами локи - не ее проблемы. ОС все равно, для чего этот лок, ее задача обеспечить, а не угадать.

полудух
Так что в unix-based-системах бОльшую часть времени мы откатываем назад к pthread -интерфейсам (pthread_mutex) и там старые механизмы, и они конечно не лучше.
Единственная вещь, которая передаётся с помощью mutex это WORD, который из потока ожидает на указанном локе. Can be attached to one specific action on which the threat is waiting.
Но тут опять человечек не сможет разгрести, т.к. придётся оперировать тысячами локов. Это просто невозможно.

fibers + coroutines + promises + future = решение всех проблем за 10% от скорости (которая нужна только Nginx & Co).


Часто локов можно избежать на архитектурном уровне при построении приложения. Я хотел сказать именно об этом.
А "решение всех проблем" - это, скажем так, слишком смелое заявление.
19 окт 18, 19:59    [21709508]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
Addx
У Вас сплошная путаница.

не у меня, а у человека, который пишет компиляторы и на ночь читает чертежи процессоров.
Ulrich Drepper зовут.
но у вас конечно аппаратура лучше

В процессоре нет "бутылочных горлышек".

есть.
помимо блока инструкций, ещё например кэш
сегодняшние процессоры по скорости ~ такие же, как были в 80е годы
всё решает кэш.
19 окт 18, 20:38    [21709534]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6384
полудух
не у меня, а у человека, который пишет компиляторы и на ночь читает чертежи процессоров.
Ulrich Drepper зовут.

Ну, он еще PulseAudio создал. А это большой минус в карму ))
19 окт 18, 20:43    [21709538]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Addx
Member

Откуда:
Сообщений: 957
полудух
не у меня, а у человека, который пишет компиляторы и на ночь читает чертежи процессоров.
Ulrich Drepper зовут.
но у вас конечно аппаратура лучше


Всегда удивляли люди, которые говорят от имени других людей.

полудух

В процессоре нет "бутылочных горлышек".

есть.
помимо блока инструкций, ещё например кэш
сегодняшние процессоры по скорости ~ такие же, как были в 80е годы
всё решает кэш.


Бред сивой кобылы.
Нынешние процы даже на равной частоте рвут "процы 80х" как Тузик грелку.
И да, если считать кэш узким местом, то тогда уж лучше память считать таковым.
Да ладно память, лучше диск. )
22 окт 18, 12:29    [21710927]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
Addx
полудух
не у меня, а у человека, который пишет компиляторы и на ночь читает чертежи процессоров.
Ulrich Drepper зовут.
но у вас конечно аппаратура лучше


Всегда удивляли люди, которые говорят от имени других людей.

это лучше, чем нести ахинею от своего имени.
Внезапно всегда есть специалисты, которые лучше знают тему.

Нынешние процы даже на равной частоте рвут "процы 80х" как Тузик грелку.

благодаря кэшу.

И да, если считать кэш узким местом, то тогда уж лучше память считать таковым.
Да ладно память, лучше диск. )

уж лучше жевать, чем говорить. Вы даже не понимаете сути. Кэш узкое место, потому что его очень легко заполнить и тогда проц станет тормозить.
Диск тут рядом не стоял, как и память.
22 окт 18, 14:49    [21711138]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
clihlt
Member

Откуда: Донецк
Сообщений: 1123
полудух
Кэш узкое место, потому что его очень легко заполнить и тогда проц станет тормозить.


А кеш процессора бывает не заполненный?

Сообщение было отредактировано: 10 дек 18, 07:29
22 окт 18, 16:38    [21711364]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Anatoly Moskovsky
Member

Откуда: Odessa
Сообщений: 6384
clihlt
и почему вдруг процессор начнет тормозить если кеш полон?

Ну если программа написана левой ногой, то почему бы и нет
Но конечно не кэш узкое место, а внешняя память.
23 окт 18, 12:46    [21712202]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
clihlt
Да я ж спросил всего то ). В каких случаях кеш вообще бывает не заполненным (ну кроме старта проца) и почему вдруг процессор начнет тормозить если кеш полон?

любая программа это поток инструкций, которые помещаются в кэш, который находится внутри процессора и ему ничего не стоит в него сходить
ежели он заполнится, то инструкции будут помещаться уже во внешнюю память, до которой ему идти в десятки, а то и сотни раз дольше
такая же ситуация, как между памятью и диском (там в тысячи раз разница)
23 окт 18, 16:27    [21712501]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 42925
Давайте мысль подкину.

Каковы накладные расходы на сидение потока (pthread) в mutex?
23 окт 18, 18:25    [21712669]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Dima T
Member

Откуда:
Сообщений: 14096
полудух
clihlt
Да я ж спросил всего то ). В каких случаях кеш вообще бывает не заполненным (ну кроме старта проца) и почему вдруг процессор начнет тормозить если кеш полон?

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

С кэшированием кода все гораздо проще чем с кэшированием данных. Тут проблемы что данные тупо не влезли (по размеру) в кэш, и что данные меняются несколькими потоками (ядрами) одновременно, т.е. кэш ядра постоянно становится невалидным.
23 окт 18, 20:20    [21712768]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
ViPRos
Member

Откуда:
Сообщений: 9631
полудух
clihlt
Да я ж спросил всего то ). В каких случаях кеш вообще бывает не заполненным (ну кроме старта проца) и почему вдруг процессор начнет тормозить если кеш полон?

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

значит надо по уму помещать в кеш, а не всю х..ню
23 окт 18, 20:30    [21712773]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
mayton
Давайте мысль подкину.

Каковы накладные расходы на сидение потока (pthread) в mutex?

там где много корутин + fibers мьютексы не рекомендуются
23 окт 18, 21:00    [21712789]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 945
ViPRos
значит надо по уму помещать в кеш, а не всю х..ню

в асинхронном программировании так можно и двинуться умом
23 окт 18, 21:01    [21712792]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 42925
полудух
mayton
Давайте мысль подкину.

Каковы накладные расходы на сидение потока (pthread) в mutex?

там где много корутин + fibers мьютексы не рекомендуются

Чтобы обосновано продолжить судить классическую мультипоточность
нужно увидеть ее недостатки. Какие аргументы могут быть самыми убедительными?
- Сгорание в топке процессора мегафлопов которые расходуются не на полезную
работу.
23 окт 18, 21:02    [21712795]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
ViPRos
Member

Откуда:
Сообщений: 9631
полудух
ViPRos
значит надо по уму помещать в кеш, а не всю х..ню

в асинхронном программировании так можно и двинуться умом

нет проблемы "асинхронного программирования", есть проблема "синхронизации" процессов (задач, операций,...).
сейчас воще под "асинхронным" программированием стали подразумевать вызов подпрограмм ввода/вывода и запутали народ вконец
23 окт 18, 21:22    [21712806]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Программирование Ответить