powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Java JIT - всё? Берёмся за ум
111 сообщений из 111, показаны все 5 страниц
Java JIT - всё? Берёмся за ум
    #39462708
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TL;DR

Мы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор

https://habrahabr.ru/company/jugru/blog/329728/

От меня: просто так без жертв не выйдет, как и для NET native, но в целом +...
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39462718
Roman Mejtes
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
на SQL.ru модно стало с GT и HABRAHABRA статьи репостить? это вообще соответствует правилам форума?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39462745
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman Mejtes,

Это не репост, и не моя статья.

Да и здесь площадка, для статей, мягко говоря - непригодная. Так что радоваться надо.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39462757
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargl...но теперь признаем, что надо просто сделать обычный компилятор

Вот хорошо бы теперь ссылку на официальный сайт Oracle дать в подтверждение этого высказывания.

А то получается "опять-таки случай так называемого вранья" ( C )
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39462792
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglМы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор

У JIT тоже есть шанс. 20506460 Случайно выяснилось что на разных процах .NET работает по-разному и даже иногда обгоняет С++.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39462801
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglTL;DR

Мы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор

https://habrahabr.ru/company/jugru/blog/329728/

От меня: просто так без жертв не выйдет, как и для NET native, но в целом +...
не совсем понятно откуда вырван контекст, там куча презентаций
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463062
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TСлучайно выяснилось что на разных процах .NET работает по-разному и даже иногда обгоняет С++.
А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463094
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockА как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то.
имеется ввиду сравнение кодогенераторов
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463107
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockDima TСлучайно выяснилось что на разных процах .NET работает по-разному и даже иногда обгоняет С++.
А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то.
Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463126
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TНеверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят.
Еще одно теоретическое достоинство JIT, что он имеет доступ к статистике выполнения кода. Т.е., теоретически, располагает информацией о профиле нагрузки на конкретный код в конкретном алгоритме, что большой плюс. Например можно оптимизировать промахи предсказателя переходов и так далее.

Теоретически, т.к. насколько эффективно это реализовано в JIT-компиляторах - огромный вопрос.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463363
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TYuRockпропущено...

А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то.
Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят.Может, но на практике я подтверждений этому не видел. Даже наоборот -JIT тратит гораздо больше ресурсов на компиляцию/оптимизацию
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463415
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TYuRockпропущено...

А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то.
Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят.
Не вижу, где "неверно".
Если компилятор C++ сгенерил бинарник под конкретную платформу - то он только в ней и запустится. И, конечно же, он знал, под какую нужно оптимизировать. Под какой проц, если речь о нативном бинарнике. Я уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463416
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRock...Я уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp.И лучше не говори, о слишком сложных для тебя вещах
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463419
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglYuRock...Я уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp.И лучше не говори, о слишком сложных для тебя вещахТа с удовольствием бы, но не могу пройти иногда мимо, когда чайник с водой сравнивают.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463428
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRock,

Ага. Пойми принципиальное отличие C++ от C++/CLI, C++/CX

Эти гон..ны хотят под прикрытием марки С++ продвинуть свой крючок в твоей з.д..це, а ты подставляешься
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463435
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglYuRock,

Ага. Пойми принципиальное отличие C++ от C++/CLI, C++/CX

Эти гон..ны хотят под прикрытием марки С++ продвинуть свой крючок в твоей з.д..це, а ты подставляешься
Слушай, мне пофиг вообще все эти войны, они меня не возбуждают. Но как ты ни крути, c++ - язык, а .net - платформа.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463436
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TВ итоге все компилируется в машинный код, т.е. в ассемблер
это разные понятия
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463438
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockЯ уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp.
это не C++ , а неведома зверушка от MS (Managed C++)

YuRockЕсли компилятор C++ сгенерил бинарник под конкретную платформу
компилятор C++ вполне может ограничиться генерацией кода LLVM и отложить генерацию машинного кода
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463440
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилкомпилятор C++ вполне может ограничиться генерацией кода LLVM и отложить генерацию машинного кодаЯ для простоты написал. А строго говоря компилятор, C++ в частности, объектные файлы генерит. А что потом из них делается и под какую платформу - другой вопрос.
Изопропилэто не C++ , а неведома зверушка от MS (Managed C++)Синтаксис похож на C++? Это уже не мало.

В Delphi "nextgen", вон, и строки с нуля, и счетчик ссылок на объекты для их самоудаления... А всё равно это паскаль. Как и "Delphi .net" давно мёртвый тоже Паскалем был.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463484
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockDima Tпропущено...

Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят.
Не вижу, где "неверно".
Если компилятор C++ сгенерил бинарник под конкретную платформу - то он только в ней и запустится.
С++ генерит готовый бинарник под конкретную платформу и на другой уже не запустится. .NET (даже при использовании его из С++) генерит промежуточный IL код, который будет "докомпилирован" во время запуска.
Поэтому в случае С++ мы выбираем: либо компиляция под любой проц, либо под конкретный, но на другом бинарник может не заработать. В случае с .NET этой проблемы нет.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463493
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockНо как ты ни крути, c++ - язык, а .net - платформа.
Все это маркетинг от МС. Они так хорошо все запутали, что без бутылки не разобраться.
Если упрощенно: .net это среда исполнения IL кода. Получить IL код (сборку) можно компиляторами C#, F#, VB.NET и т.д. Причем в готовом приложении можно скомбинировать сборки от разных ЯП.
В основном под .net пишут на C#. С++ не умеет компилировать .net сборки, он может только использовать готовые, но на практике это мало кто использует.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463510
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TС++ не умеет компилировать .net сборки
поделка под названием "managed c++" - может создавать чистые .net сборки, ключик для этого у cl есть.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463526
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если рассматривать пользу от байткода за последние годы со времен JDK 1.1 то я-бы
сказал что он внес неоценимый вклад в развитие Open-Source. Именно благодаря строгому
стандарту, и возможности делать рефлексию мы сегодня имеем ГАРАНТИИ прозрачности
использования интерфейсной части любой Java-библиотеки. Про .Net я точно не скажу
но думаю что некоторые пункты будут тоже аналогичны.

Что будет если мы из стека технологии убираем байткод? Тоесть переходим к классической
модели дистрибуции ПО.

Наш Open-Source станет хуже? Или станет ли менее открытым способ распространения
кода?

Прошу высказать ваше мнение.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463542
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonПрошу высказать ваше мнение.
ничего не произойдёт, говнокод останется говнокодом, в частности
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463561
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЧто будет если мы из стека технологии убираем байткод? Тоесть переходим к классической
модели дистрибуции ПО.

Наш Open-Source станет хуже? Или станет ли менее открытым способ распространения
кода?
С/С++ Open-Source как-то живет без байт-кода. Распространение станет менее удобным, т.к. компилировать придется под конкретную платформу.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463569
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

Это называется модульность. Есть в разных языках и не особо как то влияет на открытость.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463696
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TYuRockНо как ты ни крути, c++ - язык, а .net - платформа.
Все это маркетинг от МС.
с++ придумал на MS. Он был языком, когда MS еще не было.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463704
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockDima Tпропущено...

Все это маркетинг от МС.
с++ придумал на MS. Он был языком, когда MS еще не было.
Я про .Net и все что с ним связано.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463714
andr_andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TYuRockпропущено...

