[Prev][Next][Index][Thread]
Re[4]: Dylan performance
Hello oodl,
Monday, January 15, 2001, 2:30:01 PM, you wrote:
omdc> In article <ljg56tg7qhrp1pv43gj203fe0h35q9mj3c@4ax.com>,
omdc> Jason Trenouth <jason@harlequin.co.uk> wrote:
>> On Sun, 14 Jan 2001 16:15:02 -0500 (EST), oodl@my-deja.com wrote:
>>
>> > By the way, when t1 and t2 are defined at the top level like this:
>> >
>> > define constant t1 = make(<float-array>, dimensions: list(300, 300),
>> > fill: 0.0);
>> > define constant t2 = make(<float-array>, dimensions: list(300, 300),
>> > fill: 0.0);
>> >
>> > it is evident from the dispatch coloring, that Function Developer is
>> > not optimizing the array accesses.
>>
>> Try adding " :: <float-array>" to the declarations in the above
>> case. It turns all grey then.
>>
>> __Jason
>>
omdc> But why is the ":: <float-array>" type specification necessary
omdc> for a constant? It seems like the compiler's optimizer should be
omdc> smart enough to figure that out.
yes, you're right. the compiler is in general able to make the type
inference that the result of a make(type, ...) call is an instance of
type where type is a compile-time knowable type. unfortunately, it
appears that some artifact of variable definitions is thwarting this
optimization in this particular case. i'll look into it...
the interesting flip side of this optimization is that user-defined
make methods must return instances of the "derived type" on their
first parameter. for example, the following somewhat artificial make
method will fail with a type error (e.g., 1 is not a <point>) when
called:
define method make (x == <point>, #key x, y) => (res)
1
end method;
despite no user defined return types.
meanwhile, we're still looking into the stack allocation problem. stay
tuned...
jonathan bachrach
Follow-Ups:
References: