Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • For example, look at perl's highly fine-tuned regular expression engine written in C. CL-PCRE, a Perl-compatible regular expression library written in Lisp, claims to outperform perl's (when compiled with CMUCL).

    CL-PCRE is a compiler while perl regexp engine is an interpreter, so it's not the compiler, it's the algorithm what is faster!... though you can argue that writing portable compilers in C is almost imposible while in a high level lenguage like LISP it is trivial.

    Anyway, I agree with you that C i

    • I'm ignorant of CL-PCRE's internals, and (fairly) ignorant of perl's internals, but I'm not sure it comes down to a compiler vs an interpereter. It's about whether the intepereter is implemented directly in hardware.

      As I understand it, perl compiles a regex into its own intermediate (bytecode) representation, and then interperets the compiled regex.

      Unless CL-PCRE's compiler outputs native code that the processor can inteperet (I guess it could also output Lisp that CMUCL could compile into native code), I r
      • I guess it could also output Lisp that CMUCL could compile into native code

        exactly, that's how it works!

        In Lisp, you can extend the language using macros (functions that can manipulate the program structure at compile time) and writing a compiler is usually as simple as writing an interpreter.

        In that case, a regular expresion is expanded into a chunk of Lisp code that gets inlined and compiled with the rest of the program.

        Most Lisp hackers believe that macros are one of the most important features o

        • Aha. The more I thought about it, the more I thought this was probably the case.

          If the regular expression is known at compile time, I could see how this would lead to big savings.

          But what if the regular expression is not known until runtime? In that case, perl has to compile the regex and then interperet it while the program is running. Depending on how CMUCL implements eval, CL-PCRE would have to either: compile the regex into Lisp, then invoke CMUCL to compile into native code to be interpereted by the processor; OR do some sort of non-native interpretation anyway. I wonder if the double-compile is still a performance savings.
          • The lisp compiler is available at run time.

            It's true that EVAL may interpret (in implementations that have an interpreter), but if there is a compiler, you can call it and have the regular expressions compiled to native code at run time.

            The question is whether the application will need to execute the run-time defined regular expression more than once, to amortize the cost of the compilation done at run-time, or whether the regular expression will be applied to a text big enough.