А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то.
Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят.

Для оптимизации работы приложения под конкретную платформу испокон веков используется модульная(плагинная) архитектура.
Например, древний Adobe Photoshop подключал модули использующие MMX-команды (и другие SIMD-расширения), если видел, что процессор их поддерживает. Практически все CAD-системы делают аналогично, настраиваясь на аппаратное и программное окружение.
Поэтому утверждение о "медленности" С++ по сравнению с .NET - маркетинговый ход.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463719
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglmayton,

Это называется модульность. Есть в разных языках и не особо как то влияет на открытость.
Я говорю о свойствах рефлексии байт-кода и интроспекции. Про модульность я вообще не говорил
и это отдельная "плоскость" или "измерение" если хотите.

Если разработчики Jdk9/Java9 перейдут на модель дистрибуции основанную на платформенном коде
то я считаю что это нанесет некоторый ущерб открытости.

Впрочем за это говорить еще рано. Давайте посмотрим что будет в девятке и как.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463722
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andr_andreyПоэтому утверждение о "медленности" С++ по сравнению с .NET - маркетинговый ход.
Я выше ссылку давал на результаты конкретного теста. И не утверждал что С++ медленнее. Не надо передергивать.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463739
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЧто будет если мы из стека технологии убираем байткод? Тоесть переходим к классическоймодели дистрибуции ПО. Можно вспомнить легенду для чего создали яву. Согласно преданию неск. чел-к хотели, чтобы оно везде могло работать, вот и порешили использовать всеобщий интерпретатор.
Если его убрать, то дотнет и ведроид будут навроде радстудии - такой же вещью в себе. С разницей лишь, что рад и нет станут похожими по концепцииям, если захочется сохранить заменяемость c# / vb# ... , к-рые тогда вновь станут обычными, без диезов.
Ну а ява - не фиг тогда 1 класс= 1 файл с тем же именем. И что станет с JSP я Х3.
И как там будет с прозраачностью или открытостью - тоже Х3. Смартфончики, хе-хе - тут уж выбирай сильно заранее, на чью марку подсесть. А кому все эти резиновые интерфесы станут нужны? Во, блин! веб-дизайнерам лафа настанет.

Короче, не было гвоздя - подкова пропала, не было подковы - лошад за хромала ...
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463796
Фотография makhaon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторС выпуском JDK 9 «из коробки» появляется возможность статической компиляции, т.е. преобразования в код целевой платформы (т.н. native). Правда, пока только под Linux.

Поразительно, как весь мир массово занимается творческим онанизмом и генерацией энтропии годами и десятилетиями вместо работы :) Ну да ладно - пусть развлекаются.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463802
Фотография makhaon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мы делали, делали, делали, и, наконец, к 9-й версии, придумали компилятор!
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463844
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пока этот топик - собрание научной фантастики и туманных прогнозов.

Давайте еще раз внимательно прочитаем JEP 295: Ahead-of-Time Compilation
http://openjdk.java.net/jeps/295 и попытаемся понять о чем там вообще идет речь.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463877
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TЯ про .Net и все что с ним связано.
Ты сравнивал язык и платформу.
Это всё равно, что сказать "По учебникам математики" учиться математике быстрее, чем по учебникам, написанным на русском языке. При том, что учебники математики одинаковы на всех языках (к примеру).
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463909
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockDima TЯ про .Net и все что с ним связано.
Ты сравнивал язык и платформу.
Это всё равно, что сказать "По учебникам математики" учиться математике быстрее, чем по учебникам, написанным на русском языке. При том, что учебники математики одинаковы на всех языках (к примеру).
.Net платформа только для языков созданных для нее (C#, F#, VB.NET и т.д.) и С++ к ним не относится.
Я сравнивал скорость работы алгоритма на C# и на С++ (исходники тут 20505601 ), но с таким же успехом я мог написать на VB.NET, т.к. к итоге мой код откомпилируется в IL-код .Net, а при запуске .Net скомпилирует IL-код его в бинарный код. В отличии от С++, который сразу компилирует в бинарный код.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39463916
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockТы сравнивал язык и платформу.
Топик именно об этом: что лучше JIT-компилятор или обычный компилятор. Собственно поэтому я написал .Net, т.к. это и есть JIT-компилятор.

В том ключе, в котором ты смотришь на мои посты, наверно, правильнее было бы писать C#.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464036
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonПока этот топик - собрание научной фантастики и туманных прогнозов.

Давайте еще раз внимательно прочитаем JEP 295: Ahead-of-Time Compilation
http://openjdk.java.net/jeps/295 и попытаемся понять о чем там вообще идет речь.
Это же читать, переводить и думать надо ((((
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464039
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Топик IMHO банален

автор топикано теперь признаем, что надо просто сделать обычный компилятор

М.Булгаков Мастер и маргаритаопять-таки случай так называемого вранья
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464066
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Собственно, тема появилась одновременно с самими jit компиляторами.
И дело не в .NET и C++
Реальный вопрос такой - может ли jit-компилятор быть быстрее обычного компилятора?
Ответ очевиден - да, может. Теоретически. А дальше есть много факторов - среда, железо, софт.
Банально - компилятор не может знать о наличии расширенных инструкций у проца (ключи компиляции и исходники - из другой оперы), а вот jit-компилятор - легко. Ускорение и в 10, и в 100 раз может быть! В теории)
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464093
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО На практике в итоге упремся в нехватку кэша проца, т.е. тормоза чтения из памяти и при многопоточности в тормоза синхронизации кэшей проца .
И тут пофиг JIT или нет компилятор. Тут важно как код написан, т.е. алгоритмы.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464104
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На практике за JIT мы платим свою плату. Например PermGen (Metaspace) всегда будет хранит
копии модулей байткода даже если они уже переложены в native. По сути имеет место дублирование
логики.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464110
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TИМХО На практике .....упремся...
На какой практике?

Обычно, в космической практике, сферические кони в вакууме никуда упираться не должны!

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

Если же у Вас они упираются, Вы где-то ошиблись и отступили от методологии. Ищите ошибку в Вашем коде.

IMHO & AFAIK

Dima T.... тормоза чтения из памяти и ...
совершенно детсадовское изложение принципов работы вакуумных насосов и психологии коней

может быть 100500 причин, почему IPC не достигает максимального значения, скорость памяти - лишь одна из них и, скорее всего, даже не основная

Т.к.:
1) AFAIK значительно более частая ситуация, что инструкции не могут быть поставлены на выполнение, т.к. ожидают данных от пред. инструкций
2) "скорость памяти" это вообще мифологическое существо. У процессора есть кэшь. Доступ к которому занимает несколько тактов. Т.ч. "скорость памяти", вроде даже и термина такого в пакетах типа Intel VTune нет. Она никого не интересует. Есть метрика промахи кэша (вроде даже разнообразные). Которые, опять таки, могут возникать по 100500 причинам.
и так далее....

IMHO & AFAIK. Не являюсь специалистом по high performance, Intel VTune последний раз запускал много-много лет назад.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464113
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonНа практике за JIT мы платим свою плату. Например PermGen (Metaspace) всегда будет хранит
копии модулей байткода даже если они уже переложены в native. По сути имеет место дублирование
логики.
Дублирование при современных компьютерах - фигня

Самая большая проблема, возрастает сложность системы. Никто не может объяснить, как же этот JIT работает.

Поэтому, если все хорошо, все счастливы и восхваляют создателей.

А если что-то не хорошо... то никто не знает, что делать... если есть бубны - берут бубны... если есть деньги - начинают ритуалы поклонения карго-культу...

А истина элементарна. Никто не знает, как же оно на самом деле работает. Разных теорий и точек зрения мульон, а как же на самом деле - никто не знает. Возможно, даже не знают создатели JIT и Java. Слишком велика сложность получившейся системы. И слишком она, в силу своей сложности, стала закрытой.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464118
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev, о какой закрытости ты говоришь? Есть сорцы. Сиди.. разбирайся.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464119
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevDima TИМХО На практике .....упремся...
На какой практике?
Например используя буфер влезающий в кэш проца я ускорил расчет вдвое.

По второму пункту тут добавив выравнивание под кэш линию проца (class lite_align64_t) я ускорил тест с 35 до 40 млн. попугаев в секунду.

Вот такая практика.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464121
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevНа какой практике?

Обычно, в космической практике, сферические кони в вакууме никуда упираться не должны!

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

Если же у Вас они упираются, Вы где-то ошиблись и отступили от методологии. Ищите ошибку в Вашем коде.

Я месседж Димы понял так.

- Мы не можем наращивать производительность в одном слое архитектуры. Например
подтянули больше ядер процессоров - получили когерентность. Блокировки... спины.. стали
взымать с нас "дань" просто так. Просто подняли тактовую
частоту - надо поднимать и частоту системной шины и как следствие планок памяти и как
следствие HDD тоже должны быстрее отдавать отклики.

Я к этому пришел в нулевых, когда апгрейтил свой комп для игр.

И я вас прошу! Не надо про коней. Уж очень толсто получается.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464128
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton...
И я вас прошу! Не надо про коней. Уж очень толсто получается.
Так тема изначально такая )))
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464131
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЯ месседж Димы понял так...
Все правильно, дело не в способе компиляции, JIT/неJIT примерно одинаковы, т.е. +/- пару процентов производительности, поэтому проблемы уходят в другие слои. Вот мой замер цены записи в одну кэшлинию проца разными потоками. Тормоза в 5-7 раз! Какой тюнинг компилятора это перекроет?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464134
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton....
Я месседж Димы понял так.

