The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск Java SE 20, opennews (?), 21-Мрт-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


26. "Выпуск Java SE 20"  –4 +/
Сообщение от Илья (??), 22-Мрт-23, 08:08 
Я матерится, когда пытался сделать запилить для себя издателя-подписчика на котлине и узнал, что там дженерики на самом деле фикция.

Вот так нелья SomeClass: SomeInterface<T1>, SomeInterface<T2>

Плюс, структур нет. То есть, вычисления на стеке без аллокаций исключены

Плюс, там какая-то вакханалия с десятками сборочных систем и самих рантаемов. Oracle microsoft gradle openjdk dalvik android SE maven ? Там пока разберёшься...

Поэтому дотнет

Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск Java SE 20"  –1 +/
Сообщение от жявамэн (ok), 22-Мрт-23, 08:50 
> вакханалия с десятками сборочных систем

Поехавший, назови что то кроме мавена и градла, что используются в 99.9 % проектов.
Десятки у него лол.

Ответить | Правка | Наверх | Cообщить модератору

42. "Выпуск Java SE 20"  +4 +/
Сообщение от Аноним (42), 22-Мрт-23, 10:26 
>Я матерится, когда пытался сделать запилить для себя издателя-подписчика на котлине и узнал, что там дженерики на самом деле фикция.
>Вот так нелья SomeClass: SomeInterface<T1>, SomeInterface<T2>

Пришел в тему Java, поругался на Kotlin.

>Плюс, структур нет. То есть, вычисления на стеке без аллокаций исключены

Зачем вам вычислять на стеке? В java есть нормальный gc.

>Плюс, там какая-то вакханалия с десятками сборочных систем и самих рантаемов. Oracle microsoft gradle openjdk dalvik android SE maven ? Там пока разберёшься...

Случайные слова написал, ну круто че. Есть сборочные системы ant, maven, gradle. Ant уже найти можно только в древности. Maven используется почти везде. Иногда люди переходят на gradle, так как больше возможностей.
Oracle, microsoft (amazon, openjdk, etc) - это вы видимо про поставщиков jdk. Берите любого, все идет через стандартизацию.
Dalvik - это виртуальная машина android, причем тут она

У вас синдром утенка видать, раз готовы называть левые слова чтобы опорочить что-то иное.

>Поэтому дотнет

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

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

62. "Выпуск Java SE 20"  +2 +/
Сообщение от Аноним (62), 22-Мрт-23, 16:25 
У языков с GC, в дизайне которых заложено 99% вещей отправлять в heap, в итоге дикая фрагментация кучи и под высокой нагрузкой становятся ощутимым влияние кэш-промахов, возникающих из-за вышеупомянутой фрагментации (нарушение принципа локальности).

Разработка на языках типа C/C++, Rust отлично демонстрирует, что необходимость в куче возникает, когда нужно:
1) Держать в памяти что-то сильно большое
2) Держать в памяти какой-то shared объект, к которому должен быть организован параллельный доступ из нескольких потоков
3) Когда размер аллоцируемой памяти не может быть вычислен на этапе компиляции, поэтому нужна динамическая память

Во всех остальных случаях, если разработчик отдает себе отчёт, что стек вызовов не безразмерный и разумно аллоцирует на стеке небольшие структуры/массивы структур, то оказывается, что чаще всего большую часть бизнес-логики можно описать, через такие вот "автоматические" переменные, которые освободят место сразу после выхода из блока кода, heap pressure ощутимо снижается -> у GC меньше работы, он меньше перемещает данные в памяти из одного места в другое и делает меньше stop-the-world.

Насколько знаю, в Java-сообществе в курсе проблемы, есть Project Valhalla, в рамках которого разрабатываются т.н. value types (по сути, "плоские" объекты, массивы которых JVM будет уметь хранить как массив структур, а не массив ссылок на объекты)/

