Re[14]: Потерялся, ищу совета
От: FR  
Дата: 11.02.08 04:37
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Приведённый выше пример можно записать как

M>s = [ 2*x | x <- [0..], x^2 > 3 ]
M>а можно как
M>"S is the list of all 2*x where x is an item in the list of natural numbers, and x squared is greater than 3."
M>Ты уверен, что для незнакомого с хаскелевским синтаксисом человека, вторая запись не будет более простой и понятной?

Не будет. Ты здесь реально просто тоже самое выразил в другом синтаксисе (да еще похоже в таком который править будет невозможно) а выше был разговор о том чтобы сложную абстракцию развернуть так чтобы она стала понятной новичку, здесь нет никакой развертки.
Re[15]: Потерялся, ищу совета
От: mkizub Литва http://symade.tigris.org
Дата: 11.02.08 10:48
Оценка:
Здравствуйте, FR, Вы писали:

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


M>>Приведённый выше пример можно записать как

M>>s = [ 2*x | x <- [0..], x^2 > 3 ]
M>>а можно как
M>>"S is the list of all 2*x where x is an item in the list of natural numbers, and x squared is greater than 3."
M>>Ты уверен, что для незнакомого с хаскелевским синтаксисом человека, вторая запись не будет более простой и понятной?

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


Наверное в этом и корень непонимания. Я имел в виду под развёрткой — представление той-же абстрации, но в более развёрнутом синтаксисе, более громоздком и более понятном синтаксисе для человека не знакомого с компактным синтаксисом. Именно об этом противоречии и шла речь в изначальном постинге http://www.rsdn.ru/forum/message/2822611.1.aspx
Автор: Klapaucius
Дата: 04.02.08
на который я отвечал и вся эта под-ветка началась:
Упрощенно: громоздкий синтаксис тяготеет к литературному языку и доступен после окончания первого класса; легковесный — тяготеет к математической нотации, с понятными проблемами — первого класса уже недостаточно!
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[14]: Потерялся, ищу совета
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.02.08 11:19
Оценка:
Здравствуйте, mkizub, Вы писали:
M>Приведённый выше пример можно записать как
M>s = [ 2*x | x <- [0..], x^2 > 3 ]
M>а можно как
M>"S is the list of all 2*x where x is an item in the list of natural numbers, and x squared is greater than 3."
M>Ты уверен, что для незнакомого с хаскелевским синтаксисом человека, вторая запись не будет более простой и Нпонятной?
Совершенно не факт, что синтаксис хаскеля изучить существенно сложнее, чем понятия "естественных чисел" и "отквадраченный х".
И это еще вырожденный пример — в реальной жизни такие простые выражения — исключения. Ну вот посмотрите в википедии про Exceptionally Simple Theory of Everything. Проблема там не в синтаксисе, а в семантике.

M>Это не развёртка, это выражение одной абстракции через другие, более примитивные. При этом первоначальная абстрация уже отсутствует, она теряется. Такой же пример я могу привести из собственного опыта написания компиляторов — развёртка декларативного пролог-подобного кода в императивную state machine. При этом теряется как понятность так и декларативность. Но эти записи не эквивалентны, это потеря информации.

Ну вот пока непонятно, откуда возьмется недостающая информация.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Потерялся, ищу совета
От: Gaperton http://gaperton.livejournal.com
Дата: 11.02.08 11:24
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


G>>>>Есть примеры, когда JIT или интерпретатор обходит native?

C>>>HotSpot JVM на некоторых микротестах.
G>>Ты же понимаешь, что это не совсем "практика". Это спорт.
C>Все ближе к реальной практике. Я бы сказал, что года через четыре уже будет реально заметно на макроскопических программах.

Я понимаю, о чем ты. Я про это читал уже давно — теоретически, у JIT больше информации для генерации оптимального кода, так как ему доступна статистика выполнения, чего нет у компилятора. Теоретически, возможно применять это знание для, скажем, выбора оптимальной схемы компиляции switch или множественных if. Также, JIT может генерировать специализированные версии функций для частных случаев, что радикально поправляет здоровье в случае динамики, как делает, например, Psyco.

Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT). Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco.

G>>В реальности все знают, что у JVM-приложений хуже отклик и они медленнее — это реально заметно на апликухах.

C>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++.

Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад. Что я могу сказать — налицо просос как минимум раза в 2 по сравнению с нативными играми по отклику при сравнимом уровне графики.

C>Естественно, в некоторых случаях могут быть проблемы из-за сборщика мусора — но он в Sun JVM пока что самый лучший в индустрии не-realtime-коллектор.


