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

[crypto5]

Почему?

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

Если я правильно читаю этот код то при обращении к URL json/ никакие драйвера и конекшны делатся не будут, а просто вернется простой json.

[crypto5]

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

Я думаю классические джава сервера и с блокированными тредами неплохо живут, все эти дела нужны очень маленькой части програм.

[avitya]

Почему?

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

Так мы теоретический перформанс сравниваем или на приложениях, которые существуют в реальности?

[crypto5]

Почему?

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

Так мы теоретический перформанс сравниваем или на приложениях, которые существуют в реальности?

Стенкин критикует конкретный бенчмарк на данный момент.

[crypto5]

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

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

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

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

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

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

Ну точнее можно, но вся распаралеливаемость потеряется.

[rorp]

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

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

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

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

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

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

Ну почему сразу кривой дизайн? Представьте, что инты мы достаём из БД, и мы не хотим делать по запросу на каждый инт, а сразу все нужные нам инты достать пачкой. А функция не от хорошей жизни таску возвращает, а потому что делает RPC к сервису, написанному нашими братьями с солнечного субконтинента. Так прямее?

И у меня это прекрасно компонуется:

Code: Select all

  def compose(futureInts: Future[List[Int]], f: Int => Future[Long]): Future[List[Long]] = {
    for {
      ints  <- futureInts
      longs <- Future.sequence(ints.map(f))
    } yield longs
    // или futureInts.flatMap(ints => Future.sequence(ints.map(f)))
  }

И никаких if'ов и try/catch'ей, несмотря на то, что в этом коде делатся куча проверок и отлов исключений.

[Интеррапт]

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

Все.

Ну конечно. Во-первых как только exec() закончится (а ведь он не будет ждать выполнения асинхронной операции), то тут-же ожидающий его get() разблокируется, а к этому времени ответ от асинхронного read() еще может не прийти, поэтому данных у нас не будет. У exec (который boolean, а не void) есть возможность указать "return false", чтобы просигнализировать, что мы еще ждем данные от какой-то асинхронной операции, тогда ожидающий get будет ждать, вызова complete(), но все это время там просто поток будет тупо сидеть в join().

Нет, смысла запихивать асинхронное чтение в ForkJoinTask вообще не вижу.

[crypto5]

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

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

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

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

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

Ну почему сразу кривой дизайн? Представьте, что инты мы достаём из БД, и мы не хотим делать по запросу на каждый инт, а сразу все нужные нам инты достать пачкой. А функция не от хорошей жизни таску возвращает, а потому что делает RPC к сервису, написанному нашими братьями с солнечного субконтинента. Так прямее?

И у меня это прекрасно компонуется:

Code: Select all

  def compose(futureInts: Future[List[Int]], f: Int => Future[Long]): Future[List[Long]] = {
    for {
      ints  <- futureInts
      longs <- Future.sequence(ints.map(f))
    } yield longs
    // или futureInts.flatMap(ints => Future.sequence(ints.map(f)))
  }

И никаких if'ов и try/catch'ей, несмотря на то, что в этом коде делатся куча проверок и отлов исключений.

Такое на джава 8 тоже легко запрограмировать, но как я уже написал, это плохо распаралеливается дальше: у вас все колапсируется в одну future которая будет выполнятся в одном потоке, но в вашем примере с БД видимо по другому не выйдет.

[crypto5]

вызова complete(), но все это время там просто поток будет тупо сидеть в join().

Здесь я думаю у тебя ошибка в утверждении, когда вызовется join(), ForkJoinPool увидит что ReadFromNetTask еще не релизнута, и не будет блокировать поток, а отдаст потоку какую то другую таску из очереди выполнения.

[Интеррапт]

вызова complete(), но все это время там просто поток будет тупо сидеть в join().

Здесь я думаю у тебя ошибка в утверждении, когда вызовется join(), ForkJoinPool увидит что ReadFromNetTask еще не релизнута, и не будет блокировать поток, а отдаст потоку какую то другую таску из очереди выполнения.

Я не вижу в этом ни малейшего performance gain по сравнению с, например AsynchronousSocketChannel (и его производных), который просто возвращает Future на read.

[stenking]

Почему?

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

Если я правильно читаю этот код то при обращении к URL json/ никакие драйвера и конекшны делатся не будут, а просто вернется простой json.

