LINUX.ORG.RU
ФорумTalks

Minimal Value Types

 


0

2

Посоны, я вам тут покушать принёс. Ссылка.

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

Олсо, tl;dr. В жабе можно будет делать пользовательские «примитивные» типы-значения, с минимальным оверхедом, примерно как int в C/C++. Но записываться они будут всё равно как обычные классы! И потом с помощью специальной жава-магии из них будет исчезать жир. Слоган: «codes like a class, works like an int».

Это только начало, в будущем надо будет рассмотреть вопрос более подробно. В любом случае, хочется услышать ваше авторитетное мнение по поводу «нужно» либо «не нужно».

★★★★☆

хочется услышать ваше авторитетное мнение по поводу «нужно» либо «не нужно».

если это не будет порождать костыли типа автобоксинга - то нужно

Deleted ()

Безусловно нужно. На какой-нибудь UUID или LocalDateTime жалко тратить столько накладных расходов. Мелкие строки бы тоже было круто засовывать в такие типы. 128 битов это 16 ASCII-символов или 8 типичных юникодных символов, это наверное 90% значений в типичной программе.

Legioner ★★★★★ ()
Ответ на: комментарий от Deleted

ты про язык Java?

на этапе минимального прототипа, в самом языке Java нет вообще нет поддержки прямого управления Q-типами. Просто нет таких ключевых слов и аттрибутов

вся тема происходит в байткоде, и там да - везде используется хитрый автоматический автобоксинг. С другой стороны, поскольку для таких объектов нет никакого смысла в обычной ссылочной эквивалентности или эскейп-анализе, по ресурсам такой боксинг не стоит почти ничего (на стандартном ворклоаде, массив Q-типов из элементов «инты парами» работает примерно как обычный массив, в котором примитивных интов в два раза больше, и иногда даже чуть быстрее, т.к. JVM немного знает структуру и может иногда применять оптимизации пачек и автовекторизацию)

на этапе расширенного прототипа (который, кажется, уже существует, но не дошли руки), будет поддержка и в языке. Естественно, при работе с Q-типами в жабе, «ощущаться» они будут как обычные объекты, и это может привести к какоаму-то изначальному боксингу. Но в конце концов, он тоже будет почти бесплатный.

stevejobs ★★★★☆ ()
Ответ на: комментарий от Zenom

а при чем тут Scala? Scala работает на JVM, текущая JVM не умеет в value types. Без изменений в JVM любая запись этой сущности в синтаксисе любого jvm-языка будет всего лишь синтаксическим сахаром над лютейшим боксингом, отчего перфоманс будет прямо скажем, не bare metal. Чтобы это заработало, в JVM будут добавлены новые байткоды для value-type операций, вначале некая основная часть «чтобы просто заработало» (как и описано в этом тексте), потом появятся апи для удобной работы и станут доступны через invokedynamic, потом некоторые часто используемые фичи станут байткодами

stevejobs ★★★★☆ ()

Конечно нужно.

Особенно если сделают.

grim ★★★☆ ()
Ответ на: комментарий от Zenom

Какую фичу следующей потащат из Scala?

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

Deleted ()
Ответ на: комментарий от stevejobs

В Скале там была фича с Generics над примитивными типами в T, что оно вроде умело генерировать специализацию, а не реальный Generic (в котором по сути Object).

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

vertexua ★★★★★ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

В Скале там была фича с Generics над примитивными типами в T, что оно вроде умело генерировать специализацию, а не реальный Generic (в котором по сути Object).

В данном случае я о другой фиче: https://docs.scala-lang.org/overviews/core/value-classes.html

Zenom ★★★ ()
Ответ на: комментарий от Zenom

Да, там именно это и написано:

Because the JVM does not support value classes, Scala sometimes needs to actually instantiate a value class. Full details may be found in SIP-15.

This is accomplished through the definition of new AnyVal subclasses.Universal traits allow basic inheritance of methods for value classes, but they incur the overhead of allocation.

Нормальные типы-значения в JVM будут делать всё это во много раз лучше, уже просто со старта. И органичения на их использование будут куда как мягче (т.е. они реально будут всегда работать, а не «ой, сломалось»). И Scala сможет мгновенно этим воспользоваться под капотом.

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

Ограничения и взялись из-за того, что разработчики Scala не могут по своей воле менять спецификации JVM.

Zenom ★★★ ()
Ответ на: комментарий от grim

