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

[reality]

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

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

[Интеррапт]

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

В том, что изначально ты говорил, что FJT разрулит блокирующие операции (в частности ожидание сети). А это совершенно не так. Ничего оно не разрулит, еще и перформанс для таких операций может быть хуже, чем с обычным пулом потоков.
Теперь оказывается туда нужно асинхронное чтение запихивать (т.е. ни о каком ожидании сети речь больше не идет). Но заворачивать асинхронное чтение в FJ task - это какая-то бесполезная операция (если не сказать "вредительская"), зачем это нужно? Собственно о чем и речь, что FJ хорош для CPU-bound задач, а никак не для I/O-bound.

[crypto5]

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

В том, что изначально ты говорил, что FJT разрулит блокирующие операции (в частности ожидание сети). А это совершенно не так. Ничего оно не разрулит, еще и перформанс для таких операций может быть хуже, чем с обычным пулом потоков.
Теперь оказывается туда нужно асинхронное чтение запихивать (т.е. ни о каком ожидании сети речь больше не идет). Но заворачивать асинхронное чтение в FJ task - это какая-то бесполезная операция (если не сказать больше), зачем это нужно? Собственно о чем и речь, что FJ хорош для CPU-bound задач, а никак не для I/O-bound.

Я не писал что FJ pool разрулит блокирующие операции к сети, подразумевалось что их действительно нужно интегрировать в fork join pool правильно, извини что ввел тебя в заблуждение.

[crypto5]

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

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

Отлично, так какая причина почему я не могу использовать такую же стратегию в моем fork join pool-e?

[stenking]

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

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

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

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

И вас даже не смущает что это один файл? Давайте я по шагам пройдусь.

1) $app = new Phalcon\Mvc\Micro() - всё нормально, загружаем фраимворк

2) $app['db'] = function() { ... } - полный капец. Коннектимся к базе.

3 ) $app['view'] = function() { .. } - ещё один капец . Загружаем и выполняем шаблонизатор который к тому же использует кеш на файловой системе ( io операции )

4 ) $app->map('/db') ..... добавляем дополнительные routes. Что бы эпп стал тяжелее и медленее. Как будто 2 и 3 было мало.


Файл должен быть такой:

Code: Select all

 $app = new Phalcon\Mvc\Micro();

    $app->map('/json', function() {
        header("Content-Type: application/json");
        echo json_encode(array('message' => 'Hello, World!'));
    });

    $app->handle();

[reality]

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

Мне кажется куда печальнее попасть в компанию в которой все пихают в ForkJoin pool потому что он сам все локи уберет и сделать все супер быстрым. А оглянуться по сторонам и посмотреть а что ваще еще есть в мире той же JVM хотя бы и что народ и как делает как то не с руки. Я думаю что 95% процентов знающих про аппликативные функторы до этого удосужились прочитать хотя бы спеку java.util.concurrent и откровенную чушь и не перформящие решения видят за километр. Future.get() ни в каком пуле под нагрузкой никогда в жизни перформить не будет.

[crypto5]

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

Мне кажется куда печальнее попасть в компанию в которой все пихают в ForkJoin pool потому что он сам все локи уберет и сделать все супер быстрым. А оглянуться по сторонам и посмотреть а что ваще еще есть в мире той же JVM хотя бы и что народ и как делает как то не с руки. Я думаю что 95% процентов знающих про аппликативные функторы до этого удосужились прочитать хотя бы спеку java.util.concurrent и откровенную чушь и не перформящие решения видят за километр. Future.get() ни в каком пуле под нагрузкой никогда в жизни перформить не будет.

Если вы чего то не понимаете (как работает fork join pool), то может не стоит это валить на здоровую голову?

[Интеррапт]

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

В том, что изначально ты говорил, что FJT разрулит блокирующие операции (в частности ожидание сети). А это совершенно не так. Ничего оно не разрулит, еще и перформанс для таких операций может быть хуже, чем с обычным пулом потоков.
Теперь оказывается туда нужно асинхронное чтение запихивать (т.е. ни о каком ожидании сети речь больше не идет). Но заворачивать асинхронное чтение в FJ task - это какая-то бесполезная операция (если не сказать больше), зачем это нужно? Собственно о чем и речь, что FJ хорош для CPU-bound задач, а никак не для I/O-bound.

Я не писал что FJ pool разрулит блокирующие операции к сети, подразумевалось что их действительно нужно интегрировать в fork join pool правильно, извини что ввел тебя в заблуждение.

ОК. Но тогда я не понимаю, для чего асинхронное чтение нужно FJT засовывать и в чем будет польза? Для чтения уже есть неблокирующие I/O операции. Не вижу, чем может помочь, если вокруг них FJ слой накрутить.

[reality]

