Можем ли мы сделать общие заявления о производительности интерпретируемого и скомпилированного кода?

60

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

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

Итак, мой вопрос: можем ли мы когда-нибудь сказать о производительности скомпилированных / интерпретированных технологий? Если мы можем сказать, что компилирование обычно быстрее, чем интерпретируется, как я могу убедить рецензента в моей точке зрения?

EpicSam
источник
76
Поскольку это кажется практической проблемой, а не академическим упражнением, было бы целесообразно даже не пытаться дать общий ответ, а на самом деле оценивать технологии A и B. Хотя общий ответ, вероятно, не может быть дан, безусловно, можно оценить характеристики производительности двух конкретных технологий, указывающие на их актуальность для приложений, в которых заинтересована ваша организация.
5gon12eder
26
Вопрос спрашивает об общих чертах , но, похоже, ваша настоящая проблема связана со спецификой технологий A и B. Хотя я думаю, что в целом интерпретируемые языки могут быть медленнее в целом, этот факт, вероятно, не имеет абсолютно никакого отношения к вашим конкретным технологиям. Вполне возможно, что ваш конкретный интерпретированный B быстрее, чем ваш скомпилированный A, независимо от общей тенденции.
Брайан Оукли
18
Случайно выберите интерпретируемый язык и скомпилированный, и поставьте доллар на то, что скомпилированный будет быстрее. Повторите достаточно много раз, и вы в конечном итоге выйдете достаточно далеко, чтобы купить обед в Метро. Тем не менее, есть более быстрые и более интересные способы для компетентного программиста заработать столько денег. И Метро не так уж и здорово.
Эд Планкетт
23
Вы, кажется, противоречат себе. С одной стороны, вы хотите сделать общее утверждение о интерпретируемых и скомпилированных языках. Но с другой стороны, вы хотите применить это общее утверждение к конкретному сценарию. Но как только вы примените его к конкретному сценарию, он больше не обобщается . Поэтому, даже если вы можете утверждать, что интерпретируемые языки в целом медленнее , ваш рецензент не заботится об этом. Вы делаете анализ двух очень специфических технологий. Это буквально противоположно обобщению.
одинокий катер
8
Честно говоря, какого чёрта вы хотите дать релевантную для компании рекомендацию по одной из двух технологий, в первую очередь основанных на производительности? В особых случаях (например, программирование высокоскоростных 3D-игр) производительность может быть важным критерием, но для большинства реальных бизнес-программ она должна сравниваться последней, а не первой.
Док Браун

Ответы:

110

Нет.

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

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

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

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

Йорг Миттаг
источник
12
насколько я могу сказать , свой собственный предшествующий ответ в связанном (возможно дубликате) вопрос охватывает эти вопросы гораздо лучше , чем это
комар
11
Если невозможно сделать общие выводы о производительности, и мы можем написать определенную программу на A, которая превосходит аналогичную программу на B, но мы также можем написать программу на B, которая превосходит написанную на A. Мы не можем на самом деле сделать вывод о скорость языка когда-нибудь? В любом случае, Форт выглядит интересно, я должен буду прочитать об этом позже.
EpicSam
36
@EpicSam: правильно. Сама идея «скорости языка» принципиально бессмысленна.
Йорг Миттаг
23
В общем: будьте конкретны.
igouy
19
Я предполагаю, что под «... и некоторыми очень медленными компиляторами» вы подразумевали код, который они генерируют, а не скорость их компиляции.
Мартино
81

Обобщения и конкретные сценарии буквально противоположны.

Вы, кажется, противоречат себе. С одной стороны, вы хотите сделать общее утверждение о интерпретируемых и скомпилированных языках. Но с другой стороны, вы хотите применить это общее утверждение к конкретному сценарию, включающему Технологию A и Технологию B.

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

loneboat
источник
3
Это, безусловно, лучший ответ на текст вопроса, в отличие от названия вопроса.
Дэвид
37

Как правило, интерпретируемая программа примерно в 2–10 раз медленнее, чем написание программы на главном языке переводчика, при этом интерпретаторы для более динамичных языков работают медленнее. Это связано с тем, что интерпретируемая программа должна выполнять всю фактическую работу, но дополнительно имеет накладные расходы на интерпретацию.

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

