|
|
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
TL;DR Мы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор https://habrahabr.ru/company/jugru/blog/329728/ От меня: просто так без жертв не выйдет, как и для NET native, но в целом +... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 23:10 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
на SQL.ru модно стало с GT и HABRAHABRA статьи репостить? это вообще соответствует правилам форума? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2017, 23:41 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Roman Mejtes, Это не репост, и не моя статья. Да и здесь площадка, для статей, мягко говоря - непригодная. Так что радоваться надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 00:29 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Siemargl...но теперь признаем, что надо просто сделать обычный компилятор Вот хорошо бы теперь ссылку на официальный сайт Oracle дать в подтверждение этого высказывания. А то получается "опять-таки случай так называемого вранья" ( C ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 01:00 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglМы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор У JIT тоже есть шанс. 20506460 Случайно выяснилось что на разных процах .NET работает по-разному и даже иногда обгоняет С++. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 07:30 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglTL;DR Мы очень долго пытались всех на%^&ть с JIT, но теперь признаем, что надо просто сделать обычный компилятор https://habrahabr.ru/company/jugru/blog/329728/ От меня: просто так без жертв не выйдет, как и для NET native, но в целом +... не совсем понятно откуда вырван контекст, там куча презентаций ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 08:10 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TСлучайно выяснилось что на разных процах .NET работает по-разному и даже иногда обгоняет С++. А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 13:32 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockА как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то. имеется ввиду сравнение кодогенераторов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 14:05 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockDima TСлучайно выяснилось что на разных процах .NET работает по-разному и даже иногда обгоняет С++. А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то. Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 14:16 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TНеверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят. Еще одно теоретическое достоинство JIT, что он имеет доступ к статистике выполнения кода. Т.е., теоретически, располагает информацией о профиле нагрузки на конкретный код в конкретном алгоритме, что большой плюс. Например можно оптимизировать промахи предсказателя переходов и так далее. Теоретически, т.к. насколько эффективно это реализовано в JIT-компиляторах - огромный вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 14:42 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TYuRockпропущено... А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то. Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят.Может, но на практике я подтверждений этому не видел. Даже наоборот -JIT тратит гораздо больше ресурсов на компиляцию/оптимизацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 21:13 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TYuRockпропущено... А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то. Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят. Не вижу, где "неверно". Если компилятор C++ сгенерил бинарник под конкретную платформу - то он только в ней и запустится. И, конечно же, он знал, под какую нужно оптимизировать. Под какой проц, если речь о нативном бинарнике. Я уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 23:46 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRock...Я уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp.И лучше не говори, о слишком сложных для тебя вещах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2017, 23:51 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglYuRock...Я уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp.И лучше не говори, о слишком сложных для тебя вещахТа с удовольствием бы, но не могу пройти иногда мимо, когда чайник с водой сравнивают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 00:00 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRock, Ага. Пойми принципиальное отличие C++ от C++/CLI, C++/CX Эти гон..ны хотят под прикрытием марки С++ продвинуть свой крючок в твоей з.д..це, а ты подставляешься ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 00:27 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglYuRock, Ага. Пойми принципиальное отличие C++ от C++/CLI, C++/CX Эти гон..ны хотят под прикрытием марки С++ продвинуть свой крючок в твоей з.д..це, а ты подставляешься Слушай, мне пофиг вообще все эти войны, они меня не возбуждают. Но как ты ни крути, c++ - язык, а .net - платформа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 00:45 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TВ итоге все компилируется в машинный код, т.е. в ассемблер это разные понятия ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 00:53 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockЯ уже не говорю о том, что на C++ можно создавать бинарники под платформу .net или uwp. это не C++ , а неведома зверушка от MS (Managed C++) YuRockЕсли компилятор C++ сгенерил бинарник под конкретную платформу компилятор C++ вполне может ограничиться генерацией кода LLVM и отложить генерацию машинного кода ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 00:58 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Изопропилкомпилятор C++ вполне может ограничиться генерацией кода LLVM и отложить генерацию машинного кодаЯ для простоты написал. А строго говоря компилятор, C++ в частности, объектные файлы генерит. А что потом из них делается и под какую платформу - другой вопрос. Изопропилэто не C++ , а неведома зверушка от MS (Managed C++)Синтаксис похож на C++? Это уже не мало. В Delphi "nextgen", вон, и строки с нуля, и счетчик ссылок на объекты для их самоудаления... А всё равно это паскаль. Как и "Delphi .net" давно мёртвый тоже Паскалем был. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 01:20 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockDima Tпропущено... Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят. Не вижу, где "неверно". Если компилятор C++ сгенерил бинарник под конкретную платформу - то он только в ней и запустится. С++ генерит готовый бинарник под конкретную платформу и на другой уже не запустится. .NET (даже при использовании его из С++) генерит промежуточный IL код, который будет "докомпилирован" во время запуска. Поэтому в случае С++ мы выбираем: либо компиляция под любой проц, либо под конкретный, но на другом бинарник может не заработать. В случае с .NET этой проблемы нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 07:41 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockНо как ты ни крути, c++ - язык, а .net - платформа. Все это маркетинг от МС. Они так хорошо все запутали, что без бутылки не разобраться. Если упрощенно: .net это среда исполнения IL кода. Получить IL код (сборку) можно компиляторами C#, F#, VB.NET и т.д. Причем в готовом приложении можно скомбинировать сборки от разных ЯП. В основном под .net пишут на C#. С++ не умеет компилировать .net сборки, он может только использовать готовые, но на практике это мало кто использует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 07:57 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TС++ не умеет компилировать .net сборки поделка под названием "managed c++" - может создавать чистые .net сборки, ключик для этого у cl есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 08:26 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Если рассматривать пользу от байткода за последние годы со времен JDK 1.1 то я-бы сказал что он внес неоценимый вклад в развитие Open-Source. Именно благодаря строгому стандарту, и возможности делать рефлексию мы сегодня имеем ГАРАНТИИ прозрачности использования интерфейсной части любой Java-библиотеки. Про .Net я точно не скажу но думаю что некоторые пункты будут тоже аналогичны. Что будет если мы из стека технологии убираем байткод? Тоесть переходим к классической модели дистрибуции ПО. Наш Open-Source станет хуже? Или станет ли менее открытым способ распространения кода? Прошу высказать ваше мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 09:05 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
maytonПрошу высказать ваше мнение. ничего не произойдёт, говнокод останется говнокодом, в частности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 09:22 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
maytonЧто будет если мы из стека технологии убираем байткод? Тоесть переходим к классической модели дистрибуции ПО. Наш Open-Source станет хуже? Или станет ли менее открытым способ распространения кода? С/С++ Open-Source как-то живет без байт-кода. Распространение станет менее удобным, т.к. компилировать придется под конкретную платформу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 09:44 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
mayton, Это называется модульность. Есть в разных языках и не особо как то влияет на открытость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 09:57 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TYuRockНо как ты ни крути, c++ - язык, а .net - платформа. Все это маркетинг от МС. с++ придумал на MS. Он был языком, когда MS еще не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 11:44 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockDima Tпропущено... Все это маркетинг от МС. с++ придумал на MS. Он был языком, когда MS еще не было. Я про .Net и все что с ним связано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 11:50 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TYuRockпропущено... А как может платформа быть быстрее языка программирования (на котором, к слову, можно писать программы для этой платформы)? Абсурд какой-то. Неверно. В итоге все компилируется в машинный код, т.е. в ассемблер. Только по-разному: .NET учитывает особенности конкретного проца, т.к. компиляция идет по месту, а С++ нет, т.к. понятия не имеет где его запустят. Для оптимизации работы приложения под конкретную платформу испокон веков используется модульная(плагинная) архитектура. Например, древний Adobe Photoshop подключал модули использующие MMX-команды (и другие SIMD-расширения), если видел, что процессор их поддерживает. Практически все CAD-системы делают аналогично, настраиваясь на аппаратное и программное окружение. Поэтому утверждение о "медленности" С++ по сравнению с .NET - маркетинговый ход. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 11:59 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Siemarglmayton, Это называется модульность. Есть в разных языках и не особо как то влияет на открытость. Я говорю о свойствах рефлексии байт-кода и интроспекции. Про модульность я вообще не говорил и это отдельная "плоскость" или "измерение" если хотите. Если разработчики Jdk9/Java9 перейдут на модель дистрибуции основанную на платформенном коде то я считаю что это нанесет некоторый ущерб открытости. Впрочем за это говорить еще рано. Давайте посмотрим что будет в девятке и как. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 12:02 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
andr_andreyПоэтому утверждение о "медленности" С++ по сравнению с .NET - маркетинговый ход. Я выше ссылку давал на результаты конкретного теста. И не утверждал что С++ медленнее. Не надо передергивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 12:07 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
maytonЧто будет если мы из стека технологии убираем байткод? Тоесть переходим к классическоймодели дистрибуции ПО. Можно вспомнить легенду для чего создали яву. Согласно преданию неск. чел-к хотели, чтобы оно везде могло работать, вот и порешили использовать всеобщий интерпретатор. Если его убрать, то дотнет и ведроид будут навроде радстудии - такой же вещью в себе. С разницей лишь, что рад и нет станут похожими по концепцииям, если захочется сохранить заменяемость c# / vb# ... , к-рые тогда вновь станут обычными, без диезов. Ну а ява - не фиг тогда 1 класс= 1 файл с тем же именем. И что станет с JSP я Х3. И как там будет с прозраачностью или открытостью - тоже Х3. Смартфончики, хе-хе - тут уж выбирай сильно заранее, на чью марку подсесть. А кому все эти резиновые интерфесы станут нужны? Во, блин! веб-дизайнерам лафа настанет. Короче, не было гвоздя - подкова пропала, не было подковы - лошад за хромала ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 12:20 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
авторС выпуском JDK 9 «из коробки» появляется возможность статической компиляции, т.е. преобразования в код целевой платформы (т.н. native). Правда, пока только под Linux. Поразительно, как весь мир массово занимается творческим онанизмом и генерацией энтропии годами и десятилетиями вместо работы :) Ну да ладно - пусть развлекаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 13:28 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Мы делали, делали, делали, и, наконец, к 9-й версии, придумали компилятор! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 13:32 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Пока этот топик - собрание научной фантастики и туманных прогнозов. Давайте еще раз внимательно прочитаем JEP 295: Ahead-of-Time Compilation http://openjdk.java.net/jeps/295 и попытаемся понять о чем там вообще идет речь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 14:23 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TЯ про .Net и все что с ним связано. Ты сравнивал язык и платформу. Это всё равно, что сказать "По учебникам математики" учиться математике быстрее, чем по учебникам, написанным на русском языке. При том, что учебники математики одинаковы на всех языках (к примеру). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 15:09 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockDima TЯ про .Net и все что с ним связано. Ты сравнивал язык и платформу. Это всё равно, что сказать "По учебникам математики" учиться математике быстрее, чем по учебникам, написанным на русском языке. При том, что учебники математики одинаковы на всех языках (к примеру). .Net платформа только для языков созданных для нее (C#, F#, VB.NET и т.д.) и С++ к ним не относится. Я сравнивал скорость работы алгоритма на C# и на С++ (исходники тут 20505601 ), но с таким же успехом я мог написать на VB.NET, т.к. к итоге мой код откомпилируется в IL-код .Net, а при запуске .Net скомпилирует IL-код его в бинарный код. В отличии от С++, который сразу компилирует в бинарный код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 15:43 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
YuRockТы сравнивал язык и платформу. Топик именно об этом: что лучше JIT-компилятор или обычный компилятор. Собственно поэтому я написал .Net, т.к. это и есть JIT-компилятор. В том ключе, в котором ты смотришь на мои посты, наверно, правильнее было бы писать C#. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 15:52 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
maytonПока этот топик - собрание научной фантастики и туманных прогнозов. Давайте еще раз внимательно прочитаем JEP 295: Ahead-of-Time Compilation http://openjdk.java.net/jeps/295 и попытаемся понять о чем там вообще идет речь. Это же читать, переводить и думать надо (((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 17:52 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Топик IMHO банален автор топикано теперь признаем, что надо просто сделать обычный компилятор М.Булгаков Мастер и маргаритаопять-таки случай так называемого вранья ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 17:55 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Собственно, тема появилась одновременно с самими jit компиляторами. И дело не в .NET и C++ Реальный вопрос такой - может ли jit-компилятор быть быстрее обычного компилятора? Ответ очевиден - да, может. Теоретически. А дальше есть много факторов - среда, железо, софт. Банально - компилятор не может знать о наличии расширенных инструкций у проца (ключи компиляции и исходники - из другой оперы), а вот jit-компилятор - легко. Ускорение и в 10, и в 100 раз может быть! В теории) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 18:54 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
ИМХО На практике в итоге упремся в нехватку кэша проца, т.е. тормоза чтения из памяти и при многопоточности в тормоза синхронизации кэшей проца . И тут пофиг JIT или нет компилятор. Тут важно как код написан, т.е. алгоритмы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 19:54 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
На практике за JIT мы платим свою плату. Например PermGen (Metaspace) всегда будет хранит копии модулей байткода даже если они уже переложены в native. По сути имеет место дублирование логики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:12 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima TИМХО На практике .....упремся... На какой практике? Обычно, в космической практике, сферические кони в вакууме никуда упираться не должны! Т.к. по методологие, сферические кони должны плавать в полном вакууме. А в вакууме, по определению, не должно быть ни памяти, ни синхронизации. Т.ч., если все сделано верно, то упираться в них кони никак не могут! Если же у Вас они упираются, Вы где-то ошиблись и отступили от методологии. Ищите ошибку в Вашем коде. IMHO & AFAIK Dima T.... тормоза чтения из памяти и ... совершенно детсадовское изложение принципов работы вакуумных насосов и психологии коней может быть 100500 причин, почему IPC не достигает максимального значения, скорость памяти - лишь одна из них и, скорее всего, даже не основная Т.к.: 1) AFAIK значительно более частая ситуация, что инструкции не могут быть поставлены на выполнение, т.к. ожидают данных от пред. инструкций 2) "скорость памяти" это вообще мифологическое существо. У процессора есть кэшь. Доступ к которому занимает несколько тактов. Т.ч. "скорость памяти", вроде даже и термина такого в пакетах типа Intel VTune нет. Она никого не интересует. Есть метрика промахи кэша (вроде даже разнообразные). Которые, опять таки, могут возникать по 100500 причинам. и так далее.... IMHO & AFAIK. Не являюсь специалистом по high performance, Intel VTune последний раз запускал много-много лет назад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:17 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
maytonНа практике за JIT мы платим свою плату. Например PermGen (Metaspace) всегда будет хранит копии модулей байткода даже если они уже переложены в native. По сути имеет место дублирование логики. Дублирование при современных компьютерах - фигня Самая большая проблема, возрастает сложность системы. Никто не может объяснить, как же этот JIT работает. Поэтому, если все хорошо, все счастливы и восхваляют создателей. А если что-то не хорошо... то никто не знает, что делать... если есть бубны - берут бубны... если есть деньги - начинают ритуалы поклонения карго-культу... А истина элементарна. Никто не знает, как же оно на самом деле работает. Разных теорий и точек зрения мульон, а как же на самом деле - никто не знает. Возможно, даже не знают создатели JIT и Java. Слишком велика сложность получившейся системы. И слишком она, в силу своей сложности, стала закрытой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:23 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, о какой закрытости ты говоришь? Есть сорцы. Сиди.. разбирайся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:33 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevDima TИМХО На практике .....упремся... На какой практике? Например используя буфер влезающий в кэш проца я ускорил расчет вдвое. По второму пункту тут добавив выравнивание под кэш линию проца (class lite_align64_t) я ускорил тест с 35 до 40 млн. попугаев в секунду. Вот такая практика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:34 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevНа какой практике? Обычно, в космической практике, сферические кони в вакууме никуда упираться не должны! Т.к. по методологие, сферические кони должны плавать в полном вакууме. А в вакууме, по определению, не должно быть ни памяти, ни синхронизации. Т.ч., если все сделано верно, то упираться в них кони никак не могут! Если же у Вас они упираются, Вы где-то ошиблись и отступили от методологии. Ищите ошибку в Вашем коде. Я месседж Димы понял так. - Мы не можем наращивать производительность в одном слое архитектуры. Например подтянули больше ядер процессоров - получили когерентность. Блокировки... спины.. стали взымать с нас "дань" просто так. Просто подняли тактовую частоту - надо поднимать и частоту системной шины и как следствие планок памяти и как следствие HDD тоже должны быстрее отдавать отклики. Я к этому пришел в нулевых, когда апгрейтил свой комп для игр. И я вас прошу! Не надо про коней. Уж очень толсто получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:40 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
mayton... И я вас прошу! Не надо про коней. Уж очень толсто получается. Так тема изначально такая ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:50 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
maytonЯ месседж Димы понял так... Все правильно, дело не в способе компиляции, JIT/неJIT примерно одинаковы, т.е. +/- пару процентов производительности, поэтому проблемы уходят в другие слои. Вот мой замер цены записи в одну кэшлинию проца разными потоками. Тормоза в 5-7 раз! Какой тюнинг компилятора это перекроет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:53 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
mayton.... Я месседж Димы понял так. - Мы не можем наращивать производительность в одном слое архитектуры. Например подтянули больше ядер процессоров - получили когерентность. Блокировки... спины.. стали взымать с нас "дань" просто так. Просто подняли тактовую частоту - надо поднимать и частоту системной шины и как следствие планок памяти и как следствие HDD тоже должны быстрее отдавать отклики. Я к этому пришел в нулевых, когда апгрейтил свой комп для игр. Вроде же есть понятие "масштабируемость". Если конкретная задача и конкретная алгоритм нормально масштабируется - добавили нужного ресурса, получили обещанный прирост производительности Если не масштабируется, то хоть процессоров, хоть памятью, хоть дисками можно весь дом забить - быстрее работать не будет И никак это ни с процессорами, ни со скоростью памяти не связано. Исключительно с задачей, используемым алгоритмом и кривизной рук архитектора/программиста. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 20:55 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Dima T....Тормоза в 5-7 раз! Какой тюнинг компилятора это перекроет? Я приводил реальную задачу, на реальном проекта Прикладная система на конкретной железяке (Numa 2 core, 40 ядер) жестоко отжирала CPU. Настройками JVM (GC и JIT) потребление CPU снизилось в 3-4 раза. Куда уходило CPU - я не выяснил (да и не нафиг это не интересно), просто куда-то уходило, "в между модульное пространство". В данном случае, точнее "в между thread пространство". Причину (особенности конфигурации продакшен сервера) и метод лечения (нужные ключи JVM) нашли, на этом разбирательство завершили. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 21:01 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
P.S. Изначально грешили на низкую скорость ConcurrentLinkedList и чрезмерное обилие Atomic'ов в коде. Пытались оптимизировать код. Реальность оказалась проще ))) Шедулер потоков Linux и JVM, почему-то стал "не так" работать. Вот честно, брать сорцы и разбираться "как же он на самом деле работает" - можно годами. Фиг какая фирма такие разбирательства в рабочее время и необходимое оборудование оплатит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 21:05 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevВроде же есть понятие "масштабируемость". Это красиво в теории. В дискретной математике. В конечных автоматах и сетях Петри. На практике очень мало задач удачно без потерь масштабируются. Возьмите любую проблему из области баз данных там где мы работаем не с историческими а с актуальными сведениями. И начинается. Шардинг. Партишининг. Это все не безплатно. Кластеры? Они имеют ограничения. Тот-же Oracle RAC Емнип больше 64-х узлов не строится. Есть там сетевые проблемы. Причем лавинно растущие. Хорошо масштабируется только то что вообще не взаимодействует ни с чем. Типа shared nothing. Но мы живем в мире где не shared nothing а скорее наоборот. Shared 100%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 21:08 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Mayton, IMHO теперь Вы начали поднимать "очень толстые темы" mayton....Тот-же Oracle RAC Емнип больше 64-х узлов не строится. Есть там сетевые проблемы.... Нет там сетевых проблем. Там есть финансовые проблемы. Если кто-то оплатил лицензии на Oracle EE на RAC на 64-х узлах... уверяю Вас... у него нет "сетевых проблем". Что бы под этим не подразумевалось. У него проблем ни с сетью, ни с автомобилем, ни с дачей - нет ))) По определению. mayton... Возьмите любую проблему из области баз данных там где мы работаем не с историческими а с актуальными сведениями. И начинается. Шардинг. Партишининг. Это все не безплатно. Что значит "не бесплатно"? Если задача допускает партиционирование - в чем проблема? Если же для задачи партиционирование, как собаке пятая нога, так это и называется "задача (или алгоритм ее решения) не масштабируется". Тот же www.google.com, vk.com, youtube как-то работают ))) и "в скорость памяти" совершенно не упираются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 21:38 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
По поводу масштабируемый, 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 таблицам ))). И нельзя было для реальных, практических запросов соорудить уже готовую агригацию на нужном уровне деталировки. Как уже говорили в подфоруме работа про одну российскую компанию "при должно умение, старание и выделенном бюджете, любую базу данных можно сделать самой большой в Европе. И незачем этим гордиться" (не дословно, по памяти) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 22:02 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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 чтобы получше продавались их суперкомпьютеры, потому что иначе все начали считать на копеечных интельПК - хватало ресурсов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 22:37 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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. Если найду - отпишу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2017, 23:58 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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 ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 00:47 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, Просто не нужно слишком акцентироваться на заголовке - туда развернутую мысль не всунешь. Так что про полный отказ от JIT речь не идет. Просто вместо идеи, что JIT решает все проблемы - признали что нет, не все. И предкомпиляция нужна и даже весьма. Если еще немного обратить внимание на Java9, то можно заметить, что делаются шаги по уменьшению монструозности инсталляции - назвали это модульностью. Leonid KudryavtsevАналогично и холивар JIT/не JIT. C / Java. Одни задачи решаются более эффективно/проще на одном средстве, другие на другом. Ниши применения у них достаточно разные. Никто в здравом уме не будет делать высокопроизводительные видео-кодеки на Java, просто потому, что Java не имеет нужных инструментов (например возможность писать код с SIMD инструкциями). Так же, вряд ли кто-то будет создавать сайт-визитку в I-net на Assembler'е и MMX/SSE командах, что бы "быстрее работало" Ява более эффективна исключительно в интерпрайзном говнокодинге - она простая как тапок и любой "индус" быстро ей обучится. А сайты- визитки продолжат делать на Пыхе. Что же касается эффективности - то нет задач, на которой Ява будет быстрее С, она всегда пусть ненамного но отстает (этим можно обычно пренебречь). Но это если не учитывать, что она жрет память до 10х-кратного объема от компилируемых языков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 10:38 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglЧто же касается эффективности - то нет задач, на которой Ява будет быстрее С, она всегда пусть ненамного но отстает (этим можно обычно пренебречь). Но это если не учитывать, что она жрет память до 10х-кратного объема от компилируемых языков. истинные учёные (которые не бизнесмены) трудозатраты программистов не учитывают никогда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 13:41 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
и заодно предкомпиляцией подтвердили (да и джитом, как и многоядерностью тоже), что эпоха, когда скоростью железа решали проблемы тормозов, как минимум сделала длительную паузу, и требуются алгоритмы. Не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 13:55 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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х-кратного объема от компилируемых языков. Я не помню ты был участником нашего тяпничного бенчмарка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 15:49 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Ну не всем же индусам работать тимлидами - потому такой длинный список типовому кодеру учить не надо. Это кстати, преимущество Явы (и Питона) - что есть куча готовых инструментов и можно быстро научить новичка "методом обезъяны" mayton..Я не помню ты был участником нашего тяпничного бенчмарка? Был, я переводил на D. И, насколько помню, этот процесс перевода был гораздо более гладким, чем Ява - версия. Т.е. утверждать, что Ява идеально повышает производительность труда, я бы не стал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 18:30 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Я просто хочу акцентировать внимание на то что Java как вещь в себе - никому не нужна. Она сильна вовсе не языком. И вовсе не перформансом. Который по сабжу (как мы помним) весьма неплох .(.. ну порядка 170% потраченого времени от C++ на тестах с 3D Графикой. Тот же Питон вылез на порядки с более худшим резалтом). Но Java сегодня КМК сильна экосистемой фреймворков и библиотек и она сильна своим сообществом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 19:52 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglЭто кстати, преимущество Явы (и Питона) - что есть куча готовых инструментов и можно быстро научить новичка "методом обезъяны" Это преимущество 1С, "индусы" все там. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 20:13 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Никоим образом не возражаю. А если удастся за счет AOT выкинуть JIT из памяти (а это он ее жрет - как впрочем и С++ компилятор - Несколько сотен Мб) и с помощью JigSaw уменьшить футпринт, то будет просто супер. Ну разве что за исключением синтаксиса - но это можно списать на вкусовщину. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 20:16 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
mayton- Solid (типичные ошибки и нарушения любого их 5 пунктов) Самая типичная ошибка - применение его в стиле "и лоб разобьёт" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2017, 20:17 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglА если удастся за счет AOT выкинуть JIT из памяти (а это он ее жрет - как впрочем и С++ компилятор - Несколько сотен Мб) Хуже отсутствующих знаний - только неправильныеjavaw -Xms1g -Xmx1g jedit.jar ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 09:44 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
В 1.8 не знаю (они там с метаспейс больно уж намудрили), в предыдущих Java'ах JIT'у под скомпилированный код выдавали 32 Mb с возможным увеличением максимум до 64 Mb. Даже сильно enterprise проектам (Oracle Customer Care & Billing), вполне хватало ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 10:40 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
авторНо Java сегодня КМК сильна экосистемой фреймворков и библиотек Вот многие так говорят. Интересно, что же там такое есть, чего нет у других языков? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 12:18 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Не "у других языков", а "у других экосистем". Чтобы перенести C/C++ приложение с одной архитектуры или/и операционной системы на другую требуется: 1. Изначально заботиться о кросплатформенности; 2. Уметь собирать приложение для всех целевых платформ. В случае Java первый пункт реализован JVM, JLS и Java SE (другими pure-java) API, второй - JRE, частью которых является JVM. Про то, что процедура сборки java-приложения не в пример проще и полностью унифицирована - вообще молчу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 12:31 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках. Фотошоп, Офисы (и MS и бесплатные), Skype, Telegram, Viber (кроме Андроида, то есть - под Андроид написали, но это не привело к мульти-платформенности, пришлось писать на разных языках), все распространенные браузеры. Серверные Nginx, Апач сервер, Mongo DB, Ms Sql, MySQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 13:42 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, Т.е 180Мб этого мало? Кроме того, посмотри пик рабочего набора - потому что JIT уже отработал в основном. А виртуальная память не особо интересна пока не используется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 14:20 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
На всякий уточню - выделенная память - это виртуальная.Перевод неточный. Рабочий набор - это оперативная память (плюс ммапные исполнимые модули почему то) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 14:27 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
makhaonBasil A. Sidorov, Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках. Фотошоп, Офисы (и MS и бесплатные), Skype, Telegram, Viber (кроме Андроида, то есть - под Андроид написали, но это не привело к мульти-платформенности, пришлось писать на разных языках), все распространенные браузеры. Серверные Nginx, Апач сервер, Mongo DB, Ms Sql, MySQL. native на мобильной платформе я могу объяснить. Очень сильно экономили энергию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 14:42 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
makhaonBasil A. Sidorov, Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках... Far только под винду. Miranda тоже. Там где деньги - перепишут под что угодно, если на этом еще денег можно заработать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 19:16 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
makhaonBasil A. Sidorov, Удивительно что вот всё так хорошо, и при этом почти всё более-менее распространенное написано на нативных языках. Фотошоп, Офисы (и MS и бесплатные), Skype, Telegram, Viber (кроме Андроида, то есть - под Андроид написали, но это не привело к мульти-платформенности, пришлось писать на разных языках), все распространенные браузеры. Серверные Nginx, Апач сервер, Mongo DB, Ms Sql, MySQL. А все более-менее приносящее деньги, совершенно на других языках ))) Oracle E-Business Suite, SAP R3, etc... etc... Я так понимаю, по сравнению с баблом который течет с enterprise консалтингового рынка, даже MS Windows - детский лепет ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 19:35 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglТ.е 180Мб этого мало?Вы правда считаете, что Seamonkey на скриншоте в двух местах - просто так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 21:14 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovSiemarglТ.е 180Мб этого мало?Вы правда считаете, что Seamonkey на скриншоте в двух местах - просто так?Я думаю что надо пояснять свою мысль. У меня она была проста - компилятор в памяти => несколько сотен Мб. А в чем суть сравнения с Сеаманки я не понимаю - современный браузер гораздо сложнее текстового редактора jEdit и содержит внутри себя кучу интерпретаторов CSS/HTMLK/JS и мало ли что еще. Тогда уж с Netsurf сравнивать. Но повторяю, я идею из слинкованного скриншота не оценил - ну запросили зарезервировать память Яве - она и система сделали, но память виртуальная и пока что ни на что не влияет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2017, 21:24 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Siemarglчто надо пояснять свою мысль. У меня она была проста - компилятор в памяти => несколько сотен Мб. Хотелось бы видеть откуда взялась цифра "несколько сотен" По ощущениям, там даже несколько десятками не пахнет. Накладные расходы по памяти для Java 1.6 были порядка 32 Mb под скомпилированный код (можно уменьшить или увеличить). Сколько занимает собственно код самого компилятора, не знаю. Но сомневаюсь, что это больше десятка - двух десятков мегабайт. Т.е. на мой взгляд, накладные расходы и до 100 Mb не дотягивают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2017, 02:09 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
By the way, Там очень большие накладные расходы совершенно в другом. В потоках. Если на компьютере 256 процессоров, Java по умолчанию под 200+ потоков компилятора и garbage collector'а запускает... занафига?... никому не известно.... ответ из Oracle на одном из форумов "у нас enterprise решение, нужно использовать все ресурсы компьютера" ))) Т.ч. даже примитивная программа Hello World начинает создавать под 400-500 потоков и больше... в ряде случаев, это приводит к пушному зверьку, который феерический отсвечивает всеми цветами радуги на системном мониторинге и грузит процессор под 100%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2017, 12:26 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
На одном из буржуйских форумов, читал негодование человека, у него какая-то примитивная программа на Java для мониторинга, которая на "обычном" компе потребляла десяток мегабайт, на сервере хотела > 2 Gb оперативки ))) просто на сервере 256 процессоров ))) Весь прикол заключался в том, что программа встроена была в ядро Солярки и доступа к ключам JVM не было. И, вроде, писец доходил до того, что она на сервере вообще запустится не могла.... в результате сервер "не все функции выполнял". В общем, дефолтные значения в Java Oracle менять отказался, сказав "что Java создана для серверов и должна использовать все возможные ресурсы " ))) пообещали наехать на коллег которые пишут Солярку и сделать патч для Солярки ))) чем дело кончилось, на форуме не сообщалось ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2017, 12:34 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevТ.ч. даже примитивная программа Hello World начинает создавать под 400-500 потоков и больше... в ряде случаев, это приводит к пушному зверьку, который феерический отсвечивает всеми цветами радуги на системном мониторинге и грузит процессор под 100%. Описано красочно. И... очень эмоционально. Я охотно верю в то что рантайм оставляет за собой право запускать нужное количество потоков под нужный getAvailableProcessors() но в то что это приводит к пушному зверьку для HelloWorld я не верю. Или надо детально разбираться уже имея доступ к консоли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2017, 13:01 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevВесь прикол заключался в том, что программа встроена была в ядро Солярки и доступа к ключам JVM не было. И, вроде, писец доходил до того, что она на сервере вообще запустится не могла.... в результате сервер "не все функции выполнял". В общем, дефолтные значения в Java Oracle менять отказался, сказав "что Java создана для серверов и должна использовать все возможные ресурсы " ))) пообещали наехать на коллег которые пишут Солярку и сделать патч для Солярки ))) чем дело кончилось, на форуме не сообщалось ))) Насколько я понимаю "хозяин" приложения встроил запуск приложения на java ... в т.н. ядро солярки и не дал возможности управлять ключами и опциями. Что-ж. Он - сам себе злобный Буратино. Но если в этой формулировке убрать "java" и заменить это на что-то другое, то становиться очевидным что это configuration bug и его надо фиксить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2017, 13:04 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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-процессорами и какой-то банальный агент не может запуститься... не хватает памяти ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2017, 13:49 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
mayton....Но если в этой формулировке убрать "java" и заменить это на что-то другое, то становиться очевидным что это configuration bug и его надо фиксить. Да это понятно. Дело в другом. Что фиг кто о таком __документированном__ поведении Java знает и задумывается. А когда видишь такое в живую.... месяц уходит, что бы понять, в чем же тут дело и кто виноват. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2017, 13:51 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Вы замечательно описали последствия от применения "безискусьвенного интеллекта" (имею ввиду т.н. "умное" перераспределение ресурсов в динамике). Вопрос из сабжа только остаётся открытым, кто виноват должен браться за ум? и что делать возьмётся ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 11:22 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevSiemarglчто надо пояснять свою мысль. У меня она была проста - компилятор в памяти => несколько сотен Мб. Хотелось бы видеть откуда взялась цифра "несколько сотен" По ощущениям, там даже несколько десятками не пахнет. Накладные расходы по памяти для Java 1.6 были порядка 32 Mb под скомпилированный код (можно уменьшить или увеличить). Сколько занимает собственно код самого компилятора, не знаю. Но сомневаюсь, что это больше десятка - двух десятков мегабайт. Т.е. на мой взгляд, накладные расходы и до 100 Mb не дотягивают. Несколько сотен - до 400Мб можно наблюдать при компиляции чего то большого С++ что gcc, что clang. Поскольку уровень оптимизации в Яве сравним - то можно предположить, что и затраты на компиляцию будут сравнимыми - язык конечно проще, но не сильно. "По ощущениям" - метрика конечно еще та, но: - поковыряв доступными системными инструментами Rammap/vmmap, я конкретики тоже не увидел. - Helloword должен загрузить как минимум интерпретатор - но он потребляет 12Мб С этой стороны непонятно, куда используется память. Еще погуглил на тему Java Mission Control - нашел кое что интересное - ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 11:45 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
По поводу GC. Мы как-то делали скрипты (Power Shell), занимающиеся многопоточным копированием файлов. Они забивали абсолютно всю память, 99.99% процессорного времени и вывешивали намертво сервера. Довольно нетривиальным способами + постоянным ручным вызовом сборщика удалось довести до более-менее работоспособного состояния. Рядом тихи-мирно трудился нативный сервер (Delphi) с раз в 5 большим числом потоков, поставляя эти файлы скрипту и разруливая кучу запросов. Занимая мизер ресурсов. Вот такой опыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 12:26 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Еще добавлю. Когда говорят о том что GC плох - то говорят о "GC в вакууме". На самом деле в Java их существует минимум 2. Классический ParallelGC, старый. И G1GC который позиционируется как новый ему на замену. Есть еще SerialGC который почти ничем не отличается от первого алгоритмически и есть также CMS который проектировался для UI приложений типа сред разработки. Плюс разные коммерческие с закрытым кодом типа С4, и другие о которых нам не известно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 13:16 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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 - нормальный деловой процесс. Накойхер было поднимать безоглядный кипеш? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2017, 17:21 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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, померяем и сравним - стало ли лучше и насколько. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 11:50 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Siemargl5.4 сек против 1.5 сек твоя работа в постоянном перезапуске приложения заключается? Не вздумай работать с приложениями Autodesk ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 12:20 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного? Кстати, у п-кода, да еще ООП должно быть весьма сложно реализовать возможность постраничной загрузки по pagefault - требованию. Т.е в память надо грузить все и ой - это же zip - памяти надо вдвое. Ну или очень медленно. Нет. Не превращаются. Ну.... не все 52Мб. Если вы запустите java -verbose:class то увидите спул работы Classloaders. Грузится не весь rt.jar а только те classes которые есть в зависимостях. Кстати этот аспект повлиял на введение модулей в Java9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 12:41 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Изопропил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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 12:53 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
предков еще можно выбрать по имени каталога, которое совпадает с иерархией классов, но вот перекрестные зависимости..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 12:58 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
maytonSiemarglСо вторым - а если мегабайты П-кода (rt.jar 52Мб) превращаются в сотни машинного?.... Нет. Не превращаются. .... Нет. Не превращаются. Физически превратиться не могут. Кто же им даст? Параметр такой есть, командной строки: -XX:ReservedCodeCacheSize=32m Т.ч. максимум в 32m превратиться могу (by default). Ох уж эти сказочники, ох уж эти сказочники.... ( C ) [spoiler] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 13:17 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, https://blogs.oracle.com/poonam/why-do-i-get-message-codecache-is-full-compiler-has-been-disabled Немного не впечатляет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 13:35 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Ну я с таким сообщением ни разу не сталкивался. Вот 750-800 мегабайт под классы (PermGen) - бывало приходилось выделять, а с данной областью памяти проблем не было ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 14:08 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglОк, но это приличная разница между п- и машкодом -распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и -загрузить 4кб по нужному смещению из dllВы опять недодумали: когда работает JIT - всё уже загружено и слинковано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:44 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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. Да, J(ava)S(hared)A(rchive) не компиляция в нативный код. Но! Прежде чем фантазировать о гигабайтах и мегаиопсах - не худо бы ознакомиться с вопросом, чтобы понимать адекватность не только используемых инструментов, но и выбранных метрик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:54 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglОк, но это приличная разница между п- и машкодом -распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и -загрузить 4кб по нужному смещению из dll И это еще не все. Если верить Шипилёву... и его конференциям (а я ему вобщем-то верю т.к. оппозиционных мнений просто не существовало в момент доклада и после) то существует целый слой т.н. intrinsic методов которые уже собраны нативно (в частности методы класса String:: и пространства java.nio.*) и используют SSE инструкции для оптимизации некоторых низкоуровневых операций типа копирования из строк в строки. И это еще в семерке и в восьмерке. Поэтому в части runtime я думаю что "все уже украдено до нас" и умные люди давно уже ломали голову как разогнать системные классы и я думаю что там уже все разогнано. Вот прикладной код. Это дааа... это вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:09 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
На знал про intrinsic методы, слушок был, но точно не знал. Список intrinsic методов захардкоденных в Open JDK: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/vmSymbols.hpp#l581 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 19:01 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovSiemarglОк, но это приличная разница между п- и машкодом -распаковать zip - рекурсивно выбрать из него всех предков нужных классов, скомпилировать, слинковать и -загрузить 4кб по нужному смещению из dllВы опять недодумали: когда работает JIT - всё уже загружено и слинковано. Линковка это в т.ч процесс проставления физических адресов вызываемых функций в вызываемой. Потому пока JIT не сгенерирует машкод, проставлять еще просто нечего. JSA - посмотрю что за зверь, и включен ли по умолчанию. Ознакомлюсь с вопросом =) PS. Надеюсь что dz это не Завалишин /= maytonИ это еще не все. Если верить Шипилёву... и его конференциям (а я ему вобщем-то верю т.к. оппозиционных мнений просто не существовало в момент доклада и после) то существует целый слой т.н. intrinsic методов которые уже собраны нативно (в частности методы класса String:: и пространства java.nio.*) и используют SSE инструкции для оптимизации некоторых низкоуровневых операций типа копирования из строк в строки. И это еще в семерке и в восьмерке. Поэтому в части runtime я думаю что "все уже украдено до нас" и умные люди давно уже ломали голову как разогнать системные классы и я думаю что там уже все разогнано. Вот прикладной код. Это дааа... это вопрос. Это великолепно контрастирует с утверждениями, что JIT тем и хорош, что может оптимизироваться на лету под процессор исполнения Бггг. Но -со скоростью кода в яве и так все неплохо -линкеру неважно какой код подставлять - интринсик или свеже-сгенерированный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 21:53 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglЭто великолепно контрастирует с утверждениями, что JIT тем и хорош, что может оптимизироваться на лету под процессор исполненияПросто в конкретном x86-мире всё очень однозначно - сопроцессор вшит на кристалл ещё со времён Pentium, SSE - со второй половины нулевых. Но вот если вам потребовалось "переехать" с x86-64 на ARM или на экзотику типа Power, то разница будет, даже если лично вы не сможете эту разницу оценить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 15:20 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
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. Да, J(ava)S(hared)A(rchive) не компиляция в нативный код. Но! Прежде чем фантазировать о гигабайтах и мегаиопсах - не худо бы ознакомиться с вопросом, чтобы понимать адекватность не только используемых инструментов, но и выбранных метрик. В доке написано, что это предварительная компиляция rt.jar во внутренний формат VM. Только не верится, что 52Мб rt.jar превращается в 12Мб classes.jsa. Кстати, сжатия rt.jar не применяет. Написано, что по умолчанию JSA уже используется. Попытка форсить (-Xshare:on) или запрещать к видимым изменениям скорости загрузки не привела. Кроме того, форс работает на винде через раз - вылетая с такой диагностикой, как тут Ну ок. Если гипотезу откидываем, что rt.jar раздувается в сотни Мб, то надо Жруна искать дальше (GC пока остается под подозрением). Ждем релиз Java9 и будем смотреть, что изменилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 01:29 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
SiemarglКстати, сжатия rt.jar не применяетНу так примените. Можете ещё "переехать" (un)pack200, чтобы убрать отладочную информацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 17:29 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovSiemarglКстати, сжатия rt.jar не применяетНу так примените. Можете ещё "переехать" (un)pack200, чтобы убрать отладочную информацию. Наоборот хорошо, значит там 52Мб байткода а не 100 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 19:52 |
|
||
|
Java JIT - всё? Берёмся за ум
|
|||
|---|---|---|---|
|
#18+
Еще один до сих пор не знает, что такое AOT, которое в .NET было с самого начала, в виде утилитки ngen. .NET Native утилитарная параша, которая нужна тока для мобильной мелкософтовской хрени, т.е. <5% рынка. Так что JIT+AOT/ngen никуда не уходил и живее всех живых. А ты просто слышал звон, да не знаешь где он. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 19:36 |
|
||
|
|

start [/forum/topic.php?all=1&fid=16&tid=1340359]: |
0ms |
get settings: |
4ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
144ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 445ms |

| 0 / 0 |
