Динамические языки медленнее, чем статические языки? [закрытый]

Средам выполнения динамического языка нужно только иногда проверять тип .

Но, как правило, все еще медленнее.

Однако есть люди, утверждающие, что такие пробелы в производительности уязвимы; например http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

Нет.

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

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

Чтобы язык мог даже запускать , сначала он должен быть реализован . Теперь вы можете измерять производительность, но вы не измеряете производительность языка , вы измеряете производительность механизма выполнения ]. Большинство языков имеет множество различных механизмов выполнения с очень разными характеристиками производительности. Для C, например, разница между самой быстрой и самой медленной реализациями составляет примерно 100000 раз!

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

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

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

Возьмем, к примеру, Smalltalk, Lisp, Java и C ++. Все они являются или когда-то были языком выбора для высокопроизводительного кода. Все они огромные инженеры и исследователи потратили на них столетия, чтобы сделать их быстрыми. Все они имеют хорошо настроенные проприетарные коммерческие высокопроизводительные механизмы исполнения. Учитывая примерно одну и ту же проблему, реализованную примерно сопоставимыми разработчиками, все они работают примерно одинаково.

Два из этих языков являются динамическими, два - статическими. Java интересен тем, что, хотя это статический язык, большинство современных высокопроизводительных реализаций на самом деле являются динамическими реализациями.(Фактически, несколько современных высокопроизводительных JVM на самом деле являются либо замаскированными виртуальными машинами Smalltalk, производными от виртуальных машин Smalltalk, либо написанными компаниями Smalltalk VM.) Lisp также интересен, потому что, хотя это динамический язык, некоторые (хотя и не многие) ) статические высокопроизводительные реализации.

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

Разумно предположить, что во время выполнения необходимо вычислить больше вещей.

Использование файла, сопоставленного с памятью, позволяет избежать копирования из кэш-памяти файловой системы в (управляемую) память приложения, если используется представление только для чтения (хотя для доступа к памяти необходимо использовать указатели byte *). И вместо создания множества потоков используйте один поток для последовательного сканирования файла, используя, например 100MB отображенные представления памяти в файл (не сопоставляйте весь файл сразу с адресным пространством процесса).

Просто глядя на вашу конкретную ситуацию, мне приходят в голову следующие точки.

1) Две модели действительно очень похожи 2) Если добавить «MiddleName», необходимо добавить его в двух местах 3) Когда вы говорите «Я хочу только передать назад тонкий объект» - фактический POST будет содержать тот же объем данных, независимо от того, привязываете ли вы к исходной модели или к новой (он будет содержать пару ключей, значений для каждого пользователя-ввода в форме) 4) Вы исключаете возможность отображения данных на вашей странице «Сохраненный ОК» или «Что-то не является действительным», поскольку она не является частью модели

По этим причинам я бы рекомендовал использовать ту же модель для GET и POST действия.

Нет, динамические языки необязательно медленнее статических.

Проекты pypy и psyco значительно продвинулись в создании компиляторов JIT для питона, которые имеют компиляцию на основе данных; другими словами, они автоматически компилируют версии часто называемых функций, специализированных для конкретных общих значений аргументов. Не только по типу, как шаблон C++, но и фактические значения аргументов; скажем, аргумент обычно равен нулю, или Нет, тогда будет специально скомпилированная версия функции для этого значения.

Это может привести к тому, что скомпилированный код будет быстрее, чем компилятор C++, и так как он делает это во время выполнения, он может обнаружить оптимизации специально для фактических входных данных для этого конкретного экземпляра программы.

Сначала вы должны уточнить, рассматриваете ли вы

• динамическую типизацию или статическую типизацию или
• статически скомпилированную языковую или интерпретируемые языки против JIT с байт-кодом.

Обычно мы имеем в виду

• динамический язык = динамическая типизация + интерпретация во время выполнения и
• статические языки = статическая типизация + статическая компиляция

, но это не обязательно.

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

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

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

РЕДАКТИРОВАТЬ

Если вам нужны числа , я предлагаю вам взглянуть на Тесты компьютерного языка . Я нашел это проницательным.