- Мы не можем наращивать производительность в одном слое архитектуры. Например
подтянули больше ядер процессоров - получили когерентность. Блокировки... спины.. стали
взымать с нас "дань" просто так. Просто подняли тактовую
частоту - надо поднимать и частоту системной шины и как следствие планок памяти и как
следствие HDD тоже должны быстрее отдавать отклики.

Я к этому пришел в нулевых, когда апгрейтил свой комп для игр.

Вроде же есть понятие "масштабируемость".

Если конкретная задача и конкретная алгоритм нормально масштабируется - добавили нужного ресурса, получили обещанный прирост производительности

Если не масштабируется, то хоть процессоров, хоть памятью, хоть дисками можно весь дом забить - быстрее работать не будет

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

IMHO
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464139
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima T....Тормоза в 5-7 раз! Какой тюнинг компилятора это перекроет?
Я приводил реальную задачу, на реальном проекта

Прикладная система на конкретной железяке (Numa 2 core, 40 ядер) жестоко отжирала CPU. Настройками JVM (GC и JIT) потребление CPU снизилось в 3-4 раза. Куда уходило CPU - я не выяснил (да и не нафиг это не интересно), просто куда-то уходило, "в между модульное пространство". В данном случае, точнее "в между thread пространство".

Причину (особенности конфигурации продакшен сервера) и метод лечения (нужные ключи JVM) нашли, на этом разбирательство завершили.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464141
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
P.S. Изначально грешили на низкую скорость ConcurrentLinkedList и чрезмерное обилие Atomic'ов в коде. Пытались оптимизировать код. Реальность оказалась проще ))) Шедулер потоков Linux и JVM, почему-то стал "не так" работать.

Вот честно, брать сорцы и разбираться "как же он на самом деле работает" - можно годами. Фиг какая фирма такие разбирательства в рабочее время и необходимое оборудование оплатит.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464143
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevВроде же есть понятие "масштабируемость".

Это красиво в теории. В дискретной математике. В конечных автоматах и сетях Петри.
На практике очень мало задач удачно без потерь масштабируются.

Возьмите любую проблему из области баз данных там где мы работаем не с историческими
а с актуальными сведениями. И начинается. Шардинг. Партишининг. Это все не безплатно.
Кластеры? Они имеют ограничения. Тот-же Oracle RAC Емнип больше 64-х узлов не строится.
Есть там сетевые проблемы. Причем лавинно растущие.

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

Но мы живем в мире где не shared nothing а скорее наоборот. Shared 100%.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464151
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mayton, IMHO теперь Вы начали поднимать "очень толстые темы"

mayton....Тот-же Oracle RAC Емнип больше 64-х узлов не строится.
Есть там сетевые проблемы....
Нет там сетевых проблем.
Там есть финансовые проблемы.

Если кто-то оплатил лицензии на Oracle EE на RAC на 64-х узлах... уверяю Вас... у него нет "сетевых проблем". Что бы под этим не подразумевалось. У него проблем ни с сетью, ни с автомобилем, ни с дачей - нет ))) По определению.

mayton...
Возьмите любую проблему из области баз данных там где мы работаем не с историческими
а с актуальными сведениями. И начинается. Шардинг. Партишининг. Это все не безплатно.

Что значит "не бесплатно"?

Если задача допускает партиционирование - в чем проблема?
Если же для задачи партиционирование, как собаке пятая нога, так это и называется "задача (или алгоритм ее решения) не масштабируется".

Тот же www.google.com, vk.com, youtube как-то работают ))) и "в скорость памяти" совершенно не упираются.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464162
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу масштабируемый, RAC и прочего

Бог с ними с OLTP. Это нужно смотреть конкретный код. Возьмем замечательные и популярные ныне системы DWH. Oracle уже много лет назад, позволял делать Materialized View, Query Rewrite, что бы можно было данные __заранее__ пред-агрегировать и не выполнять всю агрегацию в момент обращения пользователя....

В каком же направление развивается ныне DWH решения?

Правильно - масштабирование, шардинг, партиционирование, RAC...

Возьмем 100500 ядер, выдадим им 100500 SSD дисков, разделим один SELECT SUM(*) c FULL TABLE SCAN по 100 Gb таблице на 100500 мелких Select'ов и будем выполнять их параллельно. Все ядра объединим по FC и InfiniBand. И все это назовем Oracle Exadata, а что бы пользователи понимали, что это не хухры мухры, их БД назовем BigDate и DWH....

А поскольку стоить это будет столько, что даже представить сложно... Exadata будем продавать не целиком, а половинками, четвертинами и по одной восьмой части )))

Только, лично у меня, почему-то возникают сомнения, что в 95% задач, которые решаются на таком оборудование, реально нужен FULL TABLE SCAN по 100-1000 GB таблицам ))). И нельзя было для реальных, практических запросов соорудить уже готовую агригацию на нужном уровне деталировки.