Лучший в индустрии коллектор, который дает soft-realtime, пока что в Erlang/OTP, и аналогов ему (пока) в индустрии нет. Он, может быть, и тормознее, чем сановский — все-таки stop-and-copy, зато обеспечивает великолепный и почти постоянный отклик, гораздо лучше явких GC. Еще есть вроде как WebLogic RealTime Edition, но народ кто с ним работал морщится и говорит что добавив в название RealTime они погорячились.

Однако — все течет, все меняется, и я знаю что сейчас очень много усилий тратится на разработку эффективных инкрементальных mark-and-sweep коллекторов. Эти исследования рано или поздно принесут результат.
Re[19]: Потерялся, ищу совета
От: Gaperton http://gaperton.livejournal.com
Дата: 11.02.08 11:26
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Как показывает практика native совсем не означает быстро работать


G>>Есть примеры, когда JIT или интерпретатор обходит native?


AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.


Андрей, это казуистика, понятно, что сделать тормозной native элементарно и без помощников . Я, разумеется, имел в виду — лучший JIT против лучшего Native.
Re[22]: Потерялся, ищу совета
От: mkizub Литва http://symade.tigris.org
Дата: 11.02.08 11:37
Оценка: 6 (1)
Здравствуйте, Gaperton, Вы писали:

G>Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT). Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco.


Легко.

public class Test {
  public static final boolean DEBUG = Main.DEBUG;
  public int test(int a, int b) {
    int result = a + b;
    if (DEBUG) System.out.println("add "+a+" to "+b+" is "+result);
    return result;
  }
}
public class Main {
  public static boolean DEBUG;
  public static void main(String[] args) {
    if (args.length > 0 && "--debug".equals(args[0]))
      Main.DEBUG = true;
    Test t = new Test();
    for (int i=0; i < 10000000; i++)
      for (int j=0; j < 10000000; j++)
        t.test(i,j);
  }
}


Пример с отладочным кодом — самый простой. В реале final поля инициализированные из файлов конфигурации очень хорошо ускоряются программы.
Более сложный пример — изменение call conventions для оптимального вызова методов и т.п.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[15]: Потерялся, ищу совета
От: Gaperton http://gaperton.livejournal.com
Дата: 11.02.08 11:54
Оценка: 24 (4) +5
Здравствуйте, VladD2, Вы писали:

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


G>>Не знаю, не знаю. Нивабиду, но люди говорят, что бабло плохо вас мотивирует в случае сайта. Жалуются, что у вас даже за деньги рекламу разместить проблема. Жалуются, что баннер ваш меняется слишком редко — доходит до идиотизма, скажем, неделями висит баннер с рекламой уже прошедшего семинара, и снять его нельзя.


VD>Это утут совсем офтоп, но по сикрету тебе скажу, что банер менять можно. Можно даже снять, но вот продавать мы может только на фиксированный срок. Иначе ничего не спланируешь.


VD>Ну, и деньги это копеечные. На них даже одному черовеку зарплату платить нельзя.


Этот оффтоп я развел к тому, чтобы наглядно показать, что деньги и прочего рода взятки не являются определяющим фактором для развития мотивации. Я уверен что при желании сделать деньги на RSDN и наличии организованности внутри команды у вас бы все получилось — дело скорее в том, что у вас это никому нахрен не надо, и это первично, а не деньги. То есть дело не в деньгах, а в желании.

Вот я вам, например, предлагал купить лицензию на движок вашего форума. И не только я. Выяснилось, что сделать это невозможно, и всем похрен. При этом, вы жалуетесь на недостаток ресурсов для развития сайта, продавать его не хотите, но и в open source вы ни под какой лицензией его класть тоже не хотите — хотя могли бы выложить его под двойной лицензией — GPL + коммерческая.

Короче, Влад, мне кажется, деньги вам не нужны. И в контексте ситуации вокруг Немерле — это скорее плохо, чем хорошо. Потому, что ваша мотивация не сфокусирована и в большей части определяется сиюминутными интересами учатсников. Хочу подчеркнуть — это мое впечатление, я не собираюсь его никому навязывать и не хочу никого обидеть или обвинять в чем-то. Я в данный момент стараюсь быть честным.

G>>С этим я безусловно согласен. Немерле — это отличный опыт, практически доказывающий, что возможно мягкое введение концепций ФП в мэйнстримовые языки. Примерно, как это было сделано с С, С++, и ООП. Важность Немерле с этой точки зрения сложно переоценить.


