Здравствуйте, Cyberax, Вы писали:

G>>JFYI: Динамический инлайнинг виртуальных функций на новых процах уже не даст выраженного преимущества JIT, так как мне из достоверных источников известно, что разработчики процессоров уже научились делать предвыборку и предсказания по косвенным джампам. Специально для того, чтобы понизить цену виртуального вызова. Насколько я слышал краем уха, в процах последней линейки эта фича уже есть. Они ведь тоже ориентируются на производительность реальных приложений.
C>Это еще в вроде бы P4 было, я про это даже сюда как-то писал. Там фича в том, что таблица предсказателя — она не бесконечная, сам предсказатель не идеальный, и сам косвенный вызов становится дешевле, но не совсем бесплатным. Так что инлайнинг помогает.

Таблицы предсказания не будут большой проблемой, так как это реально важно в циклах. К тому же, таблицы сейчас реально большие — там сотни элементов точно, может быть даже тысяча. Предсказатель сейчас умеют делать очень хороший — у МИПСов которые 64 процент успешных предсказаний более 90%, что говорить о Core Duo.

G>>А для инлайна статических вызовов, раскрутки циклов, и распределения регистров (которых в x86 неприлично мало) у нормалного компилятора есть гораздо больше времени, чем у JIT. И на оптимальную кодогенерацию у него также гораздо больше времени, чем у джит. Скажем, IC++ учитывает такое количество факторов при кодогенерации, которое JIT-у в реальном времени учесть просто не под силу.
C>Только большую часть этих фич можно предрассчитать заранее В частности, это одна из причин почему в Java 7 вводят систему модулей, которые будут работать наподобии сборок в .NET. Модули можно будет заранее слинковать и кэшировать для них оптимизированый код.

Ну, оптимальную кодогенерацию, такую ацкую, как в IC++, с учетом параметров конвейра проца, особо не предрасчитаешь. Например , оптимальные алгоритмы распределения регистров сами по себе довольно тормозные. А преварительная компиляция — это уже не совсем JIT.

G>>Так что такие разговоры — скорее умный маркетинговый ход. Когда увижу, что джит убедительно обойдет IC++ на приложениях вроде SPEC — тогда можно будет отнестись к тому серьезно. Я думаю, так.
C>Еще нужно учесть фичи типа обязательной проверки границы в массивах в Java, отсутствие указателей и т.п.

Верно, на этом, мне кажется, во многом и получается просос раза в два.

C>>>Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится.
G>>Борись-не борись, а природу не обманешь. Интерпретация кода по любому на порядок тормознее выполнения native. А JIT — чем больше времени тратится на компиляцию, тем оптимальнее получается код, и тем больше выходит задержки. Хочешь учитывать факторы динамики — изволь периодически перекомпилять код.
C>Сейчас с приложениями на Java проблема в том, что они долго запускаются.
Ничего, это можно пережить ИМХО.

C> В Java 7 это частично пофиксили — оно умеет прекомпилировать системные файлы и сохранять их в виде кэшированого исполняемого кода. Поэтому в бэтах JDK7 приложения реально "на глаз" начали запускаться как нативные.

Прекомпиляция — это ведь опять не JIT, да?

C>>>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.
G>>Тебе про ИЛ-2 ответили чуть ниже — справедливости ради. Почему логика была на Java, и что произошло, когда ее на С++ переписали. Кроме того, я же тебе говрю — по приложениям заметны тормоза. Я видел это на игрушке своими глазами — полигонов и объектов там было меньше, чем в аналогичных играх в native, а тормозила она больше.
C>Как создатель видеочата с DIVX компрессией на Java могу сказать, что больше всего проблем было с GC. Скорость вообще проблемой не была.

Скорость, значит, была достаточной для твоих нужд.

C>Ну и ИЛ-2 работал так вполне прилично, когда еще был на Java написан.

Прилично, но по показаниям свидетеля переписывание дало таки ускорение в два раза, нет?

G>>Можешь называть эрланговский GC тупым и тормозным, если тебе так нравится, но факт состоит в том, что в отличии от мега-умных GC Java, — это настоящий инкрементальный GC, который обеспечивает реактивность приложения достаточную для телеком применений, что ни одна другая платформа со сборкой мусора сейчас дать не способна.
C>Инкрементальные GC — это фигня. Они есть ВЕЗДЕ, даже JVM можно настроить, чтобы использовался только трехцветный mark&sweep. Проблема с ними в том, что мутатор (т.е. работающая программа) на Java может заполнять кучу намного быстрее, чем ее будет собирать mark&sweep. В результате приложение может вдруг получать OutOfMemory. Не веришь — возьми сложное приложение на Java и поставь только инкрементальный mark&sweep. Потом наблюдай спецэффекты.

Приведи пожалуйста ссылку, подтверждающую отсутствие проблем с soft-realtime в любой JVM. Это следует из твоего текста.