Как уже говорили в подфоруме работа про одну российскую компанию "при должно умение, старание и выделенном бюджете, любую базу данных можно сделать самой большой в Европе. И незачем этим гордиться" (не дословно, по памяти)
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464174
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevПо поводу масштабируемый, RAC и прочего

Бог с ними с OLTP. Это нужно смотреть конкретный код. Возьмем замечательные и популярные ныне системы DWH. Oracle уже много лет назад, позволял делать Materialized View, Query Rewrite, что бы можно было данные __заранее__ пред-агрегировать и не выполнять всю агрегацию в момент обращения пользователя....

В каком же направление развивается ныне DWH решения?

Правильно - масштабирование, шардинг, партиционирование, RAC...

Возьмем 100500 ядер, выдадим им 100500 SSD дисков, разделим один SELECT SUM(*) c FULL TABLE SCAN по 100 Gb таблице на 100500 мелких Select'ов и будем выполнять их параллельно. Все ядра объединим по FC и InfiniBand. И все это назовем Oracle Exadata, а что бы пользователи понимали, что это не хухры мухры, их БД назовем BigDate и DWH....

А поскольку стоить это будет столько, что даже представить сложно... Exadata будем продавать не целиком, а половинками, четвертинами и по одной восьмой части )))

Только, лично у меня, почему-то возникают сомнения, что в 95% задач, которые решаются на таком оборудование, реально нужен FULL TABLE SCAN по 100-1000 GB таблицам ))). И нельзя было для реальных, практических запросов соорудить уже готовую агригацию на нужном уровне деталировки.

Как уже говорили в подфоруме работа про одну российскую компанию "при должно умение, старание и выделенном бюджете, любую базу данных можно сделать самой большой в Европе. И незачем этим гордиться" (не дословно, по памяти)
Вот правильная мысль. Только для другой моей темы - грамотные люди эксплуатируют чужую лень, зарабатывая на этом.

// мод UFO on
Яву изобрели Sun, Oracle и IBM чтобы получше продавались их суперкомпьютеры, потому что иначе все начали считать на копеечных интельПК - хватало ресурсов.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464193
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevТот же www.google.com, vk.com, youtube как-то работают ))) и "в скорость памяти" совершенно не упираются.
Все примеры - разные и неудачные.

google.com - по большей части hadoop. Тоесть исторические сведения. Не реал-тайм. Там - масса хитростей
и финтов как уйти от конкуренции и нагрузки. Вобщем хадуп он в африке слон. Нет транзакций. Хадуп индекс
обещает что индексирует ваш сайт. Но когда он сделает это. Сейчас или через сутки - на это нет контракта.

vk.com - материализация даных причем ненормализованных. Ленты сообщений. Не реляционные. Append-only.
По сути это текстовые файлы. Тоже много пространства для манёвра. Тем более что (здесь старик Брюер нам едко
усмехается) система класса A+P (availability + partition tolerance). Нет консистентности.

youtube - вообще не по адресу. Это хранилище огромных мультимедиа-файлов. Почти вся нагрузка - на видео.
A+P. Изменений очень мало. Консистентности нет.

По поводу oracle - дайте время поискать пруфы. Это было во времена Oracle10g. Если найду - отпишу.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464198
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonПо поводу oracle - дайте время поискать пруфы. Это было во времена Oracle10g. Если найду - отпишу.
Да верю я, что было ограничение на число нод.
Ну и что с того? 64 ноды для Oracle это дофига и больше.

Будете готовы купить Oracle на 1024 ноды (думаю стоимость лицензии под миллиард долларов уйдет + саппорт под сотню миллионов в год), Ларри Эллисон лично для Вас персональную версию Oracle Database распорядится сделать и лично же вручит лицензию и DVD диск перевязанный ленточкой )))

Не думаю, что Ларри настолько богат, что бы терять клиента, готового заплатить миллиард долларов, из-за каких-то "проблем с сетью" )))

IMHO

maytonвсе примеры - разные и неудачные.

Примеры задач, которые успешно масштабируются

Бессмысленно говорить о производительности или масштабируемости "сферического коня". Одни задачи - лучше масштабируются, другие - хуже.

DWH - масштабируются более-менее хорошо, OLTP - хуже и может требовать __переписывание__ системы.

Аналогично и холивар JIT/не JIT. C / Java. Одни задачи решаются более эффективно/проще на одном средстве, другие на другом.

Ниши применения у них достаточно разные.

Никто в здравом уме не будет делать высокопроизводительные видео-кодеки на Java, просто потому, что Java не имеет нужных инструментов (например возможность писать код с SIMD инструкциями). Так же, вряд ли кто-то будет создавать сайт-визитку в I-net на Assembler'е и MMX/SSE командах, что бы "быстрее работало"

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

А вообще, нит рассуждений я уже потерял )))

Все началось с вброса, что кто-то "Мы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор".

Желательно увидеть хоть какую-то ссылку на официальный сайт, где бы говорилось, что в следующей версии Java JIT не будет, а будет обычный компилятор.

Пока такого нет, обсуждать нечего. "Опять-таки случай так называемого вранья" ( C )
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464343
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,

Просто не нужно слишком акцентироваться на заголовке - туда развернутую мысль не всунешь.
Так что про полный отказ от JIT речь не идет. Просто вместо идеи, что JIT решает все проблемы - признали что нет, не все. И предкомпиляция нужна и даже весьма.

Если еще немного обратить внимание на Java9, то можно заметить, что делаются шаги по уменьшению монструозности
инсталляции - назвали это модульностью.

Leonid KudryavtsevАналогично и холивар JIT/не JIT. C / Java. Одни задачи решаются более эффективно/проще на одном средстве, другие на другом.

Ниши применения у них достаточно разные.

Никто в здравом уме не будет делать высокопроизводительные видео-кодеки на Java, просто потому, что Java не имеет нужных

инструментов (например возможность писать код с SIMD инструкциями). Так же, вряд ли кто-то будет создавать сайт-визитку в

I-net на Assembler'е и MMX/SSE командах, что бы "быстрее работало"
Ява более эффективна исключительно в интерпрайзном говнокодинге - она простая как тапок и любой "индус" быстро ей обучится.
А сайты- визитки продолжат делать на Пыхе.

Что же касается эффективности - то нет задач, на которой Ява будет быстрее С, она всегда пусть ненамного но отстает (этим можно обычно пренебречь).
Но это если не учитывать, что она жрет память до 10х-кратного объема от компилируемых языков.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464640
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglЧто же касается эффективности - то нет задач, на которой Ява будет быстрее С, она всегда пусть ненамного но отстает (этим можно обычно пренебречь).
Но это если не учитывать, что она жрет память до 10х-кратного объема от компилируемых языков.
истинные учёные (которые не бизнесмены) трудозатраты программистов не учитывают никогда.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464660
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и заодно предкомпиляцией подтвердили (да и джитом, как и многоядерностью тоже), что эпоха, когда скоростью железа решали проблемы тормозов, как минимум сделала длительную паузу, и требуются алгоритмы. Не так?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464822
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglЯва более эффективна исключительно в интерпрайзном говнокодинге - она простая как тапок и любой "индус" быстро ей обучится.
А сайты- визитки продолжат делать на Пыхе.

