Re: [Gems-users] Question about execution slowdown due to Ruby

[Mike Marty <mikem@xxxxxxxxxxx>]

FYI-- I ran a few 16-processor SpecJBB simulations tonight with Simics
2.0.23 and Simics 3.0.11

The slowdown when running Simics 2.0.23+Ruby, compared with Simics 2.0.23
without Ruby, was 42x.

The slowdown when running Simics 3.0.11+Ruby compared to Simics
2.0.23+Ruby was 1.15x

--Mike

> Thanks for the info, I will try the sarek target and see what sort of
> slowdowns I see.
>
> Mark
>
> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx]
> On Behalf Of Mike Marty
> Sent: Friday, December 01, 2006 5:40 PM
> To: 'Gems Users'
> Subject: Re: [Gems-users] Question about execution slowdown due to Ruby
>
> Mark,
>
> A couple years ago we collected these slowdown numbers with Simics 2.0.x
> running the Sarek target (I believe):
>
> http://www.cs.wisc.edu/gems/isca_tutorial.ppt#79
>
> --Mike
>
> > -----Original Message-----
> > From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> > bounces@xxxxxxxxxxx] On Behalf Of Mark Gebhart
> > Sent: Friday, December 01, 2006 5:06 PM
> > To: Gems Users
> > Subject: Re: [Gems-users] Question about execution slowdown due to Ruby
> >
> > Mike,
> >
> > Is there a particular target you have experience with so that I could try
> > that and compare results to what you have seen?
> >
> > Thanks for the help,
> > Mark
> >
> > On Fri, 1 Dec 2006, Mike Marty wrote:
> >
> > > Still, I think Mark's Ruby slowdown seems at least an order of magnitude
> > too
> > > much.  Can you try a different target besides cashew?
> > >
> > > --Mike
> > >
> > >
> > >> -----Original Message-----
> > >> From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-
> > >> bounces@xxxxxxxxxxx] On Behalf Of Dan Gibson
> > >> Sent: Friday, December 01, 2006 4:48 PM
> > >> To: Gems Users
> > >> Subject: Re: [Gems-users] Question about execution slowdown due to Ruby
> > >>
> > >> Mark,
> > >>
> > >> We've actually looked extensively at this.
> > >>
> > >> Background: the 10x number is for a much earlier version of Simics
> > >> (pre-2.0 if I am not mistaken) and an earlier version of Ruby, with
> > >> cpu-switch-time 1000. 10x is about right for the timing of the
> > >> Tourmaline functional simulator... Ruby is now much slower relative to
> > >> Simics... because:
> > >>
> > >> Firstly, Simics 3+ runs in "fast" mode by default, whereas Simics 2.X
> > >> and earlier ran in "stall" mode by default. For that and due to other
> > >> optimizations, Simics 3+ is significantly faster than Simics 2.X in
> > >> standalone mode (eg without timing modules).
> > >>
> > >> Second, I'm not entirely familiar with the cashew target... (not
> > >> familiar at all, in fact). There might be something to do with that
> > >> particular target that creates slowdown.
> > >>
> > >> Third, the majority of the added slowdown actually occurs *within
> > >> Simics*, not within Ruby. We discovered this when when profiling Ruby's
> > >> execution time. Our theory is that Simics behaves differently when
> > alien
> > >> modules (eg Ruby) are installed. Moreover, Simics does not easily
> > >> optimize stall times of large sizes. You can test this theory yourself
> > >> by building a trivial timing module and examining its behavior. The
> > best
> > >> performance we ever attained with a trivial timing module was around
> > 10x
> > >> for Simics 2.0.x, around 30x for Simics 2.2.x, and around 100x for
> > >> Simics 3.0, both with 0-cycle memory accesses.
> > >>
> > >> There are a few things you can do to improve your simulator
> > performance:
> > >> 1) Limit Simics' memory to just below the available space of your host.
> > >> set-memory-limit is the appropriate simics command
> > >> 2) Set cpu-switch-time to something large... this sacrifices some
> > >> fidelity.
> > >> 3) Use smaller latencies -- host execution time is roughly proportional
> > >> to target execution time.
> > >>
> > >>
> > >> Regards,
> > >> Dan Gibson
> > >>
> > >> Mark Gebhart wrote:
> > >>> Hi,
> > >>>
> > >>> I am running some tests using MOSI_SMP_bcast with a 4 processor target
> > >>> machine using cashew-common.simics.  I have set the memory size in
> > both
> > >> Ruby
> > >>> and the simics config file to 4 GB.
> > >>>
> > >>> I wrote a short vector add test program and compared the time to
> > >> simulate on
> > >>> simics with and without Ruby loaded.  Ruby+simics is between 2000 and
> > >> 3000
> > >>> times slower than just simics.  I changed all of the cache latencies
> > to
> > >> be 1
> > >>> cycle and then Ruby+simcs was between 200 and 300 times slower than
> > just
> > >>> simcs.  Are these slowdowns in line with what others have observed?  I
> > >> saw
> > >>> in an archived message on this list that perhaps a slowdown closer to
> > >> 10x
> > >>> would be expected.
> > >>>
> > >>> I am using simics 3.0-22 and GEMS 1.3, my host machine is a 2.8 GHZ P4
> > >> with
> > >>> 1G of RAM and nothing else running during simulation.   The simics
> > >> process
> > >>> stays at 100% utilization throughout the execution.
> > >>>
> > >>> I have compiled Ruby with the following optimization flags:
> > >>> -O2 -finline-functions -DNO_VECTOR_BOUNDS_CHECKS -
> > >> DMULTIFACET_NO_OPT_WARN
> > >>>
> > >>> I use the -stall flag to simics and then issue the following commands:
> > >>>
> > >>> read-configuration ../../checkpoints-u3/linux-a.out-sun-4p.check
> > >>> instruction-fetch-mode instruction-fetch-trace
> > >>> istc-disable
> > >>> dstc-disable
> > >>> cpu-switch-time 1
> > >>> load-module ruby
> > >>> ruby0.setparam g_NUM_PROCESSORS 4
> > >>> ruby0.init
> > >>> con0.input "/usr/mark/a.out\n"
> > >>> c
> > >>>
> > >>> Did I perhaps misconfigure something that is causing a large slowdown?
> > >> Any
> > >>> insight or advice would be greatly appreciated.
> > >>>
> > >>> Thanks,
> > >>> Mark
> > >>>
> > >>> _______________________________________________
> > >>> 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.
> > >>>
> > >>>
> > >>
> > >> --
> > >> http://www.cs.wisc.edu/~gibson [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.
> > >
> > >
> > > _______________________________________________
> > > 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.
> > >
> > _______________________________________________
> > 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.
>
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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.
>