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

Откуда: loopback
Сообщений: 40512
Привет друзья.

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

Некоторые поинты:


1) Отказ от программирования потока Thread как от единицы параллелизма в бизнес приложениях. Предполагается что event-driven более эффектичен чем масоовые "сидения" потоков в "мониторах".
2) Использование асинхронного вызова (async-call, callable, future, promise) в тех случаях когда это возможно.
3) Пересмотр архитектуры Thread с использованием Fiber (пример project Loom). Кооперативность снова в деле. Continuations (под другим названием).
4) Использование актора (обычно в совокупности с очередями и легковесными потоками). (Akka). Неблокирующие операции. Дешевизна ресурсов. Один нативный поток ОС обслуживает сотни акторов.
5) Использование корутины (coroutines). Использование уступчивого return (yield) (C#,Python) для организации сложных итераторов и генераторов.
6) Функциональный подход в части декомпозиции циклов (for-while) в рекурсии (Erlang) где это (теоретически)
даёт возможность гибкого управления кооперативной мультипоточности.
7) Последние экономические тренды в области строительства ЦОД. Отказ от покупки крупных серверов и предпочтение
облаков. Микросервисы.
8) Специальные языки где асинхронный I/O выдвинут как feature (Node.JS). Языки - где корутина - фича. Go(goroutine).
9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).

Пруфы приводить не буду. Топик - просто является неким облаком тегов или смыслов которые я предлагаю обсудить.
Если я где-то ошибся - и классифицировал понятия не так - прошу прощения. Я также мог ошибится в связи ЯП и фич. Sorry.
Но надеюсь общий смысл будет ясен.

P.S. Убежден что поток как единица разработки совершенно необходим в вычислительных задачах с HighLoad-CPU
нагрузкой. Особенно где длительное время нет взаимодействия с внешним миром. Есть только взаимодействие АЛУ и memory
канала. Но такие задачи достаточно специфичны и в бизнес-приложениях их не много.

Какова будет мультипоточность в будущем?

Прошу ваши каменты.
12 окт 18, 22:26    [21703023]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Dima T
Member

Откуда:
Сообщений: 13634
mayton
Какова будет мультипоточность в будущем?

ИМХО все зависит от обертки, т.е. от API и синтаксического сахара для использования мультипоточности.

Например в виндовсе есть I/O Completion Ports со времен WinXP, но мало кто этим пользуется в чистом виде. Хотя штука более производительная чем классические подходы с пулами потоков.
Но стоило MS построить поверх библиотеку .Net классов с .xxxxAsync() методами, добавить async/await в C# и многие стали это использовать. Т.е. стало относительно просто писать многопоточный код.

Я думаю главное простота написания кода и максимально возможная защита от "выстрелов в ногу" неопытными разработчиками.

В остальном чудес не будет, все остальные проблемы упираются в отсутствие параллельных алгоритмов.
13 окт 18, 10:23    [21703190]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
вадя
Member

Откуда: Екатеринбург
Сообщений: 15547
mayton
Отказ от покупки крупных серверов и предпочтение
облаков. Микросервисы.
это модные тенденции. облака зависят от политики. микросервисы ....
мультипоточность нужна там где можно распараллелить работу. и там где есть физические возможности реализовать это. это было и будет определяющим.
14 окт 18, 14:50    [21703630]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38529
Dima T
Но стоило MS построить поверх библиотеку .Net классов с .xxxxAsync() методами, добавить async/await в C# и многие стали это использовать

+1
14 окт 18, 15:12    [21703637]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
SashaMercury
Member

Откуда: Москва
Сообщений: 2647
mayton
2) Использование асинхронного вызова (async-call, callable, future, promise) в тех случаях когда это возможно.

Похоже это уже сейчас(а может и вчера) везде и всюду. Мы используем, буквально несколько дней на одном из докладов тоже упоминали вскользь.

Мне кажется не будет ни в настоящем ни будущем единого хорошего подхода. Все как и сейчас будет опряделятся квалификацией и личным мнением команды, архитекторов, математиков. А может быть вообще ML будет этими вещами заниматься - не удивлюсь
14 окт 18, 18:57    [21703684]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6158
В каждом языке - взят свой подход (ну или несколько, но не все).

Осталось найти язык, в котором есть все варианты. Ну или реализованы библиотеками

Только надо составить точную классификацию подходов, чтобы удобно было ставить галочки
14 окт 18, 20:15    [21703710]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6158
Например так.

Открыто для редактирования
14 окт 18, 20:25    [21703714]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Dima T
Member

Откуда:
Сообщений: 13634
mayton
7) Последние экономические тренды в области строительства ЦОД. Отказ от покупки крупных серверов и предпочтение
облаков. Микросервисы.

Микросервисы тут не совсем в тему. Остальное это классический подход владельцев бизнеса к расходу денег: не стоит тратить сразу и много, если можно арендовать, даже если в итоге цена вопроса окажется в 1.5-2 раза выше, то это все-равно выгодно, т.к. проще платить по факту, т.е. операционные расходы, чем сразу потратить кучу денег на неопределенный срок, который может оказаться небольшим и потребуется новая куча.
14 окт 18, 20:29    [21703716]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
1. говоря об асинхронной многопоточности подразумеваем Linux/Unix;
2. C++ boost::asio включает в себя корутины, асинхронность и вообще всё что нужно. Но ещё есть boost::fibers и у неё тоже есть неплохие показатели;
3. корутины берут простоту синхронного подхода и нивелируют сложности асинхронного подхода, в итоге код становится мягким и шелковистым;
4. stackfull корутины без ниток (fibers) дают ~30k rps на поток;
5. локи (sync) не использует никто, годятся только для sync;
6. Go сливает C++;
7. C++ в многопоточности ноздря в ноздрю с Haskell (Haskell это боженька в многопоточности, там вообще 0 сложностей (со слов Ульриха));
8. есть вариант с подключением FPGA.

Есть такая вот табличка:
# СКОРОСТЬ (в микросекундах):
Haskell | stack-1.4.0/ghc-8.0.1 0.05-0.06
Go | go-1.8.1 0.42-0.49
Erlang | erts-8.3 0.63-0.73

Table 1.3. время на поток (10к+ (невозможно заспавнить 1кк потоков))
pthread 54-73
std::thread 52-73
std::async 106-122

Table 1.4. время на fiber (1кк+)
fiber (16C/32T, work stealing, tcmalloc) 0.05-0.09 // !!! future & promises, но тут есть нюансы - надо брать напильник (см.видео)...
fiber (1C/1T, round robin, tmalloc) 1.69-1.79

(почему эрланг в жопе - непонятно, видимо ему дали что-то считать... как он может сливать Go?! Erlang так то держит десятки и даже сотни лямов)

Там есть конфликт: Boost::fiber состоит из: coroutines + scheduler + manager. И этот manager конфликтует с Boost::Asio, т.к. там есть свой м-р.

оба эти парня ратуют за фьючи, а это что-то да значит...:




Асинхронная многопоточность нужна нам, чтобы победить IO (операции, которые требуют ожидания).
плохая идея - spin-лочить такие операции.
- Caller should not block the thread. If it does, an expensive context switch occurs.
- Instead we initiate the IO operation, install a callback and go and do something useful.
- When the operation completes the callback is invoked and we pick up where we were upon suspension.

