Программирование[11]

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

только вот для дефолт апишек это не особо применимо. чел решает задачу выосокооптимизированной транспортировки и трансформации логов (если я все првильно понял). часто ли дефолт джавист (или даже дефолт плюсовик) решает такие или подобные задачи? если это не HFT или не фаанги в кор перформанс командах то это все не особо нужно.

еще вопрос а точно ли ему надо было настолько упарываться в оптимизации или достоанчо было на гошке за 2 часа накидать код аналогичный джаве но который всего в 2-10 раз медленее его плюсового

Just.Doit написал 20 минут назад:

еще вопрос а точно ли ему надо было настолько упарываться в оптимизации или достоанчо было на гошке за 2 часа накидать код аналогичный джаве но который всего в 2-10 раз медленее его плюсового

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

Можно ли уломать девочку фронтендершу с помощью своих ахуительных знаний javascript'a?

Возможно.

Но мужчину фронтедера можно точно. Думай.

Ну logstash реально тяжелый кобмайн. И вообще ELK хуйня у нас на проекте  Grafana Loki вот это тема 

GoldRobot написал 20 минут назад:

Возможно.

Но мужчину фронтедера можно точно. Думай.

 

Да, но зачем выбирать?
@an7th3r

Index написал 6 часов назад:

Lotus написал 8 часов назад:

Разве что у диназавров без джавы 17 и zgc

zgc тоже делает stop the world 

А я и не писал, что не делает, но он стопит на несколько милесекунд и тайминги стопа особо не растут(а иногда вообще не растут) при росте количества объектов в куче

Grohuf написал 5 часов назад:

Index написал 6 часов назад:

Lotus написал 8 часов назад:

Разве что у диназавров без джавы 17 и zgc

zgc тоже делает stop the world 

Ну он просто думает, что если stop the world делается на отдельном потоке, то это не нагружает проц. Кстати, как он граф объектов обходит, если лочит мьютекс только в начале. Делает копию всего графа? 

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

@Grohuf почини телегу, пожалуйста.

upd: Спасибо.

Lotus написал 14 часов назад:

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

Если ты такой специалист, то разъяснил бы работягам.

Блядский Реддит хватит менять мне интерфейсы 

Grohuf написал 5 часов назад:

Lotus написал 19 часов назад:

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

Если ты такой специалист, то разъяснил бы работягам.

да я не то, чтобы эксперт, но ты прям какую-то хуйню выдал

Lotus написал 17 часов назад:

Grohuf написал 23 часа назад:

Lotus написал 26.02.2024 в 23:55:

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

Если ты такой специалист, то разъяснил бы работягам.

да я не то, чтобы эксперт, но ты прям какую-то хуйню выдал

 

Какую хуйню? Я даже почитал. Действительно, сборка мусора идет на отдельном треде. Только для того, чтобы собрать мусор используется "покраска" указателей, что замедляет доступ к этим указателям из-за синхронизации доступа. В результате сборщик мусора все равно молотит память, чтобы найти утечки, все равно создает структуры в памяти для своей работы, требует больше памяти из-за особенностей сборки и плюс к тому еще замедляет доступ к указателям.

Кроме того, исключает возможность работы с 32 битными указателями, но, думаю, такая оптимизация в Java скорее всего невозможна (она используется для экономии памяти в blink), а 32 битные приложения используются все реже.

а нахуя блинку 32битные указатели, когда эта мразь спокойно жрет 4гб на вкладку и не давится?

Kant написал 35 минут назад:

а нахуя блинку 32битные указатели, когда эта мразь спокойно жрет 4гб на вкладку и не давится?

Чтобы жрать меньше . Правда, имплементацию я не изучал, интересно почитать, как оно у них работает. Да и мб они от этого эксперимента отказались (в процесс рендерера редко заглядываю)...

Grohuf написал 7 часов назад:

Кроме того, исключает возможность работы с 32 битными указателями,

"In a 64-bit system, object references are typically 8-byte long. But in recent JVMs from Sun/Oracle you can enable Compressed Oops, which reduce reference size to 4 bytes at the cost of a smaller limit on heap size."

"Compressed oops is supported and enabled by default in Java SE 6u23 and later releases." 

не совсем понимаю как то что ты имеешь ввиду маппится с тем как работает в жвм

но бай дефолт в жаве рефы 4байта занимают

и в чем проблема работать с 32 битными (4 байта) указателями и почему там гдето исключена с ними работа - я так и не понял

PS: судя по всему в жвм уже 14 лет как эта оптимизация используется бай дефолт, которую ты исключил. а в блинке ее как ты говоришь может вообще не быть. лол