P.S. Ближайший конкурент Java, С#, имеет ключевое слово stackalloc, которым, в общем-то, довольно успешно пользуются в чувствительных к производительности .NET-решениях.

Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск Java SE 20"  +/
Сообщение от Аноним (73), 22-Мрт-23, 17:58 
>дикая фрагментация кучи

В нете сборка мусора сразу идет с жатием кучи. Все живые объекты плотно сидят в начале памяти, а за ними остается только свободное место. Это позволяет делать очень быстрые аллокации.

Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск Java SE 20"  +1 +/
Сообщение от Аноним (62), 22-Мрт-23, 18:48 
Ну допустим аллокации быстрые, т.к. до следующего GC цикла с компактификацией менеджеру кучи не нужно искать какое-нибудь свободное место подходящего размера. Но это не отменяет того, что непрямой доступ (по ссылке, которая по сути, неявный указатель) сохраняется и даже если объекты сидят в начале памяти, GC не делает их группировку по смыслу при размещении по фактическим адресам в памяти, так сказать. Т.е. допустим есть несколько List коллекций, даже если прошло сжатие кучи и все списки перемещены и "уплотнены" в начале кучи, это абсолютно не значит, что объекты не перемешаны друг относительно друга в рандомном порядке (т.к. GC работает в несколько параллельных потоков, намеренно не синхронизированных, ордеринг по размещению в памяти не сохраняется). А это выливается в то, что когда проц грузит данные в кэши, то в кэш-линиях соседствуют друг с другом данные, не связанные по смыслу. Из-за чего cache miss постоянный и связанные с ним издержки. В каком-нибудь хайлоаде с могучим RPS это имеет значение. Не зря же исписали кучу статей и исследований про data oriented programming и mechanical sympathy. Поэтому все и просят постоянно, чтобы добавили в язык "плоские" структуры и аллокацию на стеке, чтобы затрагивать хип только когда нужно, а не "почти всегда".
Ответить | Правка | Наверх | Cообщить модератору

72. "Выпуск Java SE 20"  +/
Сообщение от Аноним (72), 22-Мрт-23, 17:57 
>Пришел в тему Java, поругался на Kotlin.

это же одно и тоже почти.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

71. "Выпуск Java SE 20"  +/
Сообщение от Аноним (72), 22-Мрт-23, 17:56 
В java используется maven и gradle. Kotlin dsl есть только для gradle. Даже kotlin-native использует gradle.
Примитивные типы в java хранятся в стэке. Kotlin их тоже использует, но пожелание использовать интерпретируемый язык со сборщиком мусора и отсутствие аллокации это странно. Не знаю каким образом оно работает в net, но не думаю что чем-то отличается.

Один и тот же интерфейс и сразу 2 разных типа в параметрах SomeInterface<T1>, SomeInterface<T2> ? Ладно в java дженерики крайне ограниченные, но как в других то языках это должно работать?

>Oracle microsoft gradle openjdk dalvik android SE maven

Ну не знаю.... Вы точно программист, а не эксперт, тролящий глупым набросом?

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

91. "Выпуск Java SE 20"  +/
Сообщение от Веселый Аноним (?), 23-Мрт-23, 03:21 
> Один и тот же интерфейс и сразу 2 разных типа в параметрах SomeInterface<T1>, SomeInterface<T2> ? Ладно в java дженерики крайне ограниченные, но как в других то языках это должно работать?

Я не разбираюсь в C++, но там вроде template'ы являются шаблонами кодогенерации в compile-time, т.е. чем больше у тебя шаблонов, и чем обобщение тип в параметризации тем больше размеры бинарника на выходе компилятора, потому как генерируются перегруженные методы с разными агрументами.  

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

Пусть плюсовики подтвердят или опровергнут :) А что там в C# творится я не знаю.

Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск Java SE 20"  +/
Сообщение от Аноним (105), 24-Мрт-23, 14:49 
Подтверждаю про С++ :)
Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск Java SE 20"  +/
Сообщение от Аноним (79), 22-Мрт-23, 18:42 
> Поэтому дотнет

Теперь понятна Ваша позиция.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру