龙芯开源社区

 找回密码
 注册新用户(newuser)
楼主: jamesr

压缩、解压测试脚本

  [复制链接]
发表于 2008-7-9 07:06:47 | 显示全部楼层
clovertown单核与PE2140同为CORE2架构,前者是后者的2.6倍的性能,主频2.33:1.60,深刻怀疑测试的可信度??GCC4.1.1与GCC4.2.3

[ 本帖最后由 wshd 于 2008-7-9 07:11 编辑 ]
发表于 2008-7-9 07:24:25 | 显示全部楼层
不懂!?
发表于 2008-7-9 09:04:16 | 显示全部楼层
正在生成32M测试文件...
8192+0 records in
8192+0 records out
33554432 bytes (34 MB) copied, 9.77959 seconds, 3.4 MB/s
测试文件生成完毕,测试开始
系统信息:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm) Proswssor
stepping        : 0
cpu MHz         : 1921.123
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts
bogomips        : 3844.86

Linux version 2.6.18-6-486 (Debian 2.6.18.dfsg.1-18etch1) (waldi@debian.org) (gc c version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Sun Feb 10 22:06:33 UTC 2008
bzip2, a block-sorting file compressor.  Version 1.0.3, 15-Feb-2005.

   Copyright (C) 1996-2005 by Julian Seward.

   This program is free software; you can redistribute it and/or modify
   it under the terms set out in the LICENSE file, which is included
   in the bzip2-1.0 source distribution.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   LICENSE file for more details.

gzip 1.3.5
(2002-09-30)
Copyright 2002 Free Software Foundation
Copyright 1992-1993 Jean-loup Gailly
This program comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
Compilation options:
DIRENT UTIME STDC_HEADERS HAVE_UNISTD_H HAVE_MEMORY_H HAVE_STRING_H HAVE_LSTAT A SMV
Written by Jean-loup Gailly.
bzip2默认压缩,解压:

real    0m26.438s
user    0m25.702s
sys     0m0.356s

real    0m10.098s
user    0m9.653s
sys     0m0.256s

real    0m26.442s
user    0m25.850s
sys     0m0.248s

real    0m9.944s
user    0m9.569s
sys     0m0.216s

real    0m26.417s
user    0m25.774s
sys     0m0.324s

real    0m10.040s
user    0m9.677s
sys     0m0.208s
gzip默认压缩,解压:

real    0m3.290s
user    0m3.000s
sys     0m0.216s

real    0m0.629s
user    0m0.364s
sys     0m0.196s

real    0m3.333s
user    0m3.012s
sys     0m0.232s

real    0m0.626s
user    0m0.376s
sys     0m0.200s

real    0m3.355s
user    0m3.048s
sys     0m0.216s

real    0m0.615s
user    0m0.384s
sys     0m0.180s
测试完毕,删除测试文件
 楼主| 发表于 2008-7-9 09:11:32 | 显示全部楼层

      
2F 800M  gcc 4.2.3
  Tualatin 1G gcc 4.1.2
Athlon 1.92G gcc 4.1.2
bzip2平均压缩CPU时间s
      
83.31362.067
25.775
-log10(时间*主频)越大越好
      
-4.8238
      
-4.7929
      
-4.6945
bzip2平均解压CPU时间s
      
27.077
      
19.404
      
9.663
-log10(时间*主频)越大越好-4.3357
      
-4.2880
      
-4.2684
gzip平均压缩CPU时间s12.929
      
8.380
      
3.020
-log10(时间*主频)越大越好-4.0147
      
-3.9232
      
-3.7633
gzip平均解压CPU时间s1.437
      
0.869
      
0.375
-log10(时间*主频)越大越好-3.0605
      
-2.9390
      
-2.8573
由于x86默认的gcc优化比mips好,等待优化版本的测试。
由于gzip计时较短,相对误差较大。

龙芯推荐优化参数为:-O3 -mips3 -mrename-registers -mno-branch-likely
如果是最新版的gcc 4.4:-O3 -march=loongson2f -mtune=loongson2f
P3推荐优化参数为:-O3 -march=pentium3
Athlon推荐优化参数为:-O3 -march=athlon-4

[ 本帖最后由 jamesr 于 2008-7-9 09:26 编辑 ]
发表于 2008-7-9 09:24:18 | 显示全部楼层
实测结果,该怀疑的不是数据是否造假,而是这个事实该如何解释。好像jamsr的机器装的是32位系统,这个会吃亏一些。此外还不确定的,但是会对此项测试结果产生影响的因素还有内存的性能。要想得到进一步的解释,可能需要对压缩和解压缩profiling一下。不过,目前我们至少确认2F不会比图拉丁奔III 1G差,优化一番之后应该有一定的优势。

原帖由 wshd 于 2008-7-9 07:06 发表
clovertown单核与PE2140同为CORE2架构,前者是后者的2.6倍的性能,主频2.33:1.60,深刻怀疑测试的可信度??GCC4.1.1与GCC4.2.3

[ 本帖最后由 simonxue21 于 2008-7-9 09:25 编辑 ]
 楼主| 发表于 2008-7-9 09:27:50 | 显示全部楼层
原帖由 simonxue21 于 2008-7-9 09:24 发表
实测结果,该怀疑的不是数据是否造假,而是这个事实该如何解释。好像jamsr的机器装的是32位系统,这个会吃亏一些。此外还不确定的,但是会对此项测试结果产生影响的因素还有内存的性能。要想得到进一步的解释, ...


我在怀疑是否不同平台上生产测试文件的算法不一样,那样结果就没有可比性了。
发表于 2008-7-9 09:29:55 | 显示全部楼层
不都是你写的脚本生成的32M文件么?难道你的意思是说“该文件的内容毕竟还是不同的,所以压缩的时候会有差异”?这个有道理。可是我们找到一个共用的32M文件也不好共享啊。
原帖由 jamesr 于 2008-7-9 09:27 发表


我在怀疑是否不同平台上生产测试文件的算法不一样,那样结果就没有可比性了。

[ 本帖最后由 simonxue21 于 2008-7-9 09:31 编辑 ]
发表于 2008-7-9 09:36:07 | 显示全部楼层
原帖由 simonxue21 于 2008-7-9 09:29 发表
不都是你写的脚本生成的32M文件么?难道你的意思是说“该文件的内容毕竟还是不同的,所以压缩的时候会有差异”?这个有道理。可是我们找到一个共用的32M文件也不好共享啊。


网上找一个,大家都下载就可以了。
发表于 2008-7-9 09:44:17 | 显示全部楼层
不用找了,我在硬盘上找了个33M的RAR文件做了testdata的替身,注释掉dd那行,结果与原来一样。
 楼主| 发表于 2008-7-9 09:50:39 | 显示全部楼层
原帖由 simonxue21 于 2008-7-9 09:29 发表
不都是你写的脚本生成的32M文件么?难道你的意思是说“该文件的内容毕竟还是不同的,所以压缩的时候会有差异”?这个有道理。可是我们找到一个共用的32M文件也不好共享啊。


刚才查了一下,这个生成的文件不好,不够公平。
再换一个方法,使用同一个文件。

本版积分规则

小黑屋|手机版|Archiver|Lemote Inc.  

GMT+8, 2019-8-25 03:47 , Processed in 0.186531 second(s), 16 queries .

快速回复 返回顶部 返回列表