# с коллбэками есть проблемки:
* Difficult to explain and to maintain
    - the business logic of the class is split up into disjoint functions;
    - state has to be stored and retrieved each time a callback is called;
* Error handling is difficult:
    - in particular exception cannot be used (because the stack in which it lives is not the same stack in which the original initiated function was invoked.
        So initiated function can no longer see that exception in the normal way);
        Но ежели код ок и есть тесты, то эксепшены как бы и нах.. не нужны (мой случай)...
* The proble requires inversion of control:
    - we would like the function and the callback to behave as they were in control.
15 окт 18, 02:40    [21703807]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542

# lvl0: блокирование и ожидание
понятность++; эффективность--; сложность = 0;
(через ОС. Годится для не очень нагруженных приложений)

# lvl1: неблокирующее ожидание (ad hoc)
понятность--; эффективность++; сложность++;
(если вы вдруг автор Nginx, то у вас тернистый путь, вам нужно явно работать с низкими уровнями,
писать этот сложный код, и если вы хотите максимально уменьшать накладные расходы, то вы срезаете
все абстракции, в частности не используете никакие Future & Promises)

# lvl2: абстракции +Futures / +Actors, и их можно более глубоко интегрировать в язык за счёт Coroutines
понятность++; эффективность++; сложность /= 10 (за счёт +к скорости разработки);
(Если вы пишете большую, сложную систему, которая дб производительна, но не требует быть вылизанной до идеала
и нам более важна скорость нашей разработки, тогда можно слегка пожертвовать производительностью и ускорить разработку.)
накладные расходы на создание/уничтожение: будет заметно, когда сотни тысяч задач. Если вы пишите просто и быстро с атомиками,
тогда вы будете синхронизироваться на памяти долго и дальше надо будет отдельно выделять доп.усилия, чтобы не было синхронизации по памяти,
это то что делают, например, ребята с цилодб, у них там под 1кк+ логических задач в сек изи.

# lvl3: реализация потоков в user-space
понятность++; сложность рантайма *= 2;


# ВЫБОР ИНСТРУМЕНТА ОПРЕДЕЛЯЕТСЯ ВАШИМИ КОМПЕТЕНЦИЯМИ И РЕШАЕМОЙ ЗАДАЧЕЙ[/b]
15 окт 18, 03:25    [21703808]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
полудух
4. stackfull корутины без ниток (fibers) дают ~30k rps на поток;

Непонятно. Что за 30k rps? 38 попугаев. 5 мартышек. ?

полудух
5. локи (sync) не использует никто, годятся только для sync;

Непонятно.

полудух
6. Go сливает C++;

Это может говорить от первого лица только разработчик который писал приложение на С++
потом переписал на Go и сделал свои выводы. Поэтому я-бы воздержался от прямых
утрверждений что кто-то что-то сливает.

полудух
7. C++ в многопоточности ноздря в ноздрю с Haskell (Haskell это боженька в многопоточности, там вообще 0 сложностей (со слов Ульриха));

Хотелось-бы посмотреть на пример "0 сложностей". Я давно для себя ищу "легкую" мультипоточность.


полудух
8. есть вариант с подключением FPGA.

Хеш тег FPGA в данном форуме может сократить аудиторию на парочку порядков. Давайте не будем
пока педалить эту тему. Слишком specific.
15 окт 18, 10:01    [21703881]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
mayton
полудух
4. stackfull корутины без ниток (fibers) дают ~30k rps на поток;

Непонятно. Что за 30k rps? 38 попугаев. 5 мартышек. ?

попугаев. на поток.

полудух
5. локи (sync) не использует никто, годятся только для sync;

Непонятно.

В async используют либо fibers + coroutines, либо просто stackfull coroutines (другие варианты хуже). Локи не используют, они в sync живут (lvl0 из последнего поста).

полудух
6. Go сливает C++;

Это может говорить от первого лица только разработчик который писал приложение на С++
потом переписал на Go и сделал свои выводы. Поэтому я-бы воздержался от прямых
утрверждений что кто-то что-то сливает.

где бы мы были, если бы не доверяли тестам... Ну можете сами всё написать и потестить.
Из того что писал я - Go хуже C++ во всех прогах.

полудух
7. C++ в многопоточности ноздря в ноздрю с Haskell (Haskell это боженька в многопоточности, там вообще 0 сложностей (со слов Ульриха));

Хотелось-бы посмотреть на пример "0 сложностей". Я давно для себя ищу "легкую" мультипоточность.

https://www.google.ru/search?q=haskell async example
Haskell изи и по коду, и по подводным камням.
Erlang такой же, в принципе, но у него чё-то там со счётами хреново... Я слышал, что например JSON конвертнуть дичайше не быстро в нём.
15 окт 18, 11:23    [21703945]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
полудух
mayton
пропущено...

Непонятно. Что за 30k rps? 38 попугаев. 5 мартышек. ?

попугаев. на поток.

Ну... я могу и не продолжать дальше. Сложно с вами разговаривать.
Я говорю - здрасте! Вы отвечаете - забор покрасте!

Зачем это делать?
15 окт 18, 12:12    [21704002]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
вот это поворот
то что я тут подробнейше разжёвываю со ссылками и пояснениями - мимо?
да вы зажрались!
сложно разговаривать?
ну и лесом вас.
15 окт 18, 12:26    [21704021]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Вы приаттачили графический материал который надо просмотреть и осмыслить. Я ещё не успел это сделать. Нужно время.

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

Откуда: 010100
Сообщений: 6158
mayton
Вы приаттачили графический материал который надо просмотреть и осмыслить. Я ещё не успел это сделать. Нужно время.

Но на мой первый вопрос вы ответили загадкой.

Скорее всего, удается создать 30к фиберов в секунду, каждый из которых отвечает на простой http запрос.

Конечно, поток сознания трудно расшифровывать - даже детей учат сначала называть предмет разговора.

полудух
(sync) не использует никто, годятся только для sync
это как бы вообще класс
15 окт 18, 13:39    [21704154]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47394
mayton
В настоящее время КМК идет переосмысление технологий разработки мультипоточных приложений.

Угу. До них таки дошло, что многопоточность это слишком сложно для мозга массового программиста. Поэтому возвращаются к суррогатам, которые попроще, не вызывают гонок и прочих артефактов.
15 окт 18, 13:53    [21704174]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
Siemargl
(sync) не использует никто, годятся только для sync
это как бы вообще класс

вообще-то программная модель, целая парадигма

mayton
Вы приаттачили графический материал который надо просмотреть и осмыслить. Я ещё не успел это сделать. Нужно время.

Но на мой первый вопрос вы ответили загадкой.

Ну так идите и осмысливайте, если для вас "30k rps" это загадка. Как я тут могу ещё помочь, если вы в теме по нулям.
Вам дали кучу инфы, сэкономили кучу времени, а вы нос воротите. Некрасиво настолько, что даже неожиданно.
Когда-то вы мне помогали разобраться с SQL, а теперь я вам изо всех сил пытаюсь помочь, но, как грится, - "для дальнейшего понимания ознакомьтесь с документацией".
15 окт 18, 15:35    [21704283]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
andreykaT
Member

