RichInt#to

On Mon, Jun 29, 2009 at 06:56:53PM +0200, martin odersky wrote:
> I just noted that the step value of RichInt's to method is now a
> default parameter. I am not sure this is a good idea; maybe
> overloading would be better. The problem is that, clearly, Range#to is
> of utmost importance for efficiency. We really need to pull all stops
> to make sure that it's as fast as a C-style for loop. Anything that
> adds dead is to be avoided I think. So, let's implement Range#to(Int)
> with specialized code that does not pass a step value and does not
> test for one.

I think that was my doing.

I am totally in agreement about efficiency here, and my plan was more
along the lines of an AST transformation, which is a big part of why I'm
doing all this DSL work. If desugaring was as easy as I think it could
be, we could write the high level code like high level code and desugar
the range common case to while loops.

Here is the relevant ticket:

http://lampsvn.epfl.ch/trac/scala/ticket/1338

I am doubtful the default parameter has 1% of the performance impact of
the impact of not generating while-loop-like bytecode.

On Jun 29, 2009, at 8:28 PM, Paul Phillips wrote:

> On Mon, Jun 29, 2009 at 06:56:53PM +0200, martin odersky wrote:
>> I just noted that the step value of RichInt's to method is now a
>> default parameter. I am not sure this is a good idea; maybe
>> overloading would be better. The problem is that, clearly, Range#to
>> is
>> of utmost importance for efficiency. We really need to pull all stops
>> to make sure that it's as fast as a C-style for loop. Anything that
>> adds dead is to be avoided I think. So, let's implement Range#to(Int)
>> with specialized code that does not pass a step value and does not
>> test for one.
>
> I think that was my doing.
>
> I am totally in agreement about efficiency here, and my plan was more
> along the lines of an AST transformation, which is a big part of why
> I'm
> doing all this DSL work. If desugaring was as easy as I think it
> could
> be, we could write the high level code like high level code and
> desugar
> the range common case to while loops.

Do you plan to add some sort of meta-programming capabilities to Scala?

> Here is the relevant ticket:
>
> http://lampsvn.epfl.ch/trac/scala/ticket/1338
>
> I am doubtful the default parameter has 1% of the performance impact
> of
> the impact of not generating while-loop-like bytecode.

I think Martin was talking about the optimizer. Last time I checked it
was doing a pretty good job of optimizing ranges, but I don't know if
the default parameter changed that.

iulian

>

On Tue, Jun 30, 2009 at 12:36:41AM +0200, Iulian Dragos wrote:
> Do you plan to add some sort of meta-programming capabilities to Scala?

Yes! But I feel like I need a more robust platform on which to build, so
I don't see it happening until I've made a lot of other progress.

> I think Martin was talking about the optimizer. Last time I checked it
> was doing a pretty good job of optimizing ranges, but I don't know if
> the default parameter changed that.

That leads me to ask, what is the status of -optimise? I don't think
very many people use it, either because it's less safe (?) or because
its existence and merits are not much advertised.

Ticket #1338 reports more than an order of magnitude difference; are you
saying -optimise addresses this?

On Jun 30, 2009, at 1:00 AM, Paul Phillips wrote:

I think Martin was talking about the optimizer. Last time I checked it

was doing a pretty good job of optimizing ranges, but I don't know if

the default parameter changed that.

That leads me to ask, what is the status of -optimise? I don't think
very many people use it, either because it's less safe (?) or because
its existence and merits are not much advertised.

I think -optimise works much better than before, but I don't know how many people use it. We are planning to use the optimized build for releasing 2.8.

Ticket #1338 reports more than an order of magnitude difference; are you
saying -optimise addresses this?

Partially. I just tried the benchmark in that ticket and I get (unoptimised):
Multiply c[400,300] = a[400,350] times b[350,300]
Iterators   1,301,287,000nsLimits      1,243,689,000nsRanges      1,239,402,000nsWhile Loop  159,409,000ns
and optimised:
Multiply c[400,300] = a[400,350] times b[350,300]
Iterators   1,226,402,000nsLimits      249,041,000nsRanges      1,220,880,000nsWhile Loop  163,853,000ns
Only the 'limits' method is significantly improved.. I'm a bit surprised, I'll investigate as I think I used a similar benchmark (matrix multiplication) a few months ago and got good results without storing array lengths to locals.
iulian

--
Paul Phillips      | One way is to make it so simple that there are
Everyman           | obviously no deficiencies. And the other way is to make
Empiricist         | it so complicated that there are no obvious deficiencies.
pp: i haul pills   |     -- Hoare

--Iulian Dragos--http://lamp.epfl.ch/~dragos

I think having a more advanced framework for optimization is n
excellent goal, but it should not detract us form delivering the best
performance now. We just have optimise and specialize working. We
should now do our bets to capitalize on them, and deliver really good
performance. If we can do even better later, great! But let's deliver
some good performance now.

Btw, I really think optimise should be optimize, or else we also have
to change to specialise.

Cheers