Re: Интересное мнение про перспективы .NET

Post by **Интеррапт** » 11 Feb 2014 05:01

crypto5 wrote: Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать.

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

http://docs.oracle.com/javase/7/docs/ap ... nPool.html

The pool attempts to maintain enough active (or available) threads by dynamically adding, suspending, or resuming internal worker threads, even if some tasks are stalled waiting to join others. However, no such adjustments are guaranteed in the face of blocked IO or other unmanaged synchronization.

Там конечно есть ManagedBlocker интерфейс, который тебе самому придется имплементировать и скорее всего максимум чего ты добьешся, это такой же производительности, как для обычного thread pool.

Ты же почитай детальней про FJ, там все его бенефиты это именно для CPU-bound задач, а не I/O-bound.

crypto5 · Post by **crypto5** » 11 Feb 2014 05:08

Интеррапт wrote:
crypto5 wrote: Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать.
Обожаю, когда ты так категорично говоришь "ерунда". Fork Join вообще не предназначен для использования с блокирующими операциями, так как не только выигрыша не даст, а может даже ухудшить производительность. Ну хоть Оракловская документация то тебе указ?

http://docs.oracle.com/javase/7/docs/ap ... nPool.html

The pool attempts to maintain enough active (or available) threads by dynamically adding, suspending, or resuming internal worker threads, even if some tasks are stalled waiting to join others. However, no such adjustments are guaranteed in the face of blocked IO or other unmanaged synchronization.

Там написано про unmanaged блокировки, понятно что блокировать нужно через ForkJoinTask.join() вызов.

Там конечно есть ManagedBlocker интерфейс, который тебе самому придется имплементировать и скорее всего максимум чего ты добьешся, это такой же производительности, как для обычного thread pool.

добьюсь я того что если у меня есть 10к тасков которые блокируют друг друга, мне не нужно держать 10к заблокированных тредов, можно обойтись скажем 10-ю

Ты же почитай детальней про FJ, там все его бенефиты это именно для CPU-bound задач, а не I/O-bound.

ну-ну

vladich · Post by **vladich** » 11 Feb 2014 05:11

crypto5 wrote:
Интеррапт wrote:
crypto5 wrote:
reality wrote:Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.
Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.
Тут reality прав, кстати, что ForkJoin не предназначен для большого кол-ва потоков, которые могут долго блокироваться, так как нет смысла от хардварного параллелизма для, например, ожидания данных из сети. ForkJoin имеет смысл применять в основном только для ресурсоемких (в смысле процессора) и неблокирующих (по крайней мере на какое-то заметное время) подзадач.
Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать.

Для большого количества одновременных соединений никакой fork/join и куча threads не поможет. Они дешевые? три раза ха. Как насчет миллиона одновременных коннектов например? А 10 миллионов? А такие цифры на современном железе вполне достижимы. Это все только через epoll, completion ports или другие подобные механизмы операционной системы хорошо работает с маленьким количество ждущих физических потоков. Ну, для миллионов коннектов там еще и специфический тюнинг нужен конечно.

Post by **reality** » 11 Feb 2014 05:13

Интеррапт wrote: Ну и при чем здесь Scala и как Scala в данном вопросе поможет?

Абсолютно не причем. На скале можно точно так же убить любой пул блокирующими тасками. Только в случае двух Future c которых начался спор в скале будет это выглядеть вот так: (future1 zip future2).map(_ * _) и в отличии от Java эта операция будет неблокирующая и спокойно можно делать это в любом пуле и NIO потоке. И все это из за монады

Чтобы сделать это неблокирующе в Java нужно плясать с бубном вокруг СompletionService и где то хранить стейт или делать ан коллбеках с ListenableFuture что тоже быстро превращается в ад

Post by **Интеррапт** » 11 Feb 2014 05:13

stenking wrote:Что такое PHP на самом деле? Это просто много дополнительных функций С просто завёрнутые в другое название и опкод который исполняется он не сильно отличается от голого С. А вот такой настоящий тест не только даёт производительность выше чем у Джавы а ещё и огромную разницу в памяти, всё таки zend engine намного качественнее JVM написанной поколениями индусами

Ну ты ведь прямо сейчас это придумал, насчет опкода, который не сильно по производительности от голого Си отличается? Ну и раз у тебя есть такие сведения, может ты покажешь бенчмарки Zend Engine супротив современного джавовского JIT ?

rorp · Post by **rorp** » 11 Feb 2014 05:13

crypto5 wrote:
reality wrote:Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.
Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.

А как сложить два инта из двух разных тасок и завернуть результат в третью?

crypto5 · Post by **crypto5** » 11 Feb 2014 05:15