Откуда:
Сообщений: 1983
Dimitry Sibiryakov
mayton
В настоящее время КМК идет переосмысление технологий разработки мультипоточных приложений.

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

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

на ассемблере тоже вполне можно написать вебсервис. но все пишут его явно на чем-то с более высоким уровнем абстракции. почему же многопоточка не должна получить свою абстракцию? должна. и получает. низкоуровневая многопоточка и должна и просто обязана помереть.
15 окт 18, 16:15    [21704324]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7607
В любом случае, алгоритм должен обеспечивать возможность эту самую многопоточность заюзать

Какой бы продвинутый язык не был, боюсь сортировку пузырьком он многопоточно на этапе компиляции сделать не сможет ===> нужно использовать другие алгоритмы

А многозадачность на уровне HTTP Server или HTTP Proxy давно уже разрешена и, конечно, интересно запилить свой HTTP MPP Server орабатывающий одновременно over 100 тысяч запросов - но кому это надо?

Даже с производительность (latency) сетевого IO, все сильно не просто. Например, в Windows, планировщик при RSS, по описанию, должен пытаться конкретные "IO сессии"/"потоки" привязать к своему ядру. Что бы interrupt'ы сразу шли на ядро с прогретым кэшем. А он поймет все эти "новомодные" Akka / Haskel'ы? Или получиться "как всегда", планировщик будет процессы к ядрам "привязывать", а Akka / Haskel'ы специально "отвязывать". Один алгоритм (RSS) масло на бутерброде пытается кучкой собрать, а другой тонко размазать (легкие потоки).... При этом подходе, о производительности и low latency - даже говорить не придется. Только ассемблер, только hardcore ))) На чем, как я понимаю, специализированное железо и выживает. Т.к. скопипастить чипы/технологии типа Infiniband и обозвать Ethernet 10 G - много китайского ума не надо.... но latency, в результате, на порядки (сотни) раз будет отличаться... хотя чипы, фактически "често спизженные" AFAIK

Взять например Java NIO. Вроде, по описанию, должно быть "быстрее". А в реальности, и по Интернетам, имеем 10-30% падение производительности по сравнению с обычными Socket'ами. Да... экономим thread'ы... т.ч. если thread'ов не хватает, то нужно NIO. Но вот "быстрее" (в обработки latency одного задания) оно никак не получается (((
15 окт 18, 16:57    [21704359]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Addx
Member

Откуда:
Сообщений: 957
mayton
Привет друзья.

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

Некоторые поинты:


1) Отказ от программирования потока Thread как от единицы параллелизма в бизнес приложениях. Предполагается что event-driven более эффектичен чем масоовые "сидения" потоков в "мониторах".
2) Использование асинхронного вызова (async-call, callable, future, promise) в тех случаях когда это возможно.
3) Пересмотр архитектуры Thread с использованием Fiber (пример project Loom). Кооперативность снова в деле. Continuations (под другим названием).
4) Использование актора (обычно в совокупности с очередями и легковесными потоками). (Akka). Неблокирующие операции. Дешевизна ресурсов. Один нативный поток ОС обслуживает сотни акторов.
5) Использование корутины (coroutines). Использование уступчивого return (yield) (C#,Python) для организации сложных итераторов и генераторов.
6) Функциональный подход в части декомпозиции циклов (for-while) в рекурсии (Erlang) где это (теоретически)
даёт возможность гибкого управления кооперативной мультипоточности.
7) Последние экономические тренды в области строительства ЦОД. Отказ от покупки крупных серверов и предпочтение
облаков. Микросервисы.
8) Специальные языки где асинхронный I/O выдвинут как feature (Node.JS). Языки - где корутина - фича. Go(goroutine).
9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).

Пруфы приводить не буду. Топик - просто является неким облаком тегов или смыслов которые я предлагаю обсудить.
Если я где-то ошибся - и классифицировал понятия не так - прошу прощения. Я также мог ошибится в связи ЯП и фич. Sorry.
Но надеюсь общий смысл будет ясен.

P.S. Убежден что поток как единица разработки совершенно необходим в вычислительных задачах с HighLoad-CPU
нагрузкой. Особенно где длительное время нет взаимодействия с внешним миром. Есть только взаимодействие АЛУ и memory
канала. Но такие задачи достаточно специфичны и в бизнес-приложениях их не много.

Какова будет мультипоточность в будущем?

Прошу ваши каменты.


ИМХО, вопросы производительности и оптимизации часто встают не там, где это нужно.
Люди читают о том, как решить проблему 100500+ rps, а по факту у них там и нагрузки-то такой нет.
А есть совсем в других местах.
Но делаем тут, потому как у Google была тут проблема и они ее решили так.
Или доклад с конференции прочитали.
К вопросу о "С++ быстрее" и прочих "давай померяемся".
Это интересно и важно, но есть два фактора:
1. в 95% приложений абсолютно не нужно. Нет, если вы графический движок, или универсальный сервер пишете ...
2. На производительность часто влияют другие факторы. Реальный код не висит в воздухе, как тесты и примеры.
3. Цифры 5-10-15% вообще ни о чем для не глубоко системного ПО. Завтра оптимизируют компилятор/библиотеки/процессор и будет все наоборот.
Основная проблема многопоточности - это зависимости и блокировки. Ошибки (не только баги, но и просчеты в архитектуре) тут очень дороги, а ловить их сложнее. Поэтому ставится задача как-то упростить многопоточные неблокируемые операции, встроить в язык.
Я не исключаю, что определенная реализация сложной многопоточности появится в железе с соответствующей поддержкой в языках.
Уже сейчас есть НТ, AVX, OpenCL, но они сильно специализированы.
15 окт 18, 20:02    [21704490]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
полудух
2. C++ boost::asio включает в себя корутины, асинхронность и вообще всё что нужно. Но ещё есть boost::fibers и у неё тоже есть неплохие показатели;
3. корутины берут простоту синхронного подхода и нивелируют сложности асинхронного подхода, в итоге код становится мягким и шелковистым;

Был топик географии 17384728, где мне понадобилось реализовать Кривую Гилберта.
Она реализована как утилита но мне нужен был некий строительный шаблон набодобие
Iterator<Point> который по запросу next() выдает следующую координату кривой. Классический
алгоритм кривой - рекурсивен. Рекурсия внутри итератора - тот еще головняк. Разваливать его в FSM
со стеком мне не хотелось. Нудно да и ошибок можно наделать кучу. А реализация - вот она. Почти работает.
После этого у меня появился еще один мотиватор чтобы реализовать красивый строительный элемент.
15 окт 18, 21:28    [21704547]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6158
Addx,

подозреваю, что высокоуровневыми абстракциями все проблемы не заткнешь - но стоит пробовать

что то нет желающих позаполнять конкретикой мою табличку 21703714
15 окт 18, 21:28    [21704548]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Dimitry Sibiryakov
mayton
В настоящее время КМК идет переосмысление технологий разработки мультипоточных приложений.

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

Наверное дошло когда был замерян % времени который потоки тратят на синхронизацию
по отношению к полезной работе.
15 окт 18, 21:30    [21704552]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
Siemargl
что то нет желающих позаполнять конкретикой мою табличку 21703714

