У меня есть коллега, который на Ява пишет практически с его появления. Он называет его исключительно "Жава" (при этом с английским, русским языками у него все хорошо, как и с произношением на обоих языках). Так что кому как нравится.
С точки зрения русского языка и энциклопедических словарей, названия острова Ява и Джава - эквивалентные.
Вы точнЫ, да. Поясню, Кронштадт, как и другие города вокруг Санкт-Петербурга включены в состав города. Сейчас адреса в СПб выглядят так: г. Санкт-Петербург, г. Кронштадт, ул. .... Но от центра до центра примерно 50 километров.
Выскажу гипотезу, что вы сравниваете несравнимое. Компилятор (а мы AOT-или именно компилятор) штука достаточно сложно оптимизируемая и имеет высокую алгоритмическую сложность. Обработка DOM в этом смысле сильно проще, поскольку это большая "развесистая" структура, где за счет оптимизации расположения узлов можно экономить на бранчах в коде. Поэтому и прирост (ну или падение) у них заметно отличаются.
Повторю, это лишь гипотеза, для подтверждения требуется эксперимент и глубокий анализ.
Вкратце ответ будет такой: при длительном использовании (в рамках сборочной системы), методы компилятора успевают пройти через JIT-компиляцию вместе с профилированием. Вполне возможна ситуация, когда комбинация оптимизаций в C1/C2 вместе с профилем дает более быстрый код, чем был сгенерирован AOT. По нашим замерам разница небольшая, 1-2%.
В режиме fork запускается javac как обычное Java приложение, поэтому на каждую задачу компиляции производится "подъем" JVM. Как следствие, это дорого, и производительность проседает.
Вы правы, да мы и не утверждали, что это решение универсально и ускоряет вообще все. Это еще один инструмент в копилку разработчика. Gradle-демон штука не бесплатная. Ее надо настроить, разогреть, кеши поддерживать. В сравнении на длинной дистанции скорость сборки у демона и нативной (АОТ) версии сопоставимы, это правда. Но компиляция нескольких файлов "прямо сейчас" за счет быстрого старта проходит значительно быстрее.
Кроме того, наши измерения показывают, что при сопоставимом времени, затраченном на сборку в Gradle/Maven, AOT версия потребляет меньше CPU и памяти, а это уже существенно экономит ресурсы. На CI мы получаем 10-20% экономии по ресурсам, в зависимости от проекта.
И последнее. fork режим, если запускать оригинальный javac, действительно медленнее, АОТ версия же практически не дает просадки, а иногда и выигрывает, зависит от проекта.
Спорить с анонимусом в интернете -- так себе затея, но статей по истории не так много, потому хочется встать на защиту.
Чтобы что-то оказалось фуфлом, это должно быть сделано.
60-е, 70-е годы прошлого века были великим временем для ИТ. Компьютеры едва шевелились, а люди уже пытались завести на них искусственный интеллект. По дороге исследую все, до чего могли дотянуться, и пробуя решать задачи, которые просто никто не решал, потому что не было таких задач до этого. Да, собственно, придумывая, как можно записать задачи!
И то, что позже какие-то языки "не прошли" проверку временем, не значит, что это было бессмысленно или "оказалось фуфлом". Вовсе нет. Эти исследования выполнили важную роль, подтолкнули других авторов в их движении, в их идеях.
Многим и сегодня полезно почитать статьи тех времен, некоторые из которых совершенно не устаревают и вряд ли устареют.
Кому эти динозябры интересны?
Мне, например. Если вам что-то другое интересно, а эта тема не зашла, пройдите мимо, не топите автора.
Языки-потомки Forth, конечно, своеобразны. И работа через стек требует сноровки и насмотренности, согласен. Но в определенных условиях это оправдано, плюсы определенно есть.
Непонятно, что сколько функция берет со стека
Решается документацией, в шапке указывается сколько снимается со стека и сколько возвращается в стек. Не знаю, правда, как это сделано в TON.
Спросил у коллег, действительно, на ранних этапах говорили "Ява".
ДжеЕва же, ну :)
https://rutube.ru/video/1c045f88215ae3af6fa35b729639bf70/
Колхозный панк? ;)
Полагаю, речь о чем-то таком?
Да, хабр торт
У меня есть коллега, который на Ява пишет практически с его появления. Он называет его исключительно "Жава" (при этом с английским, русским языками у него все хорошо, как и с произношением на обоих языках). Так что кому как нравится.
С точки зрения русского языка и энциклопедических словарей, названия острова Ява и Джава - эквивалентные.
Ничего себе
О, спасибо! Я помнил, что еще один язык есть, но не вспомнил, какой... Цейлон, он же Шри-Ланка.
Вот именно это я и помню :) Что до цены, не покупал и не курил сам, не знаю.
Вы точнЫ, да. Поясню, Кронштадт, как и другие города вокруг Санкт-Петербурга включены в состав города. Сейчас адреса в СПб выглядят так: г. Санкт-Петербург, г. Кронштадт, ул. .... Но от центра до центра примерно 50 километров.
Это, конечно, отвал башки :) Если я правильно понял, то мы сделали вторую проекцию. Но это не точно...
Выскажу гипотезу, что вы сравниваете несравнимое. Компилятор (а мы AOT-или именно компилятор) штука достаточно сложно оптимизируемая и имеет высокую алгоритмическую сложность. Обработка DOM в этом смысле сильно проще, поскольку это большая "развесистая" структура, где за счет оптимизации расположения узлов можно экономить на бранчах в коде. Поэтому и прирост (ну или падение) у них заметно отличаются.
Повторю, это лишь гипотеза, для подтверждения требуется эксперимент и глубокий анализ.
Вкратце ответ будет такой: при длительном использовании (в рамках сборочной системы), методы компилятора успевают пройти через JIT-компиляцию вместе с профилированием. Вполне возможна ситуация, когда комбинация оптимизаций в C1/C2 вместе с профилем дает более быстрый код, чем был сгенерирован AOT. По нашим замерам разница небольшая, 1-2%.
В режиме fork запускается javac как обычное Java приложение, поэтому на каждую задачу компиляции производится "подъем" JVM. Как следствие, это дорого, и производительность проседает.
Клевая картинка, спасибо, утащу себе :)
Вы правы, да мы и не утверждали, что это решение универсально и ускоряет вообще все. Это еще один инструмент в копилку разработчика.
Gradle-демон штука не бесплатная. Ее надо настроить, разогреть, кеши поддерживать. В сравнении на длинной дистанции скорость сборки у демона и нативной (АОТ) версии сопоставимы, это правда. Но компиляция нескольких файлов "прямо сейчас" за счет быстрого старта проходит значительно быстрее.
Кроме того, наши измерения показывают, что при сопоставимом времени, затраченном на сборку в Gradle/Maven, AOT версия потребляет меньше CPU и памяти, а это уже существенно экономит ресурсы. На CI мы получаем 10-20% экономии по ресурсам, в зависимости от проекта.
И последнее.
forkрежим, если запускать оригинальный javac, действительно медленнее, АОТ версия же практически не дает просадки, а иногда и выигрывает, зависит от проекта.Блестяще!
Спорить с анонимусом в интернете -- так себе затея, но статей по истории не так много, потому хочется встать на защиту.
Чтобы что-то оказалось фуфлом, это должно быть сделано.
60-е, 70-е годы прошлого века были великим временем для ИТ. Компьютеры едва шевелились, а люди уже пытались завести на них искусственный интеллект. По дороге исследую все, до чего могли дотянуться, и пробуя решать задачи, которые просто никто не решал, потому что не было таких задач до этого. Да, собственно, придумывая, как можно записать задачи!
И то, что позже какие-то языки "не прошли" проверку временем, не значит, что это было бессмысленно или "оказалось фуфлом". Вовсе нет. Эти исследования выполнили важную роль, подтолкнули других авторов в их движении, в их идеях.
Многим и сегодня полезно почитать статьи тех времен, некоторые из которых совершенно не устаревают и вряд ли устареют.
Мне, например. Если вам что-то другое интересно, а эта тема не зашла, пройдите мимо, не топите автора.
Языки-потомки Forth, конечно, своеобразны. И работа через стек требует сноровки и насмотренности, согласен. Но в определенных условиях это оправдано, плюсы определенно есть.
Решается документацией, в шапке указывается сколько снимается со стека и сколько возвращается в стек. Не знаю, правда, как это сделано в TON.
Добавил в статью ссылку на краткий вводный материал с примерами.