Re: [Gems-users] opal and benchmarks

[Dan Gibson <degibson@xxxxxxxx>]

Hi Sudharsan.

First of all, if I read your script properly, you're issuing the following commands to your target machine:
gzip < gzip.source
magic_call break

This set of commands will run gzip to completion, then issue a magic call to Simics and stop simualtion *after* gzip has finished execution. I assume you want to simulate gzip itself, so you must stop simics before gzip completes. There are two ways to do that:

(1) Add a magic-call to gzip itself -- the WIKI details how to do that. This ensures that you start opal while gzip is running, and you don't simulate a lot of transient effects due to process setup and teardown. Magic calls at gzip's main() function (one at the start, another at the end), would allow you to simulate *only* gzip.

(2) IF you really don't want to change the gzip binary, you can do this instead:
magic_call break
gzip < gzip.source
magic_call break

You'll have to load opal at the first magic call. Thus, opal will simulate the keyboard input, the forking of the gzip process, the opening of the file, the reading from disk, etc. Simulation will stop at the second break. Essentially, you'll simulate the last half of the first magic_call, the process startup and file I/O for gzip, the gzip algorithm itself, the process teardown for gzip, and the first half of the second magic_call.

You should also expect the simulation to be very long-running. I don't know the performance numbers for opal-only, but some users report up to 40,000X SLOWDOWN with GEMS, depending on host machine and target machine. Assuming a meager 10,000X slowdown, 2 seconds of "real execution time" would require around five and a half hours of simulation (these are contrived, ballpark numbers -- again, I don't know how fast opal-only runs). This is another good reason to use option (1) instead of option (2), since simulating process managment takes a long time and is probably not what you want to be studying anyway.

Regards,
Dan

Sudharsan Rangarajan wrote:

Hello,

Im very confused on how to run benchmarks on opal. I am trying to run gzip from SPECint 2000. Ive a binary for SPARC and a magic_call binary.

Since im not going to use ruby, i did not try to warm up caches. Instead i ran the program once as

simics> magic-break-enable

./gzip < ./gzip.source ; magic_call

and then did

simics> write-configuration gzipsol

 

I did not load ruby/opal to do this.

 

I then did

 

simics> read-configuration gzipsol

simics> istc-disable

simics> dstc-disable

simics> instruction-fetch-mode instruction-fetch-trace

simics> load-module opal0

simics> opal0.init

simics> opal0.sim-start "gzip.opal"

simics> opal0.sim-step 10000000000

 

Somethings been running for the last 1 hr, the program runs in a sec or two on a alpha 466Mhz processor that ive.

 

I do not understand the magic_call and the checkpointing. The checkpoint basically holds the state of the machine, and the magic_call just causes a break to simics.

How are we running the simulation? It could be the case only if simics stores a entire history of commands in the checkpoint file. I am new to both simics and gems, some help would be greatly appreciated.

 

Thanks,

Sudharsan

 

 

 

 

 

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.