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.

Есть такая вот табличка:

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

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

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

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 конвертнуть дичайше не быстро в нём.

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

Siemargl(sync) не использует никто, годятся только для syncэто как бы вообще класс
вообще-то программная модель, целая парадигма

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

Но на мой первый вопрос вы ответили загадкой.
Ну так идите и осмысливайте, если для вас "30k rps" это загадка. Как я тут могу ещё помочь, если вы в теме по нулям.
Вам дали кучу инфы, сэкономили кучу времени, а вы нос воротите. Некрасиво настолько, что даже неожиданно.
Когда-то вы мне помогали разобраться с SQL, а теперь я вам изо всех сил пытаюсь помочь, но, как грится, - "для дальнейшего понимания ознакомьтесь с документацией".

Siemarglчто то нет желающих позаполнять конкретикой мою табличку 21703714
а что там заполнять? поставьте жирную галку в C++ fibers и всё

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).

Haskell vs C++
Go vs C++

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 строк кода.

Basil A. SidorovP.S.
Посмотрел гитхаб с асинхронной обработкой http-запроса в хаскеле и так и не понял, почему эта кучка кода проще двух строчек асинхронных ява-сервлетов.
зацените, как ява любит память ...

[quote Siemargl]полудухпропущено...

microsoft же - синоним "как из мухи сделать 50-этажного слона"
нет там нихрена. Всё либо эмуляция, либо маркетинг.
армия индусов не способна написать ничего качественного

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

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

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

на тестах что-то не видно "полностью угробленной скорости доступа к RAM" )
чтобы не проседать надо не перегружать L1/L2 cache - в нём вся скорость
т.е. всякие инлайны не собирать в цикле, например

цифра из тех видео, что в том же посте , и следующее за ним. Там в каждом вроде свои тесты есть
где взять кошерный, самый честный/чистый/профессиональный тест между C++ и Haskell/Erlang я не знаю (
прямо чтобы профи со знанием дела одно и то же потестили

anyway, coroutines + fibers + future это самое быстрое соотношение скорости и лёгкости кода
быстрее только опускаться ниже этих абстракций, но прирост будет всего %10
это очень быстрое решение для сотен тысяч и даже миллионов rps
у вас 350к на 1 поток?