VD>В общем, то концепции ООП он тоже туда вводит. Тут он конечно не один. Есть скала, да и Шарп подтягивается. Но лично мне ждать пока МС или Сан дорастут скажем до паттер-матчинга или сделает чтобы все стрэйтменты можно было в выражениях использовать я не хочу. Боюсь, что столько не проживу.


Думаю, кстати, проживешь. Ведь МС зачем-то взял разработчиков Немерле на работу — это не просто так. Языки типа Немерле и Scala являются источником вдохновения для разработчиков C#. Это по сути исследовательские языки, на которых проходят апробацию новые концепции. Единственное — у них есть понятие learning curve. Однако, они теперь могут запускать и параллельные ветки — F# же они включили в список поддерживаемых языков. Я уверен, что Немерле гораздо лучше F# приспособлен к современным реалиям, потому что это не калька с известного языка, а творческая и удачная переработка. По своей значимости он похож на С++ — обеспечивает мягкое введение в новый мир. Однако, без поддержки майкрософта — здесь мне кажется мало что может произойти.

То есть, сценария у нас три, и они не являются взаимоисключающими.
1) Один из поддерживаемых языков платформы С# или F# приобретает наиболее удачные свойства Немерле, приближаясь к нему.
2) Немерле с некоторыми модификациями становится одним из официальных языков платформы .NET
3) Про Немерле все забывают. R.I.P.

При данном раскладе — я бы просто подождал, что произойдет дальше. А на вашем месте — попытался бы получить финансирование данных работ от Microsoft Research, как они делали с F#. Если вы, конечно, серьезно настроены. Возможно, у вас есть другой план действий — так озвучте его, чтобы народ успокоить, вдохновить, и вселить в их сердца надежду. А пока — как очень метко сказал GlebZ, ваш шкаф зело похож на гроб, а его ручка — на красивую ошибку природы.
Re[22]: Потерялся, ищу совета
От: Cyberax Марс  
Дата: 11.02.08 12:06
Оценка: 4 (1) +1
Здравствуйте, Gaperton, Вы писали:

G>Я понимаю, о чем ты. Я про это читал уже давно — теоретически, у JIT больше информации для генерации оптимального кода, так как ему доступна статистика выполнения, чего нет у компилятора. Теоретически, возможно применять это знание для, скажем, выбора оптимальной схемы компиляции switch или множественных if. Также, JIT может генерировать специализированные версии функций для частных случаев, что радикально поправляет здоровье в случае динамики, как делает, например, Psyco.

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

G>Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT).

Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится.

G>Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco.

Собственно, при прочих равных — превосходство очевидно, у JITа в запасе больше трюков, чем у статического компилятора.

C>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++.

G>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад.
Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.

В приложениях на Java задержки от JITа вообще не составляют заметной проблемы, после пары десятков секунд все что нужно — уже будет скомпилировано. Основная проблема — это сборщик мусора. Именно он и создает в играх тормоза — в нативных играх используется хорошо оптимизированая ручная работа с памятью.

Если убрать задержки от GC — то Java спокойно держит soft-realtime. Обратись в Azul Systems, они тебе с радостью продадут машину с аппаратным ускорением GC, ликвидирущим GC-паузы — эти машинки многие сейчас используют для всяких трейдерских систем.

C>>Естественно, в некоторых случаях могут быть проблемы из-за сборщика мусора — но он в Sun JVM пока что самый лучший в индустрии не-realtime-коллектор.

G>Лучший в индустрии коллектор, который дает soft-realtime, пока что в Erlang/OTP, и аналогов ему (пока) в индустрии нет.
Наоборот, в Erlang'е очень тупой и тормозной GC — просто сам язык устроен так, что хватает и такого тупого GC. Какой смысл тратить кучу человеческих ресурсов на разработку супербыстрого GC, если интерпретатор языка будет работать так медленно, что GC будет простаивать почти все время?

G>Он, может быть, и тормознее, чем сановский — все-таки stop-and-copy, зато обеспечивает великолепный и почти постоянный отклик, гораздо лучше явких GC. Еще есть вроде как WebLogic RealTime Edition, но народ кто с ним работал морщится и говорит что добавив в название RealTime они погорячились.

Есть realtime-сборщики для Java на J2ME, но их особо никому не нужно.

G>Однако — все течет, все меняется, и я знаю что сейчас очень много усилий тратится на разработку эффективных инкрементальных mark-and-sweep коллекторов. Эти исследования рано или поздно принесут результат.

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