Хм..а мне кажется что там по дефолту еager loading а не lazy. Вроде как раз в этом и отличие от традиционных фраимворков что все классы загрузились как C разрешение и потом используются нашару. Хотя я могу ошибатся.

[crypto5]

вызова complete(), но все это время там просто поток будет тупо сидеть в join().

Здесь я думаю у тебя ошибка в утверждении, когда вызовется join(), ForkJoinPool увидит что ReadFromNetTask еще не релизнута, и не будет блокировать поток, а отдаст потоку какую то другую таску из очереди выполнения.

Я не вижу в этом ни малейшего performance gain по сравнению с, например AsynchronousSocketChannel (и его производных), который просто возвращает Future на read.

Разница в том что "Future на read" будет блокировать лишний поток пока рид не завершился, а в ForkJoin pool-e поток блокироваться не будет, а будет выполнять другую полезную работу.

[rorp]

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

Я думаю классические джава сервера и с блокированными тредами неплохо живут, все эти дела нужны очень маленькой части програм.

Сервера может и неплохо живут -- они железные. А вот писателям их не позавидуешь.

[rorp]

Такое на джава 8 тоже легко запрограмировать

А как? В жаба 8 у Future нет ни map'а, ни flatMap'а.

[crypto5]

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

Я думаю классические джава сервера и с блокированными тредами неплохо живут, все эти дела нужны очень маленькой части програм.

Сервера может и неплохо живут -- они железные. А вот писателям их не позавидуешь.

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

[crypto5]

Такое на джава 8 тоже легко запрограмировать

А как? В жаба 8 у Future нет ни map'а, ни flatMap'а.

У колекций есть

[rorp]

Такое на джава 8 тоже легко запрограмировать

А как? В жаба 8 у Future нет ни map'а, ни flatMap'а.

У колекций есть

И как это поможет для композиции фьючерсов?

[crypto5]

Такое на джава 8 тоже легко запрограмировать

А как? В жаба 8 у Future нет ни map'а, ни flatMap'а.

У колекций есть

И как это поможет для композиции фьючерсов?

Ну я в примере с сложением сделал пример композиции, легко представить как это сделать в каком нибудь "reduce".

[Komissar]

у скала-лазов overengineering rules.

[rorp]

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

Я думаю классические джава сервера и с блокированными тредами неплохо живут, все эти дела нужны очень маленькой части програм.

Сервера может и неплохо живут -- они железные. А вот писателям их не позавидуешь.

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

Какие еще сложности? Теория категорий? Монада Future (не путать с java.util.concurrent.Future) специально придумана, чтоб программисты не сношали себе мозг мульти-тредингом, а просто писАли бизнес-логику. На Finagle гляньте при случае.

[rorp]

Такое на джава 8 тоже легко запрограмировать

А как? В жаба 8 у Future нет ни map'а, ни flatMap'а.

У колекций есть

И как это поможет для композиции фьючерсов?

Ну я в примере с сложением сделал пример композиции, легко представить как это сделать в каком нибудь "reduce".

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

[crypto5]

А как? В жаба 8 у Future нет ни map'а, ни flatMap'а.

У колекций есть

И как это поможет для композиции фьючерсов?

Ну я в примере с сложением сделал пример композиции, легко представить как это сделать в каком нибудь "reduce".

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

Я это заметил еще когда вы меня попросили сложение реализовать

[crypto5]

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

Я думаю классические джава сервера и с блокированными тредами неплохо живут, все эти дела нужны очень маленькой части програм.

Сервера может и неплохо живут -- они железные. А вот писателям их не позавидуешь.

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

Какие еще сложности? Теория категорий? Монада Future (не путать с java.util.concurrent.Future) специально придумана, чтоб программисты не сношали себе мозг мульти-тредингом, а просто писАли бизнес-логику. На Finagle гляньте при случае.

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

[reality]

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

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

[reality]

у скала-лазов overengineering rules.

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

А пример самого ужасного в мире overengineering я видел как раз таки на джаве. Когда был изобретен свой фреймворк для distributed-computations и в котором никто ничего не опнимал кроме автора. Но автор был VP Citibank по этому все ели кактус. Точно такойже фреймфорк, хотя по сути он был идиотский но написанный на скале был бы раз в 10 меньше в объеме кода и тогда возможно был бы еще шанс его понять.