My assumption (and I could be wrong) is that whenever you do something that's ultimately CPU intense, perl dives into C code. The sort of stuff you do with perl tends to be a lot of string manipulation and it turns out perl is pretty hyper optimized for that sort of workload.

Other languages could do the same, but often they have a few more layers before they start running that C code.

I'd be curious to know if the perl grammar also somehow lends itself to being fairly optimizable for it's interpreter.

Perl does a kind of half JIT when you start a script. It doesn't compile fully down to native machine code, but it does parse and lex the script to build an internal representation. The code is then interpreted, but since it doesn't have to parse each line again it runs very fast and also you can interpret code on the fly in a variable so you get the best of both worlds.

This has been the usual way to implement interpreted languages for decades; Perl isn't special in that regard. JIT generally refers to generation and execution of native code specifically.

I'm pretty sure bash still interprets line by line because you can mess up a script by editing it while it is executing.

bash (and other shells) are special in that regard, because they use textual substitution so heavily - to pass arguments etc.

But Python, Ruby etc all compile to bytecode, and have always done so as far as I can remember.

> Afaik perl is a plain old interpreted language with no JIT, what makes it so fast?

IDK. I didn't waste time checking why.

My guess is that due to the much smaller code size, it reaches a sweetpoint where it fits nicely in the L1 or L2 cache.

But it's just a hunch, I couldn't prove it.

Perl likely spends a lot more time in C than a lot of other bytecode-compiled languages like Python.

  while(<STDIN>) {
   print $_;
  }

isn't doing much of its work at the top level.