То что переносят фичи из Скала - это очень хорошо.

Разумеется. Я просто хотел тролльнуть в соответствии с традициями всеобщего ненужно, принятыми на ЛОРе.

Zenom ★★★ ()
Ответ на: комментарий от grim

чуваки, или вы сошли с ума, или я - наркоман

никто не «переносит фичи из Scala».

JVM нельзя сравнивать со Scala, это разные вещи. Scala можно сравнивать с языком Java.

так вот в Java value types еще НЕ появились, а может быть и вообще не появятся (будут существовать как скрытая оптимизация)

JVM можно сравнивать с другими виртуальными машинами и рантаймами. Например, насколько знаю, в .NET CLR value types существуют.

но это даже нельзя назвать «переносом фич из .NET», потому что value types это базовая теоретическая идея, она появилась задолго до появления JVM и .NET как таковых, появилась вместе с первыми попытками сделать виртуальную машину для объектно-ориентированного языка.

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

чуваки, или вы сошли с ума, или я - наркоман

ты конечно тот еще наркоман, но это скала-фанбои

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от stevejobs

в Java value types еще НЕ появились, а может быть и вообще не появятся

тогда ненужно.

но это даже нельзя назвать «переносом фич из .NET», потому что value types это базовая теоретическая идея, она появилась задолго до появления JVM и .NET

Назовите в каких ещё рантаймах с JIT и байткодом это было?

grim ★★★☆ ()
Последнее исправление: grim (всего исправлений: 1)
Ответ на: комментарий от stevejobs

value types это базовая теоретическая идея

В базовой теоретической идее противопоставление value type и reference type идёт только в контексте глубокого копирования, не затрагивая вопросы представления, размещения на стеке/в куче и боксинга. Иными словами, поддержка value types — это свойство именно языка. Свойство рантайма — это оптимизация представления значений value type.

Zenom ★★★ ()
Последнее исправление: Zenom (всего исправлений: 1)
Ответ на: комментарий от Zenom

В scala, классы, которые extends AnyVal, являются синтаксическим костылём, который разруливается в scalac.

Отчасти поэтому, AnyVal-классы могут иметь ровно один аргумент в «конструкторе». Т.е. нельзя в scala реализовать пример по ссылке, где передаются два double-аргумента в value-type конструкторе.

И нельзя будет до тех пор, пока в jvm эта поддержка не появится.

shahid ★★★★★ ()
Последнее исправление: shahid (всего исправлений: 3)
Ответ на: комментарий от shahid

По SIP-15 VT должен быть эфемерным:

A class or trait C is ephemeral if the following holds:

- C may not declare fields (other than the parameter of a value class).
- C may not contain object definitions.
- C may not have initialization statements.

Т.е. не только в конструкторе нельзя передать больше 1 значения, но и вообще никаких полей иметь нельзя

По сути юзать их можно только для овеществления всяких метрик типа скорости

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

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Scala AnyVal-классы внутри — это по сути автоматическая конвертация n-arity методов класса в статические (n+1)-arity методы, сваленные в отдельном сгенеренном классе, где нулевой аргумент метода — это единственный аргумент воображаемого AnyVal-конструктора.

В scala часто такая трансформация используется: например, до java8+scala2.12, дефолтовые реализации методов в trait'ах (интерфейсах) просто сбрасывались в отдельный искусственный класс и становились статическими по той же схеме.

shahid ★★★★★ ()

Так аналог шарповых структур давно же запилить хотят, несколько лет уже. А это как раз оно и есть, как я понимаю.

evilface ★★ ()

Медленно разгоняются. Позовите, когда «изобретут» беззнаковые типы и адресную арифметику.

E ★★★ ()
Ответ на: комментарий от Deleted

Интеллектуала выдает культура прущая из него как нарзан из канализации.

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

Ну да.

theNamelessOne ★★★★★ ()

Вот когда запилят, тогда и приходи со своей простыней. Я эту хрень ещё с 14-го года жду, когда шла речь о вычислениях на ГПУ нативно из ЖВМ.

И что я слышу в итоге, когда одному из ведущих разрабов задают вопрос: «Кто сейчас работает над проектом Саматра?» - Никто.

foror ★★★★ ()
Последнее исправление: foror (всего исправлений: 1)

По ссылке не ходил, но судя из описания первая действительно нужная вещь со времен шестой жабы.

ya-betmen ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.