а что там заполнять? поставьте жирную галку в C++ fibers и всё
16 окт 18, 00:26    [21704633]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
hVostt
Member

Откуда:
Сообщений: 15325
Исходить надо из задач, условий, ресурсов. Мультипоточность зачем вообще может быть нужна? Считать? Давно уже. Обрабатывать пользовательские запросы? Другое дело, вот тут был затык, пока не подстуетились разработчики языков, инструментов и компиляторов.

Разрабы алгоритмов таки, урааа, обрадовались! Теперь у нас фсё будет, и корутины и асинки и прочая дребедень. И вернулись к сям
16 окт 18, 00:53    [21704642]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
Addx
Основная проблема многопоточности - это зависимости и блокировки. Ошибки (не только баги, но и просчеты в архитектуре) тут очень дороги, а ловить их сложнее. Поэтому ставится задача как-то упростить многопоточные неблокируемые операции, встроить в язык.
Я не исключаю, что определенная реализация сложной многопоточности появится в железе с соответствующей поддержкой в языках.
Уже сейчас есть НТ, AVX, OpenCL, но они сильно специализированы.

"Основная проблема многопоточности" в следующем:
Компьютер выполняет только ОДНУ программу за раз. Точка. (конечный автомат)
Программа может быть ЗАГРУЖЕНА В ПАМЯТЬ параллельно с другой, но выполняться будет только одна.
Можно переключаться между ними, но тогда это роняет безопасность, т.к. никакой защиты нету.

В наши дни программы имеют сотни и тысячи инструкций, что нагружает то самое "бутылочное горлышко" в процессоре - блок разбора инструкций, куда они попадают в первую очередь.
И чтобы компьютер не простаивал, а был занят делом постоянно, нужно держать в памяти более 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, что есть оверхед.
И ничего не поделаешь с этим. Можно только признать недостатки этой модели и придумать другую...

В общем армии локов это ПЛОХО. Локи это очень ПЛОХО. Гемор это ПЛОХО. И с т.з. ОС локи тоже ПЛОХО, потому что интерфейс, который мы юзаем, это просто набор примитивов, которые не несут сильно много информации для ОС о том, а для чего этот лок. Они никогда не были спроектированы под программы для конечного юзера, они есть низкоуровневые примитивы.
Так что в 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).
16 окт 18, 01:04    [21704645]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
Haskell vs C++
Go vs C++
16 окт 18, 08:31    [21704728]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
andreykaT
Member

Откуда:
Сообщений: 1983
локи может и плохо но есть мнение, что алгоритмы на локах построить заметно проще, чем лок-фри решения.
16 окт 18, 12:58    [21705097]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7607
hVostt
...Обрабатывать пользовательские запросы? Другое дело, вот тут был затык, пока не подстуетились разработчики языков, инструментов и компиляторов.

Тупые Java Servlets, там часто встретишь sincronize ? - нет
Но обрабатывать множество пользовательских запросов - это нисколько не мешает. Поол worker'ов на уровне Apache Tomcat или другого app server'а.

СУБД - аналогично. Разошлись по пользователям и 95% времени живем счастливо (желание многозадачности только при батч расчетах может возникнуть 1-2 раза в месяц).

Для бизнес-программиста (OeBS,FoxPro,PB,MS Access etc), thread и прочая многозадачность, в 99 % случаях не нужна. Поэтому когда приходишь устраиваться на работу, дикларируется что команда собирается писать __учетный софт__ для учета сертификатов сваршиков, а требования: threads, blockchain.... Блин... Это не IT, это чистая наука. Удовлетворения своего любобытства за чужой счет. В классической науке - за счет государства, в таких "проектах" - за счет заказчика.

IMHO & AFAIK
16 окт 18, 13:19    [21705158]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
exp98
Member

Откуда:
Сообщений: 1624
полудух,
У меня 4-х ядерный комп, что дома что на службе. Если запускаю долгий макрос в эселе, то грузится 25% проца. Смотрю в диспетчере - работают преимущественно 1-2 ядра. Чессгря, не знаю мож и одна только команда способна выполниться одномоментно, а мож и нет.
Только, когда я работал не на персоналках, у нас были по-настоящему многопроцессорные компы, полностью синхронные, с неск арифметиками и неск доступами в память (правда не к одному адресу).
А сложность лично я вижу не только вблокировках и т.п., а в теории,т.е. в синхронизации точек ветвления алгоритма, особенно для одной задачи, если её распараллеливать. Точки ветвления - большая теоретическая проблема.
16 окт 18, 13:36    [21705188]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
exp98
Member

Откуда:
Сообщений: 1624
Вот это отмечу как полезный приём.
полудух
Асинхронная многопоточность нужна нам, чтобы победить IO (операции, которые требуют ожидания)
16 окт 18, 13:46    [21705203]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7607
exp98
Вот это отмечу как полезный приём.
полудух
Асинхронная многопоточность нужна нам, чтобы победить IO (операции, которые требуют ожидания)

Не все так однозначно ( C ) Дочь офицера

В low-latency IO даже на аппаратном уровне __уходят__ от прерываний (аппаратный аналог асинхронности). Т.ч. latency - слишком большое и ассинхроность сильно дорого (например параметр interrupt moderation у сетевых карт).

У Intel команада open source пытается для Ethernet card востановить/допилить старые драйвера от FreeBSD с целью получить low latency. Без прерываний, просто тупой пулинг (цикл: while (true) { проверить_карту; обработать_пакет; } )

Про то, что NIO на практике 10-30 % (скорее 10) медленнее старых Socket'ов - уже приводил. А 10% не так уж и мало.

К тому же, если расматривать комплекс проблем целиком, то сейчас все High Performance сервера - NUMA. "Побеждать IO" за счет "в 2-3 раза затормозить/убить RAM" - как-то на мой взгляд сильно накладно.

С той же самой NIO, была проблема, что на __реальном__ сервере (NUMA, 2 CPU, 40 cores), от патерна нагрузки NIO + Java менеджеру потоков в Linux голову снесло. Перевод проекта Socket --> NIO привел к увеличению в 3-4 __раза__ потребления CPU. Вылечилось уменьшением кол-ва потоков для java GC и java JIT через командную строчку.
16 окт 18, 14:06    [21705229]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47394
mayton
Наверное дошло когда был замерян % времени который потоки тратят на синхронизацию
по отношению к полезной работе.

Но вместо того, чтобы рихтовать руки разработчикам, втыкающим синхронизацию туда куда не нужно, решили отказаться от многопоточности. Логично, это же путь наименьшего сопротивления.
16 окт 18, 14:07    [21705232]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9133
Leonid Kudryavtsev
В low-latency IO даже на аппаратном уровне __уходят__ от прерываний (аппаратный аналог асинхронности). Т.ч. latency - слишком большое и ассинхроность сильно дорого (например параметр interrupt moderation у сетевых карт).
Когда эта проблема возникла впервые - были времена пень-три.
Для них, да: максимальная частота прерываний от стомегабитного езернета - "немножко множко" и выделить отдельный процессор SMP-железки для работы в режиме опроса будет дешевле.

Ну дык, для гигабитного езернета эту проблему решили на протокольном уровне (burst-mode) - можно передать и принять пачку езернет-кадров "на одном дыхании".
Процессоры, опять-таки, и частоты повысили и задержки уменьшили.

