Как стать автором
Обновить

Комментарии 92

Все рассказы о производительности java натыкаются на одну смешную истину: на java не написано ни одного более-менее вменяемого браузера. Вот когда напишут — вот тогда можно будет посмотреть, кто быстрее. Без всяких кивков в сторону gc, "неправильно готовят" и т.д.
До этого момента java идёт в одном ряду с другими "песочными" языками класса перла, питона, руби и т.д., которые хороши для мелкоприкладной разработки но совершенно не готовы к системам с требованиями высокой производительности.
Количество браузеров, написанных на той или иной платформе — это очень странная метрика популярности. Последние лет 10 речь в мире идет про серверную Java, поэтому я плохо понимаю, что вы тут такое вообще написали :)
На чистом С и фортране тоже ни одного браузера.
НЛО прилетело и опубликовало эту надпись здесь
на java не написано ни одного более-менее вменяемого браузера

А можно список языков, кроме С++, на которых написаны более-менее вменяемые браузеры? Насколько я знаю, на D, Go, Rust тоже не написано ни одного вменяемого браузера, тоже производительность виновата? Всех популярных вменяемых браузеров штук пять-шесть, наверное, да и то большая часть клоны друг друга.
Автор комментария выше, скорее всего пенял на производительность GUI Java приложений, в частности, популярных IDE. Я с ним согласен, работаю только в vim или sublime, т.к. IDE на Java для меня очень прожорливые, жрут ресурсы как игры 2008 года. Тот же Sublime с плагинами под IDE работает в разы быстрее как с обычными задачами, так и с задачами с файловой системой и с сетью.
IDEA жрет много ресурсов из-за умных автоподстановок и прочих умных плюшек, При желании можно все отключить, но тогда главные плюсы IDEA теряются.
НЛО прилетело и опубликовало эту надпись здесь
а ещё можно разрабатывать на компьютере мощнее чем микроволновка
НЛО прилетело и опубликовало эту надпись здесь
Справедливости ради, микроволновка — достаточно мощный прибор, впрочем, как и чайник… :)
А servo?
ладно, а сколько на java написано 3d движков? сколько HFT систем в бекенде исползуют java? вы видели GUI которые написаны на java и которые тормозят? мне неизвестны числодробилки/реал-тайм (привет GC) приложения на java, в основном java исползуется для написания приложений которые большую часть времени ждут I/O (диск/сеть), если я не прав, прошу меня поправить :)
По моему скромному мнению java популярна по причине легкости обучения и относительной сложностью выстрелить себе в ногу.
P.S.
Есть проект Cassandra DB переписанной на C++ (http://www.scylladb.com/), так авторы заявляют о 10х кратном приросте производительности.
ладно, а сколько на java написано 3d движков?

достаточно
мне неизвестны числодробилки/реал-тайм

а их много, научные числодробилки, базы данных и nosql хранилища, поисковые системы, машинное обучение и нейроные сети и т.п.
привет GC

Есть специальные JVM для реал-тайм, где нет остановки мира от слова совсем
Есть проект Cassandra DB переписанной на C++ (http://www.scylladb.com/), так авторы заявляют о 10х кратном приросте производительности.

Ну, так то авторы, они и стократный прирост заявят. Если бы так просто было бы получить такой прирост никто бы даже не начинал писать Cassandra DB и ей подобные базы данных на Java. Опять-таки Hadoop и прочий BigData это как раз числодробилки.

P.S. Естественно, у Java тоже есть предел и для ряда задач C и С++ будут лучше, тем не менее есть очень много задач (в том числе по обработке данных) в которых разница между производительностью Java и C++ не так существенна, как разница в затраченных ресурсах разработчкиов. Собственно есть ряд задач где С лучше С++, а есть где рулит только ассемблер.
Да-да, играл я в игрушки на Jave. Тот же Wurm-онлайн. Графика середины 2010-х, а ресурсы кушает как последний фаркрай.
Есть и другие проекты на Jave — Salem Online, Hafen — у всех у них БОЛЬШИЕ проблемы с графикой и очень большие с прожорливостью.
Так что, про триДэ на яве — не надо, нет его вменяемого.
.Net? Та же Java только в профиль. Очень активно используется в игроиндустрии.
достаточно

Справедливости ради 3d движков по ссылки три, а успешных в лучшем случае полтора. А пригодных для игр AAA-класса — ноль.
Есть специальные JVM для реал-тайм, где нет остановки мира от слова совсем

Есть с предсказуемой задержкой (до 1мс). При этом Oracle разработку таких версий свернул в 2012, а у других вендоров версия JVM в лучшем случае седьмая (у IBM), а то и вообще шестая (JamaicaVM). Плюс версии эти дорогии, так что для ускорения работы уютненькой питерской Идейки подходят слабо. А тем у кого есть деньги зачастую проще взять сишника с опытом.
Если бы так просто было бы получить такой прирост никто бы даже не начинал писать Cassandra DB и ей подобные базы данных на Java.

Ну, Майнкрафт же написали.
Опять-таки Hadoop и прочий BigData это как раз числодробилки.

Тут нужно понять, что вы понимает под числодробилками. Я думал это скорее всякие аудио/видео кодеки, архиваторы, всякие мат. библиотеки. Тут плюсы и фортран все-таки вне конкуренции.
http://lessthanoptimal.github.io/Java-Matrix-Benchmark/runtime/2015_07_XeonQuad/
http://stackoverflow.com/questions/529457/performance-of-java-matrix-math-libraries

Другое дело что мне не известно ничего написанного не на C++/C/Fortran, что работало бы быстрее. Хотя нет, вру CLR имеет первый старт субьективно побыстрее, в остальном у него даже скорость GUI не лучше, хотя GUI у него некроссплатформенный и гвоздями прибит к WinAPI. А объяснение простое — нулевая стоимость абстракций — это не пустой звук, а здесь у "сей" ("плоских" и с "крестами") конкурентов пока нет. В теории Rust еще может к ним может когда-нибудь добавиться. При этом Rust объективно сложнее Java.
Справедливости ради 3d движков по ссылки три, а успешных в лучшем случае полтора. А пригодных для игр AAA-класса — ноль.

Ну из той же справедливости, если верить вики , то на чем-то кроме C++/C движков практически и нет (в частности в списке нет ни Go, ни D, ни Rust). Вообще это не совсем правильный критерий, использование ЯП в какой-то области далеко не всегда зависит от производительности и возможностей языка, основное все-таки наличие уже готовых разработок, большого количества разработчиков и т.п. Нечестно же сравнивать, например, кол-во игров для Андроида на Java и других языках, потому что понятно что у Java будет преимущества нативного ЯП.
аудио/видео кодеки, архиваторы

Ну, кстати нет, такие задачи тоже не числодробилки. Были у меня подобные задачи на Java, там тоже все упиралось в скорость диска, то есть пока архивированный поток читается/пишется, его успевают и разархивировать и обработать и заново заархивировать в параллельном потоке и ещё полно времени остается.
P.S. Я не спорю, задачи где производительности Java может не хватить бывают, но их не так много как кажется, в большинстве случаев все (базы данных, кодеки, архиваторы, биг дата) всё равно чаще упирается в скорость диска или сети, то есть тормозит в первую очередь от кривой архитектуры или кривых рук.
Я на каждом языке, который начинаю изучать, пишу задачу вычисления простых чисел (алгоритм по определению). Чистой воды числодробилка получается. Так вот, сравнение скорости с другими языками:
Java: Delphi -> 2: 1 (Intel), 6: 1 (AMD Vishera)
Java: C# -> 1: 1.25 (Intel), 1.75: 1 (AMD Vishera)
Обратите внимание на разницу при смене архитектуры. Не видел, чтобы кто-то сравнивал скорость одного кода на нескольких разных машинах, а это важно. Тестят всё на эталоне. JIT даёт огромное преимущество в сравнении с заточенным под одну архитектуру нативным кодом.
справедливости ради
суперуспешный майнкрафт написан на джаве, все волками выли от тормозов, пишут патчи для оптимизации, но играют
У вас с аргумента жЫр стекает.
все ваши аргументы рассыпаются после поверки IDE.
Все лучшее, что есть — построено на опыте IntellijIDEA, пупсик
И тормозит на больших проектах, как бы я не обожал Clion
Тормозит потому что в IntellijIDEA очень умная система автоподстановок и т.п. умных штук, IDEA очень часто догадывается о том что хочет программист, но это сжирает дофига ресурсов. Поотключать это можно и тормозить не будет, другое дело что это практически главное преимущество этой IDE. Тут несколько некоректно сравнивать IDEA с просто продвинутыми редакторами, так как в них всех умных штук просто нет.
Да ладно. KDevelop и Qt Creator предлагают +- тот же самый набор фич.
Там не в фичах дело, не знаю насколько это явно в Clion, но в Java IDEA умудряется практически угадывать что сейчас напишет программист и давать умные подстановки имен, типов и методов, что дико облегчает разработку, ни в одной другой IDEA такого удобства не видел. ИМХО, я вполне понимаю на что уходит производительность и меня такая "цена" вполне устраивает (лучше я куплю более дорогой комп, но буду на 20% продуктивнее, чем наоборот).
И как это реализовано? Магией или всё-таки фичами?)
У меня само написание кода занимает не такой большой промежуток времени. Конечно иногда доводится строчить код практически безостановочно, но в среднем у меня ощущение, что тобы ускориться на 20% надо чтоб код набирался сам и мгновенно.
Кроме того, особо крупные проекты там тормозят(тормозили?) даже на топовой конфигурации. И что? Двухпроцессорник собирать? На ноуте даже не мечтать IDE запустить?
Если холиварить, то на С++ оно наверняка бы не тормозило. Я уверен. Если холиварить с самим собой, за те же деньги и время на С++ подобное написать наверняка невозможно. Что возвращает нас к вопросу о том, что у каждого языка своя ниша, и утверждение Java круче C++ (как и обратное) смысла не имеет. Но любой кулик, как известно, своё болото хвалит...
а вы сколько багов против них завели?
Завел в основном фич реквесты, под багами комметирую, привожу способы воспроизведения, etc.
На протяжении всего интервью подчеркивается то, что, чтобы Java была по-настоящему высокопроизводительной ее нужно тонко настраивать под каждую конкретную систему, что неприемлимо для десктоп-приложений.
Где вы такое увидели? Как раз наоборот, Java имеет преимущество перед нативным кодом в плане подстраивания под систему. Смотрите мой коммент выше.
Нужно понимать, что джава занимает свою нишу и не предоставляет программисту низкоуровневых фич для написания браузеров или ОС. Хотя тенденции идут к тому, что в 10-ке (думаю конец 2017 года уже будут тестовые сборки) программисты получат низкоуровневые фичи. Вплоть до инлайна машинных кодов в методы классов и дешевый вызов функций из нативных библиотек. Что сделает реальностью написание браузера на джаве.
А ставить на один уровень джаву с перлам и питонами — попахивает любительством в области разработки ПО. Я бы вас еще понял, если сравнение шло с Go, D или подобными ЯП.
Зато на java написан Elasticsearch, который мы сейчас используем на большом кластере. Ничего, работает, я бы сказал отлично :) Можете сказать, что если переписать его на, то мы сэкономили бы парочку серверов. Но нет, он есть только на джаве.
Хотел сказать "переписать его на ваш любимы язык"
НЛО прилетело и опубликовало эту надпись здесь
Кстати, это на десктопе нет, а как же J2ME (земля пухом) и андроид? Не знаю как на андроиде, там всё-таки можно взять C/C++, но J2ME? А как же Opera Mini? Там было даже немного яваскрипта :D
Да ей наверно до сих пор пользуются. И это на кирпичиках с около 2мб хипа. Как раз "более-менее вменяемый браузер" на java :)
и давно у вас браузер — мерило всего? Вообще, налицо недопустимая для технически грамотного человека подмена понятий
не написано браузера — значит почему-то «не готовы к системам highload»