vladich wrote:
crypto5 wrote:
Интеррапт wrote:
crypto5 wrote:
reality wrote:Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.
Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.
Тут reality прав, кстати, что ForkJoin не предназначен для большого кол-ва потоков, которые могут долго блокироваться, так как нет смысла от хардварного параллелизма для, например, ожидания данных из сети. ForkJoin имеет смысл применять в основном только для ресурсоемких (в смысле процессора) и неблокирующих (по крайней мере на какое-то заметное время) подзадач.
Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать.
Для большого количества одновременных соединений никакой fork/join и куча threads не поможет. Они дешевые? три раза ха. Как насчет миллиона одновременных коннектов например? А 10 миллионов? А такие цифры на современном железе вполне достижимы. Это все только через epoll, completion ports или другие подобные механизмы операционной системы хорошо работает с маленьким количество ждущих физических потоков. Ну, для миллионов коннектов там еще и специфический тюнинг нужен конечно.

Да, да, в fork-join пуле обычно крутится малое количество физических тредов, обычно равное количеству ядер проца.

crypto5 · Post by **crypto5** » 11 Feb 2014 05:17

rorp wrote:
crypto5 wrote:
reality wrote:Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.
Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.
А как сложить два инта из двух разных тасок и завернуть результат в третью?

Ну я вверху привел приблизительный код, вам точный привести? Думаю как то так:
ForkJoinTask task = forkJoinPool.submit(() -> f1.get() + f2.get());

vladich · Post by **vladich** » 11 Feb 2014 05:21

crypto5 wrote:
vladich wrote:
crypto5 wrote:
Интеррапт wrote:
crypto5 wrote: Это обычный pool будет пухнуть, а фишка fork join-a что он будет работать так как я описал. Там правда нужно вместо Future получать ForkJoinTask из forkJoinPool.
Тут reality прав, кстати, что ForkJoin не предназначен для большого кол-ва потоков, которые могут долго блокироваться, так как нет смысла от хардварного параллелизма для, например, ожидания данных из сети. ForkJoin имеет смысл применять в основном только для ресурсоемких (в смысле процессора) и неблокирующих (по крайней мере на какое-то заметное время) подзадач.
Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать.
Для большого количества одновременных соединений никакой fork/join и куча threads не поможет. Они дешевые? три раза ха. Как насчет миллиона одновременных коннектов например? А 10 миллионов? А такие цифры на современном железе вполне достижимы. Это все только через epoll, completion ports или другие подобные механизмы операционной системы хорошо работает с маленьким количество ждущих физических потоков. Ну, для миллионов коннектов там еще и специфический тюнинг нужен конечно.
Да, да, в fork-join пуле обычно крутится малое количество физических тредов, обычно равное количеству ядер проца.

Да пофигу сколько там тредов крутится на обработку, вопрос в том сколько IO-тредов крутится на ожидание данных из сокета.

Post by **Интеррапт** » 11 Feb 2014 05:22

crypto5 wrote: добьюсь я того что если у меня есть 10к тасков которые блокируют друг друга, мне не нужно держать 10к заблокированных тредов, можно обойтись скажем 10-ю

Не добьешься. Вообще никак.

crypto5 wrote:Там написано про unmanaged блокировки, понятно что блокировать нужно через ForkJoinTask.join() вызов.

ForkJoinTask говоришь?

http://docs.oracle.com/javase/7/docs/ap ... nTask.html

Tasks should also not perform blocking IO, and should ideally access variables that are completely independent of those accessed by other running tasks. Minor breaches of these restrictions, for example using shared output streams, may be tolerable in practice, but frequent use may result in poor performance, and the potential to indefinitely stall if the number of threads not waiting for IO or other external synchronization becomes exhausted.

Уже в документации прямым текстом говорят, что нельзя это использовать для blocking I/O, а ты продолжаешь спорить.

Post by **reality** » 11 Feb 2014 05:23

crypto5 wrote: Ну я вверху привел приблизительный код, вам точный привести? Думаю как то так:
ForkJoinTask task = forkJoinPool.submit(() -> f1.get() + f2.get());

Это опять же блокирующая операция которую не рекомендуется делать внутри пула. Как вы сделаете ее неблокирующей? Если забыли с чего начали: пример кода который легок и приятен на скале и боль на джаве и что не так с джава фьючарами. Вот я и показываю что с ними не так.

Как я это напишу на скале я написал пару сообщений выше.

stenking · Post by **stenking** » 11 Feb 2014 05:27

crypto5 wrote: С чего вы взяли что в приведенном мной бенчмарке на каждой итерации парсятся срцы? Вот тут внятно написано что юзается php apc: https://github.com/TechEmpower/Framewor ... lcon-micro

Ну ок, не будем придиратся даже к тому что это фалкон 1 когда сейчас уже вышел фалкон 2. Который сильно лучше по моему мнению. Дело не технологиях а в людях идиотах которые пишут тесты