Я сегодня был на собеседовании. Меня хотят нанять на новый проект.
И из трехчасового диалога - мы говорили о Java где-то минут 15.
Все остальное - это (навскидку попробую вспомнить):
- Java (15 минут. Что-то про автобоксинг. Вобщем говно. Нечего говорить)
- Solid (типичные ошибки и нарушения любого их 5 пунктов)
- DBMS.Optimiztic-Pessimistic locking. Примеры.
- Rest/SOAP/HTTP/ORMs
- Scrum/Agile/Estimation
- CI/CD
- Security.
- SQL performance tunning (basics)
- GWT/JavaScript.
- Code style/Refactoring/SonarQube/Code quality/Metrics
- DI, testing

И этот список тем не исключительный а типичный. Поэтому "индус" быстро не обучается. Т.к. даже обученый
Java индус по прежнему никому не нужен. Таких масса. А нужен тот кто выкурит больше технологий смежных
с сабж.

Что же касается эффективности - то нет задач, на которой Ява будет быстрее С, она всегда пусть ненамного но отстает (этим можно обычно пренебречь).
Но это если не учитывать, что она жрет память до 10х-кратного объема от компилируемых языков.
Я не помню ты был участником нашего тяпничного бенчмарка?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464949
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну не всем же индусам работать тимлидами - потому такой длинный список типовому кодеру учить не надо.

Это кстати, преимущество Явы (и Питона) - что есть куча готовых инструментов и можно быстро научить новичка "методом обезъяны"

mayton..Я не помню ты был участником нашего тяпничного бенчмарка?
Был, я переводил на D.

И, насколько помню, этот процесс перевода был гораздо более гладким, чем Ява - версия. Т.е. утверждать, что Ява идеально повышает производительность труда, я бы не стал.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464982
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я просто хочу акцентировать внимание на то что Java как вещь в себе - никому не нужна.
Она сильна вовсе не языком. И вовсе не перформансом. Который по сабжу (как мы помним)
весьма неплох .(.. ну порядка 170% потраченого времени от C++ на тестах с 3D Графикой. Тот же Питон вылез
на порядки с более худшим резалтом).

Но Java сегодня КМК сильна экосистемой фреймворков и библиотек и она сильна
своим сообществом.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464995
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglЭто кстати, преимущество Явы (и Питона) - что есть куча готовых инструментов и можно быстро научить новичка "методом обезъяны"
Это преимущество 1С, "индусы" все там.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464997
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никоим образом не возражаю.

А если удастся за счет AOT выкинуть JIT из памяти (а это он ее жрет - как впрочем и С++ компилятор - Несколько сотен Мб) и с помощью JigSaw уменьшить футпринт, то будет просто супер.

Ну разве что за исключением синтаксиса - но это можно списать на вкусовщину.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39464998
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton- Solid (типичные ошибки и нарушения любого их 5 пунктов)
Самая типичная ошибка - применение его в стиле "и лоб разобьёт" :)
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465094
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglА если удастся за счет AOT выкинуть JIT из памяти (а это он ее жрет - как впрочем и С++ компилятор - Несколько сотен Мб)
Хуже отсутствующих знаний - только неправильныеjavaw -Xms1g -Xmx1g jedit.jar
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465103
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В 1.8 не знаю (они там с метаспейс больно уж намудрили), в предыдущих Java'ах JIT'у под скомпилированный код выдавали 32 Mb с возможным увеличением максимум до 64 Mb. Даже сильно enterprise проектам (Oracle Customer Care & Billing), вполне хватало
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465123
Фотография makhaon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНо Java сегодня КМК сильна экосистемой фреймворков и библиотек

Вот многие так говорят. Интересно, что же там такое есть, чего нет у других языков?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465128
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не "у других языков", а "у других экосистем".
Чтобы перенести C/C++ приложение с одной архитектуры или/и операционной системы на другую требуется:
1. Изначально заботиться о кросплатформенности;
2. Уметь собирать приложение для всех целевых платформ.
В случае Java первый пункт реализован JVM, JLS и Java SE (другими pure-java) API, второй - JRE, частью которых является JVM.
Про то, что процедура сборки java-приложения не в пример проще и полностью унифицирована - вообще молчу.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465153
Фотография makhaon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,

Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках.
Фотошоп, Офисы (и MS и бесплатные), Skype, Telegram, Viber (кроме Андроида, то есть - под Андроид написали, но это не привело к мульти-платформенности, пришлось писать на разных языках), все распространенные браузеры. Серверные Nginx, Апач сервер, Mongo DB, Ms Sql, MySQL.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465166
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov,

Т.е 180Мб этого мало?

Кроме того, посмотри пик рабочего набора - потому что JIT уже отработал в основном.

А виртуальная память не особо интересна пока не используется
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465169
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На всякий уточню - выделенная память - это виртуальная.Перевод неточный.

Рабочий набор - это оперативная память (плюс ммапные исполнимые модули почему то)
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465178
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
makhaonBasil A. Sidorov,

Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках.
Фотошоп, Офисы (и MS и бесплатные), Skype, Telegram, Viber (кроме Андроида, то есть - под Андроид написали, но это не привело к мульти-платформенности, пришлось писать на разных языках), все распространенные браузеры. Серверные Nginx, Апач сервер, Mongo DB, Ms Sql, MySQL.
native на мобильной платформе я могу объяснить. Очень сильно экономили энергию.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465286
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
makhaonBasil A. Sidorov,

Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках...
Far только под винду. Miranda тоже.
Там где деньги - перепишут под что угодно, если на этом еще денег можно заработать.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465293
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
makhaonBasil A. Sidorov,

Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках.
Фотошоп, Офисы (и MS и бесплатные), Skype, Telegram, Viber (кроме Андроида, то есть - под Андроид написали, но это не привело к мульти-платформенности, пришлось писать на разных языках), все распространенные браузеры. Серверные Nginx, Апач сервер, Mongo DB, Ms Sql, MySQL.
А все более-менее приносящее деньги, совершенно на других языках )))

Oracle E-Business Suite, SAP R3, etc... etc...

Я так понимаю, по сравнению с баблом который течет с enterprise консалтингового рынка, даже MS Windows - детский лепет )))
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465331
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglТ.е 180Мб этого мало?Вы правда считаете, что Seamonkey на скриншоте в двух местах - просто так?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465334
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovSiemarglТ.е 180Мб этого мало?Вы правда считаете, что Seamonkey на скриншоте в двух местах - просто так?Я думаю что надо пояснять свою мысль.

У меня она была проста - компилятор в памяти => несколько сотен Мб.

А в чем суть сравнения с Сеаманки я не понимаю - современный браузер гораздо сложнее текстового редактора jEdit и содержит внутри себя кучу интерпретаторов CSS/HTMLK/JS и мало ли что еще.
Тогда уж с Netsurf сравнивать.

Но повторяю, я идею из слинкованного скриншота не оценил - ну запросили зарезервировать память Яве - она и система сделали, но память виртуальная и пока что ни на что не влияет.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465392
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglчто надо пояснять свою мысль.

У меня она была проста - компилятор в памяти => несколько сотен Мб.

