My best guess based on your breif description is that when you split your float data into the array, the C-version is performing the ascii-to-binary conversion once and the array iterated over is float *; or double * and all subsequent process of these numbers id performed on them in their binary form.

In the Perl version, the numbers are being maintained in the array in their ascii form, and each time any calculation with or comparison of them is done, perl has to perform the conversion to binary (though this step can be skipped if this scalar was use for numeric purposes previously I think as perl keeps a copy of the binary representation once a scalar has been used for math), do the math and then convert back to ascii representation and store.

The upshot is that every calculation between 2 floats, (ex. num1 *= num2; in the C version comes down to

load reg a, num1;  move 8 bytes from memory (probably cache)
; maybe 2 or 4 clock cycles barring stalls which given the 
;C array is probably contigious memory probably happens every 128K val
+ues 
;after the array is initially addressed depending on the size of the L
+1/L2 caches 
;and what else the surrounding code is doing

load reg b, num2; ditto

fmul reg a, regb; A Floating Point processor instruction
; Depending on the processor could be 1 to 10 or maybe 20 clock cycles

store reg a, num1; 8 bytes stored.
; Another 2/4 clock cycles.
[download]

maybe 30/40 clock cycles at most, and usually much less.

Whereas for Perl, the equivalent processor instructions involve

1. locating the base SV,
2. indexing that to find the XVPLV.
3. Locating, and possible performing ascii-binary conversion on the index var,
4. then using the value to calculate the offset into the storage pointed at by the XVPLV to
5. locate the SV pointing to the float element.
6. Loading the base of that SV,
7. checking to see if the NOK flag is set.
8. If it is load the previous binary value of this scalar.
9. If not, chase the XPVNV to the ascii representation.
10. Read the string byte by byte in a loop and perform the math to convert it to binary form.
11. Repeat from step 1 for the second variable.
12. Finally we have the two floats in binary form, but in (temporary?) storage not registers.
13. Perform the actual math using essentially the same steps as outlined above for the C version.
14. Now peform the reverse of the first 10 steps, twice, remembering we must always do the binary-to-ascii convertion on store as the next use of the variable may be as a string (eg. print), but that we also store both binary reps (which may save considerable time if the next use is numeric).
15. Do lots of flag checking/setting and other housekeeping.

I make no claims for the above being complete, correct or accurate in anyway whatsoever, but it gives a feel for whats involved

As you can see, the process of adding two floats held in an array in perl is considerably more involved than in C and takes in the order of 100's if not low 1000's of clock cycles, as opposed to 10's in C. That's the price you pay for Perl's infinitely simpler and more flexible type-polymorphism, DWIMery and transparent housekeeping.

It makes me wonder if Perl 6 couldn't reverse the magic used by Perl 5 as far as numbers are concerned. That is to say, once a value has been used as a number, if the ascii representation of that var couldn't be flagged as 'dirty' and not maintained until such times as an attempt is made to use it's contents in a non-numeric capacity. Ie. As well as the IOK and NOK flags, have a AOK flag, allowing the ascii representation not to be updated until necessary?

That said, in the above sequence, it's the pointer chasing and flag waving required by perls infinitly flexible array representation that makes the biggest difference beween it and the C-float array process, so it probably wouldn't make a whole heap of difference.

The upshot is, that if you want to do math intensive programming, use a language that lends itself to that, or find a module that allows you to hand over the storage and processesing of numeric data to a library written in such a language.

It would be nice to thing that our favorite language could be extended in its upcoming 'new' form to allow us to gives clues when we declare vars as to their most prevelent usage and that it could transparently (and without too much overhead) allocate, store and manipulate them ways more efficient to that usage, whilst retaining the DWIMery and flexibility of the standard Perl data representations. (You have no idea how hard it was to write that sentance without mentioning types :). I'm sort of thinking about the perl 6 attributes here.