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

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

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

Однако в последнее время меня все больше и больше раздражает потребление памяти моих программ больше, чем что-либо еще. Это может быть связано с тем фактом, что, хотя закон Мура на нашей стороне для необработанного исполнения, мы осознали, что другие узкие места имеют большее значение. Это, и я не склонен обновлять свое оборудование время от времени, и у меня есть некоторые «старые» (читай Pentium 4 с частотой 3,6 ГГц 2005-2006 гг. С 4 ГБ ОЗУ), которые в настоящее время трудно использовать для больших приложений без требуя от меня больших трудностей, чтобы выжать из них каждый кусочек сока (выбор ОС, пользовательского интерфейса, настройка служб и демонов, выбор приложений для использования в той или иной задаче ...). Честно говоря, иногда я запускаю topили procexpплачу при виде памяти, используемой большинством невинных программ.

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

Современные инструменты для современных нужд

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

Итак, мой вопрос: есть ли подвеска для Benchmarks Game и других, которые фокусируются на сравнении базового потребления памяти во время выполнения языков?

И даже более того, существуют ли некоторые исследования, которые сопоставляют это с другими параметрами (аналогично тому, что эта статья сделала, например, для других критериев, также основанных на игре Benchmarks Game )?

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

Существующая литература:

• Эмпирическое сравнение 7 языков программирования - Prechelt (2000) [ PDF ]

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

• Скорость, размер и независимость языков программирования - Марсо (2009) [ блог ]

• Используемый код, используемые формы времени из игры Benchmarks [ u32 , u32q , u64 , u64q ]

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

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

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

Чтобы сделать еще один шаг назад, отчасти причина, по которой мы находимся в ситуации, в которой мы находимся сегодня, с относительно крупными платформами и некоторым незначительным игнорированием общей эффективности, помимо аппаратных улучшений, является наследием. Совместимость с унаследованными системами укрепляет нашу совместимость на вершине совместимости. Это не столько ошибка времени выполнения верхнего уровня, сколько, по сути, одно и то же время выполнения, действующее довольно эффективно и производительно при использовании в другой операционной среде (например, Xbox, Windows Mobile до 7/8 / Surface, Java Micro Framework , так далее).

Сравните степень совместимости настольного компьютера с его устаревшим программным обеспечением и степень совместимости мобильного устройства.

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

Для настольных компьютеров все наоборот. Если существенное прорывное изменение наносит удар по маркетологам или ранним последователям неправильно, оно многократно выдвигает необходимые функции и необходимые изменения в подсобку. В какой-то момент я вспоминаю слухи о том, что мы, пользователи Windows, найдем совершенно и совершенно новую файловую систему с Windows XP, затем в Vista, позже то же самое для Seven и, наконец, снова в Eight, но нет, просто постепенно улучшаемся, так как мы впервые увидели это на Windows2000? Новая файловая система долгое время сидела без дела, была списана, и, как ни странно, слухи решают историю после этого. Это, наверное, самый большой известный случай, но я уверен, что это не единственный большой случай.

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

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

Экономика играет большую роль в этом уравнении; как мы финансируем наши вычисления и приложения в одном, и как они финансируются в другом, следуют поразительно разным схемам. Там, где когда-то Wintel сильно повлиял на устаревание, Apple и Google превратили его в почти строгий график. Это далеко от курса, чем я намеревался, поэтому я уйду, как есть, и позволю читателям взять это оттуда.

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