Новый подход к программированию - интервью
Когда я был на JavaOne на прошлой неделе то дал интервью Джеку Хэррингтону - он автор книжки "Code Generation in Action", а также он поддерживает web-site посвященный генерации кода - http://www.codegeneration.netRead more... )
а) оставили на железке от всей VM-ки один интерпретатор
б) делают глобальную оптимизацию кода на хосте, в частности с profile-based инлайнингом
в) умеют апдейтить код и данные на железке через сеть
Собственно, это всё (не считая важных, но нудных деталей типа плагина для eclipse и пр). Остальные "достижения" о которых они рассказывают - только следствие вышеупомянутого, а именно:
а) небольшие требования к памяти - а чего там требовать, если там только интерпретатор без всего остального; а с фортом им слабо было размер VM-ки сравнить :)
б) вдвое быстрей любого явовского интерпретатора - ещё-бы, с глобальной то оптимизацией на хосте; да и не понятно где они эти явовские интерпретаторы брали - если они сравнивали с Sun-овским же KVM - то я когда-то за смешные деньги его Samsung-у в 8 раз ускорил
в) апдейт без перезагрузки системы - ну так на то он и Smalltalk, что там объектами является всё до последнего байта, вся информация есть.
Принципиально они просто сделали хороший оптимизирующий компайлер в свой личный байткод, и тщательно проработали апгрейд "на лету" работающей системы без её остановки. А вот маркетинговый пафос (малые требования, вся из себя ОО) - только для безграмотных менагеров работает, а реально какой-нибудь форт требовал-бы меньше, а какой-нибудь функциональный язык (а-ля OCaml) был-бы много мощнее. Что и обнаружилось не сходя с места, когда упрощённая реализация IP стека сразу подняла требования к памяти с 32 до 128 кб - осталось добавить GUI, и оно потребует больше J2ME :) Собственно, если выкинуть из java столько, сколько они выкинули из Smalltalk-а - она будет не хуже, а может и лучше. Чудес не бывает.
Я не говорю, что он плохой программист. Но принципиально нового (в смысле развития программирования) там ничего нет вообще. Он сам сказал - мы ничего не добавляли, мы только отрезали ненужное для embedded девайсов.
И уж никакого непривязанного к языку представления - там нет и подавно.
Reply
По поводу б), на самом деле, довольно интересно, как это технически сделано. Как резвенько железяка может сказать хосту, чего надо скомпилировать, и как резвенько же получить назад скомпилированный код? Или там пре-профиляция от тестовых прогонов? Впрочем, эта часть как раз к теме отношения не имеет. Можно асей или мылом.
в) Чего-то я не понимаю. Вы про какую все-таки ВМ говорите? Если про Смолток, то как сравнивать с Жабьим КВМом? Если же про Жабу, то причем тут Смолток?
Оптимизюче транслировать Жабу в коды Смолтоковской ВМ как-то смысла не сильно много. Стековый интерпретатор на распространенных современных процессорах не может не тормозить из-за архитектурной разницы между интерпретатором и реальным железом. Лучше, чем стандартный жабий код, конечно, сделать можно, но чтобы сильно - что-то сомнительно. Про отдельную кривизну типа отсутствия инициализаторов массивов константами я не говорю.
Если никакого непривязанного к языку представления нет, а есть только низкоуровневое представление сугубо для оптимизючей трансляции из одного байткода в другой, то, действительно, не интересно. Но хотелось бы в этом убедиться.
В смысле же размера ьыдо бы радикальнее сгенерировать код под данное конкретное приложение, снабдить его специально сгенерированным же интерпретатором и заслать для выполнения. Идея старая.
Reply
К сожалению, мылом обсуждать особенно нечего по двум причинам - а) кода их я ещё не видел (их же только вчера купили, их код ещё в репозитории не появился и я его не видел), и б) поди разберись, не выдам ли я какую страшную тайну :) Но если что - пиши на mkizub at esmertec dot com
Разные языки программирования (в том числе с разными VM) сравниваются очень просто - пишется бенчмарк на обоих языках (какое-нибудь вычисление чисел Фибоначи), и рассказывается о том, как наша платформа круто уделала конкурирующую платформу. Видимо так он и сравнивал по скорости oovm и jvm - правда, исходников самих бенчмарков не приводит :) Хотя основная идея оптимизации интерпретатора у него проглядывается - они используют 20 опкодов для своей VM, а остальные 236 используют для объединения нескольких опкодов в один. То есть в среднем, там где ява исполняет 2 опкода - они исполняют 1.
Откуда у тебя взялось "трансляция из одного байткода в другой" мне не понятно. Они из исходников ST в байткод для ST компиляют, никаких "других" байткодов там нет.
Интерпретатор под каждое конкретное приложение они не делают (он у них на С++ сделан). Но сам набор объединённых байткодов (вот эти 236 штук) - это опять-же profile-based методом они выяснили для типичного приложения. Они подумывают над изготовлением интерпретатора "на лету", но пока сильно сомневаются, что с этого будет заметный эффект.
Reply
Из кувшина "Открой тайну, несчастный" шептал не я. Исходников я тоже не просил. Хотелось описания технического промежуточного языка. Больше не хочется.
Сжатие со статическим словарем с сохранением исполняемости.
Reply
Leave a comment