Tons of numerics and lots of array lookups - the kind of job that lends itself well to C. That said, I see quite a bit of room in your Perl.

There's loads of pointless temporary variables and intermediate assignments. Why do @params = @_? Just use @_ directly, there's nothing special about it. List::Util is also likely to hugely speed up parts of your job. Your if/elsif chains are not helping either. The ccond() function f.ex should be written along these lines, using aforementioned module:

my @ccond =
    sub {
        $rddt[$_[0]] - sum(@rrdt[$_[0]-12 .. $_[0]-1]) / 12;
    },
    sub {
        $rddt[$_[0]] - sum(@rrdt[$_[0]-50 .. $_[0]-1) / 50;
    },
    sub {
        $rddt[$_[0]] - min(@rddt[$_[0]-5 .. $_[0]-1]);
    },
    # ...
);
[download]

    $cv = sprintf "%0.2f", $ccond[$cond]->($i);
[download]

That way, rather than rippling through the entire if/elsif cascade every time, the correct code block is selected in constant time. An analogous change applies to the other function.

Obviously, this approach will be much harder to translate into C. As you can see, properly Perlish code would also have been drastically shorter than your offering.

Will those practices let Perl beat the C version? Not likely. However, I'm fairly confident that given a capable Perl programmer, resorting to C will only be required very rarely. (And note that the min and sum functions from List::Util I used here are written in C. So in a way, you have outsourced your C rewriting to CPAN authors - not a bad deal IMO.)

Makeshifts last the longest.