Но тут подоспел Ethernet 10/40/100G и проблема возникла снова. Даже для быстрых процессоров.

Это всё тот же характерный пример: решаем проблему, которая нас вообще не касается.

P.S.
Посмотрел гитхаб с асинхронной обработкой http-запроса в хаскеле и так и не понял, почему эта кучка кода проще двух строчек асинхронных ява-сервлетов.
16 окт 18, 17:24    [21705605]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
exp98
полудух,
У меня 4-х ядерный комп, что дома что на службе. Если запускаю долгий макрос в эселе, то грузится 25% проца. Смотрю в диспетчере - работают преимущественно 1-2 ядра. Чессгря, не знаю мож и одна только команда способна выполниться одномоментно, а мож и нет.
Только, когда я работал не на персоналках, у нас были по-настоящему многопроцессорные компы, полностью синхронные, с неск арифметиками и неск доступами в память (правда не к одному адресу).

ну так:
полудух
1. говоря об асинхронной многопоточности подразумеваем Linux/Unix;

microsoft же - синоним "как из мухи сделать 50-этажного слона"
автор
Предыдущий оратор, который убеждал нас пользоваться библиотекой Microsoft Foundation Class (MFC), сказал нам, что поддержка OLE в MFC "включает 20000 строк кода, _необходимых_ для
каждого базового приложения OLE 2.0". Аудитория была ошеломлена не полезностью MFC, а тем фактом, что для написания базового приложения OLE 2.0 требуется 20000 строк кода.
16 окт 18, 19:28    [21705787]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
Basil A. Sidorov
P.S.
Посмотрел гитхаб с асинхронной обработкой http-запроса в хаскеле и так и не понял, почему эта кучка кода проще двух строчек асинхронных ява-сервлетов.

зацените, как ява любит память...
16 окт 18, 19:33    [21705792]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6158
Basil A. Sidorov,

Не забывай про свой процессор в сетевой и райде - именно они обрабатывают прерывания. на основной проц это не ложится

полудух
полудух
1. говоря об асинхронной многопоточности подразумеваем Linux/Unix;

microsoft же - синоним "как из мухи сделать 50-этажного слона"
автор
Предыдущий оратор, который убеждал нас пользоваться библиотекой Microsoft Foundation Class (MFC), сказал нам, что поддержка OLE в MFC "включает 20000 строк кода, _необходимых_ для
каждого базового приложения OLE 2.0". Аудитория была ошеломлена не полезностью MFC, а тем фактом, что для написания базового приложения OLE 2.0 требуется 20000 строк кода.

Кстати, в Линухе что, появился асинхронный в/в к блок девайсам? В Вин есть.

И ты цитируешь как бы не 20-летнюю проблему. Сейчас 20000 строк в стандартной библиотеке явы или буста - пшик.
16 окт 18, 19:51    [21705803]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9133
полудух
зацените, как ява любит память...
В первой строчке она любит её меньше, чем це-с-крестами.
В остальных - больше, но вопрос остаётся прежним: какую проблему решаем?
16 окт 18, 20:37    [21705832]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 9133
Siemargl
Не забывай про свой процессор в сетевой и райде - именно они обрабатывают прерывания. на основной проц это не ложится
Сейчас много где собственные процессоры - в жёстких дисках, например. Иногда - многоядерные.
Главное - не забывать, что сетевое оборудование делается так, чтобы почти всё выполняло специализированное железо.
Как только нагрузка ложится на процессор сетевого устройства в хоть сколько-нибудь товарных объёмах - сеть падает.
16 окт 18, 20:42    [21705833]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6158
Basil A. Sidorov,

последнюю сентенцию не оценил
16 окт 18, 21:35    [21705864]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
[quote Siemargl]
полудух
пропущено...

microsoft же - синоним "как из мухи сделать 50-этажного слона"

нет там нихрена. Всё либо эмуляция, либо маркетинг.
армия индусов не способна написать ничего качественного
16 окт 18, 22:44    [21705892]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Basil A. Sidorov
полудух
зацените, как ява любит память...
В первой строчке она любит её меньше, чем це-с-крестами.
В остальных - больше, но вопрос остаётся прежним: какую проблему решаем?

Я не понял в чем был смысл этого сообщения? Какой вопрос обсуждается?
16 окт 18, 23:12    [21705922]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
mayton
полудух
2. C++ boost::asio включает в себя корутины, асинхронность и вообще всё что нужно. Но ещё есть boost::fibers и у неё тоже есть неплохие показатели;
3. корутины берут простоту синхронного подхода и нивелируют сложности асинхронного подхода, в итоге код становится мягким и шелковистым;

Был топик географии 17384728, где мне понадобилось реализовать Кривую Гилберта.
Она реализована как утилита но мне нужен был некий строительный шаблон набодобие
Iterator<Point> который по запросу next() выдает следующую координату кривой. Классический
алгоритм кривой - рекурсивен. Рекурсия внутри итератора - тот еще головняк. Разваливать его в FSM
со стеком мне не хотелось. Нудно да и ошибок можно наделать кучу. А реализация - вот она. Почти работает.
После этого у меня появился еще один мотиватор чтобы реализовать красивый строительный элемент.

Друзья. Топик - сложный и многогранный. Я форкну отдельное обсуждение по корутинам (сопрограммам).
Я возьму штук 3-5 ЯП и промоделирую итератор Гильберта. Особо меня интересует перформанс и как оно реализовано
с практической точки зрения. Прошу прощения что я беру такую специфичную задачу но у меня в наличии
пока ничего другого нет. Если у вас есть предложения - рад послушать.
16 окт 18, 23:17    [21705928]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
hVostt
Member

Откуда:
Сообщений: 15325
Leonid Kudryavtsev
Тупые Java Servlets, там часто встретишь sincronize ? - нет
Но обрабатывать множество пользовательских запросов - это нисколько не мешает. Поол worker'ов на уровне Apache Tomcat или другого app server'а.


Пул воркеров без асинхронных операций, КПД ниже плинтуса.

Leonid Kudryavtsev
СУБД - аналогично. Разошлись по пользователям и 95% времени живем счастливо (желание многозадачности только при батч расчетах может возникнуть 1-2 раза в месяц).


Аналогично. Многозадачность многопользовательская. В остальном, параллелить алгоритмы? Бог ты мой, какие? И какая ценность у них в их шаткой нифига не тестируемой и зачастую кривой реализации?

Нет, ну конечно, видосы рендерить и сапромат считать -- великое дело. Главное, чтобы к майнингу не свелось )))


Leonid Kudryavtsev
Для бизнес-программиста (OeBS,FoxPro,PB,MS Access etc), thread и прочая многозадачность, в 99 % случаях не нужна.


.. была не нужна, так как слишком дорого обходилось. Сейчас обходится дёшево. Ну как. Знания и понимание нужны, а с ними в любой год туго. Другое дело, что реализация стала достижимой с точки зрения стоимости и трудозатрат.
17 окт 18, 02:37    [21705999]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7607
hVostt
Leonid Kudryavtsev
Тупые Java Servlets, там часто встретишь sincronize ? - нет
Но обрабатывать множество пользовательских запросов - это нисколько не мешает. Поол worker'ов на уровне Apache Tomcat или другого app server'а.


