Re[2]: Ela. Разработка интерпретируемого языка программирова
От: Воронков Василий Россия  
Дата: 24.12.10 19:11
Оценка:
Здравствуйте, Shizuka-kun, Вы писали:

SK>Здравствуйте.

SK>Интересно, почему 64-битные числовые типы выделяются в куче. Для того, чтобы уменьшить объем памяти, занимаемый стеком в большинстве случаев использования?

Размер стековых типов так или иначе надо было ограничить. В противном случае, учитывая динамическую типизацию, стек нельзя было бы рассчитать в компайл-тайм, а это чревато. Да и декодирование данных со стека стало бы слишком дорогим. В общем бенефитов от того, что, скажем, операции над Int64 совершаются на стеке, практически не осталось бы.
А благодаря фиксации размера стековых типов до четырех байт, там получает довольно простая как бы in-place структура для описания любого значения. В ней содержится int + указатель. Она не слишком велика, и нет серьезной стагнации производительности из-за ее копирований на стеке (если заменить int на long, то разница в производительности будет весьма заметна). И практически нет никакого декодирования.

Кстати, разница в Int32 и в Int64 арифметике, конечно, заметная, но не космос.

SK>И еще, планируется ли в будущем переход на регистровую ВМ.


Вряд ли. Это надо все переписывать Саму ВМ, естественно, и, главное, компилятор. Компилятор в MSIL будет сделать проще Причем переписывать надо, а какие будут бенефиты сказать сложно. Например, текущая версия работает раза в полтара быстрее, чем та, которая описывается в статье за счет весьма локальных архитектурных улучшений и оптимизаций. Не факт, что регистровая ВМ даст такой же выигрыш. И кстати если стековая ВМ позволяет мне легко и просто пользоваться сборкой мусора "из коробки", то с регистровой такой трюк не прокатит. Кто мусор-то из регистров будет чистить? Разумное решение здесь — огранизовывать свой хип и хранить в регистрах только хэндлы. А это кардинально усложняет все, в том числе и интероп с дотнетным кодом.
Наконец тот же CLR, JVM — это все стековые машины. И имея стековую машину тоже проще будет их поддержать в перспективе, сделав просто транслятор из своего байт-кода.

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

SK>P.S. Если говорю глупости — не судите строго знаний в этой области у меня еще пока нет, так, знаю несколько терминов и общих принципов понаслышке, только собираюсь пробовать. Ela — очень интересный для меня материал для изучения.


Да я тоже в общем диссертацию на эту тему не защищал
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.