Кейс для языка более высокого уровня: 64 или 32-битный?

Question

С выходом OS X 10.5.7 много говорилось о приложениях, которые являются 64-битными по сравнению с 32-битными приложениями ... производителями, которые должны будут конвертировать приложения, производителями, которые не смогут в ближайшее время из-за нехватки ресурсов (это очевидно огромная сделка) и т. д. В чем преимущества преобразования определенного приложения (например, iTunes) и т. д. ....

Мне интересно, если, когда вы работаете на виртуальной машине (я имею в виду, например .Net Framework или JVM) и кодируете только в "управляемом коде"? (в Java нет JNI, не уверен, что это будет в Ruby):

<Ол>

получаете ли вы преимущества, когда ваша виртуальная машина становится 64-битной, и вам даже не нужно знать об этом? ИЛИ

неужели вы на самом деле не получаете преимуществ (и проблем с конвертацией), поскольку ваши приложения довольно неэффективны по сравнению с тем, что возможно (хотя, возможно, достаточно быстро, чтобы делать то, что вам нужно)?

Answer 1

Основная причина, по которой я разрабатываю 64-битную версию - это память. Гораздо больше памяти адресуется с помощью 64-битных указателей, а для некоторых проблемных областей теоретический предел 4 ГБ при 32-битном (часто меньше) менее чем удовлетворительный.

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

Я не уверен, как 64-битная OSX справляется с 32-битными двоичными файлами, но в Windows эмуляция почти идеальна, и для многих приложений просто не нужно обновлять.

Answer 2

Я не могу говорить за CLR (я бы предположил, что он похож), но 64-битная JVM даст вам все преимущества 64-битной памяти без какого-либо преобразования.