Хотелось бы видеть откуда взялась цифра "несколько сотен"

По ощущениям, там даже несколько десятками не пахнет. Накладные расходы по памяти для Java 1.6 были порядка 32 Mb под скомпилированный код (можно уменьшить или увеличить). Сколько занимает собственно код самого компилятора, не знаю. Но сомневаюсь, что это больше десятка - двух десятков мегабайт. Т.е. на мой взгляд, накладные расходы и до 100 Mb не дотягивают.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465436
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
By the way,

Там очень большие накладные расходы совершенно в другом. В потоках. Если на компьютере 256 процессоров, Java по умолчанию под 200+ потоков компилятора и garbage collector'а запускает... занафига?... никому не известно.... ответ из Oracle на одном из форумов "у нас enterprise решение, нужно использовать все ресурсы компьютера" )))

Т.ч. даже примитивная программа Hello World начинает создавать под 400-500 потоков и больше... в ряде случаев, это приводит к пушному зверьку, который феерический отсвечивает всеми цветами радуги на системном мониторинге и грузит процессор под 100%.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465439
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На одном из буржуйских форумов, читал негодование человека, у него какая-то примитивная программа на Java для мониторинга, которая на "обычном" компе потребляла десяток мегабайт, на сервере хотела > 2 Gb оперативки ))) просто на сервере 256 процессоров )))

Весь прикол заключался в том, что программа встроена была в ядро Солярки и доступа к ключам JVM не было. И, вроде, писец доходил до того, что она на сервере вообще запустится не могла.... в результате сервер "не все функции выполнял". В общем, дефолтные значения в Java Oracle менять отказался, сказав "что Java создана для серверов и должна использовать все возможные ресурсы " ))) пообещали наехать на коллег которые пишут Солярку и сделать патч для Солярки ))) чем дело кончилось, на форуме не сообщалось )))
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465445
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevТ.ч. даже примитивная программа Hello World начинает создавать под 400-500 потоков и больше... в ряде случаев, это приводит к пушному зверьку, который феерический отсвечивает всеми цветами радуги на системном мониторинге и грузит процессор под 100%.
Описано красочно. И... очень эмоционально. Я охотно верю в то что рантайм оставляет за собой право
запускать нужное количество потоков под нужный getAvailableProcessors() но в то что это приводит
к пушному зверьку для HelloWorld я не верю. Или надо детально разбираться уже имея доступ к консоли.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465446
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevВесь прикол заключался в том, что программа встроена была в ядро Солярки и доступа к ключам JVM не было. И, вроде, писец доходил до того, что она на сервере вообще запустится не могла.... в результате сервер "не все функции выполнял". В общем, дефолтные значения в Java Oracle менять отказался, сказав "что Java создана для серверов и должна использовать все возможные ресурсы " ))) пообещали наехать на коллег которые пишут Солярку и сделать патч для Солярки ))) чем дело кончилось, на форуме не сообщалось )))
Насколько я понимаю "хозяин" приложения встроил запуск приложения на java ... в т.н. ядро солярки и не дал возможности
управлять ключами и опциями. Что-ж. Он - сам себе злобный Буратино.

Но если в этой формулировке убрать "java" и заменить это на что-то другое, то становиться очевидным что это configuration
bug и его надо фиксить.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465460
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton....но в то что это приводит
к пушному зверьку для HelloWorld я не верю. Или надо детально разбираться уже имея доступ к консоли.
Приводит. Когда на сервере крутится много приложений HelloWorld и каждое пытается дофига потоков создать. Накладные расходы представить можно.

В реальности на 40-ка ядерном сервере, на реальной системе, было примерно 5-6 пользовательских потоков (потоков мало, т.к. NIO) и >60 системных. Пушной зверек по показателям системного мониторинга был во всей красе. Судя по всему, overhead на переключения потоков при __таком__ паттерне нагрузки был ужасающий. Что именно не нравилось шедулеру и что безумно нагружало систему, не знаю. Но ситуация была совершенно ненормальная. CPU просто непонятно куда девалось, в между-thread пространство.

Когда в приложении было 200 пользовательских потоков (обычный IO) и те же 60 системных - эффект не проявлялся. Загрузка CPU была нормальной. Как только пользовательских потоков стало мало - потребление CPU выросло в разы (по всей системе) и возможно даже на порядки (по выполняемому коду). Сократили системные потоки (до 4 потоков на GC и 2 потока на JIT) - все нормализовалось, потребление CPU упало в 3-4 раза. Статистика в gc.log осталась примерно той же.

Ну и у человека тоже ситуация была красивая. Сервер с 256-процессорами и какой-то банальный агент не может запуститься... не хватает памяти )))
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465461
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton....Но если в этой формулировке убрать "java" и заменить это на что-то другое, то становиться очевидным что это configuration
bug и его надо фиксить.
Да это понятно.

Дело в другом. Что фиг кто о таком __документированном__ поведении Java знает и задумывается. А когда видишь такое в живую.... месяц уходит, что бы понять, в чем же тут дело и кто виноват.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465780
exp98
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вы замечательно описали последствия от применения "безискусьвенного интеллекта" (имею ввиду т.н. "умное" перераспределение ресурсов в динамике).
Вопрос из сабжа только остаётся открытым, кто виноват должен браться за ум? и что делать возьмётся ли?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465797
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevSiemarglчто надо пояснять свою мысль.

У меня она была проста - компилятор в памяти => несколько сотен Мб.

Хотелось бы видеть откуда взялась цифра "несколько сотен"

По ощущениям, там даже несколько десятками не пахнет. Накладные расходы по памяти для Java 1.6 были порядка 32 Mb под скомпилированный код (можно уменьшить или увеличить). Сколько занимает собственно код самого компилятора, не знаю. Но сомневаюсь, что это больше десятка - двух десятков мегабайт. Т.е. на мой взгляд, накладные расходы и до 100 Mb не дотягивают.
Несколько сотен - до 400Мб можно наблюдать при компиляции чего то большого С++ что gcc, что clang.
Поскольку уровень оптимизации в Яве сравним - то можно предположить, что и затраты на компиляцию будут сравнимыми - язык конечно проще, но не сильно.

"По ощущениям" - метрика конечно еще та, но:
- поковыряв доступными системными инструментами Rammap/vmmap, я конкретики тоже не увидел.
- Helloword должен загрузить как минимум интерпретатор - но он потребляет 12Мб

С этой стороны непонятно, куда используется память.

Еще погуглил на тему Java Mission Control - нашел кое что интересное
-
YouTube Video
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465810
Фотография makhaon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу GC. Мы как-то делали скрипты (Power Shell), занимающиеся многопоточным копированием файлов. Они забивали абсолютно всю память, 99.99% процессорного времени и вывешивали намертво сервера. Довольно нетривиальным способами + постоянным ручным вызовом сборщика удалось довести до более-менее работоспособного состояния.

Рядом тихи-мирно трудился нативный сервер (Delphi) с раз в 5 большим числом потоков, поставляя эти файлы скрипту и разруливая кучу запросов. Занимая мизер ресурсов.

Вот такой опыт.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39465836
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще добавлю. Когда говорят о том что GC плох - то говорят о "GC в вакууме".
На самом деле в Java их существует минимум 2. Классический ParallelGC, старый.
И G1GC который позиционируется как новый ему на замену.

