[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] sparc32-linux-user / SPEC 2000 status update
From: |
Vince Weaver |
Subject: |
[Qemu-devel] sparc32-linux-user / SPEC 2000 status update |
Date: |
Thu, 25 Sep 2008 13:16:13 -0400 (EDT) |
Hello
I'm not sure if this list is interested in summaries like this, but I
thought I'd post it.
We currently have 46/48 of the SPEC 2000 benchmarks running under
sparc32-linux-user (on an x86_64 machine). The two benchmarks
that aren't working are (I suspect) due to linux-user syscall
issues, not architectural emulation. To put this in perspective,
as of SVN 4992 only 6 of the benchmarks ran properly.
I counted the retired instruction count on real hardware (a Niagara
T1 system using perfmon2) and compared it against the count given
using Qemu SVN 5306 with my BBV-instrumentation patch applied
(see http://www.csl.cornell.edu/~vince/projects/bbv_research ).
As you can see, the counts given match very closely, in all but
one case by far under 0.1%.
Remaining differences seem to be caused by non-determinism in
the benchmarks themselves, especially with regard to the
virtual memory addresses of memory allocations (you can see
a paper I wrote for way more detail on this issue:
http://www.csl.cornell.edu/~vince/papers/iiswc08/ )
Benchmark HW Perf Counter Qemu % Diff
-------------------- -------------- -------------- -------
253.perlbmk.makerand 1,404,947,767 1,404,994,700 0.0033%
176.gcc.expr 7,438,524,056 7,439,822,058 0.0174%
176.gcc.integrate 7,496,590,557 7,496,932,953 0.0046%
253.perlbmk.perfect 22,090,018,022 22,117,246,402 0.1233%
176.gcc.166 24,096,748,165 24,099,211,420 0.0102%
164.gzip.log 32,220,222,634 32,220,258,877 0.0001%
176.gcc.scilab 38,943,582,033 38,954,242,610 0.0274%
253.perlbmk.535 52,797,417,192 52,812,588,889 0.0287%
179.art.110 55,919,697,739 55,919,809,366 0.0002%
253.perlbmk.704 56,138,421,439 56,155,913,315 0.0312%
252.eon.rushmeier 59,734,334,097 59,754,206,796 0.0333%
179.art.470 61,320,265,673 61,320,378,433 0.0002%
164.gzip.source 64,028,560,356 64,028,627,716 0.0001%
181.mcf 66,952,070,888 66,955,397,677 0.0050%
176.gcc.200 69,304,422,957 69,323,496,419 0.0275%
164.gzip.random 72,129,328,188 72,129,329,697 0.0000%
175.vpr.route 80,003,670,096 80,004,767,633 0.0014%
252.eon.cook 81,546,300,471 81,582,283,446 0.0441%
164.gzip.graphic 84,794,373,750 84,794,614,880 0.0003%
256.bzip2.source 85,705,886,914 85,705,888,072 0.0000%
253.perlbmk.957 93,025,850,757 93,047,199,542 0.0229%
256.bzip2.program 104,202,484,846 104,202,485,985 0.0000%
255.vortex.1 104,232,857,833 104,324,773,140 0.0882%
252.eon.kajiya 105,264,967,103 105,318,413,139 0.0508%
253.perlbmk.850 107,063,868,164 107,084,662,958 0.0194%
255.vortex.2 112,156,726,713 112,244,643,448 0.0784%
175.vpr.place 115,176,477,366 115,176,656,963 0.0002%
255.vortex.3 116,025,640,113 116,128,639,345 0.0888%
256.bzip2.graphic 120,800,611,046 120,800,612,184 0.0000%
164.gzip.program 123,680,369,194 123,680,901,121 0.0004%
183.equake 151,889,001,382 151,891,686,411 0.0018%
186.crafty 206,305,279,572 206,315,053,194 0.0047%
254.gap 210,517,827,839 210,558,299,855 0.0192%
171.swim 240,514,963,796 240,515,886,318 0.0004%
189.lucas 266,811,475,823 266,811,478,992 0.0000%
300.twolf 305,337,539,213 305,339,039,589 0.0005%
191.fma3d 341,030,439,528 341,075,610,275 0.0132%
168.wupwise 341,661,289,809 341,661,294,714 0.0000%
177.mesa 346,548,676,244 346,551,169,132 0.0007%
188.ammp 349,598,884,109 349,606,001,911 0.0020%
197.parser 355,866,671,084 356,177,932,828 0.0875%
178.galgel 384,843,413,509 384,843,478,318 0.0000%
301.apsi 404,410,763,702 404,412,372,555 0.0004%
173.applu 483,553,093,892 483,553,210,988 0.0000%
172.mgrid 523,649,830,576 523,650,635,035 0.0002%
200.sixtrack 531,777,045,890 531,779,537,683 0.0005%
BROKEN
------
253.perlbmk.diffmail 32,527,608,598 SEGFAULT -100.0000%
This is due to a known bug in Qemu where the memremap() syscall
will return an address with more than 32-bits even if the system
we are simulating is only a 32-bit systemm.
187.facerec 326,679,452,956 SEGFAULT -100.0000%
This is possibly due to the fact that facerec does a mind-boggling
huge amount of mmap() calls. Still tracking this down, but it happens
45 minutes into the benchmark run so a bit annoying to track down.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] sparc32-linux-user / SPEC 2000 status update,
Vince Weaver <=