, я уже больше года занимаюсь программированием игр для iPhone! Я начал делать большинство вещей в Objective-C, но затем я узнал, что для большинства графических (или вычислительных) интенсивных игр Objective-C на самом деле не лучший вариант. Существует множество путей, таких как Pure Objective-C для логики, и встроенные функции C для более «интенсивных» частей вашей игры, Obj-C также позволяет использовать файлы C++ (например, для классов модели) с Obj-C + + (который в основном является файлом исходного кода .m Obj-c, но переименован в .mm

Сказав, что, Cocos-2D является, на мой взгляд, замечательной библиотекой, она в основном написана на Obj-C, но имеет чистые части C для самых интенсивных процессоров (физика это chipmunk physics и Box2D, они также имеют библиотеку хэш-таблицы, написанную на чистом C, чтобы избежать вызова NSDictionary много). Cocos2D не трудно использовать, и вы можете получить хорошую игру работать довольно быстро!

Вы можете встроить весь Cocos-2D в ваш проект или просто встроить некоторые его полезные части (например, Cocos-Live for On-Line Scares, Texture loaders и т.д.). Можно также начать работу непосредственно с проекта Cocos-2D Xcode и удалить то, что вам не нужно (например, примеры и т.д.).

Простое объяснение Cocos-2D лицензии см. в разделе Здесь !

О OpenGL, с Cocos вам не нужно будет учиться глубоко, если вы не начнете попадать в очень пользовательские вещи.

Сказав все это, вот мои рекомендации:

1) GUI требует времени, GUI может занять много (даже больше 50%) вашего исходного кода на самом деле... так что принимайте это во внимание, если вы собираетесь иметь игровые меню и т.д.. и скорректируйте свои временные графики, чтобы обеспечить соответствие кода GUI!

2) Когда вы немного выучили Cocos, начните играть с OpenGL, это замечательная поездка, и это действительно здорово знать немного о «движке» вашего «автомобиля», так что если ваш «автомобиль» (Cocos2D) ломается или делает не совсем то, что вы хотите, вы всегда можете подправить здесь и там, чтобы сделать его работать.

Следует отметить, что List имеет очень специфическое значение в scala, что не эквивалентно интерфейсу java.util.List . Список представляет собой закрытый абстрактный класс, представляющий рекурсивную структуру данных, которая имеет заголовок и конец . (В scala существуют структуры, похожие на список Java, некоторые из которых являются изменяемыми.)

Список Скалы являются неизменяемыми ; изменение списка каким-либо образом невозможно, хотя можно создать новый список, который будет предшествовать существующему (что вернет новый объект). Несмотря на их незыблемость, структура не является более дорогой с точки зрения создания объектов, чем, скажем, добавление к java.util.LinkedList

Метод + устарел по уважительной причине, поскольку он неэффективен; вместо этого используйте:

val newList = theList ::: List(toAppend)

Я полагаю, что другим способом было бы дополнить 2 разворота:

val newList = (toAppend :: theList.reverse).reverse

Я сомневаюсь, что это более эффективно! Вообще, если я хочу добавить поведение, я использую добавить , а затем обратить (в точку необходимости доступа к списку):

val newList = toAppend :: theList
//much later! I need to send the list somewhere...
target ! newList.reverse

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

Однако это не обязательно означает, что реализация программы будет медленнее на динамических языках - существует множество документированных случаев реализации одной и той же программы как на статическом, так и на динамическом языке, и динамическая реализация оказалась более быстрой. Например, это исследование (PDF) дало такую же проблему программистам на различных языках и сравнило результат. Среднее время выполнения для реализаций Python и Perl было быстрее, чем среднее время выполнения для реализаций C++ и Java.

Для этого есть несколько причин:

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

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

3) навык программиста важнее скорости языка - неопытный программист может писать медленный код на любом языке. В вышеупомянутом исследовании было несколько порядков различий между самой быстрой и самой медленной реализацией в каждом из языков.

4) во многих проблемных доменах скорость выполнения, в которой доминирует ввод-вывод или какой-либо другой фактор, внешний по отношению к языку.

5) Выбор алгоритма может привести к карликовому выбору языка. В книге «More Programming Pearls» Джон Бентли реализовал два алгоритма для задачи - один был O (N ^ 3) и реализован в оптимизированном фортране на Cray1. Другой был O (N) и реализован в BASIC на TRS80 домашнем микро (это было в 1980-х годах). Этот TRS80 превосходил Cray 1 для N > 5000.

На самом деле трудно сказать, потому что многие из используемых тестов не так репрезентативны. А с более сложными средами выполнения, такими как HotSpot JVM, различия становятся все менее значимыми. Взгляните на следующую статью:

Теория и практика Java: динамическая компиляция и измерение производительности

Самым важным фактором является рассмотрение алгоритма диспетчеризации метода. В статических языках каждому методу обычно присваивается индекс. Имена, которые мы видим в исходном коде, на самом деле не используются во время выполнения и находятся в исходном тексте для удобства чтения. Естественно, такие языки, как java, сохраняют их и делают доступными в отражении, но с точки зрения вызова метода они не используются. Я оставлю размышления и привязку к этому обсуждению. Это означает, что при вызове метода runtmne просто использует смещение для поиска в таблице и вызова. С другой стороны, динамический язык использует имя функции для поиска по карте, а затем вызывает указанную функцию. Хэш-карта всегда будет медленнее, чем поиск по индексу в массиве.