Пул воркеров без асинхронных операций, КПД ниже плинтуса.


Пул воркеров без асинхронных операций, КПД ниже плинтуса. - вообще не понял, что эти слова значат

hVostt
Leonid Kudryavtsev
СУБД - аналогично. Разошлись по пользователям и 95% времени живем счастливо (желание многозадачности только при батч расчетах может возникнуть 1-2 раза в месяц).


Аналогично. Многозадачность многопользовательская. В остальном, параллелить алгоритмы? Бог ты мой, какие? И какая ценность у них в их шаткой нифига не тестируемой и зачастую кривой реализации?

Нет, ну конечно, видосы рендерить и сапромат считать -- великое дело. Главное, чтобы к майнингу не свелось )))


Leonid Kudryavtsev
Для бизнес-программиста (OeBS,FoxPro,PB,MS Access etc), thread и прочая многозадачность, в 99 % случаях не нужна.


.. была не нужна, так как слишком дорого обходилось. Сейчас обходится дёшево. Ну как. Знания и понимание нужны, а с ними в любой год туго. Другое дело, что реализация стала достижимой с точки зрения стоимости и трудозатрат.


Не все Ваши мысли понял.

Т.ч. просто попытаюсь пояснить свою

Для БИЗНЕС приложений, в 99 % случаев многозадачность решается на уровне системного софта.

Есть Apache Tomcat, Weblogic, WebSphere, Oracle etc - там есть пул-потоков, локи, латчи и так далее. С многозадачностью все хорошо. Прикладного программиста это ни сколько не касается.

Если говорить о математике и расчетах в кластерах - то, насколько я знаю, там опять таки СПЕЦИАЛИЗИРОВАННЫЕ средства, имеющие достаточно мало общего с перечисленными в первом сообщении. В том числе, можно и про CUBE и расчетах на MMX/SSE/GPU вспомнить. Т.ч. между вопросома вида "легкие потоки vs lock'и" и БИЗНЕС потребностями математиков опять таки прямой связи нет.

Если же мы говорим о СИСТЕМНОМ софте, то тогда нужно расматривать ВЕСЬ стек. Начиная от процессора и кончая нашим кодом. А вот тут то, совершенно не ясно, насколько высокоуровнивые концепции эффективно ложаться на технические средства (OS). Особенно на современные технические средства (low latency network/RSS, NUMA, хитрые алгоритмы диспетчера потоков OS)

Т.ч. сама проблема и термин "будущая мультипоточность" лично мне не так очевидна и не очень понятна. Мультипоточность где и для чего? И что этой мультипоточностью хотят достигнуть.

P.S.
Сам написал и сразу же в голову пришла такая доля рынка как написание игр. Но, подозреваю, там тоже какие-то свои специализированные системы/скрипты написания AI.
17 окт 18, 18:30    [21707046]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7607
Если же говорить про "переосмысления технологий разработки"

То одно из основных требований:

1. Оно должно быть максимально ПОНЯТНО и максимально естественно для человека.
2. Оно должно быть понятно компьютеру. Т.е. более менее легко ложиться на современные технические средства

Все остальное: многопоточность / не многопоточность - глубоко пофиг. Будет средство решать прикладные задачи "интуетивно понятным" образом - им будут пользоваться. Будет решать интуетивно "узкому кругу лиц" понятным образом - этот "узкий круг" и будет им пользоваться, а остальные останутся ретроградами и будут пользоваться java, delphi и так далее.
17 окт 18, 18:40    [21707058]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
Leonid Kudryavtsev
Т.ч. сама проблема и термин "будущая мультипоточность" лично мне не так очевидна и не очень понятна. Мультипоточность где и для чего? И что этой мультипоточностью хотят достигнуть.

полудух
Асинхронная многопоточность нужна нам, чтобы победить I/O (операции, которые требуют ожидания).

эта проблема встречается в любых задачах.

зы: много воды льёте
17 окт 18, 18:52    [21707071]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7607
полудух
победить I/O (операции, которые требуют ожидания).

эта проблема встречается в любых задачах.

Уже написал. По сетевому IO

Тяпничная будущая мультипоточность

1) побеждали, побеждали... Но Java NIO на практике на 10-30% медленнее обычных thread на socket'ах. И это факт
2) кроме того, кроме собственно ожиданий, есть проблема диспетчеризации работы на ядра процессоров/ноду, особенно в NUMA. Т.ч. легким движением руки можем "победить IO" (см. п.1), но при этом полностью угробить скорость доступа к RAM (т.е. просесть в 3-4 раза _на_всех_ командах процессора)

Т.ч. профит от такой победы не очень понятен.

полудух
зы: много воды льёте

Скучно... что же еще на форуме делать )))
17 окт 18, 19:08    [21707085]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
на тестах что-то не видно "полностью угробленной скорости доступа к RAM" )
чтобы не проседать надо не перегружать L1/L2 cache - в нём вся скорость
т.е. всякие инлайны не собирать в цикле, например
17 окт 18, 22:00    [21707202]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

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

Откуда: Odessa
Сообщений: 6351
Немного вернемся к этому.
полудух
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

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

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

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

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

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

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

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

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

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

Откуда: планета орков, г.Зверополис
Сообщений: 542
ну 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

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

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

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

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

Откуда: Odessa
Сообщений: 6351
полудух
не у меня, а у человека, который пишет компиляторы и на ночь читает чертежи процессоров.
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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

нет проблемы "асинхронного программирования", есть проблема "синхронизации" процессов (задач, операций,...).
сейчас воще под "асинхронным" программированием стали подразумевать вызов подпрограмм ввода/вывода и запутали народ вконец
23 окт 18, 21:22    [21712806]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
ViPRos
полудух
пропущено...

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

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

Чисто эстетически... Писать код с асинхронными вызовами легче чем "на потоках". И ошибок меньше.
Я здесь говорю безотносительно I/O. А вообще.
23 окт 18, 22:39    [21712840]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
mayton
ViPRos
пропущено...

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

Чисто эстетически... Писать код с асинхронными вызовами легче чем "на потоках". И ошибок меньше.
Я здесь говорю безотносительно I/O. А вообще.

это когда под рукой абстракции вроде корутин и ниток
а в оригинале ваще не легче )
23 окт 18, 23:07    [21712857]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
qasta
Member

Откуда:
Сообщений: 57
Addx

ИМХО, вопросы производительности и оптимизации часто встают не там, где это нужно.
Люди читают о том, как решить проблему 100500+ rps, а по факту у них там и нагрузки-то такой нет.
А есть совсем в других местах.
Но делаем тут, потому как у Google была тут проблема и они ее решили так.
Или доклад с конференции прочитали.
К вопросу о "С++ быстрее" и прочих "давай померяемся".
Это интересно и важно, но есть два фактора:
1. в 95% приложений абсолютно не нужно. Нет, если вы графический движок, или универсальный сервер пишете ...
2. На производительность часто влияют другие факторы. Реальный код не висит в воздухе, как тесты и примеры.
3. Цифры 5-10-15% вообще ни о чем для не глубоко системного ПО. Завтра оптимизируют компилятор/библиотеки/процессор и будет все наоборот.
Основная проблема многопоточности - это зависимости и блокировки. Ошибки (не только баги, но и просчеты в архитектуре) тут очень дороги, а ловить их сложнее. Поэтому ставится задача как-то упростить многопоточные неблокируемые операции, встроить в язык.
Я не исключаю, что определенная реализация сложной многопоточности появится в железе с соответствующей поддержкой в языках.
Уже сейчас есть НТ, AVX, OpenCL, но они сильно специализированы.


