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

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

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

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

Ты уж определись, проблема в "интерпретации" или все таки в GC? Первое и второе никак не связаны.

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

Решения со статическое компиляцией есть и для Java и для .NET. Только особого успеха они не имеют, несмотря на то, что, теоретически, нет никаких проблем сделать оптимизацию не хуже любого статического компилятора. Опять же, для .NET есть ngen.

G>Те-те-те. Без всяких проблем с откликом — это сильно сказано. Проблем нет, пока не идет речь хотя бы о мягком реальном времени.

А какой процент рынка софта имеет дело с реалтаймом? Ты ведь не говорил, что промежуточный код не годится конкретно для реалтайма, не так ли?

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

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

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

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

А в чём именно помощь? Там сохраняется какая-то полезная для него информация? Или просто у него будет относительно больше времени на старте и, соответственно, JIT может потратить его на более сложные алгоритмы оптимизации?

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

C>>Это помощь JITу — оно потом может совершенно стандартным образом в runtime'е перекомпилироваться.
D>А в чём именно помощь? Там сохраняется какая-то полезная для него информация? Или просто у него будет относительно больше времени на старте и, соответственно, JIT может потратить его на более сложные алгоритмы оптимизации?
Проблема в том, что при старте приложения — JIT в полном цейтноте, особенно для десктопных приложений. Нужно быстро запустить хоть что-то, так что просто не до оптимизаций.

Прекомпилированые библиотеки позволяют быстро запустить приложение с приемлимой скоростью, а потом уже вдумчиво все оптимизировать.

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

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

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

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

Вообще — да, ты прав, эту проблему уже решили. Например, вот.
http://www.ibm.com/developerworks/java/library/j-rtj4/index.html

Однако, по состоянию на 2004 год, когда я изучал тему, она нихрена не была решена.

Здравствуйте, AndrewVK, Вы писали:
AVK>>>Как показывает практика native совсем не означает быстро работать
G>>Есть примеры, когда JIT или интерпретатор обходит native?
AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
А где можно посмотреть на тесты? (в дельфях есть возможность ассемблерных вставок прямо в основном коде)

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

_>А где можно посмотреть на тесты?

В инете. Здесь на сайте тоже статья была.

_> (в дельфях есть возможность ассемблерных вставок прямо в основном коде)

И что? Это как то улучшает характеристики дельфового оптимизатора?

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

_>>А где можно посмотреть на тесты?
AVK>В инете. Здесь на сайте тоже статья была.
Ну, будет время — поищу.
Посмотрим на тесты вроде обработки DOM с десятками тысяч узлов и прочими "могильщиками" GC

_>> (в дельфях есть возможность ассемблерных вставок прямо в основном коде)
AVK>И что? Это как то улучшает характеристики дельфового оптимизатора?
Качество оптимизатора в дискуссии не обсуждалось.
Исходный тезис (ваш) был такой:
G>>Есть примеры, когда JIT или интерпретатор обходит native?
AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.

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

_>Посмотрим на тесты вроде обработки DOM с десятками тысяч узлов и прочими "могильщиками" GC

При чем тут GC? Речь о native vs JIT.

AVK>>И что? Это как то улучшает характеристики дельфового оптимизатора?
_>Качество оптимизатора в дискуссии не обсуждалось.

Именно оно и обсуждалось. Если тебе очень пиписьками померяться захотелось, то на дотнете тоже можно mixed mode сборки делать с нативным кодом. Только о качестве JIT это никак не говорит.

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

_>>Посмотрим на тесты вроде обработки DOM с десятками тысяч узлов и прочими "могильщиками" GC
AVK>При чем тут GC? Речь о native vs JIT.
При чем? Проведите тесты — узнаете.

AVK>>>И что? Это как то улучшает характеристики дельфового оптимизатора?
_>>Качество оптимизатора в дискуссии не обсуждалось.
AVK>Именно оно и обсуждалось. Если тебе очень пиписьками померяться захотелось, то на дотнете тоже можно mixed mode сборки делать с нативным кодом. Только о качестве JIT это никак не говорит.
На брудершафт, голубчик, мы с вами не пили.
Необходимость же native-вставок напрямую говорит о качестве JIT

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

AVK>>При чем тут GC? Речь о native vs JIT.
_>При чем? Проведите тесты — узнаете.

Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT?

AVK>>Именно оно и обсуждалось. Если тебе очень пиписьками померяться захотелось, то на дотнете тоже можно mixed mode сборки делать с нативным кодом. Только о качестве JIT это никак не говорит.
_>На брудершафт, голубчик, мы с вами не пили.

Здесь так принято. (Достали)

_>Необходимость же native-вставок напрямую говорит о качестве JIT

Ага, а необходимость ассемблерного кода о крутости Дельфи. Тебе есть что по делу сказать, или пофлеймить захотелось?

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

AVK>>>При чем тут GC? Речь о native vs JIT.
_>>При чем? Проведите тесты — узнаете.
AVK>Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT?
Речь изначально шла о native Delphi vs .NET JIT. Вот такая речь (третий раз)
G>>Есть примеры, когда JIT или интерпретатор обходит native?
AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
Пример с десятками тысяч недолгоживущих объектов показывает одну из ситуаций, когда это не так.
И ситуаций таких можно предложить немало. Например, если вспомнить immutable у строк. Или отрисовку окошек.