при этом куча бирж работает на java, есть такие вещи как disruptor и chronicle, люди умеют обрабатывать миллион сообщений в секунду на этой самой яве, а вы явно не в теме. Сайт LMAX-exchange вам в помощь.

Последний раз, когда я видел высказывание «на яве нельзя работать с финансами», это было в блоге чувака, который… нигде сам не работает, а свои сведения почерпнул, сходив на интервью в фирму, где на яве таки работали с финансами.

И вообще это просто язык.
Уже запущенное и некоторое время работающее приложение на Java может и не очень медленно работает. Сложно сравнивать если не иметь полного аналога написанного на другом языке. Но когда мне надо провести некую операцию, которая займет 1 минуту, а для этого надо 1 минуту подождать пока запустится JVM и поднимет это самое приложение — это полный маразм. Поэтому любые десктопные приложения на Java по возможности идут в лес. А серверные… с серверными проблема не столько с производительностью, сколько с прожорливостью. Мелкое ненагруженное приложение, которое по идее должно спокойно жить на виртуалке с 128Мб памяти внезапно начинает требовать в 3-4 раза больше только из-за того оно на Java, а не на C++.
Всё зависит от задач, но в большинстве серверных случаев, такие затраты на память с лихвой окупаются простотой разработки и лёгкостью поддержки.
Легкость поддержки — это, видимо, со стороны разработчика. Ибо со стороны админа таки поддерживать в живом виде проект на джаве намного сложнее, чем проект на… на чем угодно другом. А простота разработки — это не моя проблема. Мне не важно на сколько было сложно написать софт, который компания купила и мне теперь его надо хостить.
Почему столько минусов? Всё же чистая правда. JRE уже много лет шпыняют за очень медленный старт. .NET решает эту проблему продуманной модуляризацией и оффлайн компиляцией модулей. Что же касается Java, то сначала Sun, а теперь Oracle только обещают. Поэтому GUI приложения и не пишут на Java, несмотря на весьма хорошую кроссплатформенность: юзер не будет ждать 3-5 секунд после клика на иконку приложения.
С памятью получше, аккуратным тюнингом можно добиться разумных цифр, но до С++, конечно, далеко.
Это вы у меня спрашиваете? ;)
3-5 секунд? Хм… я не заметил, чтобы мои Java-окна так тормозили, да и вообще не заметил, чтобы тормозили. Что я делаю не так?
JVM стартует 0.2-0.5 секунд с обычного HDD. Вспомним хабрасоревнование от BarsMonster. Это Java и как раз быстрая вычислительная задача. Люди соревновались из доли секунды (это включая старт JVM). Парень на третьем месте каждый тест впихнул в 0.23 секунды. Поэтому пассаж про одну минуту мне абсолютно непонятен.
Я не тестами занимаюсь. Я сеть с тремя сотнями юзеров поддерживаю. И вижу, что таки если приложение написано на джаве, то оно стартует (что на маке, что под виндой) в разы, если не на порядки, дольше, чем если оно нативное. Такова жизнь.
А что за приложения?
Просто приложения на джаве обычно гигантские: IDE-шки всякие, сервера приложений. А нативные приложухи обычно поменьше. И они обычно несоизмеримы: если бы какая-нибудь нативная IDE обладала всеми возможностями джавовой, то не факт, что она запускалась бы быстрее. Так-то студия тоже долго стартует, хоть и не на джаве.
Таки да, сложно сравнивать разные аппликушки. У меня тут по роду занятий не IDE и не сервера приложений, а всякие научные аппликушки. Каждая — единственная в своем роде. И все тормознутые до жути.
Хотя, конечно, нельзя сбрасывать со счетов вероятность, что их всех пишут левой ногой. По крайней мере багов в них море.
За плечами имею богатый опыт разработки на различных языках и могу абсолютно точно сказать что большинство проблем производительности связано с банально неоптимальным кодом на уровне работы с данными. Причем, такие «косяки» не зависят от языка.
Что интересно, именно такие горе-программисты первыми начинают искать выход в «волшебных» параметрах виртуальных машин, настройках GC и прочих подкапотных настройках.
И других стеках технологий)
Диагностировать проблемы к сожалению редко кто пытается. По тыку пальца хотят решение. Беда не только программистов.
Было бы интересно узнать о сравнении производительности JVM и CLR. Преимущества и недостатки, узкие места обоих.
Если коротко, то в большинстве простых сценариев — одинаково. В сложных Java Runtime посильнее — JIT мощнее гораздо. Банально, в него гораздо больше сил вложено.
Есть еще вариант .NET с нативной компиляцией, но там тоже пилить и пилить. И натив и RyuJIT — пока сырые. Там несколько лет работы еще нужно.
но есть вариант с C# unsafe: берешь и оптимизируешь руками :)
кстати, отстутствие техники динамической деоптимизации как HotSpot'e компенсируется тем, что все методы по-умолчанию в C# — невиртуальные, а при нехватке мощного инлайнера — ручное указание методов для этих целей.
В общем, решения есть..
да, про невиртуальность — сущая правда. В HotSpot для этого сделали спекулятивную оптимизацию: если рантайм видит только одну реализацию метода и не видит overrid-а, то он считает, что метод — невиртуальный (финальный) и генерит оптимальный код. Если же в какой-то момент приходит другая реализация того же метода, то HotSpot делает доептимизацию.
Учитывая, что IL сам по себе намного продвинутее Java байткода — c custom value types, не участвующими в сборке мусора, true generics без приведения типов, unsafe блоками кода с прямой манипуляцией указателями — я не понимаю, как JVM изначально может быть сильнее. На чем основано ваше утверждение?
НЛО прилетело и опубликовало эту надпись здесь
в Java каждая вещь, связанная с выравниванием памяти, должна поддерживаться JVM.
Так в .NET (и это не сахар C#'a) можно спокойно выранивать структуры, чтобы предотвратить False Sharing.
Для Java пришлось ждать аннотации @Contended.
Oracle полировал VM

Это да. И сил много было брошено. Однако не все так гладко. Тот самый кейс с False Sharing'ом до 2011 года мог вызывать проблемы при маркировке объектов для GC.
Этим .NET перестал страдать, начиная c .NET 2.0 (а это 2006 год).
CLR Windows only. Преимущество это или недостатки каждый решает сам.
Уже нет :)
Честно говоря, не понимаю, почему все так агрессивно минусуют аргументы выше? За ними кроется вполне очевидная чья то боль, хоть и развернуты они не совсем полностью.
Ни в коем разе не пытаюсь судить что лучше/хуже, но есть один простой факт, который меня очень давно озадачивает: Задумайтесь, про любой иной язык/платформу кроме как Java/JVM, вы видите СТОЛЬКО выступлений, статей, размышлений, документации про супер-флаги (1200 штук, прекрасно), единственная цель которых это оптимизация?
Так может быть это свидетельствует о развитом коммьюнити?
И о существующей и ни кем не отрицаемой проблеме.
Забавно, вас тоже минуснули, видимо не всеми настолько не отрицаемой. :)
Хотя вот например общаясь со знакомыми Java разработчиками, слышу от них что они правда не видят никакой необычности во всём этом.
Нет, совсем логично, я забыл упомянуть, что я имел ввиду конкретно desktop приложения, за что скорее всего и словил минусов. Чуть выше мы с товарищем обсуждали именно desktop приложения на java, на примере IDE. А так мой комментарий действительно выглядит как троллинг.
Ммм, то есть вы понимаете, что этим утверждением, автоматически утверждаете и что все остальные коммьюнити развиты меньше? Если не секрет, а насколько меньше они развиты?
UPDATE: Ладно, извиняюсь, не хочу начинать здесь святых войн, но мне правда интересно отношение коммьюнити Java к 1200 флагам для отладки оптимизации.
Они развиты меньше в разы. В Европе и странах СНГ существует примерно десяток больших Java-конференций: Devoxx, JavaZone, JFokus, JavaLand, Geekout, Geekon, JEEconf, Joker, JPoint.
Можете ли вы назвать какие-нибудь европейские Community-driven конференции по C/C++, Python, Ruby, .NET или любой другой конкретной технологии, собирающие например, по тысяче человек?
Нашел сайт Lanyrd, конечно не самый точный подсчет, не знаю я размеров конференций, да и попадаются мультинаправленные конференции, но цифры интересные:
http://lanyrd.com/topics/javascript/ — past events: 1994.
http://lanyrd.com/topics/ruby/ — past events: 863.
http://lanyrd.com/topics/java/ — past events: 769.
http://lanyrd.com/topics/python/ — past events: 795.
http://lanyrd.com/topics/net/ — past events: 323.
О, спасибо за ссылки! Это интересно, на самом деле. Показывает тренды. Хотя больших конференций там мало.
Мультинаправленные большие есть, но на них много разных технологий.
По поводу JavaScript — да, это действительно самое быстрорастущее сообщество. Очень много фреймоворков и направлений, у каждого — свое сообщество :)
Дело даже не в конференциях, а скорее в том, что вбив в гугл вопрос практически любой сложности по джаве, можно за пару минут найти ответ, а чаще несколько и с примерами кода. На любой чих есть документация, сотни тысяч библиотек от именитых компаний вроде того же гугла или племени апачей, готовых решать за программиста (почти) любые проблемы.
В той или иной степени все это есть и в других языках, но никогда не видел чего-то настолько обширного, исключительно по своим наблюдениям.
но мне правда интересно отношение коммьюнити Java к 1200 флагам для отладки оптимизации.