Есть еще SerialGC который почти ничем не отличается от первого алгоритмически
и есть также CMS который проектировался для UI приложений типа сред разработки.
Плюс разные коммерческие с закрытым кодом типа С4, и другие о которых нам не известно.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466111
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglЯ думаю что надо пояснять свою мысль.А я знаю , что вы так ничего и не поняли ...
Для Oracle JRE/JDK - виртуальная ява-машина это jvm.dll. JVM с "серверным" (C2) JIT - ~6,3Мб (x86, клиентский - раза в полтора меньше). 64-разрядная JVM (только C2) - ~8,8Мб.
IBM J9 устроена по другому - там, в частности, и ваш любимый AOT в наличиии, но суммарный размер каждого из каталогов с разными вариантами компиляторов - в пределах 30Мб.
Так вот, к чему я всё это ...
Утверждать, что компилятор промежуточного представления в машинный код (бэкэнд) требует столько же ресурсов, что и "полный фарш" (фрон и бэк) - так же странно, как и предполагать, что, после загрузки с диска, мегабайты машинного кода раздуются до сотен мегабайт.
Далее, на моём скриншоте можно увидеть, что "нативный" браузер, загрузив одну страничку требует вдвое больше памяти, чем "ява-пюре" текстовый редактор с вполне приличным функционалом.
У кого как, но лично у меня возникает вопрос - если вполне простая задача обработки данных (отображение несложной HTML страницы веб-сервера) требует сотен мегабайт памяти для данных , то какая разница - сколько экономит нативный код, если объективный пользователь это разницу не сможет даже измерить. Я уж молчу о "почувствовать"?
Нахрена нужен это крестовый поход за "натуральный продукт" и против "богомерзких промежуточных представлений"?

P.S. High Perfomance Java Compiler - это был такой проект на IBM-овском AlphaWorks в начале нулевых. Потом межделмаш перевёл проект в категорию коммерческих. Весьма вероятно, что нынешний AOT из J9 - наследник того самого HPJC.
Несколько ранее пророки встроили "jvm реального времени", сейчас будут встраивать AOT - нормальный деловой процесс.
Накойхер было поднимать безоглядный кипеш?
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466580
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov...Утверждать, что компилятор промежуточного представления в машинный код (бэкэнд) требует столько же ресурсов, что и "полный фарш" (фрон и бэк) - так же странно, как и предполагать, что, после загрузки с диска, мегабайты машинного кода раздуются до сотен мегабайт.Да, с первым утверждением я согласен (недодумал) - фронтенд С++ должен потреблять львиную долю ресурсов.

Со вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного? Кстати, у п-кода, да еще ООП должно быть весьма сложно реализовать возможность постраничной загрузки по pagefault - требованию. Т.е в память надо грузить все и ой - это же zip - памяти надо вдвое. Ну или очень медленно.

Basil A. Sidorov..Далее, на моём скриншоте можно увидеть, что "нативный" браузер, загрузив одну страничку требует вдвое больше памяти, чем "ява-пюре" текстовый редактор с вполне приличным функционалом.
У кого как, но лично у меня возникает вопрос - если вполне простая задача обработки данных (отображение несложной HTML страницы веб-сервера) требует сотен мегабайт памяти для данных , то какая разница - сколько экономит нативный код, если объективный пользователь это разницу не сможет даже измерить. Я уж молчу о "почувствовать"?
Нахрена нужен это крестовый поход за "натуральный продукт" и против "богомерзких промежуточных представлений"?Давайте сравнивать огурцы таки с огурцами -
Jedit vs Notepad++
потребляет в 3.5 раза больше памяти и ввода-вывода при загрузке, и стартует (в виртуалке - а скоро все там будем) 5.4 сек против 1.5 сек
Вполне себе можно прочувствовать и измерить. Кажется уже обсуждали.

Basil A. Sidorov..
Накойхер было поднимать безоглядный киеш?А это и не кипешь - это собственно положительная реакция на нововведение. Вот скоро выйдет Java9, померяем и сравним - стало ли лучше и насколько.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466617
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargl5.4 сек против 1.5 сек
твоя работа в постоянном перезапуске приложения заключается?

Не вздумай работать с приложениями Autodesk
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466649
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного? Кстати, у п-кода, да еще ООП должно быть весьма сложно реализовать возможность постраничной загрузки по pagefault - требованию. Т.е в память надо грузить все и ой - это же zip - памяти надо вдвое. Ну или очень медленно.
Нет. Не превращаются. Ну.... не все 52Мб. Если вы запустите java -verbose:class то увидите спул работы Classloaders.
Грузится не весь rt.jar а только те classes которые есть в зависимостях.

Кстати этот аспект повлиял на введение модулей в Java9.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466672
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилSiemargl5.4 сек против 1.5 сек
твоя работа в постоянном перезапуске приложения заключается?

Не вздумай работать с приложениями AutodeskЭто да, мне иногда нужно просмотреть сотню-другую dwg-файлов. Чтобы не тр-ься с DЦП TrueView, я просто говорю - присылайте сразу в pdf

maytonSiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного? Кстати, у п-кода, да еще ООП должно быть весьма сложно реализовать возможность постраничной загрузки по pagefault - требованию. Т.е в память надо грузить все и ой - это же zip - памяти надо вдвое. Ну или очень медленно.
Нет. Не превращаются. Ну.... не все 52Мб. Если вы запустите java -verbose:class то увидите спул работы Classloaders.
Грузится не весь rt.jar а только те classes которые есть в зависимостях.

Кстати этот аспект повлиял на введение модулей в Java9.Ок, но это приличная разница между п- и машкодом
-распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и
-загрузить 4кб по нужному смещению из dll
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466680
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
предков еще можно выбрать по имени каталога, которое совпадает с иерархией классов, но вот перекрестные зависимости.....
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466714
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonSiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного?....
Нет. Не превращаются. ....
Нет. Не превращаются. Физически превратиться не могут. Кто же им даст?
Параметр такой есть, командной строки:

-XX:ReservedCodeCacheSize=32m

Т.ч. максимум в 32m превратиться могу (by default).

Ох уж эти сказочники, ох уж эти сказочники.... ( C )

[spoiler]
YouTube Video
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466748
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466795
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну я с таким сообщением ни разу не сталкивался. Вот 750-800 мегабайт под классы (PermGen) - бывало приходилось выделять, а с данной областью памяти проблем не было
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466936
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglОк, но это приличная разница между п- и машкодом
-распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и
-загрузить 4кб по нужному смещению из dllВы опять недодумали: когда работает JIT - всё уже загружено и слинковано.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39466952
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного?
"Знай, что хаешь" (ц) dz
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
java -Xshare:dump&dir server\classes.jsa&java -version
Allocated shared space: 37879808 bytes at 0x0000000800000000
Loading classes to share ...
Preload Warning: Cannot find sun/security/provider/DSA$LegacyDSA
Loading classes to share: done.
Rewriting and linking classes ...
Rewriting and linking classes: done
Number of classes 2481
    instance classes   =  2467
    obj array classes  =     6
    type array classes =     8