Отлично, так какая причина почему я не могу использовать такую же стратегию в моем fork join pool-e?

Да никто не говорит же что нельзя. Все можно. JVM одна на всех. Можно и ифами Case Class и Pattern Matching делать, байт код все равно один. Только это можно сделать легко и поддерживаемо а можно нет. Об это и речь. И с форк джойнами в джаве это будет не поддерживаемо. Если писать на Java то хотя бы взять RxJava для начала.

[crypto5]

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

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

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

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

И вас даже не смущает что это один файл? Давайте я по шагам пройдусь.

1) $app = new Phalcon\Mvc\Micro() - всё нормально, загружаем фраимворк

2) $app['db'] = function() { ... } - полный капец. Коннектимся к базе.

3 ) $app['view'] = function() { .. } - ещё один капец . Загружаем и выполняем шаблонизатор который к тому же использует кеш на файловой системе ( io операции )

4 ) $app->map('/db') ..... добавляем дополнительные routes. Что бы эпп стал тяжелее и медленее. Как будто 2 и 3 было мало.

Чт именно вас смущает? Да в пхп версии все тесты заинтегрировали в один файл, в джава в разные, вот вам джава версия с доступом к БД https://github.com/TechEmpower/Framewor ... oller.java

[crypto5]

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

В том, что изначально ты говорил, что FJT разрулит блокирующие операции (в частности ожидание сети). А это совершенно не так. Ничего оно не разрулит, еще и перформанс для таких операций может быть хуже, чем с обычным пулом потоков.
Теперь оказывается туда нужно асинхронное чтение запихивать (т.е. ни о каком ожидании сети речь больше не идет). Но заворачивать асинхронное чтение в FJ task - это какая-то бесполезная операция (если не сказать больше), зачем это нужно? Собственно о чем и речь, что FJ хорош для CPU-bound задач, а никак не для I/O-bound.

Я не писал что FJ pool разрулит блокирующие операции к сети, подразумевалось что их действительно нужно интегрировать в fork join pool правильно, извини что ввел тебя в заблуждение.

ОК. Но тогда я не понимаю, для чего асинхронное чтение нужно FJT засовывать и в чем будет польза? Для чтения уже есть неблокирующие I/O операции. Не вижу, чем может помочь, если вокруг них FJ слой накрутить.

Тем что если нужно сложить два числа из разных ForkJoinTask то с FJ pool это можно легко сделать без нового заблокированного потока который будет ждать завершение первых двух.

[stenking]

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

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

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

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

И вас даже не смущает что это один файл? Давайте я по шагам пройдусь.

1) $app = new Phalcon\Mvc\Micro() - всё нормально, загружаем фраимворк

2) $app['db'] = function() { ... } - полный капец. Коннектимся к базе.

3 ) $app['view'] = function() { .. } - ещё один капец . Загружаем и выполняем шаблонизатор который к тому же использует кеш на файловой системе ( io операции )

4 ) $app->map('/db') ..... добавляем дополнительные routes. Что бы эпп стал тяжелее и медленее. Как будто 2 и 3 было мало.

Чт именно вас смущает? Да в пхп версии все тесты заинтегрировали в один файл, в джава в разные, вот вам джава версия с доступом к БД https://github.com/TechEmpower/Framewor ... oller.java

Меня смущает что вот такой тест будет наааамного быстрее )

Code: Select all

$app = new Phalcon\Mvc\Micro();

    $app->map('/json', function() {
        header("Content-Type: application/json");
        echo json_encode(array('message' => 'Hello, World!'));
    });

    $app->handle();

[crypto5]

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

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

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

И вас даже не смущает что это один файл? Давайте я по шагам пройдусь.

1) $app = new Phalcon\Mvc\Micro() - всё нормально, загружаем фраимворк

2) $app['db'] = function() { ... } - полный капец. Коннектимся к базе.

3 ) $app['view'] = function() { .. } - ещё один капец . Загружаем и выполняем шаблонизатор который к тому же использует кеш на файловой системе ( io операции )

4 ) $app->map('/db') ..... добавляем дополнительные routes. Что бы эпп стал тяжелее и медленее. Как будто 2 и 3 было мало.

Чт именно вас смущает? Да в пхп версии все тесты заинтегрировали в один файл, в джава в разные, вот вам джава версия с доступом к БД https://github.com/TechEmpower/Framewor ... oller.java

Меня смущает что вот такой тест будет наааамного быстрее )

Code: Select all

$app = new Phalcon\Mvc\Micro();

    $app->map('/json', function() {
        header("Content-Type: application/json");
        echo json_encode(array('message' => 'Hello, World!'));
    });

    $app->handle();

Почему?

[crypto5]

Отлично, так какая причина почему я не могу использовать такую же стратегию в моем fork join pool-e?