Во-первых, большинство экспертов сходятся что реально нужных флагов 5, максимум 10. Во-вторых, это равносильно тому что говорить раз в Linux (условно) выходит много фиксов безопсности — она дырявая OC, а в Win (условно) мало фиксов — она супернадежная. Хотя может быть ровно наоборот, те кто забили на безопаснсоть не выпускают фиксы в принципе.
Если в каком-нибудь Visual Basic'e или PHP первой версии никто не обсуждал оптимизация, это не потому что они были супер быстрыми, а потому что не было смысла что-то оптимизировать. В случае решение вроде Hadoop'а на сотню кластеров оптимизация даже на 10% даст минус 10 серверов, вполне логично что оптимизация важна. То есть вопрос вовсе не в том что JVM медленная, вопрос в том что оптимизация JVM дает вполне реальную прибыль...
Но вы же понимаете, что все эти флаги не с потолка взялись, они кому-то понадобились. Кто-то таки наступил на грабли, прошел все корнер-кейсы, тестил java на таких нагрузках, которые есть лишь у десятка компаний во всем мире. Некоторые флаги позволяют jvm-инженерам отлавливать такие concurrency-баги, которые встречаются у 1 пользователя из миллиона. И, в отличие от многих других платформ, эти баги действительно фиксят.