Поэтому, современные быстрые realtime GC (в том числе с приставкой hard-) используют конкуррентную параллельную упаковку объектов. То есть, они работают как stop-the-world, но только не останавливают приложение, а работают параллельно с ним. Для этого нужно, на самом деле, "не так много" — достаточно быстрых forwarding references и быстрых барьеров.

Могу прислать whitepaper от Azul Systems, если интересно подробнее.
Sapienti sat!
Re[16]: Потерялся, ищу совета
От: FR  
Дата: 11.02.08 12:20
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Наверное в этом и корень непонимания. Я имел в виду под развёрткой — представление той-же абстрации, но в более развёрнутом синтаксисе, более громоздком и более понятном синтаксисе для человека не знакомого с компактным синтаксисом. Именно об этом противоречии и шла речь в изначальном постинге http://www.rsdn.ru/forum/message/2822611.1.aspx
Автор: Klapaucius
Дата: 04.02.08
на который я отвечал и вся эта под-ветка началась:

M>Упрощенно: громоздкий синтаксис тяготеет к литературному языку и доступен после окончания первого класса; легковесный — тяготеет к математической нотации, с понятными проблемами — первого класса уже недостаточно!

Ну такое просто малоинтересно, так как ничего практически не дает.
Re[23]: Потерялся, ищу совета
От: Left2 Украина  
Дата: 11.02.08 12:42
Оценка: 12 (1)
C>>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++.
G>>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад.
C>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.

Справедливости ради — в итоге ИМНИП от джавы разработчики избавились совсем (или почти совсем), чем ускорили рантайм раза в два (имеется в виду не только прирост FPS но и более точный обсчёт физики, реально вряд ли ФПС подскочили в 2 раза). Основная причина по которой писали на джаве — чтобы ускорить разработку, т.к. конкуренты не дремали и сроки поджимали и игра нужна была "хоть в каком-то виде но к концу месяца". По мере развития, когда физика более-менее устаканилась — джавовую часть переписали на С++. PS — я там не инсайдер и инсайдерской информацией не владею, но это моё вольное изложение слов директора их конторы на каком-то из авиафорумов.

C>В приложениях на Java задержки от JITа вообще не составляют заметной проблемы, после пары десятков секунд все что нужно — уже будет скомпилировано. Основная проблема — это сборщик мусора. Именно он и создает в играх тормоза — в нативных играх используется хорошо оптимизированая ручная работа с памятью.

Опять же, касаясь примера — поскольку на джаве в основном была физика (т.е. обсчёты), то обьектов создавалось-умирало совсем немного, что в итоге вылилось во вполне приемлимые "лаги" в геймплее.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[24]: Потерялся, ищу совета
От: Gaperton http://gaperton.livejournal.com
Дата: 11.02.08 16:03
Оценка: -1
Здравствуйте, Left2, Вы писали:

C>>>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++.

G>>>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад.
C>>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.

L>Справедливости ради — в итоге ИМНИП от джавы разработчики избавились совсем (или почти совсем), чем ускорили рантайм раза в два (имеется в виду не только прирост FPS но и более точный обсчёт физики, реально вряд ли ФПС подскочили в 2 раза). Основная причина по которой писали на джаве — чтобы ускорить разработку, т.к. конкуренты не дремали и сроки поджимали и игра нужна была "хоть в каком-то виде но к концу месяца". По мере развития, когда физика более-менее устаканилась — джавовую часть переписали на С++. PS — я там не инсайдер и инсайдерской информацией не владею, но это моё вольное изложение слов директора их конторы на каком-то из авиафорумов.


Вот то-то и оно. В реальных аппликухах разница заметна глазом почему-то. И в два раза — это не проблема GC. GC должен давать общий оверхэд процентов в 5 от силы, если специально не стараться его нагрузить.
Re[25]: Потерялся, ищу совета
От: Cyberax Марс  
Дата: 11.02.08 16:09
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Вот то-то и оно. В реальных аппликухах разница заметна глазом почему-то. И в два раза — это не проблема GC. GC должен давать общий оверхэд процентов в 5 от силы, если специально не стараться его нагрузить.

5% на GC — это больше из области фантастики или очень особых условий. В десктопных приложениях тормоза реально из-за него и бывают, ну и из-за долгого начального запуска.

Кроме того, проблема с GC не в скорости, а в латентности. По скорости даже числодробилки на Java не так уж плохо себя ведут.
Sapienti sat!
Re[23]: Потерялся, ищу совета
От: Gaperton http://gaperton.livejournal.com
Дата: 11.02.08 16:46
Оценка: 31 (4) +1
Здравствуйте, Cyberax, Вы писали:

