Try it out. Implement the entire site in Perl, then find out which parts are taking too long. Then see whether you can find a faster Perl solution (maybe PDL is suitable for your problem space) or whether you need to reimplement parts in another language. Embedding C finctions into a Perl module is documented well enough that it should be easily possible to change the number-crunching aspects of even a complex app from one to the other.
This gives you a working (albeit possibly too slow) solution in the minimum period of time, and you can improve the parts that need improving as you go. At worst (if for some unlikely reason it turns out you need to do the entire site in C or C++), the initial Perl solution is a good prototype. You always learn when you do something for the first time, and Perl is well suited for rapid prototyping.
| [reply]
[d/l] |
Just to amplify on what tirwhan said: Get the job done before making it faster. Often, you'll find that it'll be fast enough. When it isn't, you'll often find that:
- Adding CPU/RAM/DISK/whatever may be cheaper than coding time.
- Improving the algorithm may be enough to make the system fast enough without recoding in a new language.
- Your processing time may be dominated by I/O time, making the language you choose irrelevent.
Back in the old days, I often hand-optimized code in assembler or C to make it fast enough. Now I rarely find the need. I frequently do some serious processing on fairly large files, and the processing time is small compared to the I/O time. So it would be faster in my case to get faster boxes of disks rather than spend any time on updating algorithms, translation, etc.
...roboticus
| [reply] |
Maybe PDL is what you're looking for (all the relevant parts are implemented in C/XS).
Using pure Perl for number crunching is probably not a good idea (speed-wise).
| [reply] |
Although PDL is probably a better solution Inline C could work if you need to write some custom low level things PDL doesn't provide. This way you get the speed for critical sections and all your glue and higher level work can be in Perl. | [reply] |
Forth would be scary fast for this. Aside from the time to install and learn forth. | [reply] |
I cannot imagine what you are talking about here.
What kind of operations you'll be doing with these numbers that could take too much to get completed ?
Are those data preloaded into a database? or you'll be parsing some text files over and over to do the calculations?
Have you considered relying on the database engine (if you use one) to do the basic calculations to make things faster/smoother.
If you're going to make it in Perl then I'd like to get updated on this (Might give us an estimation on how far we could go with our Perl based solutions :P ).
| [reply] |
It's massive number crunching.
That's what God gave us FORTRAN for.
| [reply] |