Обратите внимание, что время запуска является IIRC другого теста, где FPC пики
Я думаю, ответ должен быть, прежде всего, искать в том, что Free Pascal статически связывает программы по умолчанию, избегая LibC и другие вспомогательные библиотеки
Это имеет несколько последствий:
- для простых программ, которые в настоящее время протестированных программы FPC не являются статическими, используя только собственную RTL (не статические копия libc) и не имеют динамических связываний (как во времени, так и в памяти). Включить отображение общих сегментов glibc (это так?), Которые могут быть ошибочно приняты за использование памяти приложения.
- libc может сделать потенциально ненужным, но включает в себя инициализации, которые FPC не делает для этих простых программ. (например, инициализация zoneinfo)
- Поскольку FPC использует полностью независимый менеджер памяти, начальный блок кучного субаллокатора может иметь разный размер. Возможно, FPC систематически меньше.
- Для резьбы, размер стека нового потока может вызвать различные различия (размер и, может быть, тот факт, если она (частично) только оговорку или выделяемой памяти, или независимо от * Никс эквивалент этого)
В целом, я думаю, что это наблюдаемое поведение - это меньше о FPC, а также о недостатке изменений среди других эталонных систем разработки. FPC просто выделяется, потому что почти все остальное построено поверх технологии gcc/glibc (либо потому, что они являются прямыми gcc-дериватами, либо потому, что их VM/интерпретаторы построены поверх gcc), и, таким образом, все разделяют общие рекомендации libc. FPC отличается просто подчеркивает (g?) Плохое масштабирование libc в отношении простых программ. (*)
Перестрелка вероятно, может быть необъективным в том смысле, что либо общий адрес пространство подсчитывали, а не на самом деле используется частные байты, или потому, что он не делает различий между достаточно частных байтов, выделенных suballocator и частных байтов фактически используемых процессом. Для этого, вероятно, потребуется использовать libc/libmalloc core devel, и поскольку перестрелка является открытым исходным кодом, вопрос, если вы можете обеспечить лучшее измерение, открыт.
Либо это, либо есть что-то принципиально неправильное с (g) libc. (Я не эксперт в этом). Возможным решением для получения более релевантной информации будет запуск теста на FreeBSD или Linux с помощью uclibc. Короче говоря, ничего, кроме glibc.
Как указано в сообщении Igouy, при связывании с libc FPC получает (плохие) характеристики других систем разработки.Это еще один показатель того, что этот вопрос должен быть «почему GLibC с помощью бинарных файлов выполнять плохо в тесте выбывание памяти», а не «почему FPC хорошо работать в выбывание тесте»
Обратите внимание, что FPC изначально избегали Libc из-за проблемы совместимости с кросс-дистрибуцией, а не производительность или размер файла.
Итак, для всех, кто предполагает, что это случайность для измерения использования памяти FPC, когда-либо считалось, что это проблема с использованием памяти glibc или ее измерения? Или, вернее, что высокий номер Glibc является неправильным, и не малое число FPC ....
.... Разработчик FPC ....
(*) и, прежде чем вы можете сказать помните, что философия Unix состоит в том, чтобы объединить небольшие инструменты вместе, а многие процессы Unix закорочены живыми.
Одним из распространенных значений предвзятости является предрассудок - вы делаете обвинение или задаете вопрос? Вместо «предвзятого» всегда возможно, что что-то неправильно с тем, как измеряется память программы FPC. Вы посмотрели [как эти измерения сделаны] (http://shootout.alioth.debian.org/help.php#memory)? – igouy
@igoguy Я думаю, что интерпретировать это как нечто иное, чем пытаться понять дико разрозненные номера памяти, является растяжкой. Это вполне разумный способ задать этот вопрос. –
@Dave Newton - Легко спросить, почему такая большая разница в использовании памяти показана без каких-либо обвинений в предвзятости. Например, просто опустите любое упоминание о предвзятости и спросите: «Действительно ли это, что FPC намного лучше, чем g ++?» – igouy