What will scientific computing in Perl 6 look like?

[vrk]

Dear fellow monks,

unfortunately I no longer have the amounts of free time I used to, so I cannot dig an answer to this question from mailing lists, FAQs, and other online resources. The question is also ambiguous, apologies. Simply put, what kinds of scientific computing will be easier in Perl 6 compared to Perl 5, and will it be possible to apply it to a wider range of number crunching?

Currently, if I were to spend hours and days of computer time on simulations, for instance, I would reach for PDL. But won't PDL be outdated and incompatible with Rakudo + Parrot? Or can one call external C and Fortran libraries from within Parrot? There may be further complications, but a more interesting question is, do any of the new language features obsolete PDL?

Premature optimization is the root of all evil, but since Perl 6 will have hyperoperators and junctions, would it not be possible to replace PDL's threading model with those? People hype about parallel processing, but efficiently looping over an array of a dozen million floating point numbers would be very nice indeed.

Perhaps the question is more about Parrot internals than Perl 6; will it ever be possible to tune the virtual machine to handle large arrays of numbers at "near-C" execution speed?

[moritz]

First of all there's currently a Google Summer of Code project in the run that implements a simple to use NCI (native call interface), to make it easier to call C functions from parrot.

Secondly please remember that Perl 6 is designed for the utmost amount of flexibility, so it's very easy to have a nice syntax for new features, like natural arithmetic operators for vector and matrix operations.

Perl 6 comes with low-level data types (like int32 and uint32) and arrays with pre-defined shapes (see S09 for more details, there's also a section on PDL support. In conjunction with the optional static type declaration there's no reason why native Perl 6 number crunching should be any slower than C.

So to summarize, from the specification point of view the future looks very bright. But currently speed isn't the primary concern, so I don't expect the first versions of Perl 6 to be very fast.

But there's much more room for optimization for Perl 6 than for Perl 5 - on the language level as well as on the VM level (for one thing parrot does JIT already, perl 5 doesn't, and is not likely to do in near future).

Update:

A few more thoughts on concurrency: Perl 6 avoids some pitfalls that made concurrency rather hard in Perl 5, like the huge number of global variables. Stuff that was global in Perl 5 (like $_, $!, $1, $2, ...) is now mostly solved with contextual variables (lexically scoped variables that may change their value in an outer block), and the language design was done from ground off with concurrency in mind (or at least in the back of TimToady's mind).

Implementations are free (and encouraged) to autothread meta operators, so this:

my @a1 = 1, 2, 3, 4, 5;
my @a2 = 9, 8, 7, 6, 5;
my @item_wise_sum = @a1 >>+<< @a2;
my $sum = [+] @item_wise_sum;

is likely to happen in parallel without the programmer even noticing.

By the way complex numbers are natively supported in Perl 6.

So I think that both in terms of speed and syntax Perl 6 will be an improvement over Perl 5 (in the realm of sci. computing at least; don't want to start the overall discussion again), but it still needs much work to get there.

[jettero]

By the way complex numbers are natively supported in Perl 6.

Can you construct arbitrary vector spaces (e.g., the quadratics) or are the complex numbers a special case?

UPDATE: I think abstract algebra starts at the undergrad level. Also, wow, perl6 is like a whole new language.

[moritz]

Complex numbers are special cased, in that they are explicitly specced. While numerics aren't a weak spot in Perl 6, they aren't exactly the most powerful area either (Larry keeps telling us on #perl6 that he doesn't do higher mathematics ;-)

But it's quite easy to define your own data types and the associated operations:

# suppose you inherit from List to implement your vector:
class MyVector is List {
    sub infix:<+>(MyVector @self, MyVector @other) is export {
         return @self »+« @other;
    }
    # adding a scalar:
    sub infix:<+>(MyVector @self, Num $other) is export {
        return @self »+ $other
    }
}

No more hassle of overloading literal constants in the source, since multi method dispatch takes care of it all.

[blazar]

Can you construct arbitrary vector spaces (e.g., the quadratics) or are the complex numbers a special case?

I personally believe that this is slightly nonsense, since vector spaces are "simply" vector spaces, while the complex numbers can be described in a variety of different algebraic structures: they're a field, a two dimensional real algebra, a one dimensional complex algebra, etc. Now, I'm sure that binary field operations will be supported for complex numbers: thus whether arbitrary vector spaces will be supported or not, it won't be a matter of "special case."