Пойнт в том, что такое количество флагов свидетельствует о взрослости платформы (Возьмем к примеру GCC, "wc — l" показал 2500+ флагов).
А то, что про эти флаги говорят и рассказывают — как раз эффект очень развитого коммьюнити.
Каждый язык хорош на своем месте и для своих задач.
В Оракле тоже были сотни параметров. Потом в процессе матерения их количество уменьшалось.
Он становился все более самонастраивающимся.
В идеале ни у сервера БД, ни у ОС, ни у Джава машины параметров быть не должно.
Она сама должна себя оптимизировать и настраивать. Наверное Джава к этому когда нибудь придет.
идет. все движется в сторону сложных эвристик.
а потом сингулярность и сильный ии. и все)
Думаю, дело в том, что если лабать самый простой и идеоматичный Java-код, он будет довольно неторопливым. Этому способствует стандартная библиотека, которая щедро аллоцирует развесистые объекты и копирует память с места на место. Как результат — 95% Java-кода работает медленно. Когда происходит затык, люди идут в Гугл или на конференции изучать производительность.
С другой стороны, на Java можно писать очень быстрое ПО, но так почти никто не делает, потому что выходит едва ли проще, чем писать на том же C++.
Некоторые пишут, что на C++ то же самое: простой код программистов "от сохи" очень неэффективный. Я не согласен с этим: стандартная библиотека C++, общая идеоматика и паттерны гораздо экономичнее, чем в Java.
Да будет срач! Забудем о том, что у каждого языка своя ниша и будем кричать "Жаба тормозит!!!11!!" и "С++ сложна! Java быстрее ассемблера если правильно прогреть JVM!!!111!".
Если вы думаете, что фраза про нишы отменяет любые аргументы, это не так. Нишы эти пересекаются и на задачах, попадающих в пересечения, вполне можно производить сравнения.