_>>Необходимость же native-вставок напрямую говорит о качестве JIT
AVK>Ага, а необходимость ассемблерного кода о крутости Дельфи.
Ассемблерные вставки находятся в рамках native в отличие от.

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

AVK>>Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT?
_>Речь изначально шла о native Delphi vs .NET JIT. Вот такая речь (третий раз)

Да, речь шла о native vs JIT. Так вот, в большинстве случаев нетовский JIT генерит более качественный код, нежели native компилятор Дельфи. Что тут еще может быть непонятного?

_>Пример с десятками тысяч недолгоживущих объектов показывает одну из ситуаций, когда это не так.

Если в программе куча мелких быстро умирающих объектов в динамической памяти, то GC сделает любой самый навороченный менеджер памяти. Только, опять же, к разговору native vs JIT это не имеет никакого отношения, потому что и JIT может быть без GC, и GC может быть без JIT.

_>И ситуаций таких можно предложить немало. Например, если вспомнить immutable у строк. Или отрисовку окошек.

Да, вот уж immutable у строк и отрисовка окошек, это самый главный недостаток JIT. К твоему сведению, в дотнете есть и mutable строки, и окошки в винформсах отрисовываются в основном операционкой.

AVK>>Ага, а необходимость ассемблерного кода о крутости Дельфи.
_>Ассемблерные вставки находятся в рамках native в отличие от.

Это ничего не меняет.

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

AVK>>>Что мне даст проведение тестов? GC и JIT — разные вещи. Какой смысл нагружать GC для исследования производительности JIT?
_>>Речь изначально шла о native Delphi vs .NET JIT. Вот такая речь (третий раз)
AVK>Да, речь шла о native vs JIT. Так вот, в большинстве случаев нетовский JIT генерит более качественный код, нежели native компилятор Дельфи. Что тут еще может быть непонятного?
Это уже смешно просто ))))
AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
Твой базар?
Теперь у тебя появилась новая формулировка: более качественный код
Критерии качества и тесты в студию. Трепать языком — не камни ворочать.
Тесты пионеров в трех сериях "Кто шустрее", найденные на сайте просьба не предъявлять.

_>>Пример с десятками тысяч недолгоживущих объектов показывает одну из ситуаций, когда это не так.
AVK>Если в программе куча мелких быстро умирающих объектов в динамической памяти, то GC сделает любой самый навороченный менеджер памяти. Только, опять же, к разговору native vs JIT это не имеет никакого отношения, потому что и JIT может быть без GC, и GC может быть без JIT.
Он имеет отношение к конкретному обсуждаемому JIT. А во-вторых ты опять сказал ерунду, не удосужившись провести хотя бы элементарные тесты.
Все бывай, голубчик. Без дальнейшей конкретики я с тобой базарить завязал.

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

AVK>>Да, речь шла о native vs JIT. Так вот, в большинстве случаев нетовский JIT генерит более качественный код, нежели native компилятор Дельфи. Что тут еще может быть непонятного?
_>Это уже смешно просто ))))

Это факт

AVK>>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
_>Твой базар?
_>Теперь у тебя появилась новая формулировка: более качественный код
_>Критерии качества и тесты в студию. Трепать языком — не камни ворочать.

Где тесты искать я тебе сказал.

_>Тесты пионеров в трех сериях "Кто шустрее", найденные на сайте просьба не предъявлять.

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

AVK>>Если в программе куча мелких быстро умирающих объектов в динамической памяти, то GC сделает любой самый навороченный менеджер памяти. Только, опять же, к разговору native vs JIT это не имеет никакого отношения, потому что и JIT может быть без GC, и GC может быть без JIT.
_>Он имеет отношение к конкретному обсуждаемому JIT.

Читайте топик с начала.

_>Все бывай, голубчик. Без дальнейшей конкретики я с тобой базарить завязал.

Бывайте, товарищ хам.

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

EC>Покажешь как плюсовый шаблон из шарпа поюзать?

Очередные проблемы с логикой? Или на этот раз непонимание разницы в понятиях interoperability и full compatibility?

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

G>это какая такая ява реализована на дотнете? j# что-ль? или я что-то пропустил?

Ага. И не только.

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

AVK>А native совершенно не обязателен, как показывает практика. Впрочем, mono --aot и флаг вам в руки

Смешно слышать пдобные слова от того кто постоянно пропагандирует интерпретирвемые языки вроде Эрлэнга.

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

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

C# еще во времена 1.0 практически всегда уделывал Борлодовские компиляторы С++. И что?

Главное, что если не лажать, что можно писать сопостовимые с нэйтивными по скрости программы.

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

G>>Это верная постановка вопроса. Я говорил не про GC и не про компиящийся в нэйтив лисп, а про JIT и итерпретаторы.
GZ>А при чем тут интерпретаторы? JIT — это компилятор.

А это такой подход в дискуссии. Ставим в один ряд, скажем, космонавтов и педераст... конечно между ними никакой корелляции нет, но ведь осадочек то остался!

Та же фигня с JIT и интерпретаторами. Если долго ставить их в общий ряд, то моногие подумают, что связь есть.

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

VD>Очередные проблемы с логикой? Или на этот раз непонимание разницы в понятиях interoperability и full compatibility?

У тебя Янус смайлы не показывает? Или просто побухтеть охота?
Расскажи, что ты понимаешь под full compatibility применительно к языкам программирования. Очень интересно.