RE: [hackers-il] Optimizing Perl (et al.) code by converting it t o C
> -----Original Message-----The point of that article was stating that Perl built-in functions are
> From: Shlomi Fish [mailto:shlomif@...]
> Sent: Monday, October 22, 2001 9:39 AM
> To: Hackers-IL
> Subject: [hackers-il] Optimizing Perl (et al.) code by
> converting it to
> I took a look at the discussion I originally conducted in use.perl.org
> regarding Perl as a beginners language, and remembered it eventually
> diverted into a related topic.
> Apparently, some people there claimed that I will usually not gain
> speed by converting my perl code to C, while I maintained
> that for some
> programs, this is indeed the case:
> For the record, Mark Jason Dominus, a very dominant figure in the Perl
> world, wrote an article just about it to perl.com, where he
> made the claim
> that converting the program to C will usually make little difference:
are already optimized for best performance possible for generic
solutions for class of problems.
However, it is not clear to me that it is impossible to achieve better
performance in C while solving specific problems.
>Why is compiling or JIT is cheating, exactly? Nor run_time compiling
> I agree that there are many Perlish programs whose equivalent
> C code will
> not run substiantially faster. However, I do think that in
> some cases, it
> Such a case, can be a code that contains a lot of loops or otherwise
> intensive computations. My "Freecell Solver" program is such
> an example,
> because I sometimes nest loops and conditionals to very large extents.
> I encountered a similar case with Matlab. In Matlab, Matrix
> operations are
> hard-coded in C and are therefore fast, but loops are slow. Those, who
> write their programs using loops find they run incredibly slow. Matlab
> fails when one has to write an iterative process in which
> every result is
> dependant on the results of the previous iterations. In that
> case, I have
> not yet found a way to avoid loops, but then again, I'm not entirely
> proficient in Matlab.
> I think any properly designed language that is destined to be
> should make some things fast to perform and some things
> should be left to
> hard-coded extensions. While some interpereted languages now aim to
> incorporate C extensions that will make them suitable for a
> wider variety
> of tasks, I still think C will always have an edge.
> As the title implies this also concerns other languages such
> as Python,
> Ruby, PHP, Pike, whatever. And compiling or JIT compilation
> is cheating.
( in sence of inserting compiling between "READ" and "EVAL" parts of REP ),
neither JIT change the interpreted nature of a language, IMHO.
> Shlomi Fish