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

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

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

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

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

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

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

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

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

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

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


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

Откуда:
Сообщений: 54
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

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

Откуда:
Сообщений: 7438
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Откуда:
Сообщений: 989
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
Сообщений: 39224
mirudom
надо рассматривать три взаимосвязанные вещи, но которые имеют четкие границы:
1. доменную модель и возможность ( необходимость ) ее распараллеливания. И синхронизацию данных.
2. инструмент для работы: язык, фрамеворк. Позволяет ли. Заложено ли.
3. персонал, который имеет скилсы для решения и использования первых двух.

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

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

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

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

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

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

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

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

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

Грубо говоря мы с вами говорим на очень разные темы. Давайте вы конкретизируете ваши вопросы в привязке к моим пунктам.
20 янв 19, 13:21    [21789597]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Программирование Ответить