Про "плаформонезависимость" - непонял о чём вы, но я имел ввиду, "способность" програм для jvm работать на любой ОС где работает jvm без изменений под конкретнуюю ОС, на практие оно только на десктопах и годится. Про эффективность, я вам уже привёл пример: ScyllaDB. Про "есть/нет программисты" - неверно. Есть бюджет, что-бы: а) нанять программистов б) оплатить эффективное решение. Бюджетом можно распорядиться рационально, а можно разбазарить. 300 разрабов собравшихся вокруг биллинга - разбазаривание бюджета. 40 инстансов субд на java (в облаке-ли, on-premise-ли), там где справятся 3-5 инстансов субд на cpp - разбазаривание бюджета И вопрос только в том, разберёт "заказчик музыки", что ему впарили "какофонию" или нет. Увы, но часто, выбор эффективного языка, вообще не стоит в начале, пишут не оценивая будущее TCO, в результате имеем кучу легаси с тремя сотнями разрабов плящущими вокруг и доказывающими что "хуяк-хуяк и в продакшин" это time-to-market.
Не "хочешь", а надо или не надо. Вот "платформонезависимость" - не надо. Своей тонны java кода нет, что-бы пытаться не переписывая получить профит в производительности и эффективности. А начинать писать на java, то что можно эффективнее и оптимальнее реализовать на C/C++ - лишено смысла, кроме как в случае, если вокруг одни java-программисты и ты один со своим cpp.
Да никто не мешает, пусть кому надо тот и делает. Мне не надо. "малейшее изменение платформы и нужно переписывать JVM" - ну как-бы с ОС именно так. Ведь основная фишка jvm: абстрагировать, вируализировать, эмулировать - ну и логично тогда уже сразу вместо ОС применять jvm.
Во-первых, я предъявлял не языку, а jvm. Во-вторых, эта кроссплатформенность вообще не упёрлась. И предлагая задачу, я намекал на то, что jvm не позволит сделать ряд вещей, хотя как оказалось с 2019 года есть возможность запилить native приложение на java (graalvm), однако выглядит это всё равно как срещивание ужа и ежа, и со значительным оверхедом, хотя в целом неплохо в сравнении c jvm. В общем я о том, что когда нужна реальная производительность и эффективность, то выбрав java с jvm, можно долго ломать копья и всё равно не достич приемлемых показателей, и на этом фоне кроссплатформенность по типу jvm идёт лесом. Показательными примером является Cassandra vs ScyllaDB
В целом неплохо, на мышах. Но ждать ~4 минуты сборки для минимального приложения, да ещё ~2,4G ОЗУ отъело - так себе удовольствие (на Intel i5-8250U). Ну и судя по доке у native-image тоже хватает ограничений, типа невозможности подгрузить динамические штуки, есть какие-то проблемы с сериализацией, ну и если по коду попадаются какие-то особенные функции и методы, то всё равно надо положить рядом jvm.
Вот как в graalvm обойдёте явно указанные ограничения, тогда и поговорим о доступности POSIX "ровно как на сях". И с чего это никому не интересно писать второй nginx - куда ни посмотри, а на любом популярном языке не меньше десятка реализаций web-сервера или прокси или фреймворка.
Тут стоит заметить, что Ваши матрицы не единственное мерило. Расскажите как на jvm для linux в одном бинарнике сделать менеджер управляющий своими воркерам(процессы) с тредами, с возможностью оперативно уменьшать/увеличивать кол-во воркеров и с релоадом без разрыва соединений, на манер как это реализовано в nginx например. Отвечу сразу - никак, кроме запуска пачки jvm. Вообще-же jvm в качестве ОС (а не поверх ОС) - весьма интересное решение.
Надо учитывать, что это самое GRO чаще приходится отключать, чем включать, в частности на сетевых интерфейсах с чипами intel с драйвером ixgbe, меньше сбоев если отключить.
ещё немножко: https://bgpstream.com/event/269338 — тут правда не начало сбоя, а позже, но видно как потёк обратно маршрутиатор оператора Телесет в Казани, на котором по всей видимости вообще нет(не было) никаких фильтров.
На AS12389 в 7 утра анонсили 6k маршрутов, в 8ч — fulltable (~800k маршрутов), в 9ч — 1700k маршрутов (закольцевались), в это же время видимо пофиксили косяк в анонсах, в 10 уже анонсилось 800k, в к 12ч вернулись к прежним значениям. У Telianet, равно как и у остальных BGP пиров связанных с РТ, никаких fulltable не проскакивало, ни к себе ни от себя они свыше своих обычных анонсов не анонсили.
статья подустарела, в redis появилась многопототочность, по крайней мере для io. И Redis все, есть KeyDB.
Про "плаформонезависимость" - непонял о чём вы, но я имел ввиду, "способность" програм для jvm работать на любой ОС где работает jvm без изменений под конкретнуюю ОС, на практие оно только на десктопах и годится.
Про эффективность, я вам уже привёл пример: ScyllaDB.
Про "есть/нет программисты" - неверно.
Есть бюджет, что-бы:
а) нанять программистов
б) оплатить эффективное решение.
Бюджетом можно распорядиться рационально, а можно разбазарить.
300 разрабов собравшихся вокруг биллинга - разбазаривание бюджета.
40 инстансов субд на java (в облаке-ли, on-premise-ли), там где справятся 3-5 инстансов субд на cpp - разбазаривание бюджета
И вопрос только в том, разберёт "заказчик музыки", что ему впарили "какофонию" или нет. Увы, но часто, выбор эффективного языка, вообще не стоит в начале, пишут не оценивая будущее TCO, в результате имеем кучу легаси с тремя сотнями разрабов плящущими вокруг и доказывающими что "хуяк-хуяк и в продакшин" это time-to-market.
https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
Не "хочешь", а надо или не надо.
Вот "платформонезависимость" - не надо. Своей тонны java кода нет, что-бы пытаться не переписывая получить профит в производительности и эффективности. А начинать писать на java, то что можно эффективнее и оптимальнее реализовать на C/C++ - лишено смысла, кроме как в случае, если вокруг одни java-программисты и ты один со своим cpp.
Да никто не мешает, пусть кому надо тот и делает. Мне не надо.
"малейшее изменение платформы и нужно переписывать JVM" - ну как-бы с ОС именно так. Ведь основная фишка jvm: абстрагировать, вируализировать, эмулировать - ну и логично тогда уже сразу вместо ОС применять jvm.
Во-первых, я предъявлял не языку, а jvm. Во-вторых, эта кроссплатформенность вообще не упёрлась.
И предлагая задачу, я намекал на то, что jvm не позволит сделать ряд вещей, хотя как оказалось с 2019 года есть возможность запилить native приложение на java (graalvm), однако выглядит это всё равно как срещивание ужа и ежа, и со значительным оверхедом, хотя в целом неплохо в сравнении c jvm.
В общем я о том, что когда нужна реальная производительность и эффективность, то выбрав java с jvm, можно долго ломать копья и всё равно не достич приемлемых показателей, и на этом фоне кроссплатформенность по типу jvm идёт лесом. Показательными примером является Cassandra vs ScyllaDB
Да я смотрел доки по llvm. И да native-image позволяет сделать форк, оказывается в 2019 году свешилось, алилуя!
Однако:
Тоже самое на С/С++:
Ну и потреблянство сравним тоже:
В целом неплохо, на мышах. Но ждать ~4 минуты сборки для минимального приложения, да ещё ~2,4G ОЗУ отъело - так себе удовольствие (на Intel i5-8250U). Ну и судя по доке у native-image тоже хватает ограничений, типа невозможности подгрузить динамические штуки, есть какие-то проблемы с сериализацией, ну и если по коду попадаются какие-то особенные функции и методы, то всё равно надо положить рядом jvm.
Вот как в graalvm обойдёте явно указанные ограничения, тогда и поговорим о доступности POSIX "ровно как на сях".
И с чего это никому не интересно писать второй nginx - куда ни посмотри, а на любом популярном языке не меньше десятка реализаций web-сервера или прокси или фреймворка.
Неа, не получится. В graalvm:
Directly using process related syscalls like clone, fork, vfork, etc. is not supported.
The exec function family is not supported.
Ну и про глупость - java me squawk, намекают как-бы, ну и есть те кто неплохо на этом зарабатывают: https://microej.com/
Тут стоит заметить, что Ваши матрицы не единственное мерило. Расскажите как на jvm для linux в одном бинарнике сделать менеджер управляющий своими воркерам(процессы) с тредами, с возможностью оперативно уменьшать/увеличивать кол-во воркеров и с релоадом без разрыва соединений, на манер как это реализовано в nginx например. Отвечу сразу - никак, кроме запуска пачки jvm.
Вообще-же jvm в качестве ОС (а не поверх ОС) - весьма интересное решение.
Надо учитывать, что это самое GRO чаще приходится отключать, чем включать, в частности на сетевых интерфейсах с чипами intel с драйвером ixgbe, меньше сбоев если отключить.
А сколько джоулей будет стоит такой поиск в сравнении C/С++ реализацией?
А использование макоси/виндоси/соляроси/т.п. ничего не показало? И да, тот у кого авторские права может менять лицензионную политику.
ещё немножко:
https://bgpstream.com/event/269338 — тут правда не начало сбоя, а позже, но видно как потёк обратно маршрутиатор оператора Телесет в Казани, на котором по всей видимости вообще нет(не было) никаких фильтров.
Что-бы кривотолки не ползли:
https://stat.ripe.net/AS12389?sourceapp=ripedb#tabId=routing
И связанные пиры:

https://radar.qrator.net/as12389/graph#2.60.0.0/14
Да, тогда наоборот "русские хакеры положили инет"
в апреле прошлого года подобная же ситуация была у РТ с той же ASN
гуглить по RIPE monitor bgp относительно интересующей ASN
На AS12389 в 7 утра анонсили 6k маршрутов, в 8ч — fulltable (~800k маршрутов), в 9ч — 1700k маршрутов (закольцевались), в это же время видимо пофиксили косяк в анонсах, в 10 уже анонсилось 800k, в к 12ч вернулись к прежним значениям. У Telianet, равно как и у остальных BGP пиров связанных с РТ, никаких fulltable не проскакивало, ни к себе ни от себя они свыше своих обычных анонсов не анонсили.
Да, да кибератака бла-бла-бла.
На bgp анонсы посмотрите — забанили сами себя.