Changes between Version 3 and Version 4 of WhyDoesNQPGenerateInefficientCode

Show
Ignore:
Timestamp:
11/29/09 07:45:38 (12 years ago)
Author:
cotto
Comment:

better formatting for those of us with non-big screens

Legend:

Unmodified
Added
Removed
Modified
  • WhyDoesNQPGenerateInefficientCode

    v3 v4  
    11{{{ 
    22<pmichaud>  
    3 cotto_work: I do expect to try to generate smarter pir, yes.  However, the structure of Parrot doesn't allow for a lot smarter PIR. 
    4 (I'm hoping parrot will change that... but I don't expect it to happen anytime in the near future.) 
     3cotto_work: I do expect to try to generate smarter pir, yes.  However, the structure of  
     4Parrot doesn't allow for a lot smarter PIR.  (I'm hoping parrot will change that... but  
     5I don't expect it to happen anytime in the near future.) 
    56 
    67<cotto_work> 
     
    1516there's also not a good reference model 
    1617for keeping track of object references 
    17 as a result, the code that nqp generates tends to have to be somewhat pessimistic, such as continually refetching lexical and global symbol tables because of the possibility of a symbol being rebound 
     18as a result, the code that nqp generates tends to have to be somewhat pessimistic, such as continually  
     19refetching lexical and global symbol tables because of the possibility of a symbol being rebound 
    1820 
    1921<cotto_work>  
     
    2123 
    2224<pmichaud> 
    23 cotto_work: I do plan to have an option whereby code can say "assume this lexical/symbol isn't being rebound" 
    24 but since parrot doesn't have a good assignment model, most folks end up doing rebinds 
    25 partcl-nqp just went through this yesterday (until I fixed it this morning) whereby symbols were being re-bound to new PMCs instead of changing the value of an existing multiply-bound PMC 
     25cotto_work: I do plan to have an option whereby code can say "assume this lexical/symbol isn't  
     26being rebound" but since parrot doesn't have a good assignment model, most folks end up doing rebinds 
     27partcl-nqp just went through this yesterday (until I fixed it this morning) whereby symbols were being 
     28re-bound to new PMCs instead of changing the value of an existing multiply-bound PMC 
    2629 
    2730<cotto_work>  
     
    114117 $P2 = box 3 
    115118 copy $P1, $P2    (replace $P1 with $P2) 
    116 but it's horribly inefficient, because it involves making a clone of $P2 and then copying that structure into the PMC header for $P1 
    117 but so far it's about the best we can do 
    118 everything gets worse when we start talking about aggregate access 
    119 because there's not a    copy $P0[0], $P2    opcode yet 
    120 and this leads to allison's comment that it really should be the PMCs/vtables that determine behavior instead of opcodes 
    121 (which is where the model completely breaks down) 
     119but it's horribly inefficient, because it involves making a clone of $P2 and then copying that  
     120structure into the PMC header for $P1 but so far it's about the best we can do everything gets 
     121worse when we start talking about aggregate access because there's not a    copy $P0[0], $P2     
     122opcode yet and this leads to allison's comment that it really should be the PMCs/vtables that determine  
     123behavior instead of opcodes (which is where the model completely breaks down) 
    122124 
    123125<cotto_work>