кажется у тебя аутдейтед знания примерно во всем что вокруг происходит

Just.Doit написал 5 минут назад:

32 битными (4 байта)

Спасибо что уточнил

Just.Doit написал 56 минут назад:

кажется у тебя аутдейтед знания примерно во всем что вокруг происходит

Кажется, тупой джавист встрял в середину разговора, с неибаца умным лицом и решил поделиться своим мнением. Спасибо, нахуй. Я, надеюсь, ты теперь оставишь нас и можно будет продолжить общение на темы, в которых ты нихуя не понимаешь?

Grohuf написал 1 час назад:

Just.Doit написал 2 часа назад:

кажется у тебя аутдейтед знания примерно во всем что вокруг происходит

Кажется, тупой джавист встрял в середину разговора, с неибаца умным лицом и решил поделиться своим мнением. Спасибо, нахуй. Я, надеюсь, ты теперь оставишь нас и можно будет продолжить общение на темы, в которых ты нихуя не понимаешь?

Компетентное мнение грофуха:

> исключает возможность работы с 32 битными указателями, но, думаю, такая оптимизация в Java скорее всего невозможна

Реальность:

> Эта оптимизация в джаве является дефолтном последние 14 лет

точно я не понимаю ничего?

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

а на работе держат тупо потому что в этом даском легаси говне браузера больше никто не хочет копаться

Just.Doit написал 8 минут назад:

Grohuf написал 1 час назад:

Just.Doit написал 2 часа назад:

кажется у тебя аутдейтед знания примерно во всем что вокруг происходит

Кажется, тупой джавист встрял в середину разговора, с неибаца умным лицом и решил поделиться своим мнением. Спасибо, нахуй. Я, надеюсь, ты теперь оставишь нас и можно будет продолжить общение на темы, в которых ты нихуя не понимаешь?

Компетентное мнение грофуха:

> исключает возможность работы с 32 битными указателями, но, думаю, такая оптимизация в Java скорее всего невозможна

Реальность:

> Эта оптимизация в джаве является дефолтном последние 14 лет

 

точно я не понимаю ничего?

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

а на работе держат тупо потому что в этом даском легаси говне браузера больше никто не хочет копаться

Ох, долбоеб. Речь шла о том, что средствами си++, несмотря на отсутствие встроенной возможности использования сжатия указателей, в v8 его реализовали. И я написал, что средствами Java это скорее всего сделать нельзя, так как почти наверняка у вас оторвали возможность вручную манипулировать памятью. Но тут стоит слово "скорее всего", потому что я этот язык не знаю и изучать никогда не буду (предпочту c#). Но чем больше я узнаю про Java, тем больше убеждаюсь, что этот язык в принципе не может достичь производительности, сравнимой с си++, из-за постоянных невидимых накладных расходов.

Про твои перлы про скриптовые языки я вообще молчу (хоть посмотрел бы что такое и как реализован v8::Value)

Grohuf написал 57 минут назад:

Just.Doit написал 1 час назад:

Grohuf написал 2 часа назад:

Just.Doit написал 3 часа назад:

кажется у тебя аутдейтед знания примерно во всем что вокруг происходит

Кажется, тупой джавист встрял в середину разговора, с неибаца умным лицом и решил поделиться своим мнением. Спасибо, нахуй. Я, надеюсь, ты теперь оставишь нас и можно будет продолжить общение на темы, в которых ты нихуя не понимаешь?

Компетентное мнение грофуха:

> исключает возможность работы с 32 битными указателями, но, думаю, такая оптимизация в Java скорее всего невозможна

Реальность:

> Эта оптимизация в джаве является дефолтном последние 14 лет

 

точно я не понимаю ничего?

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

а на работе держат тупо потому что в этом даском легаси говне браузера больше никто не хочет копаться

Ох, долбоеб. Речь шла о том, что средствами си++, несмотря на отсутствие встроенной возможности использования сжатия указателей, в v8 его реализовали. И я написал, что средствами Java это скорее всего сделать нельзя, так как почти наверняка у вас оторвали возможность вручную манипулировать памятью. Но тут стоит слово "скорее всего", потому что я этот язык не знаю и изучать никогда не буду (предпочту c#). Но чем больше я узнаю про Java, тем больше убеждаюсь, что этот язык в принципе не может достичь производительности, сравнимой с си++, из-за постоянных невидимых накладных расходов.

Про твои перлы про скриптовые языки я вообще молчу (хоть посмотрел бы что такое и как реализован v8::Value)

чел.

еще раз

в джаве это работает из коробки забесплатно, надежно, быстро

в твоих допотопных плюсах ты сам пишешь что этого все еще нет на уровне экосистемы

...

превосходство очевидно