http://benchmarksgame.alioth.debian.org/的语言输出基准测试表明,FPC程序使用的内存约为1/50,与使用g++的程序相比较。这些基准是无意中对fpc有利的,还是说FPC真的比g++好得多?我一直认为这些基准是一个体面的微基准的集合,所以我对这些结果感到惊讶,因为50倍的因子是相当重要的IMHO。
参考文献:
http://benchmarksgame.alioth.debian.org/u32/pascal.php http://benchmarksgame.alioth.debian.org/u64q/pascal.html
编辑:--这一点变得更加有趣了,因为这页面声称pascal在某些程序中只使用了8KB,这看起来非常低。
发布于 2012-06-28 19:15:44
请注意,启动时间是IIRC,也是FPC峰值的另一个基准。
我认为必须首先找到答案,因为在默认情况下,Free静态链接程序,避免libc和其他辅助库。
这有几个后果:
总之,我认为这种观察到的行为不是关于FPC的,而是更多关于其他基准开发系统之间缺乏变化的行为。FPC只是与众不同,因为几乎所有的东西都是建立在gcc/glibc技术之上的(要么因为它们是gcc的直接衍生产品,要么是因为它们的VM/解释器是建立在成都之上的),因此它们都共享libc的一般待遇。FPC是不同的,只是突出了(g?)libc对简单程序的错误扩展。(*)
枪战可能存在偏见,因为共享入口空间被计算,而不是实际使用私有字节,或者因为它没有对子分配器分配的私有字节和进程实际使用的私有字节进行足够的区分。但是,可能需要一个libc/libmalloc核心来解决这个问题,而且由于枪战是开源的,所以您能否提供更好的度量的问题是开放的。
或者(g)libc有根本的问题。(我不是这方面的专家)。获取更多相关信息的一个可能的解决方案是在FreeBSD上运行基准测试,或者使用uclibc运行Linux。总之,除了口齿不清之外,什么都没有。
正如Igouy的post所述,在链接到libc时,FPC获得了其他开发系统的(坏)特性。这是另一个应该是的指示:“为什么使用二进制文件的glibc在冲突内存基准测试中表现不好”而不是“为什么FPC在射击测试中表现良好”。
请注意,FPC最初避免libc是因为跨发行版兼容性的考虑,而不是性能或文件大小。
所以,对于所有假设这是一个侥幸的wrt来测量FPC的内存使用情况,是否认为这是一个与glibc内存使用或它的测量的问题?或者更确切地说,高的glibc数是错误的,而不是低的FPC数.
……一个FPC开发者..。
(*)在您说它仅仅是为了“相当大的”应用程序而开发出来之前,请记住,Unix的原理是将小工具链接在一起,并且许多Unix进程的寿命被缩短了。
发布于 2012-06-27 16:01:52
是的,unix实用程序顶部报告说那些Pascal程序使用了那么多内存,而C++程序使用了那么多内存,这确实是事实。
例如,在x64上,当运行自由Pascal n体程序和运行C++ n体程序时,top报告这些度量--
VIRT RES SHR
608 4 0 FPC
7208 420 332 C++免费Pascal程序的内存使用top reports 是免费Pascal程序的 基准测试游戏报告的内存使用。
现在看那个 x64四核比较
我们可以看到两种不同的情况:
这个问题有两种选择,但通常有第三种选择--,我误解了发生了什么吗?
C++ mandelbrot程序可能比Pascal mandelbrot程序占用4000倍的内存,这一事实让OP无法相信,对OP来说,这似乎是不可能的--但有一个足够简单的解释,即时间/空间折衷。
C++程序是多线程的是为使用多核编写的,而Pascal程序是单线程的。则是使用单核编写的。
Pascal多线程mandelbrot程序的内存使用非常类似于C++多线程程序。
https://stackoverflow.com/questions/11225580
复制相似问题