Re: [Gems-users] Collecting Ruby stats for TM

[Jayaram Bobba <bobba@xxxxxxxxxxx>]

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

Dan Gibson wrote:
> These aren't the transactions you're looking for.
>
> The transaction stats you are looking at are stats for 'workload' 
> transactions, not 'transactional memory' transactions. Admittedly, the 
> stat is badly named, but was badly named before the TM craze, so it 
> wasn't changed post-craze.
> In the past, we have modified workloads to notify Ruby that progress 
> is being made through special 'magic' instructions that signal 
> 'transaction' boundaries (e.g., DB transaction boundaries, requests 
> serviced in HTTP servers, etc.) or outer-loop iterations (in 
> scientific workloads). Since your workload isn't executing any of 
> these 'workload transactions', your profiling of this flavor of 
> 'transaction' reads as zero. These transactions are totally unrelated 
> to TM transactions.
> Look around at the LogTM stats (I have no idea what they are named, 
> sorry) to find the transactions you're looking for.
> Regards,
> Dan
>
> On Sun, Nov 29, 2009 at 10:31 PM, Polina Dudnik <pdudnik@xxxxxxxxx 
> <mailto:pdudnik@xxxxxxxxx>> wrote:
>     Turn on all the debugging and make sure that your profiling flags
>     are also on. If you turn on the debugging you should see the print
>     out that says execution is in begin transaction, end transaction
>     and so forth. Make sure that transactional mode is enabled and you
>     are using the correct protocol (MESI_CMP_filter_directory).
>
>     On Sun, Nov 29, 2009 at 10:32 PM, Jiří Šimša <jiri.simsa@xxxxxxxxx
>     <mailto:jiri.simsa@xxxxxxxxx>> wrote:
>
>         Hello,
>
>         I was able to get the deque microbenchmark to run on a 4
>         processor Simics checkpoint. Next, I tried collecting
>         information about the use of transactions using Ruby as follows:
>
>         I started Simics with my checkpoint that has the binary of
>         deque_TM loaded in and everything is ready to be run.
>         Next, I did the following in Simics:
>         simics> instruction-fetch-mode instruction-fetch-trace;
>         dstc-disable; istc-disable; cpu-switch-time 1; load-module ruby
>         [cpu0 info] Note that on this cpu, instruction-fetch-trace is
>         implemented using instruction-cache-access-trace with a
>         suitable cache line size.
>         [cpu1 info] Note that on this cpu, instruction-fetch-trace is
>         implemented using instruction-cache-access-trace with a
>         suitable cache line size.
>         [cpu4 info] Note that on this cpu, instruction-fetch-trace is
>         implemented using instruction-cache-access-trace with a
>         suitable cache line size.
>         [cpu5 info] Note that on this cpu, instruction-fetch-trace is
>         implemented using instruction-cache-access-trace with a
>         suitable cache line size.
>         Turning D-STC off and flushing old data
>         Turning I-STC off and flushing old data
>         The switch time will change to 1 cycles (for CPU-0) once all
>         processors have synchronized.
>         successful installation of the ruby timing model.
>         simics> ruby0.setparam g_NUM_PROCESSORS 4
>         simics> ruby0.init
>
>         Then I ran the benchmark.
>
>         Finally, I dumped the stats using ruby0.dump_short_stats.
>         Producing:
>
>         simics> ruby0.dump-short-stats
>
>         SHORT Profiler Stats
>         --------------
>         Virtual_time_in_seconds: 878.31
>         Virtual_time_in_minutes: 14.6385
>         Virtual_time_in_hours:   0.243975
>         Virtual_time_in_days:    0.243975
>
>         Ruby_current_time: 24374620
>         Ruby_start_time: 1
>         Ruby_cycles: 24374619
>
>         Total_misses: 160366
>         total_misses: 160366 [ 9456 2310 1851 146749 ]
>         user_misses: 12822 [ 617 529 548 11128 ]
>         supervisor_misses: 147544 [ 8839 1781 1303 135621 ]
>
>         instruction_executed: 83469212 [ 24984755 25572397 25627341
>         7284719 ]
>         simics_cycles_executed: 389994915 [ 97498479 97498479 97498479
>         97499478 ]
>         cycles_per_instruction: 1.16808 [ 0.97558 0.953161 0.951118
>         3.34599 ]
>         misses_per_thousand_instructions: 1.92126 [ 0.378471 0.0903318
>         0.0722275 20.1448 ]
>
>         transactions_started: 0 [ 0 0 0 0 ]
>         transactions_ended: 0 [ 0 0 0 0 ]
>         instructions_per_transaction: 0 [ 0 0 0 0 ]
>         cycles_per_transaction: 0 [ 0 0 0 0 ]
>         misses_per_transaction: 0 [ 0 0 0 0 ]
>
>         ...
>
>         Anyone could explain to me why is the information about
>         transactions missing? Is there a simple check that I can run
>         to see if the transactional memory subsystem is actually used?
>         Thanks!
>
>         Best,
>
>         -- 
>         Jiri Simsa
>         Ph.D. Student
>         Carnegie Mellon University
>
>         _______________________________________________
>         Gems-users mailing list
>         Gems-users@xxxxxxxxxxx <mailto: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.
>
>
>
>
>     _______________________________________________
>     Gems-users mailing list
>     Gems-users@xxxxxxxxxxx <mailto: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.
>
>
>
>
>
> --
> http://www.cs.wisc.edu/~gibson <http://www.cs.wisc.edu/%7Egibson> 
> [esc]:wq!
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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.
>
>