Да никто не говорит же что нельзя. Все можно. JVM одна на всех. Можно и ифами Case Class и Pattern Matching делать, байт код все равно один. Только это можно сделать легко и поддерживаемо а можно нет. Об это и речь. И с форк джойнами в джаве это будет не поддерживаемо. Если писать на Java то хотя бы взять RxJava для начала.

Я уже неоднократно выслушал ваше мнение, и уже ответил что помоему вы не осилили как работает fork-join pool, пойдем еще по одной итерации?

[Интеррапт]

Тем что если нужно сложить два числа из разных ForkJoinTask то с FJ pool это можно легко сделать без нового заблокированного потока который будет ждать завершение первых двух.

Ты сможешь показать (кодом, например), как это будет имплементировано на примере с ForkJoinTask с неблокирующим I/O чтением?

[rorp]

Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.

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

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

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

В этом случае жаба выглядит довольно элегантно.

А что, если есть таска, которая выдает список интов и есть функция, которая берет инт и возвращает таску, в которой что-то с этим интом деалается (напиример, он возводтся в квадрат). Как при помощи этой функции сделать из таски списка интов таску списка квадратов?

[crypto5]

Тем что если нужно сложить два числа из разных ForkJoinTask то с FJ pool это можно легко сделать без нового заблокированного потока который будет ждать завершение первых двух.

Ты сможешь показать (кодом, например), как это будет имплементировано на примере с ForkJoinTask с неблокирующим I/O чтением?

Мне нужно заимплементить ForkJoinTask для неблокирующего чтения или ты поверишь что это можно сделать?

[reality]

Мне нужно заимплементить ForkJoinTask для неблокирующего чтения или ты поверишь что это можно сделать?

Я вот не верю ForkJoinTask оно совсем для другого предназначена. И я не верю что ее можно сделать неблокирующей при чтении из NIO сокета к примеру. Может быть я конечно не догоняю как это делается, но вот читаю жавадок и вообще даже не знаю как подступиться.

[crypto5]

Точнее форк-джойн будет пухнуть до лимита потоков а потом встанет.

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

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

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

В этом случае жаба выглядит довольно элегантно.

А что, если есть таска, которая выдает список интов и есть функция, которая берет инт и возвращает таску, в которой что-то с этим интом деалается (напиример, он возводтся в квадрат). Как при помощи этой функции сделать из таски списка интов таску списка квадратов?

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

[Интеррапт]

Мне нужно заимплементить ForkJoinTask для неблокирующего чтения или ты поверишь что это можно сделать?

Я вот не верю ForkJoinTask оно совсем для другого предназначена. И я не верю что ее можно сделать неблокирующей при чтении из NIO сокета к примеру. Может быть я конечно не догоняю как это делается, но вот читаю жавадок и вообще даже не знаю как подступиться.

Аналогично (ну т.е. я конечно Крипто верю, но для собственного самообразования ). Поэтому хотелось бы взглянуть на имплементацию, каким образом мы скоординируем NIO + ForkJoinTask (это ведь нам придется ждать результатов асинхронного чтения, а значит блокировать поток) и каким образом нам это сэкономит поток.
Вот хотелось бы, чтобы Крипто кодом показал, каким образом эта задача имеет смысл.

[crypto5]

Мне нужно заимплементить ForkJoinTask для неблокирующего чтения или ты поверишь что это можно сделать?

Я вот не верю ForkJoinTask оно совсем для другого предназначена. И я не верю что ее можно сделать неблокирующей при чтении из NIO сокета к примеру. Может быть я конечно не догоняю как это делается, но вот читаю жавадок и вообще даже не знаю как подступиться.

Аналогично (ну т.е. я конечно Крипто верю, но для собственного самообразования ). Поэтому хотелось бы взглянуть на имплементацию, каким образом мы скоординируем NIO + ForkJoinTask (это ведь нам придется ждать результатов асинхронного чтения, а значит блокировать поток) и каким образом нам это сэкономит поток.
Вот хотелось бы, чтобы Крипто кодом показал, каким образом эта задача имеет смысл.

Кто-то раньше жаловался что за тестовые задачи денег не платят ))

[Интеррапт]

Я даже ради интереса погуглил NIO и ForkJoinTask - глухо как в могиле, ничего даже близко подобного нет, а ведь казалось бы - это ведь должен быть прорыв в серверном перформансе.

[Интеррапт]

Кто-то раньше жаловался что за тестовые задачи денег не платят ))

Ну нет так нет, я же не настаиваю, а просто спросил.

[crypto5]

Идея вроде простая: делаем новую
class ReadFromNetworkForkJoinTask extends ForkJoinTask {
@override void exec() {
выzываем NIO с колбек, который вызовет this.complete(value);
}
}

Все.

[stenking]

Почему?

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