Вполне может, например, оказаться, что ниша языка N полностью покрывается языками M и P (или даже одним M), причем M и P превосходят язык N в соответствующих задачах. И тогда вполне можно объявлять язык N ненужным.

Или может оказаться что ниша некоего языка Q никому нафиг не нужна.
Java и C++ имеют свои преимущество и недостатки. Каждый из них находит свое применение и довольно широкое. Java безопаснее и обычно быстрее в разработке, C++ обычно быстрее. Это не значит что какой то язык лучше или хуже.
Мне кажется, что правильно подмечено, что работа над перформансом не начинается с подбора флажков хотспота, и не с понимания внутренностей jvm. Перформанс начинается с правильного выбора алгоритмов и структур данных, а это не относится к языку. В .net и в unmanaged языках побольше степеней свободы в выборе структур данных (java приблизится к решению этой проблемы к 10ке, когда value types допишут).
Тем, кто приходят на доклады про jvm performance, стоит помнить, что понимание внутренностей vm может помочь выжать последние несколько процентов с java приложений, в некоторых редких случаях — починить некие паталогические проблемы, но для большинства задач хватит перформанса со всеми настройками по умолчанию, лишь бы код был написан разумно.
Да и вообще, перформанс волнует небольшое количество разработчиков в процентном отношении, чаще людей волнует функциональность их приложения, то простота и корректность написания той функциональности, которую требует заказчик.
Java и C++ — разницу хорошо видно в сравнении Cassandra и ScyllaDB. Сцилла быстрее в 10 раз, но зато и писали её дольше во столько же раз :)
Я думаю некорректно сравнивать это таким образом. Разница в быстродействии между ними обусловлена в первую очередь не языком, а архитектурой процесса обработки запросов. В Cassandra — это SEDA (https://en.wikipedia.org/wiki/Staged_event-driven_architecture), что позволяет хорошо регулировать нагрузку на систему, что в свою очередь, дает возможность получить устойчивую работу системы под разной нагрузкой. Но, при этом приводит к многоэтапной обработке каждого запроса, большому количеству внутренних очередей, и, как следствие, переключений контекта и невысокое быстродействие.
В scylla — процесс обработки запроса построен по Seastar (http://www.scylladb.com/technology/architecture/) — оптимизирован для разделения задач по корам и сетевым картам. Как следствие, количество переключений контекста сильно минимизировано, можно достичь большого красивого быстродействия. Особенно в ситуации, когда синтетический тест ставится на наборе данных полностью помещающемся в память.
Последние несколько лет работаю с этим чудесным языком, и вполне доволен им. Я решал задачи с projecteuler.net на разных языках, и разница в производительности между c / java у меня получалась от 10% до 30%, согласитесь это не такая уж и большая разница. А наличие в java из коробки коллекций позволяет к ряду задач находить решение на порядок быстрее (можно легко реализовать кэширование вычислений или с BigDecimal можно оперировать большими числами).
Если у вас проблемы с производительностью на java, то скорее всего вы что-то делаете не так.
Ну либо задача стоит такая, что вам приходится выжимать эти несчастные доли процента перфоманса из приложения. Однако какой бы нагруженный BigData/HFT проект ни был, перфоманс начинается с архитектуры. Аминь.
У нас тут своя, нехорошая история с GC.
Поставили как-то кластер Elasticsearch на десяток машин, при этом решили посмотреть, как будет вести себя G1. Кластер работал… пару дней, дальше перезапуск, из-за появлявшейся тормозящей кластер ноды по каким-то до сих пор невыясненным причинам.
Симптом: все потоки для балков прожигали время в таблице TheadLocal.ThreadLocalMap.table. Судя по дампам, таблица разрасталась и имела большой диапазон идущих подряд Entry, на которых как раз спотыкается цикл в методе ThreadLocalMap.expungeStaleEntry() (видимо тот самый цикл, что unlike Knuth). Вычеркнуть пытался ReentrantReadWriteLock всего лишь свой readHolds. Ну и вообще, в хот-тредах эластика часто появлялись методы ThreadLocalMap, вроде getEntryAfterMiss(), долго работающие с этой разросшейся таблицей.
На GC не думали, конечно, искали баги в коде… пока не сменили сначала на дефолтовый, потом на CMS. В обоих случаях проблем не было, только при G1 проявлялась такая проблема. Гадай теперь, что виновато: алгоритмы, тюнинг или железо.
а Java у вас какая?
Восьмая, конкретно 1.8.0_72
а баг против G1 завели в JBS?
На днях только закончили страдать с этой проблемой, а так да, надо бы. Вот только джава оракловая, как того рекомендует Elasticsearch.
Заведите баг. Потому что без вашего фидбэка они там как слепые котята — у них же в тестовой среде вряд ли есть боевой кластер Elasticsearch.
Мы в Одноклассниках периодически шлем им баги. И эти баги фиксятся. Вот, например, баги от apangin.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий