Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
 Re: Виртуальные методы  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 1019
ЕвгенийВ,
Не язык а языкИ.
И они индивидуальны.
Это только MS может проектировать один всеобщий универсальный язык.
Ну, как сильверлайт типо.
Царствие ему небесное.
8 авг 19, 14:07    [21944704]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4749
PetroNotC Sharp,
Сильверлайт - это не язык.
8 авг 19, 14:11    [21944712]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
betelgeizex
Member

Откуда:
Сообщений: 70
ЕвгенийВ
PetroNotC Sharp
пропущено...
+1

А как бы вы сделали, если проектировали язык с нуля?


А что тут проектировать? В Scala давно всё придумали до нас:

class A {
  def M1(): Unit = ???

  def M2(): Unit = {
    M1()
  }
}

class B extends A {
  def M1(): Unit = ??? // Error:(12, 7) `override` modifier required to override concrete member
}


Все методы виртуальные по умолчанию, но модификатор 'override' обязателен, без него ошибка.
Модификатора 'new' нет, ибо нефиг :)
8 авг 19, 14:25    [21944751]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 1019
ЕвгенийВ
PetroNotC Sharp,
Сильверлайт - это не язык.
я про Помыслы такие, а не про язык. Сами пОмыслы греховные у тебя)
8 авг 19, 14:29    [21944766]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4749
betelgeizex


А что тут проектировать? В Scala давно всё придумали до нас:



Все методы виртуальные по умолчанию, но модификатор 'override' обязателен, без него ошибка.
Модификатора 'new' нет, ибо нефиг :)

Тоже плохо. Вызов виртуального метода дороже, чем не виртуального. А производительность и так проседает....
8 авг 19, 14:48    [21944822]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1733
ЕвгенийВ
PetroNotC Sharp
пропущено...
+1

А как бы вы сделали, если проектировали язык с нуля?


Kotlin и С++ (если не забыл) обязательно требуют писать override у методов, которые перекрывают базовые.
В результате обновление библиотеки сломало бы компиляцию и потребовало бы переименовать метод.
По-моему правильный подход.
8 авг 19, 14:52    [21944831]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1733
ЕвгенийВ
Тоже плохо. Вызов виртуального метода дороже, чем не виртуального. А производительность и так проседает....


JVM давно уже неперекрытые методы не просто делает не-виртуальными, а даже инлайнит.
Предложено вроде в eiffel - там линковщик решал, что виртуальное, а что нет.
8 авг 19, 14:53    [21944834]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 1019
ЕвгенийВ
А производительность и так проседает....
где?
8 авг 19, 14:58    [21944842]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7776
ЕвгенийВ
Тоже плохо. Вызов виртуального метода дороже, чем не виртуального. А производительность и так проседает....

Не факт

Три года назад, когда последний раз запускал VTune, у Intel процессора было > 50 независимых конвееров обращения к памяти (вычисление исполнительного адреса)

Оно, конечно, считать адрес из инструкции вроде теоретически проще, но не факт, что считать из таблицы виртуальных методов практически медленнее.
8 авг 19, 14:59    [21944847]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 1019
Производительность всегда относительно.
То есть где виртуальный стал узким горлышком?
Полиморфизм он вообще не для скорости. Глупо его так оценивать.
8 авг 19, 15:03    [21944855]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4749
PetroNotC Sharp
Производительность всегда относительно.

В данном случае сравнение стоимости виртуального и не виртуального вызова.

PetroNotC Sharp
То есть где виртуальный стал узким горлышком?

Смотря с чем сравнивать.

PetroNotC Sharp
Полиморфизм он вообще не для скорости. Глупо его так оценивать.

Речь о снижении стоимости поддержки полиморфного поведения.
8 авг 19, 16:02    [21944932]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 1019
ЕвгенийВ,
Эти слова выше просто бла бла бла ни о чем.
Удачи!
8 авг 19, 16:14    [21944944]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
betelgeizex
Member

Откуда:
Сообщений: 70
ЕвгенийВ
betelgeizex

А что тут проектировать? В Scala давно всё придумали до нас:



Все методы виртуальные по умолчанию, но модификатор 'override' обязателен, без него ошибка.
Модификатора 'new' нет, ибо нефиг :)

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


Если для вашего приложения действительно критична скорость вызова таблицы методов, то вы просто обязаны использовать профилировщик.
Профилировщик вам покажет, какие из методов требуют оптимизации. И вы этим методам проставите модификатор final (в Scala он тоже есть), это сделает методы невиртуальными и может даже заинлайнит.

Вы придумываете искусственные проблемы, мне кажется :)
8 авг 19, 16:32    [21944963]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7776
Just-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить
8 авг 19, 16:35    [21944966]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4749
Leonid Kudryavtsev
Just-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить

Тут бабка надвое сказала, дай ссылку на исследование? Какие нашел, там простейшие случаи.
У JIT сильно меньше возможностей, в том же времени, по сравнении например с оптимизирующим компилятором С++
8 авг 19, 21:46    [21945191]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
забыл ник
Member

Откуда:
Сообщений: 2859
ЕвгенийВ
Leonid Kudryavtsev
Just-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить


