On Wed, May 22, 2013 at 10:22 AM, Craig DeForest
<[email protected]> wrote:
> Chris, is your vision of the precompilation a complete compilation to Perl 
> byte-code?  Or just to complete the source filter parse step?  If the former, 
> it might also be useful to have the latter available as well.

This would be the source filtered code saved in a .pmc file.
See Module::Compile for context.

> Another useful direction to go might be to create a highly Hamming-optimized 
> alias for the revised nslice -- say "s" -- so that one could say
>
>         $a->s(5,pdl(5,6,7),[-1,1,-1])
>
> That strikes a nice balance between the full NiceSlice syntax (which I like a 
> lot, but which appears to be quite slow with the more robust newer 
> implementation) and the crazy slice syntax. What do you think?

I think it would be case of premature optimization.  The
Filter::Simple based PDL::NiceSlice filter is brute force
and slow because it checks every single line in the file.
The pre-conversion step addresses that problem.

It is also possible to optimize the processing by looking
for candidates for PDL::NiceSlice filtering in the file and
only doing the full filtering in context of those lines.  But,
I think that time would be better spent in other PDL3 work.

--Chris

> On May 22, 2013, at 8:16 AM, Chris Marshall <[email protected]> wrote:
>
>> There are two issues with PDL::NiceSlice performance:
>>
>> (1) compile time with the source filter
>> (2) execution time (it calls nslice() under the hood)
>>
>> Part of the PDL::NiceSlice work in progress and planned
>> to be completed for PDL3 is the ability to pre-compile
>> source files which avoids compile time delays which
>> can be significant for large source files.
>>
>> The second part is the rework of nslice() to not call
>> slice() to do its work.  In fact, it seems more reasonable
>> to have slice() call nslice().
>>
>> --Chris
>>
>>
>> On Wed, May 22, 2013 at 4:19 AM, Kaj Wiik <[email protected]> wrote:
>>> First, I was forced to use Matlab for a while (I used it before moving
>>> perl and PDL). I had forgotten how cubersome it is to express
>>> algorithms compared to PDL. Cheers to all PDL developers!!
>>>
>>> While ago (indeed with using Devel::NYTProf) I noticed that ->slice()
>>> is much faster than NiceSlice and nslice:
>>>
>>> use PDL;
>>> use PDL::NiceSlice;
>>> use Benchmark qw(:all);
>>>
>>> $count = 100000;
>>> $a = zeroes(100);
>>> $results = timethese($count,
>>>             {
>>>             'slice' => sub { my $b = $a->slice("5:50"); },
>>>             'NiceSlice' => sub { my $b = $a(5:50); },
>>>             'nslice' => sub { my $b = $a->nslice([5,50]); },
>>>             },
>>>             'none'
>>>    );
>>> cmpthese( $results ) ;
>>>
>>>
>>>              Rate NiceSlice    nslice     slice
>>> NiceSlice  48544/s        --      -11%      -75%
>>> nslice     54348/s       12%        --      -72%
>>> slice     192308/s      296%      254%        --
>>>
>>> Also (a trivial thing) growing a piddle is very expensive,
>>> preallocating is much faster, but that is trivial. Perhaps worth of
>>> emphasizing in documentation.
>>>
>>> Cheers,
>>> Kaj

_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to