. Ок, данный тест проходит первую проверку на идиотизм и включает в себя APC. Что впринципе для таких тестов достаточно необычно. Я даже допускаю что правильно сконфигурированный. Ну ок, я полез посмотреть на конкретно тест. Какой идиот писал этот тест для "JSON test controller"?

https://github.com/TechEmpower/Framewor ... /index.php

Даже не зная PHP я думаю вы видите что в этом тесте 1) используется подключение к базе данных 2) движок для шаблонов 3) запросы к базе данных.

Это по вашему нормальный тест сравнимый с
https://github.com/TechEmpower/Framewor ... oller.java

Какой мы делаем вывод?:)

crypto5 · Post by **crypto5** » 11 Feb 2014 05:31

Интеррапт wrote:
crypto5 wrote: добьюсь я того что если у меня есть 10к тасков которые блокируют друг друга, мне не нужно держать 10к заблокированных тредов, можно обойтись скажем 10-ю
Не добьешься. Вообще никак.

Смешно, как это не добьюсь если это именно то что FJ делает?

crypto5 wrote:Там написано про unmanaged блокировки, понятно что блокировать нужно через ForkJoinTask.join() вызов.
ForkJoinTask говоришь?

http://docs.oracle.com/javase/7/docs/ap ... nTask.html

Tasks should also not perform blocking IO, and should ideally access variables that are completely independent of those accessed by other running tasks. Minor breaches of these restrictions, for example using shared output streams, may be tolerable in practice, but frequent use may result in poor performance, and the potential to indefinitely stall if the number of threads not waiting for IO or other external synchronization becomes exhausted.

Ну да, если в FJTask втупую читать из блокирующего сокета то все поломается, нужно делать асинхронное чтение завернутое в FJTask, как собственно и у товарища в примере с монадами, если одна из компонуемых монад читает из блокирующего сокета все успешно ляжет.

crypto5 · Post by **crypto5** » 11 Feb 2014 05:34

stenking wrote:
crypto5 wrote: С чего вы взяли что в приведенном мной бенчмарке на каждой итерации парсятся срцы? Вот тут внятно написано что юзается php apc: https://github.com/TechEmpower/Framewor ... lcon-micro
Ну ок, не будем придиратся даже к тому что это фалкон 1 когда сейчас уже вышел фалкон 2. Который сильно лучше по моему мнению. Дело не технологиях а в людях идиотах которые пишут тесты . Ок, данный тест проходит первую проверку на идиотизм и включает в себя APC. Что впринципе для таких тестов достаточно необычно. Я даже допускаю что правильно сконфигурированный. Ну ок, я полез посмотреть на конкретно тест. Какой идиот писал этот тест для "JSON test controller"?

https://github.com/TechEmpower/Framewor ... /index.php

Даже не зная PHP я думаю вы видите что в этом тесте 1) используется подключение к базе данных 2) движок для шаблонов 3) запросы к базе данных.

Это по вашему нормальный тест сравнимый с
https://github.com/TechEmpower/Framewor ... oller.java

Какой мы делаем вывод?:)

Мы делаем вывод что вы сравниваете 2 разных теста, которых там аж 5-ять. В json ветке пхп кода никаких коннекшнов не создается, а возращается простой json kak и в джава коде.

crypto5 · Post by **crypto5** » 11 Feb 2014 05:35

reality wrote:
crypto5 wrote: Ну я вверху привел приблизительный код, вам точный привести? Думаю как то так:
ForkJoinTask task = forkJoinPool.submit(() -> f1.get() + f2.get());
Это опять же блокирующая операция которую не рекомендуется делать внутри пула. Как вы сделаете ее неблокирующей? Если забыли с чего начали: пример кода который легок и приятен на скале и боль на джаве и что не так с джава фьючарами. Вот я и показываю что с ними не так.

Как я это напишу на скале я написал пару сообщений выше.

Я уже достаточно подробно описал как эту операцию сделает fork join pool неблокирующей.

Post by **reality** » 11 Feb 2014 05:36

crypto5 wrote: Ну да, если в FJTask втупую читать из блокирующего сокета то все поломается, нужно делать асинхронное чтение завернутое в FJTask, как собственно и у товарища в примере с монадами, если одна из компонуемых монад читает из блокирующего сокета все успешно ляжет.

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

Post by **Интеррапт** » 11 Feb 2014 05:36

crypto5 wrote:Ну да, если в FJTask втупую читать из блокирующего сокета то все поломается, нужно делать асинхронное чтение завернутое в FJTask, как собственно и у товарища в примере с монадами, если одна из компонуемых монад читает из блокирующего сокета все успешно ляжет.