Calculating fingerprints ... done.
Removing unshareable information ... done.
Shared Lookup Cache Table Buckets = 8216 bytes
Shared Lookup Cache Table Body = 64736 bytes
ro space:   6521552 [ 35.2% of total] out of  16777216 bytes [38.9% used] at 0x0000000800000000
rw space:  10408208 [ 56.2% of total] out of  16777216 bytes [62.0% used] at 0x0000000801000000
md space:   1548120 [  8.4% of total] out of   4194304 bytes [36.9% used] at 0x0000000802000000
mc space:     34053 [  0.2% of total] out of    131072 bytes [26.0% used] at 0x0000000802400000
total   :  18511933 [100.0% of total] out of  37879808 bytes [48.9% used]

06.06.2017  20:47        18 677 760 classes.jsa

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Да, J(ava)S(hared)A(rchive) не компиляция в нативный код. Но! Прежде чем фантазировать о гигабайтах и мегаиопсах - не худо бы ознакомиться с вопросом, чтобы понимать адекватность не только используемых инструментов, но и выбранных метрик.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39467074
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglОк, но это приличная разница между п- и машкодом
-распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и
-загрузить 4кб по нужному смещению из dll
И это еще не все. Если верить Шипилёву... и его конференциям (а я ему вобщем-то верю т.к. оппозиционных мнений
просто не существовало в момент доклада и после) то существует целый слой т.н. intrinsic методов
которые уже собраны нативно (в частности методы класса String:: и пространства java.nio.*) и используют SSE инструкции
для оптимизации некоторых низкоуровневых операций типа копирования из строк в строки.
И это еще в семерке и в восьмерке. Поэтому в части runtime я думаю что "все уже украдено
до нас" и умные люди давно уже ломали голову как разогнать системные классы и я думаю
что там уже все разогнано.

Вот прикладной код. Это дааа... это вопрос.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39467216
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На знал про intrinsic методы, слушок был, но точно не знал.

Список intrinsic методов захардкоденных в Open JDK:

http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/vmSymbols.hpp#l581
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39467346
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovSiemarglОк, но это приличная разница между п- и машкодом
-распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и
-загрузить 4кб по нужному смещению из dllВы опять недодумали: когда работает JIT - всё уже загружено и слинковано.
Линковка это в т.ч процесс проставления физических адресов вызываемых функций в вызываемой. Потому пока JIT не сгенерирует машкод, проставлять еще просто нечего.

JSA - посмотрю что за зверь, и включен ли по умолчанию. Ознакомлюсь с вопросом =)
PS. Надеюсь что dz это не Завалишин /=

maytonИ это еще не все. Если верить Шипилёву... и его конференциям (а я ему вобщем-то верю т.к. оппозиционных мнений
просто не существовало в момент доклада и после) то существует целый слой т.н. intrinsic методов
которые уже собраны нативно (в частности методы класса String:: и пространства java.nio.*) и используют SSE инструкции
для оптимизации некоторых низкоуровневых операций типа копирования из строк в строки.
И это еще в семерке и в восьмерке. Поэтому в части runtime я думаю что "все уже украдено
до нас" и умные люди давно уже ломали голову как разогнать системные классы и я думаю
что там уже все разогнано.

Вот прикладной код. Это дааа... это вопрос.
Это великолепно контрастирует с утверждениями, что JIT тем и хорош, что может оптимизироваться на лету под процессор исполнения Бггг.
Но
-со скоростью кода в яве и так все неплохо
-линкеру неважно какой код подставлять - интринсик или свеже-сгенерированный
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39467907
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglЭто великолепно контрастирует с утверждениями, что JIT тем и хорош, что может оптимизироваться на лету под процессор исполненияПросто в конкретном x86-мире всё очень однозначно - сопроцессор вшит на кристалл ещё со времён Pentium, SSE - со второй половины нулевых.
Но вот если вам потребовалось "переехать" с x86-64 на ARM или на экзотику типа Power, то разница будет, даже если лично вы не сможете эту разницу оценить.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39468243
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovSiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного?
"Знай, что хаешь" (ц) dz
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
java -Xshare:dump&dir server\classes.jsa&java -version
Allocated shared space: 37879808 bytes at 0x0000000800000000
Loading classes to share ...
Preload Warning: Cannot find sun/security/provider/DSA$LegacyDSA
Loading classes to share: done.
Rewriting and linking classes ...
Rewriting and linking classes: done
Number of classes 2481
    instance classes   =  2467
    obj array classes  =     6
    type array classes =     8
Calculating fingerprints ... done.
Removing unshareable information ... done.
Shared Lookup Cache Table Buckets = 8216 bytes
Shared Lookup Cache Table Body = 64736 bytes
ro space:   6521552 [ 35.2% of total] out of  16777216 bytes [38.9% used] at 0x0000000800000000
rw space:  10408208 [ 56.2% of total] out of  16777216 bytes [62.0% used] at 0x0000000801000000
md space:   1548120 [  8.4% of total] out of   4194304 bytes [36.9% used] at 0x0000000802000000
mc space:     34053 [  0.2% of total] out of    131072 bytes [26.0% used] at 0x0000000802400000
total   :  18511933 [100.0% of total] out of  37879808 bytes [48.9% used]

06.06.2017  20:47        18 677 760 classes.jsa

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Да, J(ava)S(hared)A(rchive) не компиляция в нативный код. Но! Прежде чем фантазировать о гигабайтах и мегаиопсах - не худо бы ознакомиться с вопросом, чтобы понимать адекватность не только используемых инструментов, но и выбранных метрик.
В доке написано, что это предварительная компиляция rt.jar во внутренний формат VM.
Только не верится, что 52Мб rt.jar превращается в 12Мб classes.jsa.
Кстати, сжатия rt.jar не применяет.

Написано, что по умолчанию JSA уже используется. Попытка форсить (-Xshare:on) или запрещать к видимым изменениям скорости загрузки не привела.

Кроме того, форс работает на винде через раз - вылетая с такой диагностикой, как тут

Ну ок. Если гипотезу откидываем, что rt.jar раздувается в сотни Мб, то надо Жруна искать дальше (GC пока остается под подозрением). Ждем релиз Java9 и будем смотреть, что изменилось.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39468354
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При интнинзик где-то на 40-й минуте

YouTube Video
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39468922
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglКстати, сжатия rt.jar не применяетНу так примените. Можете ещё "переехать" (un)pack200, чтобы убрать отладочную информацию.
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39469037
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. SidorovSiemarglКстати, сжатия rt.jar не применяетНу так примените. Можете ещё "переехать" (un)pack200, чтобы убрать отладочную информацию.
Наоборот хорошо, значит там 52Мб байткода а не 100
...
Рейтинг: 0 / 0
Java JIT - всё? Берёмся за ум
    #39477310
Еще один до сих пор не знает, что такое AOT, которое в .NET было с самого начала, в виде утилитки ngen. .NET Native утилитарная параша, которая нужна тока для мобильной мелкософтовской хрени, т.е. <5% рынка. Так что JIT+AOT/ngen никуда не уходил и живее всех живых. А ты просто слышал звон, да не знаешь где он.
...
Рейтинг: 0 / 0
111 сообщений из 111, показаны все 5 страниц
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Java JIT - всё? Берёмся за ум
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]