Home | About | Sematext search-lucene.com search-hadoop.com
 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
Lisen Mu 2013-07-28, 15:34
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.
>