G>>Я понимаю, о чем ты. Я про это читал уже давно — теоретически, у JIT больше информации для генерации оптимального кода, так как ему доступна статистика выполнения, чего нет у компилятора. Теоретически, возможно применять это знание для, скажем, выбора оптимальной схемы компиляции switch или множественных if. Также, JIT может генерировать специализированные версии функций для частных случаев, что радикально поправляет здоровье в случае динамики, как делает, например, Psyco.

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

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

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

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

G>>Короче, в теории можно много чего. Практически, однако, заметного преимущества пока нет — зато есть видимый глазу просос по времени отклика — неравномено оно (понятно, что здесь и GC оказывает влияние, дело не только и не столько в JIT).

C>Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится.

Борись-не борись, а природу не обманешь. Интерпретация кода по любому на порядок тормознее выполнения native. А JIT — чем больше времени тратится на компиляцию, тем оптимальнее получается код, и тем больше выходит задержки. Хочешь учитывать факторы динамики — изволь периодически перекомпилять код.

G>>Было бы очень интересно посмотреть на работы в этом направлении, демонстрирующие убедительное превосходство JIT перед статической компиляцией. Пока мне такого не известно — если не брать случай динамических языков и Psyco.

C>Собственно, при прочих равных — превосходство очевидно, у JITа в запасе больше трюков, чем у статического компилятора.

В теории — да.

C>>>В реальности хорошие Java-приложения работают без всяких проблем с откликом и не медленнее нативных. Можно сравнить по той же Eclipse и MSVS, Eclipse полностью на Java написана (за исключением небольшого куска нативного кода в SWT), а MSVS по большей части на С++.

G>>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени. Ты много игр FPS знаешь на Java? Я вот одну видел — стратегию в 3D (с расслабленными требованиями к фреймрейту), демку ее можно было скачать с java.com несколько лет назад.
C>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.

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

C>В приложениях на Java задержки от JITа вообще не составляют заметной проблемы, после пары десятков секунд все что нужно — уже будет скомпилировано. Основная проблема — это сборщик мусора. Именно он и создает в играх тормоза — в нативных играх используется хорошо оптимизированая ручная работа с памятью.


Он создает не тормоза, а задержки, потому что не является по настоящему инкрементальным. Общее время проводимое в GC на самом деле небольшое — например, спокон веков известно, что mark and sweep GC по сумарному оверхэду эффективнее подсчета ссылок.

C>Если убрать задержки от GC — то Java спокойно держит soft-realtime. Обратись в Azul Systems, они тебе с радостью продадут машину с аппаратным ускорением GC, ликвидирущим GC-паузы — эти машинки многие сейчас используют для всяких трейдерских систем.


Это решение. Но к эффективности JIT это отношения не имеет.

C>>>Естественно, в некоторых случаях могут быть проблемы из-за сборщика мусора — но он в Sun JVM пока что самый лучший в индустрии не-realtime-коллектор.

G>>Лучший в индустрии коллектор, который дает soft-realtime, пока что в Erlang/OTP, и аналогов ему (пока) в индустрии нет.
C>Наоборот, в Erlang'е очень тупой и тормозной GC — просто сам язык устроен так, что хватает и такого тупого GC. Какой смысл тратить кучу человеческих ресурсов на разработку супербыстрого GC, если интерпретатор языка будет работать так медленно, что GC будет простаивать почти все время?

Можешь называть эрланговский GC тупым и тормозным, если тебе так нравится, но факт состоит в том, что в отличии от мега-умных GC Java, — это настоящий инкрементальный GC, который обеспечивает реактивность приложения достаточную для телеком применений, что ни одна другая платформа со сборкой мусора сейчас дать не способна.

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

G>>Он, может быть, и тормознее, чем сановский — все-таки stop-and-copy, зато обеспечивает великолепный и почти постоянный отклик, гораздо лучше явких GC. Еще есть вроде как WebLogic RealTime Edition, но народ кто с ним работал морщится и говорит что добавив в название RealTime они погорячились.

C>Есть realtime-сборщики для Java на J2ME, но их особо никому не нужно.

Для J2ME сборщики такие все из себя рилтайм, что там программерам не рекомендуют объекты шибко активно выделать, и рекомендуют выделенные объекты переиспользовать, а не оставлять их GC. А если надо отдать объект GC — то надо ручками все ссылочки занулить, чтоб бедный GC не перенапрягся. В результате, пишешь такой код, как будто никакого GC и вовсе нет. Писал я под J2ME несколько лет назад для своей мобилы, помню эти рекомендации прекрасно.

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