Полностью согласен. Особенно с выделенным. Очень часто разработчики и менеджеры занимаются не той оптимизацией, которая действительно нужна.
24 окт 18, 18:10    [21714079]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
qasta
Member

Откуда:
Сообщений: 57
Leonid Kudryavtsev
exp98
Вот это отмечу как полезный приём. пропущено...

Про то, что NIO на практике 10-30 % (скорее 10) медленнее старых Socket'ов - уже приводил. А 10% не так уж и мало.

С той же самой NIO, была проблема, что на __реальном__ сервере (NUMA, 2 CPU, 40 cores), от патерна нагрузки NIO + Java менеджеру потоков в Linux голову снесло. Перевод проекта Socket --> NIO привел к увеличению в 3-4 __раза__ потребления CPU. Вылечилось уменьшением кол-ва потоков для java GC и java JIT через командную строчку.


Можно по этим двум пунктам ссылку на исследование? Хотя бы на первое - а то в этом треде я ссылки не нашел.
24 окт 18, 18:21    [21714095]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
+
1 ноя 18, 16:08    [21721714]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7607
qasta
Leonid Kudryavtsev
пропущено...

Про то, что NIO на практике 10-30 % (скорее 10) медленнее старых Socket'ов - уже приводил. А 10% не так уж и мало.

С той же самой NIO, была проблема, что на __реальном__ сервере (NUMA, 2 CPU, 40 cores), от патерна нагрузки NIO + Java менеджеру потоков в Linux голову снесло. Перевод проекта Socket --> NIO привел к увеличению в 3-4 __раза__ потребления CPU. Вылечилось уменьшением кол-ва потоков для java GC и java JIT через командную строчку.


Можно по этим двум пунктам ссылку на исследование? Хотя бы на первое - а то в этом треде я ссылки не нашел.


Я написал - на практике.

1)
Если хотите, возмите и напишите нормальный тест, лучше, прикладную систему портируете

Если хотите, возьмите какую нибудь NIO библиотеку типа Apache Http Core и посмотрите, сколько там в NIO режиме копирований туда-сюда-обратно тебе и мне приятно между char[] и ByteBuffer. Сколько там работы с коллекциями внутри самой библиотеки (т.к. мы то код можем пишем и "ассинхронный", а вот библиотека все Channel'ы вынуждена хранить в обычной java-коллекции и по ним бегать, что бы понять какие мы обработали, а какие channel'ы еще нет).

плюс, самостоятельно напишите ассинхронный Producer, который данные между Вашим ядром будет в NIO отправлять. Добавьте, на сколько в Вашей системе станет больше One Producer One Consumer Queue (при том, что таких оптимизированный Queue даже в Java нет, или concurrentLinkedQueue - который попа боль, т.к. там нет size, или какой нибудь сторонний bounded collection, что бы ошибки переполнения буффера можно было бы хотя бы определять /если клиент очень медленно данные забирает, например у него модем 2400 бод ))) / ). Еще пара коллекций и туда-сюда-через-Queue-передали данные скорости не добавляет

В принципе, можете блоги в Инет почитать. Про пинус 10-30% скорости пишут очень многие

2)
почему медленнее. В общем то понятно. В случае сокитов, ВСЯ синхронизация выполняется системным ядром ОС. В случае NIO, вся синхронизация выполняется "руками" в NIO библиотеке и наших Producer'ах. Native OS vs Java

3)
Про проблему на сервере, уже не раз писал. Просто столкнулся. Какую Вам ссылку дать, не очень понятно. Точно знаю, что он где-то в Англии, на лондонской бирже стоит ))) если туда у Вас есть доступ, могу тогда сказать фирму-арендатор, сходите на железку посмотрите, хоть мне раскажите, как она выглядит )))
1 ноя 18, 19:32    [21721894]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
alex55555
Member

Откуда:
Сообщений: 2097
mayton
Каковы накладные расходы на сидение потока (pthread) в mutex?

До нескольких сотен тактов на переключение процессов. Если переключение происходит часто (миллион в секунду), то десятки процентов времени проц тупо перечитывает кэши. Но так убивать эффективность могут только дауны (начинающие программисты). Поэтому в нормальных случаях такого не наблюдается.
mayton
Чисто эстетически... Писать код с асинхронными вызовами легче чем "на потоках". И ошибок меньше.

Эстетичность вы оцените, когда станете писать асинхронно с рекурсивной вложенностью, да плюс пяток-другой вложенность нерекурсивная. Скажем дружно - нахер нужно (нужна) такая эстетика.
2 ноя 18, 15:48    [21722631]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
alex55555
Member

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

Сложность никуда не девается. В этом проблема. Она прячется новомодным язычком под ковёр, но тут же вылазит в другом месте.
2 ноя 18, 15:51    [21722636]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
alex55555, а где что вылазит?
boost::asio, boost::fiber, boost::coroutine2 - работают же
2 ноя 18, 16:54    [21722680]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
alex55555
Member

Откуда:
Сообщений: 2097
полудух
alex55555, а где что вылазит?
boost::asio, boost::fiber, boost::coroutine2 - работают же

В ваших тривиальных случаях - возможно и работают. Но ваши случаи не есть нечто репрезентативное.
2 ноя 18, 17:37    [21722708]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
alex55555
полудух
alex55555, а где что вылазит?
boost::asio, boost::fiber, boost::coroutine2 - работают же

В ваших тривиальных случаях - возможно и работают. Но ваши случаи не есть нечто репрезентативное.

а вы знаете мои случаи?
2 ноя 18, 19:43    [21722867]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
alex55555
Member

Откуда:
Сообщений: 2097
полудух
а вы знаете мои случаи?

Я прекрасно их представляю по вашим заявлениям. Знал бы человек что-то сложное - ему бы не представило труда опровергнуть мои заявления весьма короткими текстами с указанием на примеры сложности. Но в вашем случае за всю тему не было ни одного подобного ответа на любой заданный вам вопрос. То есть вы ничего не знаете о сложности.
3 ноя 18, 13:42    [21723230]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
alex55555
полудух
а вы знаете мои случаи?

Я прекрасно их представляю по вашим заявлениям. Знал бы человек что-то сложное - ему бы не представило труда опровергнуть мои заявления весьма короткими текстами с указанием на примеры сложности.

а о каких ваших "заявлениях" речь? Я вижу 2 поста ДО моего вопроса, в одном из которых вы заявили про сложность, про которую я и спросил.
Из вышепроцитированного потока сознания вытекает, что надо было не спрашивать, а самому ответить про сложности с примерами

автор
Но в вашем случае за всю тему не было ни одного подобного ответа на любой заданный вам вопрос. То есть вы ничего не знаете о сложности.

тут по всей теме мои ответы и на первых 2х страницах куча текста + видео
там есть любые ответы.
3 ноя 18, 18:25    [21723346]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
alex55555
Member

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

