В чем смысл предложения «мы хотели, чтобы оно было скомпилировано, чтобы процессор не записывал неправильные вещи».

Я читал эту статью. У него есть следующий абзац.

И Скала оказалась быстрой? Ну, как вы определяете пост? Примерно так же быстро, как Java. Это не должно быть так быстро, как C или Assembly. Python не значительно быстрее, чем Ruby. Мы хотели сделать больше с меньшим количеством машин, используя преимущества параллелизма; мы хотели, чтобы он был скомпилирован, чтобы процессор не записывал неправильные вещи.

Я ищу смысл последнего предложения. Как интерпретируемый язык заставит процессор делать «неправильные» вещи?

Если код говорит

A = A + 1

скомпилированный код делает это

add A, 1

интерпретированный код делает это (или некоторое изменение)

look up the location of A in the symbol table
find the value of A
see that 1 is a constant
get its value
add the value of A and the value of 1
look up the location of A in the symbol table
store the new value of A

получить идею?

мы хотели, чтобы он был скомпилирован, чтобы процессор не записывал неправильные вещи.

Похоже, они имеют в виду скомпилированные и интерпретированные. Скорее всего, вплоть до истории о перемещении задач фоновой обработки в Scala (скомпилировано) после первоначальной разработки в Ruby On Rails (интерпретировано).

Объяснение скомпилированного и интерпретированного кода здесь .

При использовании скомпилированного языка вводимый код сокращается до набора машинно-специфических инструкций перед сохранением в виде исполняемого файла. В интерпретируемых языках код сохраняется в том же формате, который вы ввели. Скомпилированные программы обычно работают быстрее, чем интерпретируемые, потому что интерпретируемые программы должны быть сведены к машинным инструкциям во время выполнения.

«Неправильные вещи» здесь означают накладные расходы, которые требуются интерпретатору для анализа и обработки кода. Это связано с понятием интерпретируемых и скомпилированных языков. Существует несколько моделей перевода кода, которые примерно относятся к одной из следующих категорий:

• Собственная компиляция - исходный код напрямую компилируется в машинный код. Лучшая производительность за счет портативности. Обычно ассоциируется с C и C ++,
• Промежуточная компиляция - исходный код компилируется в упрощенный промежуточный язык (байт-код), который позднее интерпретируется или компилируется (компиляция точно в срок) в машинный код во время выполнения. Лучшая переносимость, чем собственный код, лучшая производительность, чем чистая интерпретация, сохраняя при этом некоторые преимущества интерпретации (например, позднее связывание). Примеры включают C #, Java и другие языки, ориентированные на JVM и .NET CLR,
• Интерпретация - исходный код напрямую не переводится в машинный код, а интерпретируется и выполняется специальной программой-интерпретатором. Интерпретаторы различаются по сложности, в наивной реализации, однако все сводится к анализу, анализу и исполнению исходного кода построчно. Интерпретация обеспечивает большую гибкость, чем компиляция, поэтому интерпретируемые языки, например, более широко используют динамическую типизацию или рефлексию. Интерпретируемые языки часто рассматриваются как обеспечивающие повышенную производительность труда разработчиков, так как они требуют меньшего количества стандартного кода и прекрасно подходят для быстрого создания прототипов. Недостатком является снижение производительности. Обычно ассоциируется с JavaScript, Ruby или Python.

Следовательно, выбор между интерпретируемым и скомпилированным языком сводится к вопросу, что мы ценим больше, производительность разработчика или производительность? Миграция, описанная в этой статье, похоже, придерживается той же мысли: сильный язык прототипов Ruby заменен на Scala на основе JVM из соображений производительности.

В данном случае я имею the wrong stuffв виду отсутствие безопасности типов в некомпилированном коде.

Таким образом, код не только интерпретируется медленнее, но и более глючит ...