Re: [Gems-users] regd. event queue

[Dan Gibson <degibson@xxxxxxxx>]

Dave Z. wrote:

Thank you for your prompt reply, Dan! 

I have a few more questions regarding the magic
instructions/callbacks.

How can I find out the number of Ruby_cycles
introduced by magic instructions? Is it the number of
I-fetches?
  

It really depends on a lot of things. The best way I can think of would be to measure the execution time with and without the callbacks in place, and compare the two. I would expect the difference to be small, comparable to the number of fetches of the particular affected i-cache line.

My magic instructions/callbacks start execution of
some components I've added to Ruby. Is it possible
that there are extra Ruby_cycles observed due to the
start of components?
  

If you explicitly "charge" a penalty for starting your widget, then you should expect extra cycles. Otherwise, there should be no overhead in Ruby_cycles due solely to the starting of a widget (mind you, there could be overhead for the mere *presence* of a magic instruction, as I outlined in my earlier response).

Thank you,

Dave
  

Regards,
Dan

   

--- Dan Gibson <degibson@xxxxxxxx> wrote:

  

Simultaneous was the implementation goal for
same-cycle events -- but 
since Ruby is implemented sequentially the events,
of course, actually 
execute sequentially. Events in the "same cycle" are
technically 
unordered, though in practice they are ordered by
the implementation of 
the priority heap used by EventQueue.[Ch].

Adding magic instructions and/or callbacks will
affect the number of 
observed Ruby_cycles, in the following ways:
1) Addition of a sethi instruction (eg. magic call)
changes the 
execution path ( a sethi takes at least a cycle to
execute, after all), 
i-cache behaviour, etc., and could (very rarely)
cause more interesting 
effects (eg. perhaps by adding sethi instructions a
particular 
PC-relative branch path becomes impossible to
express).
2) Magic instructions/callbacks definitely can
impact the behaviour of 
Ruby (depending on what your code does in response
to them), which can 
in turn affect the observed cycle count.
3) Rarely, as a corollary of #1, addition of
instructions can affect 
entire dynamic executions due to changes in the
order of synchronization 
events.

Regards,
Dan

Dave Z. wrote:
    

Hello,

Does the event queue trigger simultaneous events?
      

Or
    

everything takes place sequentially?

Would the addition of magic instructions and
      

callbacks
    

increase Ruby cycles?

Thanks,

Dave

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
      

protection around 
    

http://mail.yahoo.com 
_______________________________________________
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.


    

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
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.