Интересует мнение по востребованности производительности в рамках среды обитания Java. Подразумевается, конечно же, не оптимизации запросов на стороне БД и всяческая работа с файлами да сетями, которая опять же оптимизируется вне JVM. Но интересно понять, на сколько востребована производительность именно внутри JVM, без внешних систем.

Смысл вопроса в понимании места этой технологии . Она позволяет повышать производительность ряда алгоритмов в разы, но, естественно, не без некоторых затрат на изучение предмета. По сути это упрощение связывания Java с низкоуровневым программированием. То есть оставаясь в рамках одной и той же IDE, можно писать оптимизированное до самого железа ПО.

Итак, какие встречавшиеся в вашем жизненном опыте системы упирались в производительность процессора, загружаемого именно JVM, но не сторонними системами ? На сколько простым выглядит создание конвертера из объектной модели в загружающем процессор алгоритме в набор массивов ? Массивы - это наиболее удобный способ достижения производительности на низком уровне. В них можно трансформировать всяческие структуры со ссылками друг на друга, просто заменив объекты на набор последовательно расположенных значений полей, а ссылки - на индексы в массиве. В общем - нужна ли производительность для Java и велика ли для неё цена в виде освоения системы команд процессора и написания конвертера объекты-массивы и обратно ?

Dimitry SibiryakovДля решения проблемы производительности у Java давно уже придумали JIT Compilation, которая работает без всяких ужимок и прыжков.
Если бы вы почитали текст по ссылке, то могли бы заметить рост производительности в 5 раз. Хотя да, с ужимками и прыжками. Ну да без ужимок нынче лишь некий *****код получается.

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

irbis_alЯ пользовался http://www.excelsior-usa.com/
для Линукса.
Да, это тоже опция, но как вы сами заметили - только для редких случаев. По сути эта опция делает то же самое, что и JIT, то есть компилирует байткод в нативный код. При этом производительность получается примерно такая же (если не хуже), чем у JIT.

Но суть темы по ссылке в возможности добиться лучшей производительности, чем могут JIT или сторонний компилятор. Но, конечно же, требуется приложить моск, то есть само всё не скомпилируется и не ускорится.

И да, все эти новые винды вроде включают кучу фич типа подготовки образа программы в памяти для быстрой загрузки. То есть если программа часто запускается, то винда автоматом делает её образ и в следующий раз запуск будет в разы быстрее. Не пробовали поиграться ?

Leonid KudryavtsevА это.... Какой-то велосипед из детсада с ООПшными колесами. В общем IMHO бред сивой кобылы
Этот "бред" предназначен для разработчиков на Java, которые хотят повысить производительность без нудного изучения гораздо большего списка тулзов, чем вы привели в своём посте. Ну а те, кто пишет на Turbo C/Assembler, им скорее всего и Java-то мало знакома, а вопрос-то был именно про производительность Java приложений и потребность в повышении скорости именно таких приложений.

А то, что с точки зрения писателя на голом ассемблере всё остальное есть полный отстой -
все и так знают.
Leonid KudryavtsevАссемблерный код удобно писать на языке специально для этого предназначенном. А не конструкциями вида:

parameterIn(r.EAX,IP.In0.ordinal());
Там сейчас чуть покороче:

parameterIn(r.EAX,IP.In0);

Но суть не в этом, а в том, что знатоки ассемблера должны бы вспомнить то, что называлось макро-ассемблер, и на чём писались мегабайты кода в своё время.

В данной же тулзе ряд ассемблерных операций скрыт от программиста внутри Java функций, что сильно уменьшает геморой для означенного программиста. И в результате производительность труда программиста (о которой так много писали классики), растёт не по дням, а по часам.
Leonid KudryavtsevГде в книжках Intel'а, AMD такая инструкция описана?
Вы поторопились, когда по быстрому скопировали не понравившийся вам текст и занесли его сюда. Там на пару строк ниже объясняется, что это Java функция, а не ассемблерная инструкция. Соответственно - искать её в мануалах Интела как бы не вполне разумно.
Leonid KudryavtsevПотом захочется этот код перенести в нормальный ASM файл. И что делать? Все нафиг переписывать с нуля?
Кому захочется ? Java программисту ? Вы в этом уверены ?

