All streams
Search
Write a publication
Pull to refresh
16
0

Пользователь

Send message

статья подустарела, в redis появилась многопототочность, по крайней мере для io. И Redis все, есть KeyDB.

Про "плаформонезависимость" - непонял о чём вы, но я имел ввиду, "способность" програм для 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

Да я смотрел доки по llvm. И да native-image позволяет сделать форк, оказывается в 2019 году свешилось, алилуя!
Однако:

$ time /usr/lib/jvm/java-16-graalvm/bin/javac Sample.java && time /usr/lib/jvm/java-16-graalvm/bin/native-image Sample

real	0m1.084s
user	0m1.730s
sys	0m0.191s
[sample:1115840]    classlist:   1,441.24 ms,  0.96 GB
[sample:1115840]        (cap):     840.95 ms,  0.96 GB
[sample:1115840]        setup:   3,438.19 ms,  0.96 GB
[sample:1115840]     (clinit):     374.36 ms,  1.74 GB
[sample:1115840]   (typeflow):   6,396.07 ms,  1.74 GB
[sample:1115840]    (objects):   5,129.39 ms,  1.74 GB
[sample:1115840]   (features):     488.59 ms,  1.74 GB
[sample:1115840]     analysis:  12,691.96 ms,  1.74 GB
[sample:1115840]     universe:   1,009.62 ms,  1.74 GB
[sample:1115840]      (parse):     868.96 ms,  1.77 GB
[sample:1115840]     (inline):   1,460.33 ms,  2.33 GB
[sample:1115840]    (compile):  13,060.04 ms,  2.38 GB
[sample:1115840]      compile:  16,215.19 ms,  2.38 GB
[sample:1115840]        image:   2,244.14 ms,  2.38 GB
[sample:1115840]        write:     317.16 ms,  2.38 GB
[sample:1115840]      [total]:  37,670.41 ms,  2.38 GB
# Printing build artifacts to: /home/rnz/experiments/graalvm/sample.build_artifacts.txt

real	0m38.611s
user	3m44.714s
sys	0m4.161
s
$ du -hs --apparent-size ./sample 
11M	./sample

Тоже самое на С/С++:

$ cat sample.cpp 
#include <iostream>
#include <chrono>
#include <thread>
#include <unistd.h>

using std::cout;
using std::endl;

int main()
{
  pid_t rc;
  rc = fork();
  if (rc == 0) {
    cout << "parent: " << getppid() << endl;
    cout << "child: " << getpid() << endl;
  }
  while (true) {
       std::this_thread::sleep_for((std::chrono::seconds(2)));
       if (rc == 0) {
         cout << "child: " << getpid() << endl;
       } 
  } 
  return 0;
}

$ time g++ -o cppsample sample.cpp

real	0m0.525s
user	0m0.463s
sys	0m0.060s

$ du -hs --apparent-size cppsample
23K	cppsample
$ strip cppsample && du -hs --apparent-size cppsample
15K	cppsample

Ну и потреблянство сравним тоже:

$ pmap -x $(pgrep sample) | egrep 'Address|total'
Address           Kbytes     RSS   Dirty Mode  Mapping
total kB           21488    6712    1320
Address           Kbytes     RSS   Dirty Mode  Mapping
total kB           21488    4764    1320

$ pmap -x $(pgrep cppsample) | egrep 'Address|total'
Address           Kbytes     RSS   Dirty Mode  Mapping
total kB            5976    3060     192
Address           Kbytes     RSS   Dirty Mode  Mapping
total kB            5976    1804     200

В целом неплохо, на мышах. Но ждать ~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 — тут правда не начало сбоя, а позже, но видно как потёк обратно маршрутиатор оператора Телесет в Казани, на котором по всей видимости вообще нет(не было) никаких фильтров.

Да, тогда наоборот "русские хакеры положили инет"

в апреле прошлого года подобная же ситуация была у РТ с той же ASN

гуглить по RIPE monitor bgp относительно интересующей ASN

На AS12389 в 7 утра анонсили 6k маршрутов, в 8ч — fulltable (~800k маршрутов), в 9ч — 1700k маршрутов (закольцевались), в это же время видимо пофиксили косяк в анонсах, в 10 уже анонсилось 800k, в к 12ч вернулись к прежним значениям. У Telianet, равно как и у остальных BGP пиров связанных с РТ, никаких fulltable не проскакивало, ни к себе ни от себя они свыше своих обычных анонсов не анонсили.

Да, да кибератака бла-бла-бла.
На bgp анонсы посмотрите — забанили сами себя.

Information

Rating
Does not participate
Location
Россия
Registered
Activity