Слышал, что виртуальные машины бывают стековые — JVM, CLR и безстековые — Stackless Python.
Где бы почитать про безстековые? Интересует что это и какие у него есть преимущества.
Google выдаёт ссылки только по питону, а нужно общее описание идеи.
now playing: NASA Space Recordings Of Earth — Voice Of Earth I
Здравствуйте, EvilChild, Вы писали:
EC>Слышал, что виртуальные машины бывают стековые — JVM, CLR и безстековые — Stackless Python. EC>Где бы почитать про безстековые? Интересует что это и какие у него есть преимущества. EC>Google выдаёт ссылки только по питону, а нужно общее описание идеи.
Stackless Python это попытка создания VM Python которая не использует C stack. (наконец-то)
Не больше и не меньше.
Здравствуйте, EvilChild, Вы писали:
EC>Слышал, что виртуальные машины бывают стековые — JVM, CLR и безстековые — Stackless Python. EC>Где бы почитать про безстековые? Интересует что это и какие у него есть преимущества. EC>Google выдаёт ссылки только по питону, а нужно общее описание идеи.
Могу про питон сказать. Главный смысл разделения там машиного стека и стека интерпретатора в том, чтобы легко сохранять и восстанавливать состояние интерпретатора для реализации легких, не зависимых от OS потоков. Ну и дополнительные преимущества сопрограммы и рекурсия ограниченная только виртуальной памятью.
EC>Слышал, что виртуальные машины бывают стековые — JVM, CLR и безстековые — Stackless Python. EC>Где бы почитать про безстековые? Интересует что это и какие у него есть преимущества. EC>Google выдаёт ссылки только по питону, а нужно общее описание идеи.
Стэк там есть, тольк он реализован внутри виртуальной машины и не зависит от стека операционной системы.
Здравствуйте, EvilChild, Вы писали:
EC>Слышал, что виртуальные машины бывают стековые — JVM, CLR и безстековые — Stackless Python. EC>Где бы почитать про безстековые? Интересует что это и какие у него есть преимущества. EC>Google выдаёт ссылки только по питону, а нужно общее описание идеи.
Может имеет смысл посмотреть на Continuation Passing Style? Правда это по большей части имеет отношение к компиляции.
-- Главное про деструктор копирования не забыть --
Здравствуйте, c-smile, Вы писали:
CS>Stackless Python это попытка создания VM Python которая не использует C stack. (наконец-то)
А почему наконец-то? В чём выигрыш в их случае?
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, c-smile, Вы писали:
CS>>Stackless Python это попытка создания VM Python которая не использует C stack. (наконец-то) EC>А почему наконец-то? В чём выигрыш в их случае?
Здравствуйте, VladD2, Вы писали:
EC>>Слышал, что виртуальные машины бывают стековые — JVM, CLR и безстековые — Stackless Python.
VD>Не надо путать виртуальные машины рассчитанные на JIT-компиляцию и внутреннюю архитектуру интерпретаторов.
А эти классификации не ортогональны?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, EvilChild, Вы писали:
EC>>Слышал, что виртуальные машины бывают стековые — JVM, CLR и безстековые — Stackless Python.
VD>Не надо путать виртуальные машины рассчитанные на JIT-компиляцию и внутреннюю архитектуру интерпретаторов.
JIT транслирует последовательность bytecodes в native code который (как правило) исполняется регистровой машиной (процессором).
Но JIT компиляция не изменяет стековую природу самого bytecode. Стек заложен в самой архитектуре JVM и CLR и он там есть и работает даже с JIT.
Здравствуйте, c-smile, Вы писали:
CS>JIT транслирует последовательность bytecodes в native code который (как правило) исполняется регистровой машиной (процессором). CS>Но JIT компиляция не изменяет стековую природу самого bytecode. Стек заложен в самой архитектуре JVM и CLR и он там есть и работает даже с JIT.
После компиляции о байткоде никто уже больше не вспоминает. С этого момента разговоры о нем просто являются спекуляцией.
Именно по этому я и говорю, что "не надо поутать". Джит-ы ближе к нормальным компиляторам по свойствам. А когда говорят "виртуальная машина" применительно к Яве и дотнету, то понимают нечто иное нежели когда говорят о виртуальной машине как неком наборе универсальных команд.
Разговоры же о стеках заложенных в виртуальных машинах вообще полнешая ерунда. Стековые языки типа MSIL используются для компактного представления кода. Они в висшей степени виртуальны так как практически никогда не выполняются на прямую. Ну, а с точки зрения функциональности нет никакой разницы как записывать код. При условии, конечно, что код был полон по Тюрингу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Разговоры же о стеках заложенных в виртуальных машинах вообще полнешая ерунда. Стековые языки типа MSIL используются для компактного представления кода. Они в висшей степени виртуальны так как практически никогда не выполняются на прямую. Ну, а с точки зрения функциональности нет никакой разницы как записывать код. При условии, конечно, что код был полон по Тюрингу.
Если нужны полноценые (вытесняющиеся) легкие потоки то, есть разница как записывать код, и даже откомпилированный. Так как у самых распрастраненых платформ машиный стек мешает этой задаче, то состояние программы не должно зависеть от него. В общем Stackless ортогонален компилируемости и jit'ам.
Здравствуйте, FR, Вы писали:
FR>Если нужны полноценые (вытесняющиеся) легкие потоки то, есть разница как записывать код, и даже откомпилированный. Так как у самых распрастраненых платформ машиный стек мешает этой задаче, то состояние программы не должно зависеть от него. В общем Stackless ортогонален компилируемости и jit'ам.
Я правильно понял, что ведуться работы по интеграции PyPy и Stackless Python?
Если так, то эти вещи и в самом деле ортогональны.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, EvilChild, Вы писали:
EC>>Я правильно понял, что ведуться работы по интеграции PyPy и Stackless Python?
FR>Угу.
Нашёл ещё подтверждение, Parrot регистровая машине, т.е. безстековая, но тем не менее планируют JIT:
Possible future languages and projects
There is strong interest in parts of the Ruby community. The Python community is taking more of a wait-and-see attitude, due to already having Psyco, a just-in-time Python-to-machine-code compiler, Jython, a Python-to-Java-bytecode compiler, and IronPython to compile to the .NET platform, as well the in-development PyPy, a rewrite of Python in Python itself aimed to provide static code generation as well as high-level optimization.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>JIT транслирует последовательность bytecodes в native code который (как правило) исполняется регистровой машиной (процессором). CS>>Но JIT компиляция не изменяет стековую природу самого bytecode. Стек заложен в самой архитектуре JVM и CLR и он там есть и работает даже с JIT.
VD>После компиляции о байткоде никто уже больше не вспоминает. С этого момента разговоры о нем просто являются спекуляцией.
Узнаю Влада, главное больше стали в голосе и люди тебе поверят...
Q:When native code is ready, it can replace the bytecodes. By not targeting an interpreted scenario, have you completely ruled out that approach to execution in a CLR?
Anders Hejlsberg: No, we haven't completely ruled that out. We can still interpret. We're just not optimized for interpreting. We're not optimized for writing that highest performance interpreter that will only ever interpret....
CS>Q:When native code is ready, it can replace the bytecodes. By not targeting an interpreted scenario, have you completely ruled out that approach to execution in a CLR?
CS>Anders Hejlsberg: No, we haven't completely ruled that out. We can still interpret. We're just not optimized for interpreting. We're not optimized for writing that highest performance interpreter that will only ever interpret....
Здравствуйте, c-smile, Вы писали:
VD>>После компиляции о байткоде никто уже больше не вспоминает. С этого момента разговоры о нем просто являются спекуляцией.
CS>Узнаю Влада, главное больше стали в голосе и люди тебе поверят...
Узнаю c-smile-а. Главное перевести обсуждение с проблемы на оппонента, и все тебе поверят...
CS>
CS>Q:When native code is ready, it can replace the bytecodes. By not targeting an interpreted scenario, have you completely ruled out that approach to execution in a CLR?
CS>Anders Hejlsberg: No, we haven't completely ruled that out. We can still interpret. We're just not optimized for interpreting. We're not optimized for writing that highest performance interpreter that will only ever interpret....
И что из этого следует? "Они" конечно могут что-то интерпретировать, но нигде этого не делают. Интерпретатор дотнета я видел только в одном месте — в Моно. И он используется только в тех случаях когда для ОС нет полноценной реализации моно. Дотнет проектировался под компиляцию, и вести рассуждения о стековой машине в его отношении просто бред. Более того интерпретатор (если его кто-то захочет написать) вполне может преобразовывать MSIL в своей промежуточный код для повышения эффектиности. Кстати, Феникс (фрэймворк для оптимизации и компияции) использует свой IR в который умудряется конвертировать как MSIL, так и обычный машинный x86-код. Из MSIL естественно можно взять больше информации, но это из-за ниличия метаданных, а не из-за стековрой организации MSIL-а.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, smidy, Вы писали:
EC>>NASA Space Recordings Of Earth — Voice Of Earth I
S>В космосе звук не распространяется — это то что говорит режиссер Звездных Войн залу при демонстрации новой серии. S>
S> Тихо там... однако...
Дядьки из NASA это мнение не разделяют:
The Voice of Earth Sounds come from the interaction of the Solar Wind with the magnetosphere of Earth. You are hearing the Aura Borealis, NASA Injun I, Hawkeye, IMP1 and ISEE I Space Probes Recordings.
These space sounds of Earth were recorded by the Injun I, Hawkeye, IMP I and ISEE I space probes from Earth orbit. Although space is a vacuum, this does not mean that there is no sound. it only means that there is no air in space to act as a medium to transmit soundwaves to your ear. The specially designed instruments on board these probes were designed to pick up and record these vibrational frequencies. This information, which was sent back to Earth and decoded, are the beautiful and intriguing sounds you hear on this recording. The sounds you hear are interactions of the solar wind with the Earth's magnetosphere, ionosphere, plasma wave phenomena and interactions between Earth's ionosphere and magnetosphere. These vibration frequencies are all exactly within the range of human hearing, 20 — 20,000 Hz. This is truly the real "Voice" of Earth.
