Ага, еще можно судя же приплюсовать байки про то, что современные x86 процессоры “на прямую” мало что из x86 инструкций выполняют - эмуляция на эмуляции и эмуляцией погоняет и вообще для x86 запретить компилируемые ЯП )
Протестую. Python имеет байт-код, а в паре с python-psyco, если повезёт, спускается и до x86-ассемблера.
Да почти все современные ЯВУ байт-код имеют
Это тоже интерпретация, только байткода, хотя терминология тут размытая. И нет - как я уже сказал, JIT транслирует байткод в машинный и машинный исполняется процессором также как и скомпилированный.
Нет. Про rexx не знаю, но в perl и python исходный код сначала компилируется в байткод. У perl он на диск не сохраняется, а у python даже файлы с байткодом есть.
% file /usr/local/lib/python2.6/os.*
/usr/local/lib/python2.6/os.py: ASCII English text
/usr/local/lib/python2.6/os.pyc: python 2.6 byte-compiled
/usr/local/lib/python2.6/os.pyo: python 2.6 byte-compiled
Цитата из указанного источника:
Ещё одна цитата оттуда же:
Всю-то статью прочесть не пробовал?
Это кривизна русской статьи, слово “исполняется” в этом предложении лишнее. Байт-код можно либо исполнять на виртуальной машине (это медленно), либо JIT’ить в машинный и кормить процессору (это быстро). Читайте английский вариант, Overview, первые два абзаца.
А я никогда не читаю ни начало, ни конец. Для меня главное - вырвать нужную фразу из середины.
Да, фраза не совсем точная (но я не виноват - какую ссылку дали!), но понять ее можно вполне определенно: байт-код интерпретируется процессором (т.е. железкой) и исполняется ВМ (т.е. программой). Исполнение программой - и есть интерпретация с точки зрения процессора.
andriano, вы читаете только знакомые слова? Остальные проходят мимо сознания? 
Не надо цепляться за старые байки, актуальные в начале 90-х. Сейчас всё решает прямизна рук программистов. Мы тут у себя недавно подгружали дорожную сеть. Сначала сделали конвертацию проекции через вызов функций Oracle Spatial. Процедура заняла несколько часов. Потом сделали конвертацию в виде плугина osmosis-а. Он отработал за 25 секунд. О чём это говорит? Только о радиусе кривизны рук программистов Oracle, а вовсе не о использованных технологиях.
Нет.
Да. Но в современной java этого не происходит, там jit.
В Java это не интерпретируемый язык. В яве исходный код компилируется в байткод и уже байткод испольняется в виртуальной машине (JVM). Но это уже совсем offtopic. И josm тормозит не по этому.
Развели спор. Да у вас просто мониторы разные и операционки. У меня linux и монитор 2560x1440. Знаете что это значит? Это значит что видео с youtube (даже в самом отвратительном качестве) я должен смотреть не на 26 дюймах, а на 4х, ибо не тянет 2х ядерный камень масштабирование и отображение видеопотока.
Зато josm шикарен на большом экране, у него оказывается все панельки помещаются.
А у кого-то винды и нормальный (или даже маленький нетбучный) экран, так у них flash летать будет. А josm памяти хочет оперативной много (коей на нетбуке может быть мало).
Каждому свое. А победу в споре предлагаю присудить тому, кто соберет большее количество людей к следующему воскресенью и лучше приготовит шашлык.
Вот и я на буке с linux не могу подружиться с flash технологиями.
Похоже на то. Часто с 2-мя wms слоями работаю. Если в момент появления тормозов один из слоев скрыть, то тормоза пропадают.
Я прошу прощения за личную переписку на форуме, но, увы, личных сообщений здесь не нашел.
Масштабировать должен не CPU, а GPU. Так что настоятельно рекомендую установить родные (а не те, которые входят в комплекс ОС) драйвера на видеокарту.
Ни один вменяемый софт не будет масштабировать процессором, но если он делает это через OpenGL, то тут возможны проблемы, связанные с тем, что Линукс норовит установить софтварную mesa, а все версии Винды Майкрософт снабжает тоже исключительно софтварным OpenGL. Ну политика у них такая - дискредитировать OGL.
При правильной же настройке видеосистемы всю работу по масштабированию и значительную часть работы по декодированию берет на себя GPU, так что процессор вообще сидит-курит.
У меня, правда, не нетбук, а десктоп (точнее, десктопчик), нона Atom и с одним га оперативки. Так что вполне возможно, тормозит именно из-за последнего. Зато при сегодняшней погоде имеет существенное преимущество - системник потребляет мощности меньше, чем дисплей.
Главное - не победа, главное - уча… то есть, я хотел сказать, квалифицированное обсуждение вопроса и выработка продуманного и адекватного мнения.
Драйвера у меня правильные, GPU вовсю работает, да только не ведают в adobe о нем или ведает, но реализовано через задницу. Просто flash будет тормозить на любом железе ибо крив.
В порядке оффтопика…
Там JIT не всегда, а только для критичных участков. Ну т.е. если -надцать раз кусок кода вызвать за короткий промежуток времени - он обработается JIT-ом, а если не вызвать - так и будет интерпретироваться.
Формально, кстати, Java может быть быстрее, чем традиционный заранее компилированный код, потому что к моменту вызова JIT может быть накоплена статистика по работе куска, предлагаемого к компиляции. Типа такого профилирования на лету. Вот только х его з - используется ли это хоть сколько-нибудь прилично хоть в одной JVM…
С другой стороны интеловские процессоры делают это и для скомпилрованного кода, насколько я знаю. Запоминают где и как пошло ветвление и при следующем вызове заранее пускают конвеер в наиболее вероятную сторону.