Здравствуйте, Shizuka-kun, Вы писали:
SK>Здравствуйте.
SK>Интересно, почему 64-битные числовые типы выделяются в куче. Для того, чтобы уменьшить объем памяти, занимаемый стеком в большинстве случаев использования?
Размер стековых типов так или иначе надо было ограничить. В противном случае, учитывая динамическую типизацию, стек нельзя было бы рассчитать в компайл-тайм, а это чревато. Да и декодирование данных со стека стало бы слишком дорогим. В общем бенефитов от того, что, скажем, операции над Int64 совершаются на стеке, практически не осталось бы.
А благодаря фиксации размера стековых типов до четырех байт, там получает довольно простая как бы in-place структура для описания любого значения. В ней содержится int + указатель. Она не слишком велика, и нет серьезной стагнации производительности из-за ее копирований на стеке (если заменить int на long, то разница в производительности будет весьма заметна). И практически нет никакого декодирования.
Кстати, разница в Int32 и в Int64 арифметике, конечно, заметная, но не космос.
SK>И еще, планируется ли в будущем переход на регистровую ВМ.
Вряд ли. Это надо все переписывать

Саму ВМ, естественно, и, главное, компилятор. Компилятор в MSIL будет сделать проще

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