You've indeed hit a regression in Rakudo here. Let me explain it.

1/$_**2 produces a Rat object in Perl 6 if $_ is an integer (it is here). That is, it's a rational number that stores the numerator and denominator as integers. Thus $s is als a Rat, and the way that $s is built makes the denominator grow very fast.

Since newest Rakudo has bigint support, the integers can now grow larger than 64bit, and the growing size of the integers causes the O(nē) slowness you observed.

The specification says that once the denominator exceeds 2 ** 64 128, the arithmetic ops are supposed to fall back to floating point numbers to avoid such cases of pathological performance. Rakudo hasn't implemented that part yet, hence the regression.

If you use floating point numbers to begin with, you'll get:

$ time ./perl6 -e 'my $s; for 1..10000 {$s+=1e0/$_**2};say $s'
1.64483407184807
real    0m1.659s
user    0m1.360s
sys     0m0.200s
[download]

niecza correctly implements the fallback to floating point values, and yields the correct result (in 3s on a different machine of mine; it's usually slow to compile stuff, but faster at run time).

I've already started a branch to fix the Rat arithmetic issues (branch 'Rational' on github), and I'll try to make it work before the next Star release; I can't promise it though.

P.S. I'm sad to see that perlmonks is slowly becoming more like reddit, where problems are met with rancorousness instead of being discussed on a technical level.

UPDATE (2012-02-13): I've fixed Rakudo to fall back to Num if the denominator exceeds 2**64, so now you get:

$ time ./perl6 -e 'my $s; for 1..1000 {$s+=1/$_**2};say $s'
1.64393456668156

real    0m1.341s
user    0m1.240s
sys     0m0.096s
[download]

You can get this fix by using the latest development revision from git, or wait for the next release. Thanks again for your feedback.

Second update: when running up to 10_000 it takes 2.8s on my machine, so while still a big step away from perl 5 speed, it's faster than your previous measurements.