История изменений
Исправление
stevejobs,
(текущая версия)
:
Ну так Java действительно прощает крайне неаккуратное обращение с кодом. Всякие фортеля вроде, сделать цикл от нуля до миллиарда и без слипов выплёвывать оттуда мутабельные объекты размером с кулак. Может так магически выйдет, что всё это можно будет почикать эскейп анализом и сказать, что раз данные нигде не используются, то и создавать мы их не будем. Или хотя бы растворим скаляризацией. Или умный GC поймёт что происходит треш и угар, и начнёт расстреливать сталинским методом - группируя в огромные блоки мусора и расстреливая за одну операцию блок целиком, и всё это параллельно чтобы всё не встало колом, даже несмотря на отсутствие слипов в говнокоде (А на C++ такой расстрел ещё попробуй напиши самостоятельно). Я раньше как раз любил показывать синтетический тест, на котором переход на JIT из Graal ускоряет говнокод на Scala в стопятьсот раз просто по факту агрессивного эскейп анализа.
И то же самое в статике, например в плане юнитов компиляции. В обычном приложении на Java никто не скупится на классы. Любая сущность - это класс. В библиотеке Apache Camel как сейчас помню около 7000 классов - и это была одна из более сотни зависимостей того проекта. А потом и мы, обычные говнокодеры, за два месяца написали в этом проекте пару тысяч классов. Я хорошо это помню, на эту тему был обширный срач в моем фейсбуке. Но в джаве это не проблема, у всех всё просто работает.
Люди привыкают, к хорошему. И тут C++, в котором в принципе ты тоже можешь сделать приложение на миллион классов. И всё встанет колом. И придётся мараться обо всякое говнище, мутить странные юнити билды, просаживать перформанс невключением LTO, которое на достаточно большом объеме кода может работать миллион лет, и вообще. Условно говоря, браузер Chromium на моём компе (Skylake, 16 Gb RAM, самсунговский m.2 pcie ssd) полностью собирается целую ночь, и после сборки занимает.... я не могу посмотрть сколько гигабайтов, потому что считаться будет минут десять. Скажем так, удивлюсь, если меньше 50 гигабайт. Такого НИКОГДА не бывает даже с самыми жирными джава приложениями. Джава приложения понимают, что большая часть этого кода не нужна, и компилируют только самую нужную часть прямо в рантайме.
И да, всё это - огромная поддержка для меня как разработчика. Я понимаю, что могу сконцентрироваться на смысле решаемой задачи, а не на мелочах вроде перформанса.
Исправление
stevejobs,
:
Ну так Java действительно прощает крайне неаккуратное обращение с кодом. Всякие фортеля вроде, сделать цикл от нуля до миллиарда и без слипов выплёвывать оттуда мутабельные объекты размером с кулак. Может так магически выйдет, что всё это можно будет почикать эскейп анализом и сказать, что раз данные нигде не используются, то и создавать мы их не будем. Или хотя бы растворим скаляризацией. Или умный GC поймёт что происходит треш и угар, и начнёт расстреливать сталинским методом - группируя в огромные блоки мусора и расстреливая за одну операцию блок целиком, и всё это параллельно чтобы всё не встало колом, даже несмотря на отсутствие слипов в говнокоде (А на C++ такой расстрел ещё попробуй напиши самостоятельно). Я раньше как раз любил показывать синтетический тест, на котором переход на JIT из Graal ускоряет говнокод на Scala в стопятьсот раз просто по факту агрессивного эскейп анализа.
И то же самое в статике, например в плане юнитов компиляции. В обычном приложении на Java никто не скупится на классы. Любая сущность - это класс. В библиотеке Apache Camel как сейчас помню около 7000 классов - и это была одна из более сотни зависимостей того проекта. А потом и мы, обычные говнокодеры, за два месяца написали в этом проекте пару тысяч классов. Я хорошо это помню, на эту тему был обширный срач в моем фейсбуке. Но в джаве это не проблема, у всех всё просто работает.
Люди привыкают, к хорошему. И тут C++, в котором в принципе ты тоже можешь сделать приложение на миллион классов. И всё встанет колом. И придётся мараться обо всякое говнище, мутить странные юнити билды, просаживать перформанс невключением LTO, которое на достаточно большом объеме кода может работать миллион лет, и вообще. Условно говоря, браузер Chromium на моём компе (Skylake, 16 Gb RAM, самсунговский m.2 pcie ssd) полностью собирается целую ночь, и после сборки занимает.... я не могу посмотрть сколько гигабайтов, потому что считаться будет минут десять. Скажем так, удивлюсь, если меньше 50 гигабайт. Такого НИКОГДА не бывает даже с самыми жирными джава приложениями. Джава приложения понимают, что большая часть этого кода не нужна, и компилируют только самую нужную часть прямо в рантайме.
Исходная версия
stevejobs,
:
Ну так Java действительно прощает крайне неаккуратное обращение с кодом. Всякие фортеля вроде, сделать цикл от нуля до миллиарда и без слипов выплёвывать оттуда мутабельные объекты размером с кулак. Может так магически выйдет, что всё это можно будет почикать эскейп анализом и сказать, что раз данные нигде не используются, то и создавать мы их не будем. Или хотя бы растворим скаляризацией. Или умный GC поймёт что происходит треш и угар, и начнёт расстреливать сталинским методом - группируя в огромные блоки мусора и расстреливая за одну операцию блок целиком, и всё это параллельно чтобы всё не встало колом, даже несмотря на отсутствие слипов в говнокоде (А на C++ такой расстрел ещё попробуй напиши самостоятельно). Я раньше как раз любил показывать синтетический тест, на котором переход на JIT из Graal ускоряет говнокод на Scala в стопятьсот раз просто по факту агрессивного эскейп анализа.
И то же самое в статике, например в плане юнитов компиляции. В обычном приложении на Java никто не скупится на классы. Любая сущность - это класс. В библиотеке Apache Camel как сейчас помню около 7000 классов - и это была одна из более сотни зависимостей того проекта. А потом и мы, обычные говнокодеры, за два месяца написали в этом проекте пару тысяч классов. Я хорошо это помню, на эту тему был обширный срач в моем фейсбуке.
Люди привыкают, к хорошему. И тут C++, в котором в принципе ты тоже можешь сделать приложение на миллион классов. И всё встанет колом. И придётся мараться обо всякое говнище, мутить странные юнити билды, просаживать перформанс невключением LTO, которое на достаточно большом объеме кода может работать миллион лет, и вообще. Условно говоря, браузер Chromium на моём компе (Skylake, 16 Gb RAM, самсунговский m.2 pcie ssd) полностью собирается целую ночь, и после сборки занимает.... я не могу посмотрть сколько гигабайтов, потому что считаться будет минут десять. Скажем так, удивлюсь, если меньше 50 гигабайт. Такого НИКОГДА не бывает даже с самыми жирными джава приложениями. Джава приложения понимают, что большая часть этого кода не нужна, и компилируют только самую нужную часть прямо в рантайме.