very true - as is the case with any code that is ported around I suppose.
I can say that the code looks nearly identical between the two - where it differs is in built in methods.
In Perl, if I want to split an array, I call split - in C I call strsep. The way I personally do the split in Perl, I then go directly to the spot (2 spots actually) that I want in the array and use them. In C, I iterate over the strsep calls. So it gets the same end result, but there are different things going on - so yes, there are going to be different results in how efficient each is at doing it.
Perl allows me to write it all extremely quickly because I don't have to constantly worry about the type checking like I do in C - but that also slows Perl down.
I'm iterating over 1000+ trading days, and that iteration is done over 3000 times. Aside from the counters that are incremented in loops, all the math is easy floating point math - all things that I think C is just better suited for. Perl is very good at many things - but especially dealing with Strings. For this, once I have the data loaded in from a file, the only other time it deals with a string is when it is keeping track of its ideal algorithm.
but yes, you are right in that the Perl code might have opportunities for optimization - but the same goes for the C code. I know Perl much better than I know C - so I would imagine that someone that knows C very well could make it even faster. But whether I can run through 2000 stocks in 20mins or an hour on a single machine doesn't matter for me since I will be clustering them and will get it well below that anyway.
Perl does what it is great at, dealing with strings - I use it to get all of the data and to update data once I have analyzed it.
Since I work with it frequently, I find that it is great for getting a rough draft of a program done so that it is funcitonal, and then from there I can see what speed increases I need, if any. If I don't need any - leave it in Perl. If I need some, but I really need the ease of String manipulation, then look to Java (but that currently isn't an option in clustering - should be within a year or two though). And then if that still isn't fast enough, C.
Obviously it varies as to what the task at hand is. | [reply] |