On Thu, 24 May 2001, Lee Goddard wrote:
>
> From: Paris Sinclair [mailto:[EMAIL PROTECTED]]
>
> > On Thu, 24 May 2001, Lee Goddard wrote:
> >
> > > As to doing AI in Perl - you're really much better
> > > off starting in PROLOG, POP-11, or LISP (in order of
> > > my personal preference), and then transferring to a
> > > high-power language like C++ and (ha!) Java.
> > >
> > > Perl is, to my mind, for all of it's syntactic
> > > openness, far too slow for any AI projects involving
> > > standard techniques like Artificial Neural Networks
> > > or Genetic Algorithms.
> >
> > Perl is only slow when you use algorithms that were intended for PROLOG,
> > LISP, C/C++ or Java.
>
> Which most AI algorithms are, when not written in logic notation.
Which is why a Person should know a lot of Perl before using it for
AI... if you're going to use "traditional" algorithms, it is best to use
them in the languages they were written for.
Of course, this need for rethinking is probably a good thing, since AI
lags so far behind most areas of computing...
> > Correct Perl is usually just as fast. And sometimes faster... for example
> > the Schwartzian Transform is faster than standard C algorithms for the
> > same task, because it creates less temporary variables... certainly you
> > could write the same thing in C, as perl is written in C, but it would not
> > be easy and clear.
>
> Yep: if you can do it in Perl, you can do it in C, and as the compiled C
> is not interpreted, and can be better optimised, it's usually faster.
> Of course, Perl is much clearer, nicer to read, and the people are much
> more laid back (besides me and my triple espresso), but then how many
> ground-breaking AI apps are open source?!
>
> lee
Yes, if you write the algorithm the same, the C will be as fast or faster.
Of course you make your claim without addressing the Schwartzian Transform
example... there are other such examples out there too. But if you know
anything about Perl, you know that it is inaccurate to just say it's
"interpretted." It is in fact compiled into byte code, which doesn't
require much interpretation. Real life examples that compare _good_ Perl
to _good_ C generally show that they run about the same speed... the
partially interpretted aspect of Perl allows additional types of
optimization that are not possible in C, and the largely compiled aspect
allows for optimizations not generally possible in fully interpretted
languages. One of the reasons for this might be that because you can throw
up your code much quicker in Perl, Perl programmers are more likely to
throw out a few first attempts, and do more optimization. (I make this
conjecture because I've seen studies that show Perl programmers often end
up spending as much time on the program as a C coder would)
I've heard these speed claims before, but I've also seen benchmarks of
code from the wild to perform the same tasks in many languages, (it should
be easy to find examples with google) and C and Perl performed very close
to the same speed in nearly every one of these. (whereas Java keeps up
only on certain types of tasks, and VB lags no matter what you're doing)
Paris
