Re: [v8-users] Performance of method lookups via prototypes
Great information, thanks so much.
It would be super-cool if v8 could use cleanly-structured prototype chains
to do fast property lookups. If I understand correctly, the potential would
be for the performance of this sort of method lookup to be somewhat
comparable to lookup of overridden methods in Java -- something worth
looking forward to.
Cheers,
Cris
On Thu, Aug 29, 2013 at 10:31 AM, Toon Verwaest wrote:
> So exactly in that you will not get speedup with the _current_ system.
>
> Since the prototypes are different objects, the receivers will have
> different maps. That means you are doing a polymorphic call. In Crankshaft
> we have an optimization that tries to handle those cases as if they were
> monomorphic, but only if the prototype object of all maps is exactly the
> same object. See line src/hydrogen.cc:6054:
> 6039 bool HOptimizedGraphBuilder::TryCallPolymorphicAsMonomorphic(
> ...
> 6051 for (int count = 1; count < types->length(); ++count) {
> 6052 Handle test_map(types->at(count));
> 6053 if (!CanLoadPropertyFromPrototype(test_map, name, &lookup))
> return false;
> 6054 if (test_map->prototype() != *prototype) return false;
> 6055 }
>
> We could in the future extend this to do exactly what you suggest
> (probably fairly easily); but it's not there right now.
>
> regards,
> Toon
>
>
> On Thu, Aug 29, 2013 at 6:53 PM, Cris Perdue wrote:
>
>> Toon, Jacob,
>>
>> Thank you both for your interest in the subject and and taking time to
>> respond.
>>
>> I am encouraged by some of your comments, in particular Toon's that
>> receiver code can be optimized (presumably when "this" is of the same
>> hidden class in all calls); and Jacob's comment that what applies to
>> objects also applies to prototypes.
>>
>> For what it's worth, my application uses trees of expressions of
>> different types (classes), with recursive methods that walk over those
>> trees, so the recursive methods cannot generally be inlined in any case.
>>
>> To be more specific about my optimization question, I am imagining that
>> object property lookups, including method lookups, may be inlined when a
>> variable always has the same hidden class. (I understand that the method
>> body would not be inlined.) I am further hoping that the good performance
>> of method lookups can extend to situations where the method is a property
>> of the prototype(s), even when receivers can have different prototypes,
>> provided that each prototype is built with the same properties, added in
>> the same order, so hopefully having the same hidden class.
>>
>> The recommendation to measure of course is always a sound one. I am
>> hoping you all may be able to help me avoid spending my time on experiments
>> that pursue optimizations that do not exist.
>>
>> Best regards,
>> Cris
>>
>>
>> On Wed, Aug 28, 2013 at 1:29 AM, Jakob Kummerow
>> wrote:
>>
>>> As always: when in doubt, measure it! Implement several approaches (in a
>>> simplified version of your app if necessary) and see for yourself if any of
>>> the options you're considering makes a difference.
>>>
>>> Generally I would say that what applies to objects also applies to
>>> prototypes (as they're objects too), but your question is too vague to even
>>> try to give a precise answer. As Toon said, the key idea that we keep
>>> emphasizing is to keep code monomorphic, but you stated that your code
>>> relies on polymorphism, so much of the battle is already lost anyway.
>>> As for inlining, that's generally at odds with polymorphism -- when you
>>> don't know where a call is going, how can you possibly inline it? (Well,
>>> you can, but you have to inline all possible targets, which makes it a much
>>> tougher tradeoff.) Maybe it doesn't matter if your bottleneck is elsewhere?
>>>
>>>
>>> On Tue, Aug 27, 2013 at 7:50 PM, Toon Verwaest wrote:
>>>
Such optimizations are only true for receivers. If you have different
prototypes all over the place, your code is going is not going to stay
monomorphic. For every distinct prototype there's at least unique hidden
class; given that the prototype link is hardwired in the hidden class.
regards,
Toon
On Tue, Aug 27, 2013 at 6:40 PM, Cris Perdue wrote:
> Performance optimization advice from the V8 team emphasizes
> initializing properties to objects in constructors, and always in the same
> order (for example http://www.youtube.com/watch?v=UJPdhx5zTaw). The
> explanation is that this way each instance belongs to the same hidden
> class.
>
> What if you have fairly computation-intensive code that uses
> subclassing and polymorphism? In this case method lookups need to go
> through the prototype object for the instances. Once execution gets to the
> type-specific method, life should be good again because that code always
> receives a "this" and arguments of the same type at each invocation. (The
> type-specific method code is typicall
[v8-users] Re: New feature: handle eternalization
> > > I think something is broken in the new Eternal API. > This example code block fails to compile. > Seems ObjectTemplate is missing a Cast method? > > Yep. I'll fix it tomorrow. Thanks for the report. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [v8-users] Performance of method lookups via prototypes
So exactly in that you will not get speedup with the _current_ system.
Since the prototypes are different objects, the receivers will have
different maps. That means you are doing a polymorphic call. In Crankshaft
we have an optimization that tries to handle those cases as if they were
monomorphic, but only if the prototype object of all maps is exactly the
same object. See line src/hydrogen.cc:6054:
6039 bool HOptimizedGraphBuilder::TryCallPolymorphicAsMonomorphic(
...
6051 for (int count = 1; count < types->length(); ++count) {
6052 Handle test_map(types->at(count));
6053 if (!CanLoadPropertyFromPrototype(test_map, name, &lookup)) return
false;
6054 if (test_map->prototype() != *prototype) return false;
6055 }
We could in the future extend this to do exactly what you suggest (probably
fairly easily); but it's not there right now.
regards,
Toon
On Thu, Aug 29, 2013 at 6:53 PM, Cris Perdue wrote:
> Toon, Jacob,
>
> Thank you both for your interest in the subject and and taking time to
> respond.
>
> I am encouraged by some of your comments, in particular Toon's that
> receiver code can be optimized (presumably when "this" is of the same
> hidden class in all calls); and Jacob's comment that what applies to
> objects also applies to prototypes.
>
> For what it's worth, my application uses trees of expressions of different
> types (classes), with recursive methods that walk over those trees, so the
> recursive methods cannot generally be inlined in any case.
>
> To be more specific about my optimization question, I am imagining that
> object property lookups, including method lookups, may be inlined when a
> variable always has the same hidden class. (I understand that the method
> body would not be inlined.) I am further hoping that the good performance
> of method lookups can extend to situations where the method is a property
> of the prototype(s), even when receivers can have different prototypes,
> provided that each prototype is built with the same properties, added in
> the same order, so hopefully having the same hidden class.
>
> The recommendation to measure of course is always a sound one. I am hoping
> you all may be able to help me avoid spending my time on experiments that
> pursue optimizations that do not exist.
>
> Best regards,
> Cris
>
>
> On Wed, Aug 28, 2013 at 1:29 AM, Jakob Kummerow wrote:
>
>> As always: when in doubt, measure it! Implement several approaches (in a
>> simplified version of your app if necessary) and see for yourself if any of
>> the options you're considering makes a difference.
>>
>> Generally I would say that what applies to objects also applies to
>> prototypes (as they're objects too), but your question is too vague to even
>> try to give a precise answer. As Toon said, the key idea that we keep
>> emphasizing is to keep code monomorphic, but you stated that your code
>> relies on polymorphism, so much of the battle is already lost anyway.
>> As for inlining, that's generally at odds with polymorphism -- when you
>> don't know where a call is going, how can you possibly inline it? (Well,
>> you can, but you have to inline all possible targets, which makes it a much
>> tougher tradeoff.) Maybe it doesn't matter if your bottleneck is elsewhere?
>>
>>
>> On Tue, Aug 27, 2013 at 7:50 PM, Toon Verwaest wrote:
>>
>>> Such optimizations are only true for receivers. If you have different
>>> prototypes all over the place, your code is going is not going to stay
>>> monomorphic. For every distinct prototype there's at least unique hidden
>>> class; given that the prototype link is hardwired in the hidden class.
>>>
>>> regards,
>>> Toon
>>>
>>>
>>> On Tue, Aug 27, 2013 at 6:40 PM, Cris Perdue wrote:
>>>
Performance optimization advice from the V8 team emphasizes
initializing properties to objects in constructors, and always in the same
order (for example http://www.youtube.com/watch?v=UJPdhx5zTaw). The
explanation is that this way each instance belongs to the same hidden
class.
What if you have fairly computation-intensive code that uses
subclassing and polymorphism? In this case method lookups need to go
through the prototype object for the instances. Once execution gets to the
type-specific method, life should be good again because that code always
receives a "this" and arguments of the same type at each invocation. (The
type-specific method code is typically fairly short and quick to execute in
my software.)
My question is, to what degree should we expect a similar principle to
apply, that prototypes for subclasses should have the same members and the
members should be added to each subclass in the same order? Will this make
the compiler recognize the prototypes as belonging to the same hidden class
and make a big contribution to fast method lookup? Will method lookup code
tend to be inlined? Is it OK that the prototypes are all directly instanc
[v8-users] Re: New feature: handle eternalization
Dan, I think something is broken in the new Eternal API. This example code block fails to compile. Seems ObjectTemplate is missing a Cast method? Eternal eternal; Local tmplXFile; tmplXFile = eternal.Get(pIsolate); eternal.Set(pIsolate, tmplXFile); V8\include\v8.h(406) : error C2039: 'Cast' : is not a member of 'v8::ObjectTemplate' V8\include\v8.h(3455) : see declaration of 'v8::ObjectTemplate' V8\include\v8.h(5697) : see reference to function template instantiation 'v8::Local v8::Local::Cast(v8::Local)' being compiled with [ T=v8::ObjectTemplate ] V8\include\v8.h(5696) : while compiling class template member function 'v8::Local v8::Eternal::Get(v8::Isolate *)' with [ T=v8::ObjectTemplate ] .\RXFile.cpp(452) : see reference to class template instantiation 'v8::Eternal' being compiled with [ T=v8::ObjectTemplate ] V8\include\v8.h(406) : error C2784: 'v8::Local v8::Local::Cast(v8::Local)' : could not deduce template argument for 'v8::Local' from 'v8::Value *' with [ T=v8::ObjectTemplate ] V8\include\v8.h(400) : see declaration of 'v8::Local::Cast' with [ T=v8::ObjectTemplate ] V8\include\v8.h(6285) : error C2440: 'static_cast' : cannot convert from 'v8::ObjectTemplate *' to 'v8::Value *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast V8\include\v8.h(5691) : see reference to function template instantiation 'v8::Value *v8::Value::Cast(T *)' being compiled with [ T=v8::ObjectTemplate ] .\RXFile.cpp(455) : see reference to function template instantiation 'void v8::Eternal::Set(v8::Isolate *,v8::Local)' being compiled with [ T=v8::ObjectTemplate ] -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [v8-users] Performance of method lookups via prototypes
Toon, Jacob, Thank you both for your interest in the subject and and taking time to respond. I am encouraged by some of your comments, in particular Toon's that receiver code can be optimized (presumably when "this" is of the same hidden class in all calls); and Jacob's comment that what applies to objects also applies to prototypes. For what it's worth, my application uses trees of expressions of different types (classes), with recursive methods that walk over those trees, so the recursive methods cannot generally be inlined in any case. To be more specific about my optimization question, I am imagining that object property lookups, including method lookups, may be inlined when a variable always has the same hidden class. (I understand that the method body would not be inlined.) I am further hoping that the good performance of method lookups can extend to situations where the method is a property of the prototype(s), even when receivers can have different prototypes, provided that each prototype is built with the same properties, added in the same order, so hopefully having the same hidden class. The recommendation to measure of course is always a sound one. I am hoping you all may be able to help me avoid spending my time on experiments that pursue optimizations that do not exist. Best regards, Cris On Wed, Aug 28, 2013 at 1:29 AM, Jakob Kummerow wrote: > As always: when in doubt, measure it! Implement several approaches (in a > simplified version of your app if necessary) and see for yourself if any of > the options you're considering makes a difference. > > Generally I would say that what applies to objects also applies to > prototypes (as they're objects too), but your question is too vague to even > try to give a precise answer. As Toon said, the key idea that we keep > emphasizing is to keep code monomorphic, but you stated that your code > relies on polymorphism, so much of the battle is already lost anyway. > As for inlining, that's generally at odds with polymorphism -- when you > don't know where a call is going, how can you possibly inline it? (Well, > you can, but you have to inline all possible targets, which makes it a much > tougher tradeoff.) Maybe it doesn't matter if your bottleneck is elsewhere? > > > On Tue, Aug 27, 2013 at 7:50 PM, Toon Verwaest wrote: > >> Such optimizations are only true for receivers. If you have different >> prototypes all over the place, your code is going is not going to stay >> monomorphic. For every distinct prototype there's at least unique hidden >> class; given that the prototype link is hardwired in the hidden class. >> >> regards, >> Toon >> >> >> On Tue, Aug 27, 2013 at 6:40 PM, Cris Perdue wrote: >> >>> Performance optimization advice from the V8 team emphasizes initializing >>> properties to objects in constructors, and always in the same order (for >>> example http://www.youtube.com/watch?v=UJPdhx5zTaw). The explanation is >>> that this way each instance belongs to the same hidden class. >>> >>> What if you have fairly computation-intensive code that uses subclassing >>> and polymorphism? In this case method lookups need to go through the >>> prototype object for the instances. Once execution gets to the >>> type-specific method, life should be good again because that code always >>> receives a "this" and arguments of the same type at each invocation. (The >>> type-specific method code is typically fairly short and quick to execute in >>> my software.) >>> >>> My question is, to what degree should we expect a similar principle to >>> apply, that prototypes for subclasses should have the same members and the >>> members should be added to each subclass in the same order? Will this make >>> the compiler recognize the prototypes as belonging to the same hidden class >>> and make a big contribution to fast method lookup? Will method lookup code >>> tend to be inlined? Is it OK that the prototypes are all directly instances >>> of Object, and not some application-specific class? >>> >>> Thanks much for any insights here. >>> >>> -Cris >>> >> -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to a topic in the > Google Groups "v8-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/v8-users/Heqrs8ob3n4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[v8-users] Re: New feature: handle eternalization
> > No extra object to keep around. Once the Local is saved as an eternal I > can get it back with a simple hash lookup (GetEternal()) > > Local local = Local::GetEternal(isolate, > MY_OBJECT_TEMPLATE_ID ); > > How does that sound? > > The index is isolate specific and v8 itself uses some internally, so the value of the index cannot be exposed. It's better than keeping a persistent around for cases where access times matter. Getting a Local from an Eternal is very fast. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