Суть штуковины в быстром и безболезненном переходе на заметно более высокий уровень производительности Java программ при помощи всё тех же Java разработчиков. То есть со стороны Java разработчиков нужно приложить некий минимум усилий на понимание простейших принципов работы процессора и скачивания мануала по его инструкциям, а потом можно повышать производительность высоконагруженных приложений в разы без привлечения сишных или ассемблерных гуру в Java команду.

То есть это средство быстрой разработки высокоэффективных приложений именно на Java, а не на Turbo Assembler. Не стоит путать дёргание интерфейсных методов, которые обращаются к некоему чёрному ящику, с этим самым чёрным ящиком. Здесь чистая Java и синтаксис привычный именно Java-разработчикам. А что там за дёргаемыми методами - сервер приложений или процессор - какая разница, как называется чёрный ящик ? Главное, если есть понимание ответа ящика на команды, всё остальное уже просто дело элементарной сообразительности.

Mikle83т.е. суть штуковины в создание еще одной прослойки, которая предполагается будет работать быстро, хотя реально это зависит от ее внутренней реализации. И гарантировать, что девелоперы "этой поделки" реализовали все "обертки" крайне оптимально - достаточно сложно.
В нашем мире вообще мало что гарантировано. Например когда какая-нибудь вебсфера падает, то народ не пускается в рассуждения на тему "как печально, что девелоперы этой поделки не реализовали всё оптимально", но просто перезапускает штуковину, или городит отказоустойчивый кластер. То есть если люди хотят получить результат, а некая технология им в этом помогает, то большинство находит надёжный способ использования полезной технологии.
Mikle83ИМХО, если встает реальный вопрос производительности - эта поделка выставляется как некоторая "полумера". В реальных production проектах несет ряд рисков, связанных с внутренней реализацией + в случае возникших проблем появляется дополнительное звено которое надо мониторить.
Я прям удивляюсь, как страшен мир вокруг вас. Это-ж надо, вокруг столько опасностей, одни машины на дорогах чего стоят ! И как же вы умудряетесь выживать-то с таким пессимистическим подходом ко всему на свете ?

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

MasterZivJava приложения бывают разные. Очень. Но в них всё же редко встречается требование именно к вычислительной мощности.
И тем не менее, всё, что делается в Java, всегда касается некоего процессора. Так вот этот процессор, будучи загруженным на 100%, оказывается узким местом, независимо от вида его деятельности. То есть будет ли это вычисление косинусов или некая логика поиска связей клиента в графе данных CRM, совершенно не важно. Этот самый поиск в графе есть точно так же поддающийся оптимизации алгоритм. Поэтому обращать внимание только на косинусы не есть корректный подход при поиске способов повышения производительности.

Если процессор загружен на 100% именно Java, то значит надо что-то думать в сторону оптимизации. И один из вариантов - сделать код умнее, чем способен JIT.
MasterZivУ каждой структуры данных есть свои плюсы и минусы. Сильные и слабые стороны.
Но замена всех структур на только массивы сама по себе не даёт никакой выгоды.
Если речь идёт о низком уровне, то замена даёт, и очень даже много.

SheratonСлова JAVA и Производительность рядом выглядят так же, как "скоростной запорожец".
По началу такое у многих бывает. От незнания, конечно же.

Leonid Kudryavtsevalex55555...Если процессор загружен на 100% именно Java, то значит надо что-то думать в сторону оптимизации. И один из вариантов - сделать код умнее, чем способен JIT....
На корявом средстве по Вашей ссылки Вы способны это сделать? "сделать код умнее, чем способен JIT" ?
Почитайте о средстве по ссылке, там на простом ангельском языке весьма доходчиво показано, что JIT отстаёт от ручного кода в 5 раз. Не на проценты, обратите внимание, но в разы. Так что ваши сомнения как бы со всею очевидностью показывают ваше ... Уж сори за почти прямым текстом вдоль неприятного места.
Leonid KudryavtsevТеоретически, JIT, может генерировать код значительно более эффективный чем традиционные компиляторы ... На практике, IMHO пока отстает.
Все компиляторы пока ещё слабоваты. Хотя возможность сделать их значительно умнее вполне имеется. Но пока умнее их не сделали, можно повысить производительность софта на Java при помощи указанного по ссылке подхода. При этом повышение возможно в разы. А уж на десятки процентов - это уж точно применимо к любой Java программе, загружающей процессор на 100%.