Здравствуйте, 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.
Все зависит от задач. Для чего то важнее стабильность времени отклика, для чего то средние показатели.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, 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 до такой малой величины, как половина секунды.
Здравствуйте, AndrewVK, Вы писали: AVK>>>Как показывает практика native совсем не означает быстро работать G>>Есть примеры, когда JIT или интерпретатор обходит native? AVK>Есть конечно. МСовский .NET, например, практически всегда быстрее нативного Delphi.
А где можно посмотреть на тесты? (в дельфях есть возможность ассемблерных вставок прямо в основном коде)
Здравствуйте, 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.
Читайте топик с начала.
_>Все бывай, голубчик. Без дальнейшей конкретики я с тобой базарить завязал.
Здравствуйте, GlebZ, Вы писали:
G>>Это верная постановка вопроса. Я говорил не про GC и не про компиящийся в нэйтив лисп, а про JIT и итерпретаторы. GZ>А при чем тут интерпретаторы? JIT — это компилятор.
А это такой подход в дискуссии. Ставим в один ряд, скажем, космонавтов и педераст... конечно между ними никакой корелляции нет, но ведь осадочек то остался!
Та же фигня с JIT и интерпретаторами. Если долго ставить их в общий ряд, то моногие подумают, что связь есть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Очередные проблемы с логикой? Или на этот раз непонимание разницы в понятиях interoperability и full compatibility?
У тебя Янус смайлы не показывает? Или просто побухтеть охота?
Расскажи, что ты понимаешь под full compatibility применительно к языкам программирования. Очень интересно.
now playing: Boris Brejcha — Electribe Technologie