G>>Однако — все течет, все меняется, и я знаю что сейчас очень много усилий тратится на разработку эффективных инкрементальных mark-and-sweep коллекторов. Эти исследования рано или поздно принесут результат.

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

Прежде чем ржать, подумай, может ты чего не понял. Я глупости редко пишу, я думаю ты знаешь, и это не тот случай. Потому, что этой темой я активно интересовался несколько лет назад. Дай поиск в гугле по словам incremental mark-and-sweep GC, поймешь, о чем я говорю. Речь не о скорости, не надо там ничего "ускорять". Речь об "инкрементальности" — гарантированной маленькой задержке на GC, чтобы его можно было прервать в любой момент, и хип остался в целостном состоянии. Это для mark-and-sweep — проблема. А вот для stop-and-copy делается довольно просто.

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

C>Поэтому, современные быстрые realtime GC (в том числе с приставкой hard-) используют конкуррентную параллельную упаковку объектов. То есть, они работают как stop-the-world, но только не останавливают приложение, а работают параллельно с ним. Для этого нужно, на самом деле, "не так много" — достаточно быстрых forwarding references и быстрых барьеров.


Очень многообещающие слова. И много у нас "современных коммерческих realtime GC" для Java? Мне кроме WebLogic RealTime edition вместе с паршивыми отзывами на него не известно ни одного. Список в студию, пожалуйста.

C>Могу прислать whitepaper от Azul Systems, если интересно подробнее.


Аппаратная реализация GC мне, разумеется, интересна, но это не совсем то, что надо.
Re[26]: Потерялся, ищу совета
От: Gaperton http://gaperton.livejournal.com
Дата: 11.02.08 16:54
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


G>>Вот то-то и оно. В реальных аппликухах разница заметна глазом почему-то. И в два раза — это не проблема GC. GC должен давать общий оверхэд процентов в 5 от силы, если специально не стараться его нагрузить.

C>5% на GC — это больше из области фантастики или очень особых условий. В десктопных приложениях тормоза реально из-за него и бывают, ну и из-за долгого начального запуска.

Тесты консервативного Boehm GC для С++ на реальных приложениях дают 2-3% замедления для одного и того же приложения. Надо иметь в виду, что без GC местами применяются довольно дорогие техники управления памятью, такие как подсчет ссылок, что дороже GC. Второе, что надо иметь в виду — кроме собственно поиска мертвых объектов время тратится на управление хипом, выделение и удаление объектов, и это время никуда не девается при отсутствии GC.

Управляющая программа AXD301 проводит в GC 5% своего времени. Тесты смоллток-программ показывают такую же картину — в среднем 5%. Средние затраты на GC вообще в общественном сознании сильно преувеличены, и оверхэд GC является скорее мифом — специалистам известно, что подсчет ссылок дороже чем GC, и подсчета ссылок при этом почему-то никто не боится. Затраты в случае GC заметнее потому, что современные GC не являются инкрементальными, и копят свои проценты, которые потом зачищают всем скопом. Вот тут-то GC и становится заметным.

C>Кроме того, проблема с GC не в скорости, а в латентности. По скорости даже числодробилки на Java не так уж плохо себя ведут.

Проблема не столько в латентности GC, сколько в его инкрементальности — гранулярности операций GC, а именно — его отсутствии.
Re[24]: Потерялся, ищу совета
От: Cyberax Марс  
Дата: 11.02.08 18:51
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

Это еще в вроде бы P4 было, я про это даже сюда как-то писал. Там фича в том, что таблица предсказателя — она не бесконечная, сам предсказатель не идеальный, и сам косвенный вызов становится дешевле, но не совсем бесплатным. Так что инлайнинг помогает.

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

Только большую часть этих фич можно предрассчитать заранее В частности, это одна из причин почему в Java 7 вводят систему модулей, которые будут работать наподобии сборок в .NET. Модули можно будет заранее слинковать и кэшировать для них оптимизированый код.

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

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

C>>Время отклика из-за JITа важно только во время старта приложения (с этим тоже борются, кстати), пока оно всё не устаканится.

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

C>>Классический пример — "ИЛ-2 Штурмовик". Там вся логика в игре на Java была написана с небольшим движком на С++.

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

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

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

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

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

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

Я как раз сейчас с телекомом работаю. Да, там Эрланг идеально подходит — скорость не очень важна, зато важно время отклика.