Например, Perl - это интерпретируемый язык, ориентированный на манипулирование текстом. Идиоматическая Perl-программа, выполняющая текстовые манипуляции, будет не намного медленнее, чем C-программа, и может даже превзойти C-программу в некоторых случаях (возможно, потому что Perl использует другое строковое представление и имеет различные встроенные оптимизации для текста и ввода-вывода). Однако работа с числами в Perl будет невыносимо медленной. Инкремент ++x- это отдельная инструкция сборки, но он включает несколько обходов указателей и ветвей для интерпретатора Perl. Я недавно портировал связанный с CPU сценарий Perl на C ++ и получил ускорение в 7–20 раз, в зависимости от уровня оптимизации компилятора.

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

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

При выборе технологии производительность языковой среды исполнения сама по себе совершенно не имеет значения. Скорее всего, будет важно, чтобы технология соответствовала некоторым базовым ограничениям (наш бюджет составляет $ x, мы должны быть в состоянии выполнить до yyyy-mm-dd, мы должны удовлетворить различные нефункциональные требования), и что она имеет более низкий общая стоимость владения (с учетом производительности разработчика, затрат на оборудование, затрат на бизнес-возможности, риска ошибок и непредвиденных ограничений в технологиях, затрат на обслуживание, затрат на обучение и наем,…). Например, в отрасли, где время выхода на рынок является наиболее важным фактором, технология с наилучшей производительностью разработчиков подойдет лучше всего. Для крупной организации ремонтопригодность и долгосрочные затраты могут быть более интересными.

Амон
источник
10
Если вы думаете, что «сайт с тестами по компьютерному языку имеет запутанную структуру», тогда дайте URL-адрес конкретной странице, которая поддерживает вашу точку зрения, вместо того, чтобы ожидать, что люди будут искать на верхнем уровне то, что они могут никогда не найти! Шоу; не просто скажи.
igouy
8
Если вы думаете: «Самая важная часть сайта - это не результаты тестов, а дискуссии о том, насколько трудны значимые тесты», укажите URL-адреса этих страниц. Шоу; не просто скажи.
igouy
4
Это было бы для удобства тех, кто читает ваш ответ. (Я просто тот, кто управляет игрой тестов).
igouy
2
@amon, связывающий пример k-нуклеотида в ответе, сделает его более читабельным, а заметку - более полезной, как и ссылки на обсуждения (без чтения всего сайта, для меня не очевидно, о каких обсуждениях вы говорите).
Дэвид
1
Откуда ты взял 2-10X? Соотношение полностью зависит от того, сколько времени потребуется для извлечения и отправки обработчику для каждого байт-кода, в зависимости от того, сколько времени занимает выполнение каждого обработчика, и 10x будет возможно только в том случае, если цикл выборки займет 9x столько же, сколько обработчик, что является диким неправдоподобно. Чаще всего в исполнении доминирует обработчик. и цикл выборки может быть исчезающе незначительным.
user207421
18

Вы абсолютно можете сказать что-то о производительности скомпилированных / интерпретированных технологий. Но сначала вы должны определить «производительность». Если вы строите простую в вычислительном отношении встроенную систему, то «производительность», скорее всего, будет зависеть от использования памяти. В то время как вычислительно сложная система, работающая с большими наборами данных, будет определять «производительность» в количестве вычислений за единицу времени, поскольку затраты памяти из JVM или .NET будут незначительными.

Как только вы решите, что такое «производительность», вы можете сказать что-то вроде «у нас будет 50 миллиардов объектов в памяти в любой момент времени, и интерпретируемый techA добавляет дополнительные 8 байтов к каждому объекту для внутреннего управления, что равняется накладным расходам памяти в 400 ГБ» по сравнению с techB, который не добавляет эти данные "

jhbh
источник
12

Это технический вопрос, и вы уже получили много хороших технических ответов, но я хотел бы отметить несколько иной аспект вашей ситуации: тот факт, что вы не можете просто основывать решение, такое как «технология А или технология В», чисто по техническим и / или эксплуатационным причинам.