Вы правы, там же есть ответы и о ваших познаниях.
4 ноя 18, 15:17    [21723636]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
вы сначала со своими познаниями разберитесь
я то никогда и не претендовал на гуру асинхронной многопоточности
вам задали вполне конкретный вопрос, а вы тут балабольню развели
автор
alex55555, а где что вылазит?

вопрос на это заявление:
alex55555
В целом уже было озвучено мнение - руки нужно от искривления лечить некоторым пейсателям, а не решать проблему заменой языка.

Сложность никуда не девается. В этом проблема. Она прячется новомодным язычком под ковёр, но тут же вылазит в другом месте.
4 ноя 18, 23:08    [21723855]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
На правах топик-стартера я прошу модератора удалить темы обсуждения нейронных сетей которые
я считаю полезными в целом но бесполезными в данном конкретном топике.

Кто хочет ИИ и НС - может поднять свой топик.
Модератор: Почистил. Просьба тему ИИ больше не упоминать в этом топике.
9 дек 18, 22:19    [21758624]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 542
+ ещё одно must see
не забываем юзать субтитры
17 дек 18, 01:46    [21765603]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mirudom
Member

Откуда:
Сообщений: 1014
Уважаемый mayton,
mayton
9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).
Ссылку на статью укажите пожалуста.
7 янв 19, 15:08    [21779447]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
mirudom
Уважаемый mayton,
mayton
9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).
Ссылку на статью укажите пожалуста.

Я сейчас точно не могу найти цитату. Но вот кажется эта статья.

http://citforum.ck.ua/database/articles/end_of_arch_era/
7 янв 19, 15:16    [21779454]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mirudom
Member

Откуда:
Сообщений: 1014
mayton
Привет друзья.

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

Некоторые поинты:

1) Отказ от программирования потока Thread как от единицы параллелизма в бизнес приложениях. Предполагается что event-driven более эффектичен чем масоовые "сидения" потоков в "мониторах".
2) Использование асинхронного вызова (async-call, callable, future, promise) в тех случаях когда это возможно.
3) Пересмотр архитектуры Thread с использованием Fiber (пример project Loom). Кооперативность снова в деле. Continuations (под другим названием).
4) Использование актора (обычно в совокупности с очередями и легковесными потоками). (Akka). Неблокирующие операции. Дешевизна ресурсов. Один нативный поток ОС обслуживает сотни акторов.
5) Использование корутины (coroutines). Использование уступчивого return (yield) (C#,Python) для организации сложных итераторов и генераторов.
6) Функциональный подход в части декомпозиции циклов (for-while) в рекурсии (Erlang) где это (теоретически)
даёт возможность гибкого управления кооперативной мультипоточности.
7) Последние экономические тренды в области строительства ЦОД. Отказ от покупки крупных серверов и предпочтение
облаков. Микросервисы.
8) Специальные языки где асинхронный I/O выдвинут как feature (Node.JS). Языки - где корутина - фича. Go(goroutine).
9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).

Пруфы приводить не буду. Топик - просто является неким облаком тегов или смыслов которые я предлагаю обсудить.
Если я где-то ошибся - и классифицировал понятия не так - прошу прощения. Я также мог ошибится в связи ЯП и фич. Sorry.
Но надеюсь общий смысл будет ясен.

P.S. Убежден что поток как единица разработки совершенно необходим в вычислительных задачах с HighLoad-CPU
нагрузкой. Особенно где длительное время нет взаимодействия с внешним миром. Есть только взаимодействие АЛУ и memory
канала. Но такие задачи достаточно специфичны и в бизнес-приложениях их не много.

Какова будет мультипоточность в будущем?

Прошу ваши каменты.
Должно быть упрощение разработки. Должно быть.
Уважаемый mayton,
надо рассматривать три взаимосвязанные вещи, но которые имеют четкие границы:
1. доменную модель и возможность ( необходимость ) ее распараллеливания. И синхронизацию данных.
2. инструмент для работы: язык, фрамеворк. Позволяет ли. Заложено ли.
3. персонал, который имеет скилсы для решения и использования первых двух.

mayton
9) Некоторые архитектурные ошибки строителей РСУБД которые привели к утилизации процессорных ресурсов на бесполезной
синхронизации там где этого можно было избежать вообще (статья Майкла Стоунбрейкера).
последний пункт, надо внимательно осилить оригинал статьи без перевода. Могут быть варианты.
19 янв 19, 22:12    [21789412]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
mirudom
надо рассматривать три взаимосвязанные вещи, но которые имеют четкие границы:
1. доменную модель и возможность ( необходимость ) ее распараллеливания. И синхронизацию данных.
2. инструмент для работы: язык, фрамеворк. Позволяет ли. Заложено ли.
3. персонал, который имеет скилсы для решения и использования первых двух.

С необходимостью распараллеливания вы опоздали на пол-века. Она (необходимость) уже есть.

Фреймворк? При чем здесь он? Я топик поднимал о базовых примитивах синхронизации которые стоят
на уровень ниже фрейворка.

При чем здесь персонал? Мы здесь не обсуждаем вопросы рекрутинга или обучения.
20 янв 19, 00:10    [21789466]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mirudom
Member

Откуда:
Сообщений: 1014
mayton
Какова будет мультипоточность в будущем?
Прошу ваши каменты.
Ваш вопрос, что - уже устарел, ну когда Вы его задавали ?
20 янв 19, 10:42    [21789536]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Вы невнимательно читаете первый пост.
20 янв 19, 11:09    [21789539]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mirudom
Member

Откуда:
Сообщений: 1014
mayton
Вы невнимательно читаете первый пост.
Уважаемый mayton, что из Вашего первого поста я понял не правильно ?
20 янв 19, 13:08    [21789590]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Круг замкнулся.

Давайте вернёмся в начало. Я писал прогнозы. Прогнозы на то как будет выглядеть многопоточность.

Вы квотировали все мои пункты и дали весьма отвлеченные комментарии которые я не могу привязать к моим.

Грубо говоря мы с вами говорим на очень разные темы. Давайте вы конкретизируете ваши вопросы в привязке к моим пунктам.
20 янв 19, 13:21    [21789597]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mirudom
Member

Откуда:
Сообщений: 1014
mayton
Давайте вы конкретизируете ваши вопросы в привязке к моим пунктам
Уважаемый mayton,
нет у меня вопросов, было интересно в оригинале осилить статью заслуженного чела на указанную тему.
26 янв 19, 21:40    [21794975]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mayton
Member

Откуда: loopback
Сообщений: 40512
Nice job.
27 янв 19, 01:06    [21795048]     Ответить | Цитировать Сообщить модератору
 Re: Тяпничная будущая мультипоточность  [new]
mirudom
Member

Откуда:
Сообщений: 1014
mirudom
было интересно в оригинале осилить статью заслуженного чела на указанную тему.

Интересно было прочитать, много поучительного, но, эээ такое чувство, что дискуссия ведется об
использовании различных столовых приборов, ну, достоинство вилок или ножей в различной ситуации,
супчик - так лучше ложечкой, и тд, а вот вывод, вывод делается очень интересный,
надо есть руками.
9 фев 19, 22:13    [21805455]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
Все форумы / Программирование Ответить