Re: [Gems-users] regd. event queue

[Dan Gibson <degibson@xxxxxxxx>]

I would guess that your widget either 1) isn't causing the protocol changes you're expecting or 2) IS changing the state but the transitions aren't in the trace. It depends greatly on how your widget is implemented and what it does.

Regards,
Dan

Dave Z. wrote:

Thank you for your reply, Dan! 

Here is what I cannot understand: I put
g_eventQueue_ptr->getTime() in my magic callback. The
magic callback basically starts a component, which
causes some state transitions. For a particular cache
line, the debug trace shows "X" for state transition.
But the time printed by the magic callback is greater
than X. What does the time difference mean?

Thank you,

Dave


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


---------------------------------
    Dave Z. wrote:  
Thank you for your prompt reply, Dan! I have a few
more questions regarding the
magicinstructions/callbacks.How can I find out the
number of Ruby_cyclesintroduced by magic instructions?
Is it the number ofI-fetches?  
It really depends on a lot of things. The best way I
can think of wouldbe to measure the execution time
with and without the callbacks inplace, and compare
the two. I would expect the difference to be
small,comparable to the number of fetches of the
particular affected i-cacheline.
  
My magic instructions/callbacks start execution ofsome
components I've added to Ruby. Is it possiblethat
there are extra Ruby_cycles observed due to thestart
of components?  
If you explicitly "charge" a penalty for starting your
widget, then youshould expect extra cycles. Otherwise,
there should be no overhead inRuby_cycles due solely
to the starting of a widget (mind you, therecould be
overhead for the mere *presence* of a magic
instruction, as Ioutlined in my earlier response).
  
Thank you,Dave  
Regards,
Dan
  
   --- Dan Gibson <degibson@xxxxxxxx> wrote:  
      
Simultaneous was the implementation goal forsame-cycle
events -- but since Ruby is implemented sequentially
the events,of course, actually execute sequentially.
Events in the "same cycle" aretechnically unordered,
though in practice they are ordered bythe
implementation of the priority heap used by
EventQueue.[Ch].Adding magic instructions and/or
callbacks willaffect 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
toexecute, after all), i-cache behaviour, etc., and
could (very rarely)cause more interesting effects (eg.
perhaps by adding sethi instructions aparticular
PC-relative branch path becomes impossible
toexpress).2) Magic instructions/callbacks definitely
canimpact the behaviour of Ruby (depending on what
your code does in responseto them), which can in turn
affect the observed cycle count.3) Rarely, as a
corollary of #1, addition ofinstructions can affect
entire dynamic executions due to changes in theorder
of synchronization events.Regards,DanDave 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 listGems-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 listGems-users@xxxxxxxxxxx    
    
https://lists.cs.wisc.edu/mailman/listinfo/gems-users 

      
Use Google to search the GEMS Users mailing list
byadding"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
listGems-users@xxxxxxxxxxxxxxxx://lists.cs.wisc.edu/mailman/listinfo/gems-usersUse
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.


    

__________________________________________________
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.