Слабая типизация - это повышение производительности или уменьшение?

Question

Когда пишете интерпретируемые языки, быстрее ли иметь слабую типизацию или строгую типизацию?

Мне было интересно, потому что часто бывают более быстрые интерпретируемые языки с динамической типизацией (Lua, Javascript) и фактическиинтерпретируемые языки используют слабую типизацию.

Но, с другой стороны, строгая типизация дает гарантии, что слабая типизация не дает, поэтому возможны ли методы оптимизации с одной, что невозможно с другой?

---

С строго типизированным я не имею в виду никаких неявных преобразований между типами.Например, это будет недопустимо в строго типизированном, но (возможно) законно в слабо типизированном языке: "5" * 2 == 10.Особенно Javascript печально известен этими преобразованиями типов.

Answer 1

мне кажется, что на этот вопрос будет трудно ответить явными примерами из-за отсутствия «строго типизированных интерпретируемых языков» (используя определения, которые я понимаю из комментариев к вопросу).

iне может думать ни о каком языке, который интерпретируется и не имеет неявных преобразований.и я думаю, что это по двум причинам:

1. интерпретируемые языки, как правило, не являются статически типизированными.я думаю, это потому, что если вы собираетесь реализовать статически типизированный язык, то исторически компиляция относительно проста и дает вам значительное преимущество в производительности.

2. , если язык не статически типизированзатем он вынужден иметь неявные преобразования.альтернатива усложнит жизнь программисту (им придется отслеживать типы, невидимые в источнике, чтобы избежать ошибок времени выполнения).

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

теперь вы можете ответить «ну, представьте одну».Хорошо.Итак, вы запрашиваете разницу в производительности между кодом, который обнаруживает необходимость преобразования во время выполнения, с кодом, в котором программист явно добавил преобразование.в этом случае вы сравниваете разницу между динамическим определением потребности в преобразовании и вызовом явной функции, указанной программистом.

, на первый взгляд, обнаружение всегда будет добавлять некоторые издержки (в [поздний] скомпилированный язык, который можно улучшить с помощью jit, но вы спрашиваете о переводчиках).но если вы хотите поведение при отказе (ошибки типа), тогда даже явное преобразование должно проверять типы.так что на практике я представляю, что разница относительно невелика.

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

[извините, если я все еще не понимаю.я волнуюсь, что что-то упускаю, потому что вопрос - и этот ответ - не кажется интересным ...]

[править: может быть, лучший способ задать то же самое (?) было бы что-тонапример, «каковы сравнительные преимущества / недостатки различных способов преобразования типов в динамических (поздних связываниях?) языках?»потому что я думаю, что вы могли бы утверждать, что подход python является особенно мощным (выразительным), в то же время имея такие же издержки, что и другие интерпретируемые языки (и при этом не нужно спорить, является ли python или любой другой язык «слабо типизированным» или нет). ]

Answer 2

При строгой типизации я имею в виду отсутствие неявных преобразований между типами.

"5" * 2 == 10

Проблема в том, что "слабая типизация" не является четко определенным терминомпоскольку существует два совершенно разных способа, которыми могут происходить такие «неявные преобразования», которые в значительной степени оказывают противоположное влияние на производительность:

• «Способ языка сценариев»: значения имеют тип времени выполнения и языкнеявно применяет семантические правила для преобразования между типами (например, форматирование двоичного числа в виде десятичной строки), когда операция вызывает другой тип.Это приведет к снижению производительности, поскольку A) требует наличия информации о типе во время выполнения и b) требует проверки этой информации.Оба эти требования приводят к накладным расходам.
• «C way»: во время выполнения это всего лишь байты.Если вы можете убедить компилятор применить операцию, которая принимает 4-байтовое целое число в строке, то в зависимости от того, как именно вы это сделаете, либо первые 4 байта этой строки будут просто обрабатываться, как если бы они были (вероятно, очень большими) целое число, или вы получите переполнение буфера.Или демоны вылетающие из твоего носа.Этот метод не требует дополнительных затрат и приводит к очень быстрой производительности (и очень впечатляющим сбоям).