Технические аспекты чего-то подобного - это лишь малая часть решения между А и В. Есть десятки других факторов, которые следует иметь в виду:

  • это связано с какими-либо расходами на лицензирование? Например: вы должны заплатить (значительную сумму) за использование кластера машин SQL Server, а не за кластер машин PostgreSQL.
  • у меня есть сотрудники, которые знакомы с этой технологией (стеком) и ее экосистемой? Если да, они доступны? Если нет, могу я нанять немного? Сколько это будет стоить мне? Или я тренирую существующие? Сколько это будет стоить мне?
  • что хочет клиент? Это может быть проблемой в большинстве случаев.
  • технология, которую я рекомендую, готова к использованию? Или это просто шумиха, которая может исчезнуть? (например, подумайте о Node.js, когда он впервые вышел)
  • соответствует ли технология, которую я рекомендую, существующей архитектуре или архитектуре, которую я имел в виду? Или я должен тратить много денег, чтобы они работали вместе без проблем?
  • и еще много других аспектов, которые зависят от вашей конкретной ситуации.

Как видите, при принятии такого решения нужно учитывать МНОЖЕСТВО.

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

Раду Мурзеа
источник
10

Частичная оценка - это концептуальная основа, относящаяся к интерпретаторам и составителям.

Можем ли мы сделать общие заявления о производительности интерпретируемого и скомпилированного кода?

Языки программирования являются спецификациями (написанными в некоторых отчетах, таких как R5RS или n1570 ). Это не программное обеспечение, поэтому даже не имеет смысла говорить о производительности . Но некоторые языки программирования могут иметь несколько реализаций, включая интерпретаторы и компиляторы .

Даже в традиционно скомпилированных языках (то есть языках, реализации которых часто являются компиляторами), таких как C, некоторые части часто интерпретируются. Например, строка управления форматом printf (определенная в стандарте C) часто «интерпретируется» ( стандартной библиотекой C , которая имеет printf функцию, использующую методы переменных аргументов), но некоторые компиляторы (включая GCC ) могут - в определенных ограниченных кейсы - оптимизировать его и «скомпилировать» в вызовы более низкого уровня.

И некоторые реализации, даже внутри «интерпретаторов», используют методы компиляции JIT (поэтому генерируйте машинный код во время выполнения ). Хороший пример - Луаджит . Другие реализации (например, Python, Ocaml, Java, Parrot, Lua) переводят исходный код в байт-код, который затем интерпретируется.

SBCL - это «компилятор» Common Lisp, который динамически переводит каждое взаимодействие REPL (и вызовы в evaletc ...) в машинный код. Итак, вы чувствуете, что это переводчик. Большинство реализаций JavaScript в браузерах (например, v8 ) используют методы JIT-компиляции.

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

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

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

Для некоторых типов задач стоит разработка программного обеспечения с некоторыми метапрограммирующими подходами, что дает важные ускорения. Вы можете себе представить, что при наличии определенного ввода ваша программа динамически генерирует специализированный код для его обработки. Это даже возможно с C или C ++ (либо используя некоторую библиотеку JIT, либо генерируя некоторый код C, компилируя его как плагин, который загружается динамически).

Смотрите также этот связанный вопрос о Python, и что

Василий Старынкевич
источник
7

Для такого кода A = A + B, который может компилироваться до одной или двух машинных инструкций, каждая из которых занимает определенное количество циклов. Ни один переводчик не может сделать то же самое в этом количестве циклов по простой причине.

Интерпретатор также выполняет собственный набор команд (назовите их байт-кодами, p-кодами, промежуточным языком и т. Д.). Каждый раз, когда он видит байт-код, такой как ADD, он должен каким-то образом искать его и переходить к коду, который выполняет сложение.

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

С другой стороны...

Для кода, например callSomeFunction( ... some args ...), сколько циклов тратится между вводом этого кода и выходом из него? Все зависит от того, что происходит внутри callSomeFunction. Это может быть несколько, и это может быть триллионы, даже если callSomeFunctionон сам скомпилирован. Если это много, нет смысла обсуждать стоимость интерпретации этой строки кода - деньги находятся в другом месте.

