http://www.perlmonks.org?node_id=178512


in reply to Re: Re: Artificial Intelligence Programming in Perl
in thread Artificial Intelligence Programming in Perl

I don't think Perl's speed (as in execution time) is a major concern for most AI programming

Hmm, on this note I disagree. AI tends to be computationally expensive. AL (ie GA) even more so. Even a minor efficiency improvement can make a _big_ difference.

It's frequently noted that developer time is often far more valuable then execution time for other projects, why would AI programming be any different?

Well, this is true and not true. IME its true when the speed differences are marginal at best. Implementing an efficient algorithm in C and the same in Perl will most likely produce acceptable performance for the end product with much lower dev times. However with GA/AI/AL the same is not true. (Well, from what ive seen.) Lower development times are overwhelemed by extremely slow execution times.

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Replies are listed 'Best First'.
Re(4): Artificial Intelligence Programming in Perl
by cjf (Parson) on Jul 01, 2002 at 11:51 UTC

    I agree with your disagreement ;).

    As I'm learning more about the subject (link, link, link) I can see how execution time could be very important. I've also noticed that a lot of the AI projects/libraries out there tend to have a few very computationally expensive parts, and many not so expensive parts. Wouldn't such a case be perfect for a Perl-Inline::C combination?

    Or am I just showing my Perl bias?

      Perhaps, but don't forget that the Perl-XS barrier is an expensive one to cross. Every call from Perl to C and from C to Perl creates memory accesses and runs lots of code.

      I found this out firsthand working on a QuakeIII Perl API. During development I took a lot of shit from the QuakeIII people about how Perl would be too slow to write a QuakeIII bot (which is basically a simple AI project). I thought I could beat the system with a mix of Perl and XS. Well, I was wrong.

      -sam

      Or am I just showing my Perl bias?

      No I agree.

      Perl would be ideal for much of the framework. But the kernal (ykwim) needs to be as efficient as possible. Inline::C would seem to be an ideal compromise.

      Yves / DeMerphq
      ---
      Writing a good benchmark isnt as easy as it might look.