use Perl

• different alghoritms (Score:1)

  by salva (841) on 2006.11.30 3:45 (#51981) Journal

  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 is not the fastest think anymore, I just didn't like the example!

  Reply to This

  • Re: (Score:1)

    by DAxelrod (4649)

    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
    • Re: (Score:1)

      by salva (841)

      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
      • Re: (Score:1)

        by DAxelrod (4649)

        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 pr
        • Re: (Score:1)

          by informatimago (7698)

          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.
  • Re: (Score:1)

    by DAxelrod (4649)

    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 is not the fastest think anymore, I just didn't like the example!

    Well, this is always the problem when making language comparisons. If we're just comparing compilers, then I agree that you'd want to compare performance of the exact same algorithm.

    A programming language, however, influences greatly how the programmer expresses themselves. It feels natural to write Lisp that writes Lisp. Writing C that writes C is much more difficult (despite that both languages are self-hosting). To compre languages based on the lowest common demoninator seems to devalue some of the mo