Центр информации по операционным системам: Форумы / Низкоуровневое программирование / Ответ Javе и Flash'у

Центр информации по операционным системам :: Форумы :: Программирование :: Низкоуровневое программирование		<< Предыдущая тема \| Следующая тема >>
Ответ Javе и Flash'у

Переход на страницу 1 2 3 [4] 5 6 7
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

ossadchy

Воскресенье 05.10.2008 23:41

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

NightRadio написал(а) ...

А еще по поводу виртуальных машин. Почему же в основе Google Andriod виртуальная машина Java, и не обычная, а видоизмененная для поддержки регистр-ориентированного байт-кода?

Дабы обойти лицензию SUN на JavaME. Не более того.

NightRadio написал(а) ...

И машина на нем займет мегабайт эдак 10.. Насколько быстро она будет интерпретировать и компилировать - тот еще вопрос... Я поклонник более компактных вещей.

Ну возьмусь утверждать(по своему опыту), что когда(гипотетически) ваша VM дойдет до достойного уровня, то она где-то до тех же размеров и вырастет. Суть в том что, зачастую, те мегабайты не просто так пришиты.

[ Редактирование Понедельник 06.10.2008 17:40 ]

Наверх

NightRadio

Понедельник 06.10.2008 05:55

ID пользователя #1102

Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23

На счет Java соглашусь. Обошли лицензию. Но ведь и машина у них получилась не хуже Java. А возможно и лучше

На счет LLVM не знаю пока, что сказать... Мегабайты ессно не просто так пришиты - кто ж с этим спорит. Я ж не говорю, что LLVM имеет бесполезные куски кода )
Но почему я склоняюсь к более компактным вещам - в них проще разбираться, их проще писать, проще портировать и переделывать, проще запустить на каком-нибудь маломощном КПК и т.д.

Наверх

ossadchy

Понедельник 06.10.2008 08:59

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

Изложу свое ИМХО...
Итого: вы хотите создать нечто по функционалу аналогичное JAVA, FLASH, .NET. НО чтоб оно было компактней. Верно?
Суть проблемы: если эти аналогичные вещи громоздкие, то Ваш продукт по мере развития приблизится к ним по объему.
Вывод: надо менять сам подход. Как менять -- это уже другой вопрос.

P.S. О Android. Ну получилась еще одна VM... не было бы лицензионных ограничений на J2ME -- было бы все ОК, никто бы не парился...

NightRadio написал(а) ...

Но почему я склоняюсь к более компактным вещам - в них проще разбираться, их проще писать, проще портировать и переделывать, проще запустить на каком-нибудь маломощном КПК и т.д.

Да я сам сторонник компактных и простых вещей, вопрос в том что компактность не должна означать убогость, а это ведет к потере компактности

Возможно ответ в том что следует отойти от традиционных подходов?

По поводу Android -- эффективней он может вполне оказаться чем оригинальная реализация SUN, т.к. использует бооольшое количество нативного кода(по сути и .NET так же делает)

[ Редактирование Понедельник 06.10.2008 17:41 ]

Наверх

NightRadio

Понедельник 06.10.2008 11:56

ID пользователя #1102

Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23

Мне вопрос так видится: либо брать LLVM и не морочить себе голову, либо делать что-то подобное, но более компактное.
С тем что, проект всеравно разрастется до диких размеров, я не согласен - это не правило. Тем более, что направленность не супер широкая - мультимедийные приложения. Графика, анимация, синтез звука.

Наверх

ossadchy

Понедельник 06.10.2008 12:50

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

NightRadio написал(а) ...

Мне вопрос так видится: либо брать LLVM и не морочить себе голову, либо делать что-то подобное, но более компактное.
С тем что, проект всеравно разрастется до диких размеров, я не согласен - это не правило. Тем более, что направленность не супер широкая - мультимедийные приложения. Графика, анимация, синтез звука.

Специализация языка не связана непосредственно с ядром VM. Это, скорее, задача библиотек.

А размер VM, в первую очередь, зависит не от сложности(простоты байткода), а от того насколько интенсивно оптимизируется код и какая часть библиотек внесена в VM(например, в ядро паскаля включена функция wrtieln, а в C - нет). А + или - 10-20-100 инструкций -- это считанные килобайты кода.

Кроме размера VM есть еще размер рантайма, а он будет большим(кодеки, бриджи к разным графическим библиотекам, поддержка стандартных форматов передачи данных(JSON, XML), стандартных протоколов(тот же XMLRPC), потоков, объектов синхронизации).

NightRadio написал(а) ...

Мне вопрос так видится: либо брать LLVM и не морочить себе голову, либо делать что-то подобное, но более компактное.

Порежте LLVM, желательно сохранив выбор за пользователем -- брать LLVM или LLVM Light. См. пост выше -- все равно для компактности прийдется пожертвовать оптимизацией.

А вообще надо исходить из того какой язык будет базовым для вашего проекта.

2NightRadio. А вообще, хотелось бы с вами обсудить, почему бы не применить в качестве промежуточного представления кода подход SDE/Juice? Как минимум рекомендую ознакомится... Было бы интересно выслушать ваши доводы, насколько понимаю, "против".

[ Редактирование Понедельник 06.10.2008 17:42 ]

Наверх

NightRadio

Понедельник 06.10.2008 13:56

ID пользователя #1102

Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23

Не могли бы вы поделиться ссылкой на какое-нибудь описание SDE/Juice? А то у меня что-то не получилось найти.

Наверх

ossadchy

Понедельник 06.10.2008 14:03

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

NightRadio написал(а) ...

Не могли бы вы поделиться ссылкой на какое-нибудь описание SDE/Juice? А то у меня что-то не получилось найти.

Можете взять тут.
Ну и вот сюда зайдите.

В принципе, я сейчас занимаюсь разработкой чего-то сходного... своеобразного ответа JAVA & .NET

И во главе угла простота и компактность. Правда не знаю не будет ли это во вред юзабельности )

[ Редактирование Понедельник 06.10.2008 17:43 ]

Наверх

Roman I Khimov

Понедельник 06.10.2008 14:07

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

http://www.ics.uci.edu/~franz/Site/pubs-pdf/DissETH10497.pdf

ossadchy, очень много сообщений одно за другим (т.н. "даблпостинг"), правкой можно добавлять в написанное, предупреждение.

P.S. даблпосты почистил, значительно лучше стало.

[ Редактирование Понедельник 06.10.2008 17:43 ]

Греби и улыбайся!

Наверх

ossadchy

Понедельник 06.10.2008 17:57

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

Roman I Khimov написал(а) ...

http://www.ics.uci.edu/~franz/Site/pubs-pdf/DissETH10497.pdf

ossadchy, очень много сообщений одно за другим (т.н. "даблпостинг"), правкой можно добавлять в написанное, предупреждение.

P.S. даблпосты почистил, значительно лучше стало.

Да, есть такая болезнь. Публично каюсь

Наверх

NightRadio

Вторник 07.10.2008 12:15

ID пользователя #1102

Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23

Спасибо за полезные доки! Почерпнул для себя много нового

Вижу, представления, основанные на деревьях, довольно перспективные и при увязке с JIT почти ничем не уступают обычным компиляторам. Но, к сожалению, в режиме интерпретации такие машины уступают байт/бит ориентированным. Соглашусь с тем, что идеального представления просто нет - у каждого свои приемущества и недостатки.
Буду думать...

Наверх

Переход на страницу 1 2 3 [4] 5 6 7
Перейти: Наверх