У JIT сильно меньше возможностей, в том же времени, по сравнении например с оптимизирующим компилятором С++


Это с какого перепугу? Вот тут ссылку было бы как раз неплохо.
у JIT есть преимущество, потому что ему на вход поступает не только статическая(на момент компиляции) но и динамическая(как часто какой метод или цикл выполняется), так что ему все карты в руки заоптимизировать по самое небалуй. Те же полиморфик методы по дефолту JIT делает мономорфик. Если два наследника - то bimorph, а вот если уже JIT найдет третьего - тогда он деоптимизирует код и вставляет таблицу виртуальных методов
8 авг 19, 22:45    [21945220]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 1019
ЕвгенийВ,
для сферического коня в вакууме можно идти в шарп.
Все твои теоретические вопросы разбиваются о практику.
Как например неудобство совпадения имен метода - ерунда.
8 авг 19, 23:30    [21945238]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
забыл ник
Member

Откуда:
Сообщений: 2859
PetroNotC Sharp
Как например неудобство совпадения имен метода - ерунда.


Это далеко не ерунда. Мы в RichFaces в свое время наследовались от JSF абстрактных компонент, и добавляли свои методы. И вот пришел JSF 2 и поломал нам много чего, так что проблема не надумана. И это все следствие ублюдочного дизайна наследования и ООП в целом, когда твой код может аффектнуть изменение в чужом коде.
9 авг 19, 00:12    [21945244]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 1019
забыл ник
ублюдочного дизайна наследования и ООП
ты за ФП топишь?
Мы вроде выяснили что ООП нипричем.
В дельфях есть слова в коде
f() virtual, override
9 авг 19, 08:25    [21945279]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1733
ЕвгенийВ
Leonid Kudryavtsev
Just-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить

Тут бабка надвое сказала, дай ссылку на исследование? Какие нашел, там простейшие случаи.


Это жизнь- девиртуализируются методы, которые именют не более двух ИСПОЛЬЗУЮЩИХСЯ реализаций. Например в типичном коде при вызове методов List будет учитываться только методы ArrayList
Т.е. даже если инлайна нет то вместо виртуального вызова ставится нечто вроде

if (o.type == TYPE1) staticCall TYPE1.method(o)
else if (o.type == TYPE2) staticCall TYPE2.method(o)
else убрать_всё_нафиг_и_оптимизировать_заново

ЕвгенийВ
У JIT сильно меньше возможностей, в том же времени, по сравнении например с оптимизирующим компилятором С++


На разных алгоритмах разные штуки выигрывают.
И дело даже не в использовании информации о реально встречающихся типах - JIT может использовать все возможности данного процессора и информацию о времени выполнения команд именно на нём (а не на абстрактном i86x64).
И победить JIT можно либо компиляцией под конкретный процессор, а лучше ручными ассемблерными вставками. Но это стоит очень дорого.
9 авг 19, 09:31    [21945319]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
mayton
Member

Откуда: loopback
Сообщений: 41377
Leonid Kudryavtsev
Just-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить

Я помню какой-то синтетический бенчмарк который доказывал что на виртуальных вызовах Java эффективнее С++.
Причем Java там была бородатых версий. Кажется 1.5...
9 авг 19, 12:13    [21945490]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7776
Alexey Tomin
....
И победить JIT можно либо компиляцией под конкретный процессор, а лучше ручными ассемблерными вставками. Но это стоит очень дорого.

Победить JIT в общем-то элементарно. Но обычно с этим никто не заморачивается.

Профелировал чтение тестовых строк из потока (readline, был когда-то вопрос на данном подфоруме) - предсказание переходов JIT умудрялся прос....ть полностью. Хотя, теоретически, при наличие хоть какой-то статистики времени выполнения, оптимизация предсказания переходов у JIT должна быть практически идеальной.

Полно ситуаций, когда легким движением руки, легко оптимизирующийся код становится не оптимизирующимся. Код работы со стримами. Насколько помню, есть два варианта вызова forEach() один вызывает унивирсальный итератор, второй заточен под типы. В результате банальная итерация по ArrayList в одном случае работает нормально (т.к. оптимизатор выключает проверку выхода за границы массива), в другом случае - жутко тормозит. Цикл по ByteBuffer в большистве случаев аналогично, можно в цикле получить жуткие тормоза, т.к. на каждом обращении идет проверка выхода за пределы массива (практическая задача перевести строки из одной кодировки в другую, для String - оптимизатор оптимизирует, для "универсальных" вызовов /ByteBuffer в Apache HTTP Components/ нифига).

Можно поискать в И-нете замеры скорости и код для быстрого преобразования String в другую кодировку.... жуть... а вроде элементарная и часто требующаяся задача
9 авг 19, 12:41    [21945525]     Ответить | Цитировать Сообщить модератору
 Re: Виртуальные методы  [new]
mayton
Member

Откуда: loopback
Сообщений: 41377
Leonid Kudryavtsev, оптимизация кода со Streams - хорошая тема пятничного топика.
9 авг 19, 12:51    [21945537]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Java Ответить