Існує багато порівняльних досліджень, доступних в Інтернеті, коли мова йде про продуктивність виконання програм, побудованих за допомогою тієї чи іншої мови. Деякі керуються корпораціями, деякі академічними, деякі просто особистими експериментальними звітами.

Ми також отримуємо гідну частку порівняльних досліджень щодо побічних ефектів мови програмування та її інструментарію, наприклад:

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

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

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

Сучасні засоби для сучасних потреб

Звичайно, мови вищого рівня, мабуть, краще і виправдовують їхню вагу мертвої ваги. Деякі варіанти дизайну були зроблені з добрих (або нібито цілеспрямованих) причин у багатьох ланцюжках інструментів. Спільні бібліотеки, моделі пам’яті, попередні процесори, типові системи тощо… Але деякі можуть бути більш життєздатними, ніж інші за допомогою нашого сучасного обладнання, і мені буде цікаво прочитати кілька серйозних досліджень з цього питання.

Отже, моє запитання: чи існує підвіска до Benchmarks Game та інших, які зосереджуються на порівнянні споживання базової пам’яті під час виконання мов?

І навіть далі, чи є деякі дослідження, які посилаються на це з іншими параметрами (подібно до того, що ця стаття робила, наприклад, для інших критеріїв, також заснованих на грі Benchmarks )?

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

Існуюча література:

• Емпіричне порівняння 7 мов програмування - Prechelt (2000) [ PDF ]

  Трохи датовано, але охоплює частину матеріалу, який мене цікавить, і дає уявлення про використання та виразність пам’яті під час виконання. Зараз результати можуть сильно відрізнятися, але це цікавий початок.

• Швидкість, розмір та залежність мов програмування - Марсо (2009) [ блог ]

• Код, що використовується, Фігури, що використовуються часом, від ігри з бенчмарками [ u32 , u32q , u64 , u64q ]

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

Це не дає відповіді на запитання за словом, але, можливо, трохи змінить перспективу. Я маю на увазі стенограму з чату, щоб задати тон цієї відповіді-коментаря, яка, безумовно, буде предметом багатьох голосів.

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

Щоб зробити ще один крок назад, частина причини, з якою ми опиняємось у ситуації, в якій ми знаходимось сьогодні, з порівняно масивними рамками, і деяке незначне зневага до загальної ефективності, поза межами апаратних удосконалень, є спадщиною. Сумісність із застарілими системами закріплює нас сумісністю поверх сумісності. Це не стільки вина найвищого рівня виконання, оскільки вони, по суті, однакові за часом виконання, досить ефективні та ефективні, коли використовуються в інших робочих умовах (наприклад, Xbox, Windows Mobile, попередня 7/8 / поверхня, java micro Framework тощо).

Порівняйте ступінь сумісності робочого столу з його застарілим програмним забезпеченням та ступінь сумісності, яким володіє мобільний пристрій.

З мобільними пристроями виробники пристроїв докладають певних зусиль, щоб забезпечити сумісність, але вони не зробили сумісність основним фундаментом. Коли вибір залежить від продовження забезпечення сумісності та переміщення конструкції мобільної системи вперед, мобільна система рухається вперед.

Для настільних комп’ютерів здається навпаки. Якщо значна зміна змін вражає маркетологів або ранніх тих, хто приймає, неправильно, це багато разів підштовхує необхідні функції та потребує перепроектування задньої кімнати. У якийсь момент я пригадую чутки про те, що ми, як користувачі Windows, знайшли б абсолютно нову файлову систему з Windows XP, потім у Vista, пізніше те саме для Seven, і нарешті знову у вісімці, але ні, просто поступово покращилися з тих пір ми вперше побачили це на Windows2000? Нова файлова система сиділа довгий час, була знята, але, як чутки вирішують історію після цього, я не можу сказати. Це, мабуть, найбільший відомий випадок, але я впевнений, що це не єдиний великий випадок.

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

Зараз, звичайно, Windows - це легка ціль будь-якої критики за цю ситуацію, але інші платформи далеко не "безгрішні". У екосистемі Linux є багато реліквій, які, я впевнений, викликають великі побоювання щодо систематичного вдосконалення.

Економіка відіграє велику роль у цьому рівнянні; як ми фінансуємо наші обчислення та програми на одній, і як вони фінансуються з іншого, вражають надзвичайно різні моделі. Там, де колись Вінтел сильно вплинув на застарілість, Apple і Google перетворили це на майже суворий графік. Це далі, звичайно, ніж я мав намір, тому я залишу, як він сидить, і нехай читачі візьмуть його звідти.

Якщо і коли великі постачальники змінять свої моделі моральної застарілості та ціноутворення, тоді вони можуть почати рухатися вперед із більш масштабними змінами на більш рівну швидкість. Ті рамки вищого рівня, якими керуються мови вищого порядку, певним чином зменшаться, оскільки вони зможуть досягти свого завдання високого рівня з більш низьким рівнем ефективності, оскільки неефективна проміжна сумісність і шари низького рівня будуть бути різко скороченим, якщо не усунутим.