The second piece of advice is to focus on structuring your code well rather than optimization. If you have organized your code well, then you are likely to wind up with more time to optimize, and your optimization effort can take advantage of the fact that you can profile your bottlenecks before you optimize. Good code pays off.
The third bit of advice is that Perl is an interpreted language. The more work you can shove down to Perl, the faster it will be. If you code Perl like it was C, you will run significantly slower than if you code Perl like it is Perl. For instance your loops would all be significantly faster if you wrote the as Perl-style foreach loops rather than C-style for loops. Your multiplication speed-ups are likely to wind up slower than the native simply because accessing a variable repeatedly is not free in Perl. And without measuring I would expect that for your task the array can be initialized more quickly with:
@ary = map init_val($_), 0..10_000;
Next, focus on algorithms. By learning to take advantage of things like native hashing to write efficient algorithms you can reliably find more scalable ways to write things. In C people tend to do a lot of scanning of arrays simply because complex data structures are so much work. Perl does not have that limit.
In many problems you can parallelize. There is a basic principle called the Pareto principle. You can achieve 80% of the gain for 20% of the work. That applies in general. But it is really true for parallelizing. If you have a job that will take 10 hours and you can break it into 5 pieces that can run on 5 machines, you will save yourself a lot of time. Making it a finely grained, multi-threaded beast is more likely to cost performance than gain it. (Threading improves latency, not throughput.)
And finally if you have a bottleneck, try rewriting it using Inline::C. (With which you can also inline assembler for true non-portability.) But only do this with identified bottlenecks when you absolutely need to. Odds are that if you try to rewrite your program at the first opportunity you will lose on speed simply because you do not have time to identify other optimizations, you do not have the freedom to play with algorithmic improvements, you will spend longer tracking down bugs, and you lose track of the point where your program is fast enough and you can move on.
And the very last point. If speed is of the essence and you are not dealing with a problem where Perl's RE engine is buying you a lot, then Perl probably isn't the right language to use. Use the right tool for the job, and for high performance that isn't Perl.
In reply to Re (tilly) 1: Optimizations and Efficiency
by tilly
in thread Optimizations and Efficiency
by dimmesdale
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |