JVM, CLR, native code и альтернативы
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
JVM, CLR, native code и альтернативы - 2009-08-14 03:25:40.613333
|
|
|
kreol
Сообщений: 823
Оценки: 0
Присоединился: 2007-03-08 03:13:06.876666
|
А давайте пофлудим.
Тема на пофлудить 1: скорость работы JVM и CLR.
Все видели бенчмарки программ на Java и C#, все понимают, что результаты всегда спорны, ибо разные ОСи, разные процессоры, в конце концов, неэквивалентные программы. Какого-то идеального показателя всё равно не будет, поэтому интересны личные наблюдения и мнения.
По моим наблюдениям (и данным многих бенчмарков) программы на Java, скомпилированные с опцией -server, бегают всё-таки немного шустрее дотнетовских. До тех пор, пока речь не заходит о графике и вызовах к ОС, с этим, как известно, у Java есть определённые трудности (да и опцию -server уже не включишь).
Тема на пофлудить 2: необходимость переносимости.
Преимущества промежуточного кода понятны: написал один раз и запускай на любой машине. В то же время за переносимость нужно платить производительность (вроде бы, к этому я ещё вернусь). А ведь переносимость не всегда то и нужна. Серверные программы, которые сейчас активно пишутся именно на Джавах и Сишарпах, вообще говоря, совсем не обязательно должны быть переносимы: если даже сервер заменят, ну перекомпилируешь свою программу разок, ну и пусть работает дальше. Зато выигрыш в производительности ежедневный. Отсюда вопрос: а действительно ли так часто нужна эта переносимость? Ну или, чтобы вопрос был более понятен: а вы часто действительно больно спотыкались о непереносимость программ?
Сам я серьёзно споткнулся всего один раз, причём в самом неожиданном месте, когда только что сбилженный sbcl версии 1.0.29 выругался на скомпилированные за день до этого sbcl'ем версии 1.0.28 fasl-ы. В данном случае промежуточное представление кода, такое как bytecode или IL, могло бы стать по крайней мере гарантией совместимости программных модулей, скомпилированных разными версиями компилятора.
Тема на пофлудить 3: JIT-компиляция против нативного кода.
Ни для кого не секрет, что и Java, и .Net сейчас используют JIT-компиляцию перед запуском программы. Вроде бы это накладные расходы при старте (в дальнейшем докомпилированная программа эквивалента изначально скомпилированной в native code), однако некоторые специалисты утверждают, что эти расходы даже меньше, чем для нативных исполняемых файлов. Их аргумент состоит в том, что нативные программы относительно массивны, поэтому считываются с диска в памать довольно долго, в то время как программы на промежуточном языке гораздо меньше и, соответветственно, загружаются быстрее, а время, сэкономленное на загрузку с диска, полностью окупает расходы на докомпиляцию в нативный код. Опять же, делимся наблюдениями и мнениями (хотя ссылки на серьёзные исследования приветствуются).
Ну и на серьёзное: альтернативы JVM и CLR.
На самом деле обе эти платформы я считаю убогими, в первую очередь из-за их однобокости и узкоспециализированности проможуточных языков (переубедите меня?). Я думаю, здесь таки найдётся пара-тройка людей, которые имели дело или хотя бы видели другие подобные этим рантаймам вещи. Интересуют две вещи: во-первых, промежуточное представление программы (альтернативные байткоды, IL'и и всё такое), во-вторых, платформы с мало-мальским набором готовых библиотек.
Пока что самое интересное, что видел - это slime binaries (они же OMI, они же Juice), которые хранят промежуточную программу в виде просто сжатого AST. Вроде как это даёт огромную гибкость для вышестоящих языков, да ещё и создатели заявляют небывалое снижение размера такого файла (а следовательно и скорости загрузки). Однако эту технологию почему-то давно забросили, к тому же даже оберонщики (которые в первую очередь использовали её) не всегда могут найти толковую документацию по slim binaries.
|
|
|
|
|
RE: JVM, CLR, native code и альтернативы - 2009-08-14 04:20:26.733333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
а ты напиши сервер с транзакционной семантикой и горячей заменой кода на языке без развитого рантайма (на том же C или C++). выигрыш-то прежде всего не в переносимости, а в более позднем связывании без существенной потери производительности. рефлексия, сериализация, стандарт на ABI (абсолютно неважно, на каком языке была написана .Net-сборка, бинарная совместимость на уровне IR есть), возможность управлять кодогенерацией - вот за что ты платишь минусами этого подхода. не за переносимость, переносимость - это так, дополнительный бонус сомнительной полезности
промежуточный язык узкоспециализированный только у JVM; насколько хорошо сделан в этом смысле CLR можно посмотреть по бенчмаркам Iron Python'а. альтернативных IR много - LLVM, HLVM, Parrot, NekoVM to name a few. ты с целями их использования определись сначала, чтобы можно было говорить по существу. наборы библиотек есть ко всем
|
|
|
|
|
RE: JVM, CLR, native code и альтернативы - 2009-08-14 06:52:35.440000
|
|
|
kreol
Сообщений: 823
Оценки: 0
Присоединился: 2007-03-08 03:13:06.876666
|
quote:
ORIGINAL: Denaturat
сервер с транзакционной семантикой
А это что, а это как? Журналирование сетевых транзакций что ли?
quote:
ORIGINAL: Denaturat
рефлексия, сериализация, стандарт на ABI (абсолютно неважно, на каком языке была написана .Net-сборка, бинарная совместимость на уровне IR есть), возможность управлять кодогенерацией - вот за что ты платишь минусами этого подхода. не за переносимость, переносимость - это так, дополнительный бонус сомнительной полезности
Это был вопрос не к CLR в общем, а именно к промежуточному представлению / нативному коду. Я хочу услышать реальные примеры, когда именно о непереносимость кода люди разбивали носы. А то, что CLR включает в себя кучу вкусных вещей - это отдельный вопрос.
quote:
насколько хорошо сделан в этом смысле CLR можно посмотреть по бенчмаркам Iron Python'а.
Если честно, после этих слов я ожидал увидеть на бенчмарках скорость всего в 3-5 раз ниже C#, а увидел скорость всего в 5-10 раз лучше обычного Python. Или "хорошо" означает что-то иное, а не "быстро"?
quote:
ORIGINAL: Denaturat
ты с целями их использования определись сначала, чтобы можно было говорить по существу. наборы библиотек есть ко всем
Положим, цель - создание для этого IR нескольких языков с разными парадигмами. Объясню, почему меня это заинтересовало. Сейчас загоняюсь на Clojure - очередную реализацию Лиспа, спроектированную специально для JVM. Чем больше изучаю язык, тем больше понимаю, что многие вещи в нём откровенно подогнаны под JVM, в то время, как сама Java Virtual Machine была спроестирована явно не с Lisp in mind. В итоге получаются функции, каждая из которых представляет анонимный объект, реализующий особый интерфейс и компилируется в отдельный файл, замену cons cell на java-объект (как результат, в языке нельзя создать просто пару (cons 3 5), а манипулирование списками превращается в постоянные вызовы функций) и так далее и тому подобное.
С CLR работал на порядок меньше, но и там некоторые вещи поражают. Основываясь на представлении делегатов в C# как объектов определённого класса, предположу, что и в IL тоже нет понятия функции как first-class object (сегодня уже не полезу в стандарт проверять своё предположение). Эмулирование через объект влечёт за собой создание дополнительных никому не нужных аттрибутов. А если ещё и анонимные функции через тот же механизм сделаны… Другими словами, насколько мне известно в IL-ассемблере напрямую не реализованы многие принципиальные концепции многих языков, а эмуляция, как правило, громоздка. Могу ошибаться (дада, я знаю, что стандарты рулят, но я ж тут всё-таки пофлудить, а не читать талмуды[&:])
|
|
|
|
|
RE: JVM, CLR, native code и альтернативы - 2009-08-18 18:34:52.066666
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: kreol
А это что, а это как? Журналирование сетевых транзакций что ли?
если в обработчике запроса от какого-либо из клиентов произошёл неустранимый сбой, сервер должен уметь восстановить корректное состояние, в котором он находился до начала обработки запроса
quote:
ORIGINAL: kreol
Это был вопрос не к CLR в общем, а именно к промежуточному представлению / нативному коду. Я хочу услышать реальные примеры, когда именно о непереносимость кода люди разбивали носы. А то, что CLR включает в себя кучу вкусных вещей - это отдельный вопрос.
это касалось не только CLR - это общие плюсы middleware, прежде всего - виртуальных машин различного вида. одна только задача реализации многоязыковой разработки приводит к необходимости совместимости на определённом уровне; IR даёт совместимость на уровне API (стандартные интерфейсы) или ABI (стандартный байткод). то же самое можно заметить и по остальным фичам - без промежуточного слоя они либо невозможны вовсе (сериализация системного потока, например), либо чудовищно сложны (горячая замена кода на чистом C требует эквилибристических навыков и в любом случае завязывается на ОС)
вопроса насчёт разбивания носов не понял. что именно тебя интересует? зачем вообще нужна кроссплатформенность, или зачем нужны JVM/CLR если есть middleware вроде Qt/ACE?
quote:
ORIGINAL: kreol
Если честно, после этих слов я ожидал увидеть на бенчмарках скорость всего в 3-5 раз ниже C#, а увидел скорость всего в 5-10 раз лучше обычного Python. Или "хорошо" означает что-то иное, а не "быстро"?
если некий язык программирования на неродной VM исполняется эффективней, чем на родной - это о чём-то говорит, n'est-ce pas? что же касается сравнения C# и IronPython по производительности, то не забывай, что в Python есть eval
quote:
ORIGINAL: kreol
Положим, цель - создание для этого IR нескольких языков с разными парадигмами. Объясню, почему меня это заинтересовало. Сейчас загоняюсь на Clojure - очередную реализацию Лиспа, спроектированную специально для JVM. Чем больше изучаю язык, тем больше понимаю, что многие вещи в нём откровенно подогнаны под JVM, в то время, как сама Java Virtual Machine была спроестирована явно не с Lisp in mind. В итоге получаются функции, каждая из которых представляет анонимный объект, реализующий особый интерфейс и компилируется в отдельный файл, замену cons cell на java-объект (как результат, в языке нельзя создать просто пару (cons 3 5), а манипулирование списками превращается в постоянные вызовы функций) и так далее и тому подобное.
С CLR работал на порядок меньше, но и там некоторые вещи поражают. Основываясь на представлении делегатов в C# как объектов определённого класса, предположу, что и в IL тоже нет понятия функции как first-class object (сегодня уже не полезу в стандарт проверять своё предположение). Эмулирование через объект влечёт за собой создание дополнительных никому не нужных аттрибутов. А если ещё и анонимные функции через тот же механизм сделаны… Другими словами, насколько мне известно в IL-ассемблере напрямую не реализованы многие принципиальные концепции многих языков, а эмуляция, как правило, громоздка. Могу ошибаться (дада, я знаю, что стандарты рулят, но я ж тут всё-таки пофлудить, а не читать талмуды[&:])
ни JVM, ни CLR не разрабатывались со всеми поддерживаемыми ими на сегордняшний день языками in mind. если задача стоит именно так, то тебе надо элементарно оценить пересечение операционных семантик интересующих тебя ЯП, и разрабатывать абстрактную машину для их интерпретации, исходя из этих данных. если языки заранее неизвестны, и нужен максимально низкоуровневый и сколько-нибудь универсальный механизм, то тебе прямая дорога к LLVM. в любом случае для начала неплохо было бы реализовать все эти языки в качестве eDSL'ей на том же CL - отлаживать семантику в таком режиме будет куда как проще
|
|
|
|
|
RE: JVM, CLR, native code и альтернативы - 2009-08-20 03:10:59.706666
|
|
|
kreol
Сообщений: 823
Оценки: 0
Присоединился: 2007-03-08 03:13:06.876666
|
quote:
ORIGINAL: Denaturat
вопроса насчёт разбивания носов не понял. что именно тебя интересует? зачем вообще нужна кроссплатформенность, или зачем нужны JVM/CLR если есть middleware вроде Qt/ACE?
Например, нужно портировать программу, написанную на Си, с одной платформы на другую, однако в силу некоторых обстоятельств (отсутствие части исходников, несовместимые системные вызовы, непортированные библиотеки, etc) это было невозможно или очень сложно сделать. Или когда программа перестаёт работать при изменении версии операционной системы (Windows XP -> Windows Vista), и нужны серьёзные доработки, чтобы исправить это. Да хотя бы тот же пример с разными версиями SBCL. Хочется просто увидеть примеры серьёзных траблов, связанных с привязанностью к платформе из-за использования нативного кода, а не какого-то промежуточного. Хочется оценить ценность именно переносимости как фичи. О ценности смежных фич (поддержка многих языков, managed code, горячая замена кода и т.д.) меня в данном случае не интересуют. Я не собираюсь проектировать что-то конкретное, мне просто интересно.
quote:
если некий язык программирования на неродной VM исполняется эффективней, чем на родной - это о чём-то говорит, n'est-ce pas? что же касается сравнения C# и IronPython по производительности, то не забывай, что в Python есть eval
Ой, пардон, я чё-то решил, что CPython - это чисто интерпретатор, и сравнивал скорость работы интерпретируемого и скомпилированного кода. Дада, тогда согласен.
|
|
|
|
|
RE: JVM, CLR, native code и альтернативы - 2009-08-20 17:49:28.503333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: kreol
Например, нужно портировать программу, написанную на Си, с одной платформы на другую, однако в силу некоторых обстоятельств (отсутствие части исходников, несовместимые системные вызовы, непортированные библиотеки, etc) это было невозможно или очень сложно сделать
если ты хочешь представить себе действительно страшный случай, то прикинь перенос firmware с vwWorks на QNX, а затем Linux; предполагая, что вначале разработчики завязались на модель работы с памятью vxWorks, затем переписали всё IPC на сообщения QNX, а затем переписали всё нафиг с использованием того же /proc. впрочем, достаточно представить перенос сколько-нибудь сложного сетевого приложения из Linux, завязанного на select/epoll, на Win32 (а лучше - Win64). вообще говоря, сложно придумать задачу, в которой проблем бы вообще не возникло
quote:
ORIGINAL: kreol
Хочется просто увидеть примеры серьёзных траблов, связанных с привязанностью к платформе из-за использования нативного кода, а не какого-то промежуточного
http://www.cse.wustl.edu/~schmidt/ACE-overview.html
ну бери любую фичу отсюда и рассматривай её портирование с одних нативных средств на другие. собственно, именно эта сложность и была одной из причин создания ACE
quote:
ORIGINAL: kreol
Хочется оценить ценность именно переносимости как фичи
переносимость как фича крайне важна для любого специализированного (недесктопного) софта: если стек инструментов, скажем, химика-органика, будет размазан по нескольким ОС и аппаратным платформам, использовать его будет затруднительно (а случается такое, вообще говоря, крайне регулярно). если же у него будет возможность подобрать себе аппаратно-программную базу по собственному усмотрению, не отказываясь от имеющихся инструментов, тогда он будет счастлив
если такой пример кажется слишком специфичным, представь себе заказчика некой цифровой аудиостудии, который за месяц до сдачи проекта решил, что охватить ещё 6-7% рынка было бы неплохо, и просит тебя чтобы всё работало и под MacOS X тоже
|
|
|
|
|
|
