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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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
Сообщений: 38322
полудух
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А многозадачность на уровне 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

Откуда:
Сообщений: 954
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
Сообщений: 38322
полудух
2. C++ boost::asio включает в себя корутины, асинхронность и вообще всё что нужно. Но ещё есть boost::fibers и у неё тоже есть неплохие показатели;
3. корутины берут простоту синхронного подхода и нивелируют сложности асинхронного подхода, в итоге код становится мягким и шелковистым;

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

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

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

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

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

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

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

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

а что там заполнять? поставьте жирную галку в C++ fibers и всё
16 окт 18, 00:26    [21704633]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Программирование Ответить