C>В Erlang'е все хорошо из-за того, что объекты иммутабельны — там можно выполнять упрощенный вариант трехцветного mark&sweep.

В Эрланге применяется не mark&sweep, а stop&copy с двумя поколениями. Там нет проблем ни с переполнениями, ни с прерываниями.

G>>В результате, на Эрланге можно делать такие штуки, как свитчи вроде AXD301, которые не смотря на тормознутость Эрланговского GC — одни из самых производительных в мире соф-свитчей, а на Java с его мегаумным GC — у тебя не получится. Это — факты, уважаемый коллега, а не эмоции или "мнения". Мне от GC нужна именно реактивность, во вторую очередь — производительность на реальных задачах, а на такой параметр как "умность" не совершенно плевать.
C>Я как раз сейчас с телекомом работаю. Да, там Эрланг идеально подходит — скорость не очень важна, зато важно время отклика.

C>Но ведь ты изначально про тормознутость говорил! А тут, как ты сам знаешь, Эрланг сливает по полной программе.
Ну не по полной программе он сливает. Он все-таки заметно быстрее чем Питон. И у него все-таки есть HiPE. Однако, Java по голой производительности он не конкурент.

G>>Никому не надо, говоришь? Думаешь, это так прикольно — все ссылки нулями затирать, да объекты переиспользовать? Все были бы рады нормальному GC на J2ME, который бы просто работал по человечески, да тока во встроенной системе с ограниченной памятью ты вообще никакого real-time гарантировать не сможешь. Там элементарно создать ситуацию, когда хип забит, после чего он разом освобождается, а твоя программа просит памяти еще. Вот stop and copy коллектор такой проблемы лишен by design, почему он и применяется в Эрланге.
C>Это нужен просто НОРМАЛЬНЫЙ GC, а не realtime.
Там и нормального нет. А real-time там сделать в условиях ограниченной памяти сделать просто низя.

C>>>Хахаха. Трехцветный mark&sweep известен где-то с 70-х годов. Все основные изменения в нём уже сделаны, ускорить его сильнее — нельзя в принципе. Кроме того, у mark&sweep есть два фатальных недостатка: фрагментация кучи и зависимость времени работы от количества всех объектов (а не только живых как у stop-the-world).
G>>Прежде чем ржать, подумай, может ты чего не понял. Я глупости редко пишу, я думаю ты знаешь, и это не тот случай. Потому, что этой темой я активно интересовался несколько лет назад.
C>А я ей интересуюсь постоянно. GC — это моя область экспертизы, механизмы работы GC в Java я знаю буквально до ассемблерных команд.

G>>Дай поиск в гугле по словам incremental mark-and-sweep GC, поймешь, о чем я говорю. Речь не о скорости, не надо там ничего "ускорять". Речь об "инкрементальности" — гарантированной маленькой задержке на GC, чтобы его можно было прервать в любой момент, и хип остался в целостном состоянии. Это для mark-and-sweep — проблема.
C>Да нифига это не проблема! Это решается простейшим трехцветным GC (tri-color GC, tri-color mark&sweep), корректность работы которого была доказана Дейкстрой (AFAIR) в качестве примера доказательства параллельных алгоритмов. Год точно не вспомню, но точно раньше 80-х, так как я лично держал в руках вариант Схемы начала 80-х годов с таким сборщиком.

Хорошо, я сам поищу эти материалы еще раз, и отпишу сюда.

C>Так что лучше и меня иногда послушай
С удовольствием слушаю, я на проводе.

G>>Вот скажем, в информационном письме IBM от 2003 года они с гордостью писали, что в новом релизе IBM JVM им удалось довести гаранированную задержку на GC до такой малой величины, как половина секунды.
C>Вполне нормально для обычного не-realtime.

Более-менее нормально, если не считать, что до этого у них задержка достигала десятки секунд на серверах с большим объемом памяти, что было ни разу не нормально, и они задницу в кровь порвали, чтоб до полсекунды гарантии довести. Эту ссылку я также постараюсь найти.

G>>Очень многообещающие слова. И много у нас "современных коммерческих realtime GC" для Java? Мне кроме WebLogic RealTime edition вместе с паршивыми отзывами на него не известно ни одного. Список в студию, пожалуйста.
C>Azul Systems это УЖЕ предлагает коммерчески. Их системы УЖЕ успешно используются для realtime-трейдинга. Чисто программные системы — Sun RTSJ ( http://java.sun.com/javase/technologies/realtime/ ), Aonix и еще штук 5 таких же.

C>Они не распространены из-за того, что за них денег просят.

Посмотрю, спасибо.

C>>>Могу прислать whitepaper от Azul Systems, если интересно подробнее.
G>>Аппаратная реализация GC мне, разумеется, интересна, но это не совсем то, что надо.
C>Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия.

Плисуевину для GC и к Erlang/OTP можно добавить, я думаю, это будет не слишком дорого. Тока не нужно пока.