Re: [Gems-users] How is ruby configured?

[mehmetderin.harmanci@xxxxxxx]

 Thanks for the information. I'll try all these.

    Derin Harmanci.





Bravo Daniele! Its great to see Gems users answering gems-users questions =).
Let me make a couple additional comments to each of your questions, Derin.

Daniele Bordes wrote:

>2006/7/25, mehmetderin.harmanci@xxxxxxx <mehmetderin.harmanci@xxxxxxx>:
>
>
>> Hello,
>>
>>   I'm a new GEMS user. I have a few question about the usage of ruby.
>>
>>   1) Is the memory hierarchy configurable in ruby (e.g. can we design a
>>      system with private I & D L1 caches followed by a shared L2 cache
>>      (shared between L1 caches of all processors), similarlarly can we
>>      configure a system with private L1 and L2 caches for each processors?)
>>      If we can configure the systems how is it done? in rubyconfig.defaults?
>>
>>
>>
>
>You can configure memory parameters editing rubyconfig.defaults only
>BEFORE compiling ruby;
>if you use simics, you can change the parameters at run-time by using
>simics commands like this ones:
>
>ruby0.setparam L1_CACHE_ASSOC 12
>ruby0.setparam g_NUM_PROCESSORS 4
>
>and so on...
>
>If you use the tester.exec, you can change only some parameters by
>using some command line options: for instance:
>
>tester.exec -p 8
>
>which set g_NUM_PROCESSORS = 8
>
>Take a look inside /GEMS/ruby/tester/test_framework.C:  you will find
>all command line options you can use to change parameters; obviously,
>you can add command line flags in test_framework.C and recompile ruby
>and the tester.
>
>
Most of the latency, bandwidth, cache size, etc. numbers are controlled by
rubyconfig.defaults and/or subsequent run-time specification of parameters via
ruby.setparam [paramname] [paramval].
However, the exact topology is determined by the "network" parameter. This can
be one of the "built in networks", PT_TO_PT is an example, OR the network can be
"FILE_SPECIFIED", in which case the network is built at runtime by reading a
network input file. These reside in $GEMS/ruby/network/simple/Network_Files, and
can be used as templates to build your own topologies. Unfortunately, I'm not
aware of a great reference on the network files, other than simply staring at
them until they make sense. BUT, you should DEFINATELY check out the WIKI page
that Daniele recommended,

http://www.cs.wisc.edu/gems/doc/wiki/moin.cgi/How_do_I_understand_a_Protocol

>
>
>>    2) I compiled and finally managed to run ruby. However I'm not sure it
>>       works properly. Is there a way to test if it functions properly?
>>       (I compiled the protocol which is pointed in the Documentation -
>>        Quickstart page) Does the tester do this?
>>
>>
>>
>
>At first, I think you should read this:
>
>http://www.cs.wisc.edu/gems/doc/wiki/moin.cgi/How_do_I_understand_a_Protocol
>
>Tester.exec allows you to perform trace-driven simulations; the url
>I've given shows you only two kind of memory operations:  data load
>(LD) and data store (ST); to find other kind of possible operations, I
>think you should find a file containing the definition of
>"string_to_CacheRequestType" function; this function is called in
>TraceRecord::input, and is used to "interpret" the operations (which
>could be LD, ST and many others...) you specify in the trace file.
>
>
The best way to test ruby would be to load a checkpoint within Simics, run for a
few cycles (say, 100000 or so), and have a look at ruby's output, as it shows in
the QuickStart portion of the WIKI. Naturally, you'll need a checkpoint first,
which is quite a chore in itself.

The second best way is to use the tester. After Ruby is built, the tester can be
found in $GEMS/ruby/[platform]/bin/tester.exec ... its various functions are
printed to the command line when invoked with no arguments.

>
>
>>    3) For measuring average memory request latency do we need to add some
>>       extra code or is this already given in the statistics created by
>>       ruby0.dump-stats (I looked into the file but there are many
>>       statistics that I'm not sure of).
>>
>>
>>
>
>
>
No additional code is needed here. All miss latencies are profiled into a
histogram by ruby automatically. Just open up a Ruby .stats file and search for
miss_latency... you should see something like:
 miss_latency: [binsize: 16 max: 2265 count: 1296724 average: 60.9435 .... (etc)

The various latencies are also broken down by access type and cache.

>Well, I think you don't need to add extra code, but I'm not sure; try
>to look inside output files and search for "latency".
>
>I hope this information are useful for you; well, this is all I know,
>surely Gems's Authors will be more and more accurate.
>
>
Regards,
Dan