Ну теперь мне стало понятно, что оказывается

crypto5 wrote:Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать

это оказывается обозначает "асинхронное чтение"

И зачем асинхронное чтение заворачивать в ForkJoinTask?

Ай, Крипто, от кого от кого, а от тебя таких уверток и выкручиваний не ожидал

crypto5 · Post by **crypto5** » 11 Feb 2014 05:37

reality wrote:
crypto5 wrote: Ну да, если в FJTask втупую читать из блокирующего сокета то все поломается, нужно делать асинхронное чтение завернутое в FJTask, как собственно и у товарища в примере с монадами, если одна из компонуемых монад читает из блокирующего сокета все успешно ляжет.
Не ляжет. Потому что чтение будет внутри монады и происходить будет в совсем другом пуле специально под это созданном.

Смешно, а в "другом" пуле какие то волшебные неблокирующиеся потоки?

А форк-джойн будет работать только с неблокирующими тасками.

Повторите это еще десять раз, только вряд ли это правдой станет.

Post by **reality** » 11 Feb 2014 05:38

crypto5 wrote: Я уже достаточно подробно описал как эту операцию сделает fork join pool неблокирующей.

То что было в одну строчку это не неблокирющая операция. А то что описано с ForkJoinTask это не в одну строчку. В этом и суть проблемы Future в стандартной библиотеке Java. Сделать просто и неблокирующе никак. Одно из двух.

crypto5 · Post by **crypto5** » 11 Feb 2014 05:38

Интеррапт wrote:
crypto5 wrote:Ну да, если в FJTask втупую читать из блокирующего сокета то все поломается, нужно делать асинхронное чтение завернутое в FJTask, как собственно и у товарища в примере с монадами, если одна из компонуемых монад читает из блокирующего сокета все успешно ляжет.
Ну теперь мне стало понятно, что оказывается

crypto5 wrote:Это ерунда, fork join pool как раз для большого количества тасков, которые блокируют друг друга, fork join pool трекает блокирующие зависимости и следит за тем что-бы task-a включалась когда не заблокирована, и выключалась когда заблокирована. Соответственно туда и ожидание сети можно заинтегрировать
это оказывается обозначает "асинхронное чтение"

И зачем асинхронное чтение заворачивать в ForkJoinTask?

Ай, Крипто, от кого от кого, а от тебя таких уверток и выкручиваний не ожидал

В чем увертки, не обьяснишь?

stenking · Post by **stenking** » 11 Feb 2014 05:39

crypto5 wrote: Мы делаем вывод что вы сравниваете 2 разных теста, которых там аж 5-ять. В json ветке пхп кода никаких коннекшнов не создается, а возращается простой json kak и в джава коде.

Да? А покажите мне плиз где этот таинственный тест ?

https://github.com/TechEmpower/Framewor ... lcon-micro

crypto5 · Post by **crypto5** » 11 Feb 2014 05:39

reality wrote:
crypto5 wrote: Я уже достаточно подробно описал как эту операцию сделает fork join pool неблокирующей.
То что было в одну строчку это не неблокирющая операция. А то что описано с ForkJoinTask это не в одну строчку. В этом и суть проблемы Future в стандартной библиотеке Java. Сделать просто и неблокирующе никак. Одно из двух.

Осталось повторить это девять раз.

crypto5 · Post by **crypto5** » 11 Feb 2014 05:40

stenking wrote:
crypto5 wrote: Мы делаем вывод что вы сравниваете 2 разных теста, которых там аж 5-ять. В json ветке пхп кода никаких коннекшнов не создается, а возращается простой json kak и в джава коде.
Да? А покажите мне плиз где этот таинственный тест ?

https://github.com/TechEmpower/Framewor ... lcon-micro

По вашей же ссылке https://github.com/TechEmpower/Framewor ... /index.php начинается с $app->map('/json', function() {

Post by **reality** » 11 Feb 2014 05:42

crypto5 wrote: Смешно, а в "другом" пуле какие то волшебные неблокирующиеся потоки?
Повторите это еще десять раз, только вряд ли это правдой станет.

Нет. Специальный пул потоков так в 5-10 специальн выделенный для IO операций и не мешающий рабоать остальным СPU-bounded потокам.
И да это правда. "Основной" пул который будет рулить приложением будет АБСОЛЮТНО из неблокирующих операций. Ну вот ваще кристально неблокирующие и не зависящие от IO. Вот прямо как в нетти управляющие потоки. А все что завязано на дисковую подсистему к примеру будем себе спокойно работать отдельно и пропихивать в остольной поток готовые байтики из сокета.

Post by **Интеррапт** » 11 Feb 2014 05:44

Привет

Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET

Re: Re: Интересное мнение про перспективы .NET