Помните, что интерпретируемые языки имеют свою ценность, например, нет необходимости их компилировать. («Компиляция» поверхностного синтаксиса в байтовые коды занимает тривиальное время. Возьмем, например, R или MATLAB.)

Кроме того, для интеллектуальных уровней программирования необходима гибкость. В Обществе разума Мински , глава 6.4 B- Brain, есть программы A, которые имеют дело с миром, и есть программы B, которые имеют дело с программами A, и могут быть другие уровни. Программы, которые пишут и управляют другими программами, легче выполнять в интерпретирующих системах.

В Лиспе вы можете написать, (+ A B)чтобы добавить A и B, но как только он будет записан, у вас есть только выбор: запустить его или нет. Вы также можете написать, (eval (list '+ 'A 'B))которая создает программу, а затем выполняет ее. Это может создать что-то другое.

Предметом программы является другая программа . Это легче писать на интерпретируемом языке (хотя, как указывает Йорг, более новые версии Lisp, хотя и имеют eval, компилируют на лету, поэтому они не имеют потери скорости интерпретации).

Майк Данлавей
источник
1
Мне интересно, что вы говорите, что писать программы на мета-уровне легче на интерпретируемых языках, но используйте в качестве примера Lisp, где большинство реализаций компилируется.
Йорг Миттаг
1
@ JörgWMittag: Конечно, но все они имеют evalи applyфункции, которые являются переводчиками.
Майк Данлавей
2
Я совершенно уверен, что, по крайней мере, на SBCL, evalэто не интерпретируется. И ни один не является apply. Конечно, есть реализации, которые содержат интерпретаторы, но SBCL - нет.
Йорг Миттаг
1
Интерпретатор может оптимизировать состояние цикла во время выполнения и сократить оставшиеся итерации. Это редко возможно в скомпилированных программах. В частности, точка доступа Oracle делает именно это.
Basilevs
2
@ JörgWMittag: Конечно eval, не интерпретируют ред . Это интерпретируют эр .
Майк Данлавей
5

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

Частично причина в том, что интерпретируемые языки должны иметь цикл-интерпретатор, который читает инструкцию, выбирает соответствующее действие и выполняет его. В лучшем случае, например, при интерпретации байт-кода Python или Java (как это делала старая JVM), у него есть накладные расходы, состоящие из нескольких инструкций, и он разрушает предсказатель ветвления - без последнего вы можете ожидать огромных штрафов из-за неправильных предсказаний. Даже очень тупой JIT должен значительно ускорить это.

Тем не менее, интерпретируемый язык может обмануть. Например, Matlab оптимизировал подпрограммы для умножения матриц, и с небольшими изменениями вы можете получить код, работающий на графическом процессоре (отказ от ответственности: я работаю на nVidia - любое мнение, высказанное здесь, является моим и не отражает точку зрения моего работодателя). Таким образом, вы можете написать короткий и мощный код высокого уровня, не беспокоясь о деталях - кто-то позаботился об этом и потратил время и ресурсы на его оптимизацию на языке низкого уровня. В этом нет ничего унаследованного, и это не мешает, например, Matlab JIT-коду, но часто нет причин, так как накладные расходы на вызов высокоуровневой подпрограммы минимальны по сравнению со временем, затрачиваемым на низкоуровневые.

TL; DR - скомпилированные программы имеют огромный выигрыш в производительности по сравнению с интерпретируемыми (сравнение яблок с яблоками см. В PyPy Speed ). Однако скорость исполняемого файла - только часть проблемы, и она может не сильно повлиять на общую скорость (если время в основном проводится в библиотеках). Также реализация имеет значение.

Мацей Печотка
источник
5

Ваше предположение обосновано, хотя это предположение.

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

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

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

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

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

альтернативный текст

TL; DR: ты должен быть прав, но на всякий случай проверь реальный мир.

rghome
источник
3

Если вы не используете что-то экзотическое, ваша проблема не будет связана с производительностью интерпретируемого языка A и скомпилированного языка B.

Потому что, если вы / ваша команда знаете A, а не B, и поэтому пишете код лучше на A, чем на B, у вас может получиться намного лучшая производительность на A, чем на B. Если у вас есть люди, имеющие опыт работы с одним языком, и язык / библиотеки могут это сделать работа вам нужна, придерживайтесь ее.

Вот ссылка о регулярных выражениях на разных языках; вы увидите, что регулярные выражения реализованы лучше в некоторых языках, даже если они скомпилированы или нет: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

Walfrat
источник
Проблема заключается в том, что команда может использовать как A, так и B, и не указала предпочтения ни для одного из них, когда я попросил их ввести.
EpicSam
@EpicSam, а как насчет их прошлых проектов?
Вальфрат
1
И A и B были использованы. Однако они хотят перейти на использование 1 технологии для всех проектов. Производительность обеих технологий достаточно хороша для текущих проектов. Однако потенциальная более высокая производительность одного из них должна быть рассмотрена при рассмотрении потенциальных будущих проектов.
EpicSam
3
@EpicSam лучше искать сообщество по языку и библиотеке / Framework, которые помогут вам в ваших проектах.
Вальфрат
6
Я согласен с @Walfrat. Я бы поспорил, что язык с «самым высоким потенциалом» - это прямая сборка или какой-то необработанный набор команд процессора. Но мы не говорим об этих языках, потому что «очевидно», что наличие таких инструментов, как компиляторы, интерпретаторы и предварительно написанные библиотеки, чрезвычайно важно. Я думаю, что доступность инструментов / знаний сообщества важнее, чем выбор между интерпретацией / компиляцией
Иван
1

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

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

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

KjMag
источник
0

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

Во-первых, они могут не захотеть верить скромному инженеру, поэтому я нашел несколько сопоставимых тестов производительности и процитировал их. Их много, от таких людей, как Microsoft, или от известных университетов. И они скажут что-то вроде: метод A в 3-10 раз быстрее, чем метод B, в зависимости от переменных X и Y.

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

На этом этапе разница (или ее отсутствие) между A и B должна быть настолько ясной, что вам нужно только представить ее. Так что форматируйте результаты четко, с диаграммами, если это возможно, излагая все предположения и определяя все используемые данные.

RedSonja
источник
1
Проблема с выполнением моего собственного теста состоит в том, что я фактически буду просто тестировать две конкретные программы, написанные на А и В, а не на А и В в целом. Должна быть возможность создавать программы, которые решают проблему X как в A, так и в B, где A быстрее, а затем переписывать их так, как B быстрее, и наоборот. По сути, это позволяет вам работать в обратном направлении, исходя из своего заключения, например, если вы предпочитаете A, то либо выбираете сценарий, в котором A быстрее, либо просто оптимизируйте версию A, пока она не превзойдет аналогичную в B. Поэтому мы могли бы сделать вывод о производительности только в конкретном случае. дело не общее.
EpicSam
В зависимости от того, насколько важным и важным является это решение, вы можете реализовать репрезентативную часть функциональности, используя как A, так и B. Если это действительно важное решение, то это не потерянное время. Вы должны будете обосновать, насколько репрезентативен ваш раздел, и что вы не пытаетесь склонить его в пользу своих личных предпочтений.
RedSonja
1
@EpicSam Найдите кого-то, кто явно предпочитает A, и позвольте им оптимизировать тест для A. Сделайте то же самое для B. Вам нужно только убедиться, что оба программиста находятся примерно на одном уровне и проводят примерно одинаковое время. По-прежнему существует проблема выбора эталона, но пусть оба программиста будут вовлечены в решение; в идеале, пусть они соглашаются с эталоном. Другая проблема - потраченное время, но это можно решить, выбрав что-то простое и полезное.
maaartinus
0

Я бы сказал, что любой динамический язык имеет преимущество перед статически скомпилированными: «Оптимизация во время выполнения»

Это одна из причин, почему Java может быть быстрее, чем C ++

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

ПРИМЕЧАНИЕ. Итак, Java - это интерпретируемый, а не динамический язык. Но это отличный пример того, что вы можете ускорить с информацией времени выполнения

SystematicFrank
источник
-3

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

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

Это был бы мой подход:

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

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

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

Trilarion
источник
2
Совершенно неправильно. Вы не понимаете, как работают интерпретаторы, а не как работают компиляторы.
rghome