Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Drill >> mail # dev >> escape analysis, stack allocation and scalar replacement for ValueHolders for non-primitive types


Copy link to this message
-
Re: escape analysis, stack allocation and scalar replacement for ValueHolders for non-primitive types
Jacques,

I've tested your gist, and it seems that making class EH static helps a lot.
P.S. is it possible to avoid using ValueHolder classes?

like, for projection expression 'col_a + col_b', can we generate evaluator
classes simply as:

int eval(int index) {
  return v1.accessor().get(index) + v2.accessor().get(index);
}
On Sun, Jul 28, 2013 at 9:13 AM, Jacques Nadeau <[EMAIL PROTECTED]> wrote:

> Hey Guys,
>
> I've been working on the right ValueHolder interfaces to avoid object
> allocation inside evaluation loops.  It's easy when we're dealing with
> primitives but becomes more sticky when we're dealing with complex
> types like strings.  There are two reasons I'm focused on this.  The
> first is stack allocation.  The second is scalar replacement.  Stack
> allocation seems to work very well.  However, scalar replacement seems
> slightly less reliable.  I basically modeled three things we'll be
> doing:
>
> - Simple method (with alloc and without -- the current runtime
> evaluation already using this alloc approach)
> - Set (one using multiple parameters, the other using a single object
> that contained primitives)
> - Get (one using multiple methods, one using a passed in object that
> is then populated, the third creating an object inside the get method
> and returning that object)
>
> I had been hoping that the latest JRE was smart enough to do scalar
> replacements across a single method boundary.  It looks like it works
> in most cases.  Strangely, it doesn't seem to work correctly in the
> set(Object) method.  That said, it doesn't seem like that big of a
> deal and just leads me to think that this should be done with multiple
> parameters on the ValueVector.Accessor's.
>
> Thoughts?  I didn't spend a lot of time trying to make this a super
> accurate benchmark so let me know if you think there are holes in my
> benchmark?
>
> Jacques
>
> -----
>
> gist: https://gist.github.com/jacques-n/6096934
>
> ====With Escape Analysis enabled==== (-XX:+UnlockDiagnosticVMOptions
> -XX:MaxDirectMemorySize=4G)
> initial
>         noalloc alloc   ret alloc
> method  523     538
> set     593     788
> get     425     558     424
>
> warmed up
>         noalloc alloc   ret alloc
> method  336     337
> set     261     630
> get     406     379     402
>
> ====No Escape Analysis enabled==== (-XX:+UnlockDiagnosticVMOptions
> -XX:MaxDirectMemorySize=4G -XX:-DoEscapeAnalysis)
> initial
>         noalloc alloc   ret alloc
> method  532     3982
> set     619     1850
> get     429     1985    2096
>
> warmed up
>         noalloc alloc   ret alloc
> method  337     3546
> set     299     1817
> get     414     2133    2038
>
> Run leveraging Oracle JRE 7u25 on a 2.3ghz 2012 Macbook Pro.
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB