* There is a general problem with defined? IR. I based this on the ast
compiler which has all defined? logic inlined -- when I started
implementing defined? IR, I couldn't fully follow the logic and so blindly
translated that into IR but when I was 2/3rds done and had figured out the
logic more, I started to realize that there was no reason to have all that
logic inlined rather than have it in a runtime helper library. So, I added
fixmes in IRBuilder to pull out all inlined defined? logic. So, yes, the
IR ought not to have that logic inlined in there. This is not very hard to
rip out -- just needs to be done, and will take some cycles.
* You are also right about the other two observations as well. As for
uncached ivar lookup, this is just a fix that is needed in the impl of
HasDefinedVar instruction. Several IR instructions implement caching logic
... we should go over the others and see which others might benefit from
caching.
* since OpAsgnOr reuses defined? logic (which makes sense), it ends up
creating a string even though all it cares about is a boolean (defined or
not). So, this maybe a sign to propagate some info during IR building so
this can be fixed. Something to revisit to see if we have other similar
situations where IRBuilder needs to track more information as it is
generating IR instrs.
But, I think going forward with the IR2JVM, I like your approach of
continuing to translate the IR to bytecode and highlighting these issues as
you have been. Let us periodically look at pending issues and figure out
what kind of IR fixes might be useful (new instructions, tweaking
instructions, new operands, etc.) that might address multiple concerns.
But, you should not proceed if you run into a major issue or you might be
implementing something that might change quite a bit -- I think we can look
at them as you run into these problems. Where we can fix the IR
immediately (ex: split of def-class instrs y'day), we should do that, but I
think it makes sense for you to get more and more instructions compiled
away so we find the bigger problems sooner than later. My immediate
concern is that sufficient information is getting through to the JIT and/or
the JIT is not having to contort itself generating bytecode. I will feel
better once we get JIT green, even if performance is not upto par with the
current compiler. We can more aggressively go after fixing perf
issues/refactoring once we get there. We are likely to have a more global
picture of gaps that need filling in.
Is it time to start making tasks/tickets somewhere to record some of
these? github/jira/lighthouse? That way, others can pitch in where
feasible, and things are not bottlenecked on me, Tom, or you.
Subbu.
On Sat, Apr 28, 2012 at 5:19 PM, Charles Oliver Nutter
<head...@headius.com>wrote:
> I'm trying to get @foo ||= blah compiling and I'm noticing how
> expensive it is. It does the following questionable operations:
>
> * self.getInstanceVariables().hasInstanceVariable("@foo") // uncached
> ivar lookup every time
> * creating a string for the defined? logic's return value even if it's
> not ever used
> * all of this done in-line rather than in external utiity methods
>
> At the very least the determination of whether to proceed should be a
> utility method rather than embedded inline everywhere.
>
> I'm continuing on with it the way it is, but I thought I should point
> this out. :)
>
> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