Но ведь ты изначально про тормознутость говорил! А тут, как ты сам знаешь, Эрланг сливает по полной программе.

G>Для J2ME сборщики такие все из себя рилтайм, что там программерам не рекомендуют объекты шибко активно выделать, и рекомендуют выделенные объекты переиспользовать, а не оставлять их GC. А если надо отдать объект GC — то надо ручками все ссылочки занулить, чтоб бедный GC не перенапрягся. В результате, пишешь такой код, как будто никакого GC и вовсе нет. Писал я под J2ME несколько лет назад для своей мобилы, помню эти рекомендации прекрасно.

J2ME — они разные бывают. В некоторых из них используется (до сих пор !) консервативный GC. Поэтому и такие рекомендации.

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

Это нужен просто НОРМАЛЬНЫЙ GC, а не realtime.

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

G>Прежде чем ржать, подумай, может ты чего не понял. Я глупости редко пишу, я думаю ты знаешь, и это не тот случай. Потому, что этой темой я активно интересовался несколько лет назад.
А я ей интересуюсь постоянно. GC — это моя область экспертизы, механизмы работы GC в Java я знаю буквально до ассемблерных команд.

G>Дай поиск в гугле по словам incremental mark-and-sweep GC, поймешь, о чем я говорю. Речь не о скорости, не надо там ничего "ускорять". Речь об "инкрементальности" — гарантированной маленькой задержке на GC, чтобы его можно было прервать в любой момент, и хип остался в целостном состоянии. Это для mark-and-sweep — проблема.

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

Так что лучше и меня иногда послушай

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

Вполне нормально для обычного не-realtime.

G>Очень многообещающие слова. И много у нас "современных коммерческих realtime GC" для Java? Мне кроме WebLogic RealTime edition вместе с паршивыми отзывами на него не известно ни одного. Список в студию, пожалуйста.

