Re: kurila 1.3 released

--- Scott Walters <scottslowass.net> wrote:

> On  0, Gerard Goossen <gerardtty.nl> wrote:
> > kurila 1.3 released
> > 
> > + Typed declarations (like C<my Animal
$dog>) are no longer
> possible
> 
> Just FYI, my typesafety.pm module used that.  I know I
could also
> support C<< my $x :type(foo) >>, but that's
too junky for pervasive
> use in a program.  Was this removed because it was easy
to remove?
> Or is that little feature actually prone to causing
grief and adding
> complexity to the core?

Unless I misunderstand Joshua, this could lead to a 1300%
speedup in
method calls because you can determine the type at compile
time and
make the dispatch faster.

  http://use.p
erl.org/~jjore/journal/34643

Cheers,
Ovid


--
Buy the book  - http://www.or
eilly.com/catalog/perlhks/
Perl and CGI  - http://u
sers.easystreet.com/ovid/cgi_course/
Personal blog - http://publiu
s-ovidius.livejournal.com/
Tech blog     - http://use.perl.or
g/~Ovid/journal/

On Oct 10, 2007, at 10:02 AM, Ovid wrote:

> Unless I misunderstand Joshua, this could lead to a
1300% speedup in
> method calls because you can determine the type at
compile time and
> make the dispatch faster.
>
>   http://use.p
erl.org/~jjore/journal/34643

You can't speed up 1300%.  What percentage do you really
mean?

--
Andy Lester => andypetdance.com => www.petdance.com =>
AIM:petdance

On Wed, Oct 10, 2007 at 08:02:16AM -0700, Ovid wrote:
> 
> --- Scott Walters <scottslowass.net> wrote:
> 
> > On  0, Gerard Goossen <gerardtty.nl> wrote:
> > > kurila 1.3 released
> > > 
> > > + Typed declarations (like C<my Animal
$dog>) are no longer
> > possible
> > 
> > Just FYI, my typesafety.pm module used that.  I
know I could also
> > support C<< my $x :type(foo) >>, but
that's too junky for pervasive
> > use in a program.  Was this removed because it was
easy to remove?
> > Or is that little feature actually prone to
causing grief and adding
> > complexity to the core?
> 
> Unless I misunderstand Joshua, this could lead to a
1300% speedup in
> method calls because you can determine the type at
compile time and
> make the dispatch faster.
> 
>   http://use.p
erl.org/~jjore/journal/34643
> 

Joshua did something different (the Ops package makes a
custom op).
Using a typed declaration provides only a minimal speedup:

          Rate perl  ops
perl 1578962/s   --  -3%
ops  1623590/s   3%   --

(using a default debian perl 5.8.8)


package Perl;
sub foo { _ == 2 ? $_[0][0] = $_[1] : $_[0][0] }

package get_test;
use Benchmark 'cmpthese';

my     $perl = bless [ '1' x 1<<20 ], 'Perl';
my Perl $ops  = bless [ '3' x 1<<20 ], 'Perl';

sub perl { $perl->foo }
sub ops  { $ops ->foo }

cmpthese( 0, {
    perl => &perl,
    ops  => &ops ,
} );

-- 
Gerard Goossen
TTY Internet Solutions

On  0, Ovid <publiustemp-p5p3yahoo.com> wrote:
> > On  0, Gerard Goossen <gerardtty.nl> wrote:
> > > kurila 1.3 released
> > > 
> > > + Typed declarations (like C<my Animal
$dog>) are no longer
> > possible
> > 
> > Just FYI, my typesafety.pm module used that.  I
know I could also
> 
> Unless I misunderstand Joshua, this could lead to a
1300% speedup in
> method calls because you can determine the type at
compile time and
> make the dispatch faster.
> 
>   http://use.p
erl.org/~jjore/journal/34643

Wow.  I hadn't seen that before.  Props to Joshua.  

Ovid, I was thinking of doing something similar.  Well, a
customer
had asked me to speed up their massive OO Perl app. 
Benchmarking
was done and the finger pointed squarely at the hundreds of

thousands of method calls done each hit, most of them to
tiny
methods.  So I had the idea of trying to inline the method
bodies
where they were used, hence Code::Splice.  I need to look at
it
more, but I think Joshua's approach is far superior.  I was
testing
with the type tag (my Dog $spot) but intended to eventually
do
full static analysis of the program to mechanically figure
out
where to do the optimization (due to the size of the
program).  Didn't
get to finish it.

Anyway, this kurila thing is bugging me.  I thought a fork
of Perl 5
to do some of the more radical rework was a brilliant idea. 
There
are often people in here suggesting core changes who are
turned away
with the Porters not wanting to maintain the patch or deal
with the
enusing breakage.  Moving both of those somewhere else but
letting
them exist would be fantastic.  But instead of people
experimenting
with Perl and taking it new directions (pardon my
forwardness) it
seems more like avenues are being cut off, and for little
reason.
This makes me sad.  It seems like the core could be made
less of
a mess just by cleaning up things in a way that breaks XS
modules
rather than just whacking the furtherest most appendages off
and
calling it "smaller".

Of course, whatever you do, there will be people who don't
agree
with the decsion, so I'm trying to argue my case in general
terms
rather than just in terms of a feature I've latched on to.

Anyway, with typesafety.pm, pro-actively warning about
demonstratably 
inconsistent code is my first priority there.  But I was
hoping to
connect the dots, so to speak, some day, and have it offer
to 
finalize/inline/whatever some day.

Cheers!
-scott

> Cheers,
> Ovid
> 
> 
> --
> Buy the book  - http://www.or
eilly.com/catalog/perlhks/
> Perl and CGI  - http://u
sers.easystreet.com/ovid/cgi_course/
> Personal blog - http://publiu
s-ovidius.livejournal.com/
> Tech blog     - http://use.perl.or
g/~Ovid/journal/