Azul Systems это УЖЕ предлагает коммерчески. Их системы УЖЕ успешно используются для realtime-трейдинга. Чисто программные системы — Sun RTSJ ( http://java.sun.com/javase/technologies/realtime/ ), Aonix и еще штук 5 таких же.

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

C>>Могу прислать whitepaper от Azul Systems, если интересно подробнее.

G>Аппаратная реализация GC мне, разумеется, интересна, но это не совсем то, что надо.
Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия.
Sapienti sat!
Re[27]: Потерялся, ищу совета
От: Cyberax Марс  
Дата: 11.02.08 19:05
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Тесты консервативного Boehm GC для С++ на реальных приложениях дают 2-3% замедления для одного и того же приложения. Надо иметь в виду, что без GC местами применяются довольно дорогие техники управления памятью, такие как подсчет ссылок, что дороже GC. Второе, что надо иметь в виду — кроме собственно поиска мертвых объектов время тратится на управление хипом, выделение и удаление объектов, и это время никуда не девается при отсутствии GC.

Я использовал Boehm GC в своих приложениях — ну нет там 2-3% замедления. Реально около 10-15% минимум. Для вещей типа игр оно вообще неприменимо — так как всё время норовит начать обходить графы объектов, составляющих геометрию. А это смерть для GC.

Вещи типа подсчета ссылок обычно можно очень сильно уменьшить.

G>Управляющая программа AXD301 проводит в GC 5% своего времени. Тесты смоллток-программ показывают такую же картину — в среднем 5%.

Да, это вполне реально для скриптовых языков, так как мутатор работает очень медленно. Представь, что у тебя мутатор работает в 10 раз быстрее (нативный JIT-код), а GC работает с той же скоростью. Каким тогда будет соотношение времени работы GC и полезного кода?

Вот.

Поэтому простые GC типа Эрланговского и неприменимы в быстрых нативных системах. Там приходится извращатсья с более сложными алгоритмами, из-за чего очень часто теряется realtime. Просто преимущества от него перевешивают увеличение сложности.

C>>Кроме того, проблема с GC не в скорости, а в латентности. По скорости даже числодробилки на Java не так уж плохо себя ведут.

G>Проблема не столько в латентности GC, сколько в его инкрементальности — гранулярности операций GC, а именно — его отсутствии.
А я что сказал?
Sapienti sat!
Re[25]: Потерялся, ищу совета
От: Cyberax Марс  
Дата: 11.02.08 19:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

Отвечу сам себе — механизм трехцветного GC и преимущество Erlang'а я как-то описывал в этом форуме:
http://www.rsdn.ru/Forum/?mid=2261479
Автор: Cyberax
Дата: 12.12.06
Sapienti sat!
Re[20]: Потерялся, ищу совета
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.02.08 21:13
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Андрей, это казуистика, понятно, что сделать тормозной native элементарно и без помощников


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

G>. Я, разумеется, имел в виду — лучший JIT против лучшего Native.


Это тоже не совсем корректно, потому что у лучших native вроде VC или ICC значительно более длинная история и значительно больше бабла вбухано в оптимизатор.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[25]: Потерялся, ищу совета
От: Gaperton http://gaperton.livejournal.com
Дата: 11.02.08 22:02
Оценка:
Здравствуйте, 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 можно добавить, я думаю, это будет не слишком дорого. Тока не нужно пока.
Re[26]: Потерялся, ищу совета
От: Cyberax Марс  
Дата: 11.02.08 22:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

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

У P4 был что-то около 99% процент успешных предсказаний на некоторых реальных программах. Еще шутки были, что P5 будет предсказывать результат программы еще до ее запуска.

Проблема в косвенном вызове может быть, если код не окажется в кэше, ну и длинные вызовы тоже более медленны. А еще проблемы с регистрами — в случае с inline'ингом компилятор может оптимизировать распределение для всего блока в целом.

Так что inline еще очень рано со счетов списывать.

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

Там именно предрассчет карт покрытия регистрами, раскрутки циклов и прочих хинтов хотят делать. Пока все еще на исследовательском этапе, но уже что-то интересное проявляется.

C>>Еще нужно учесть фичи типа обязательной проверки границы в массивах в Java, отсутствие указателей и т.п.

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

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

G>Прекомпиляция — это ведь опять не JIT, да?
Это помощь JITу — оно потом может совершенно стандартным образом в runtime'е перекомпилироваться.

C>>Как создатель видеочата с DIVX компрессией на Java могу сказать, что больше всего проблем было с GC. Скорость вообще проблемой не была.

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

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

G>Прилично, но по показаниям свидетеля переписывание дало таки ускорение в два раза, нет?
Ну он точно его не измерял. Можно попробовать скачать ИЛ-2 и проверить

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

G>Приведи пожалуйста ссылку, подтверждающую отсутствие проблем с soft-realtime в любой JVM. Это следует из твоего текста.
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.%20The%20Concurrent%20Low%20Pause%20Collector%7Coutline — оно не оптимизировано на ПОЛНЫЙ realtime и имеет небольшие фиксированые паузы. Однако, это уже чистая деталь реализации — там используется как раз конкуррентный mark&sweep.

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

G>В Эрланге применяется не mark&sweep, а stop&copy с двумя поколениями. Там нет проблем ни с переполнениями, ни с прерываниями.
AFAIR, их там несколько. У них изначально при передаче сообщения копировались, и отдельные кучи собирались mark&sweep'ом. Чуть позже сообщения копироваться перестали и стали (вынужденно) использовать систему с поколениями.

C>>Это нужен просто НОРМАЛЬНЫЙ GC, а не realtime.

G>Там и нормального нет. А real-time там сделать в условиях ограниченной памяти сделать просто низя.
Ну так причем тогда GC?

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

G>Хорошо, я сам поищу эти материалы еще раз, и отпишу сюда.
http://www.memorymanagement.org/glossary/t.html#tri-color.marking

Historical note: "Tri-color marking" is the term used to describe an algorithm developed in 1975 by E. W. Dijkstra and others, as an exercise in proving cooperating programs correct. They chose as their problem a parallel garbage collector, with the intent of illustrating cooperating sequential processes with a large shared data space but minimal exclusion and synchronization constraints.


C>>Так что лучше и меня иногда послушай

G>С удовольствием слушаю, я на проводе.
Алло, алло! Кто там?

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

Так можешь не искать, у нас задержка примерно в две минуты на сервере с 16Гб хипом после тюнингов. Что еще не так плохо, кстати. Нам это не так важно, так как неотзывчивый сервер у нас просто из кластера блокируется — Oracle Coherence рулит.

C>>Именно то — реальный способ сделать realtime-GC без потерь в скорости, Erlang OTP оно и не снилось. Те же техники можно сделать и программно — с заметными потерями быстродействия.

G>Плисуевину для GC и к Erlang/OTP можно добавить, я думаю, это будет не слишком дорого. Тока не нужно пока.
Erlang'у оно пока будет даже вредно — быстрый GC ему просто по причине интерпретируемости нафиг не нужен. Вот когда добавят сильную типизацию и JIT — вот тогда будет веселее
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.